Pertanyaan bagus, atau setidaknya satu dengan jawaban yang menarik. Bagian dari jawaban ini menggambarkan dunia di mana CPU dapat mengukur lebar secara efisien daripada dengan beberapa inti terpisah. Model lisensi / harga akan berbeda!
Sisanya menjelaskan mengapa mereka tidak bisa. Ringkasan:
- Biaya skala inti ganda mendekati linier
- Biaya untuk memperluas skala pipa superscalar 1 inti ~ secara kuadrat Hal ini dapat dilakukan dengan kekuatan yang cukup, sampai titik tertentu. Kinerja single-threaded sangat penting untuk penggunaan interaktif (masalah latensi end-to-end, bukan hanya throughput), sehingga CPU high-end big-core saat ini membayar harga itu. mis. Skylake (4-lebar), Ryzen (5 atau 6-lebar), dan A12 Apple (7-lebar untuk core besar, 3-lebar untuk core hemat energi kecil)
- Pengembalian IPC yang serius dan berkurang hanya dari pelebaran pipa di atas lebar 3 atau 4, bahkan dengan eksekusi out-of-order untuk menemukan ILP . Branch miss dan cache missses sulit, dan masih menghentikan seluruh pipa.
Anda tidak menyebutkan frekuensi, hanya IPC, tetapi frekuensi penskalaan juga sulit. Frekuensi yang lebih tinggi membutuhkan tegangan yang lebih tinggi, sehingga skala daya dengan frekuensi potong dadu : ^1
dari frekuensi secara langsung, dan ^2
dari tegangan. (Timbangan energi tersimpan kapasitor dengan V ^ 2, dan sebagian besar daya dinamis di luar arus bocor adalah dari memompa muatan ke beban kapasitif gerbang + kabel FET.)
Kinerja = frekuensi kali IPC. (Dalam arsitektur yang sama. SIMD yang lebih luas memungkinkan Anda menyelesaikan pekerjaan yang sama dengan instruksi yang lebih sedikit, dan beberapa ISA lebih padat daripada yang lain, misalnya MIPS sering membutuhkan lebih banyak instruksi untuk melakukan pekerjaan yang sama daripada x86 atau AArch64.)
Biaya berada di area mati (biaya produksi) dan / atau daya (yang secara tidak langsung membatasi frekuensi karena pendinginan sulit). Selain itu, daya dan kinerja per Watt yang lebih rendah adalah tujuan itu sendiri, terutama untuk seluler (baterai) dan server (kepadatan daya / biaya pendinginan / biaya listrik).
Sebelum multi-core per socket adalah suatu hal, Anda memang memiliki sistem multi-socket untuk kasus penggunaan kelas atas di mana Anda menginginkan lebih banyak throughput daripada yang dapat dicapai dengan satu CPU yang dapat diproduksi, jadi itu adalah satu-satunya sistem SMP. (Server, stasiun kerja kelas atas).
Jika satu inti dapat menskala seefisien yang Anda inginkan, kami akan memiliki sistem dengan 1 inti fisik per soket, dan SMT (mis. HyperThreading) untuk memungkinkannya bertindak sebagai beberapa inti logis. Desktop / laptop biasa hanya akan memiliki 1 inti fisik, dan kami tidak akan kesulitan untuk memaralelkan hal-hal yang tidak skala secara linear dengan lebih banyak core. misalnya make -j4
untuk memanfaatkan server multi-socket, dan / atau untuk menyembunyikan latensi I / O pada desktop. (Atau mungkin kita masih akan mencoba untuk memparalelkan banyak jika lebar pipa dengan mudah diskalakan tetapi IPC tidak, jadi kami harus menggunakan lebih banyak benang SMT.) Kernel OS Anda masih perlu dijalankan di semua inti logis, kecuali cara CPU menyajikan SMT ke OS sangat berbeda, sehingga algoritma penjadwalan paralel dan penguncian masih akan diperlukan di sana.
Donald Knuth mengatakan dalam sebuah wawancara tahun 2008
Saya mungkin juga sedikit bercerita tentang ketidakbahagiaan pribadi saya dengan tren saat ini terhadap arsitektur multicore. Bagi saya, ini kurang lebih seperti para perancang perangkat keras kehabisan ide, dan mereka sedang berusaha menyalahkan kesalahan Hukum Moore di masa depan kepada para penulis perangkat lunak dengan memberi kami mesin yang bekerja lebih cepat hanya pada beberapa tolok ukur kunci!
Ya, jika kita dapat memiliki keajaiban single-core CPU dengan 8x throughput pada program nyata , kita mungkin masih akan menggunakannya. Dengan sistem dual socket hanya ketika itu layak membayar lebih banyak untuk throughput lebih (bukan kinerja single-threaded).
Banyak CPU mengurangi biaya pengalih-konteks ketika banyak program berjalan (dengan membiarkannya benar-benar berjalan secara paralel alih-alih beralih cepat di antaranya); multitasking pre-emptive mengganggu mesin out-of-order besar seperti CPU akan membutuhkan mungkin akan lebih menyakitkan daripada yang sekarang.
Secara fisik itu akan menjadi single core (untuk hierarki cache sederhana tanpa ada interkoneksi antar core) tetapi mendukung SMT (mis. Intel HyperThreading) sehingga perangkat lunak dapat menggunakannya sebagai 8 core logis yang secara dinamis bersaing untuk sumber daya throughput. Atau ketika hanya 1 utas yang berjalan / tidak terhenti, itu akan mendapat manfaat penuh.
Jadi, Anda akan menggunakan banyak utas saat itu sebenarnya lebih mudah / alami (mis. Proses terpisah berjalan bersamaan), atau untuk masalah yang mudah diparalelkan dengan rantai ketergantungan yang akan mencegah memaksimalkan IPC binatang ini.
Namun sayangnya itu adalah angan-angan Knuth bahwa CPU multi-core akan berhenti menjadi sesuatu pada saat ini.
Penskalaan kinerja satu utas
Saya pikir jika mereka membuat 1 core yang setara dengan CPU 8 core, bahwa satu core akan memiliki peningkatan IPC 800% sehingga Anda akan mendapatkan kinerja penuh di semua program, bukan hanya yang dioptimalkan untuk banyak core.
Ya itu benar. Jika mungkin untuk membangun CPU seperti itu sama sekali, itu akan sangat luar biasa. Tapi saya pikir itu benar - benar mustahil pada proses pembuatan semikonduktor yang sama (yaitu kualitas / efisiensi yang sama dari transistor). Ini tentu saja tidak mungkin dengan anggaran daya yang sama dan area mati sebagai CPU 8-core, meskipun Anda akan menghemat logika untuk merekatkan core bersama, dan tidak akan membutuhkan banyak ruang untuk cache pribadi per-core.
Bahkan jika Anda mengizinkan peningkatan frekuensi (karena kriteria sebenarnya adalah bekerja per detik, bukan bekerja per jam), membuat CPU yang 2x lebih cepat akan menjadi tantangan besar.
Jika mungkin di mana saja di dekat daya yang sama dan anggaran die-area (sehingga biaya produksi) untuk membangun CPU seperti itu, ya vendor CPU sudah akan membangun mereka seperti itu.
Secara khusus, Lebih Banyak Core atau Core Lebih Luas? bagian, untuk latar belakang yang diperlukan untuk memahami jawaban ini; itu mulai sederhana dengan cara kerja pipelined CPU, kemudian superscalar (beberapa instruksi per jam). Kemudian menjelaskan bagaimana kita menabrak dinding daya di sekitar era P4, yang mengarah ke akhir penskalaan frekuensi yang mudah, menyisakan sebagian besar hanya IPC dan menyelesaikan lebih banyak pekerjaan per instruksi (misalnya SIMD) sebagai jalur maju, bahkan dengan transistor yang lebih kecil.
Membuat saluran pipa lebih lebar (instruksi maksimal per jam) biasanya menimbang biaya dengan lebar kuadrat . Biaya tersebut diukur dalam area die dan / atau daya, untuk pengecekan dependensi paralel yang lebih luas (deteksi bahaya), dan penjadwal out-of-order yang lebih luas untuk menemukan instruksi siap untuk dijalankan. Dan lebih banyak port baca / tulis pada file register dan cache Anda jika Anda ingin menjalankan instruksi selain nop
. Terutama jika Anda memiliki instruksi 3-input seperti FMA atau add-with-carry (2 register + flag).
Ada juga berkurangnya pengembalian IPC untuk membuat CPU lebih luas ; sebagian besar beban kerja telah membatasi skala kecil / jarak pendek ILP (Instruction-Level Parallelism) untuk dieksploitasi oleh CPU, sehingga membuat core lebih luas tidak meningkatkan IPC (instruksi per jam) jika IPC sudah dibatasi kurang dari lebar inti oleh rantai ketergantungan, kehilangan cabang, ketinggalan cache, atau warung lainnya. Tentu Anda akan mendapatkan speedup di beberapa loop terbuka dengan iterasi independen, tapi bukan itu yang dilakukan sebagian besar kode. Bandingkan / instruksi cabang membuat 20% dari campuran instruksi dalam kode "khas", IIRC. (Saya pikir saya sudah membaca angka dari 15 hingga 25% untuk berbagai set data.)
Juga, cache ketinggalan yang menghentikan semua instruksi yang bergantung (dan kemudian semuanya begitu kapasitas ROB tercapai) lebih mahal untuk CPU yang lebih luas. (Biaya peluang meninggalkan lebih banyak unit eksekusi; lebih banyak pekerjaan potensial yang tidak dilakukan.) Atau kehilangan cabang juga menyebabkan gelembung.
Untuk mendapatkan IPC 8x, kami membutuhkan setidaknya 8x peningkatan dalam akurasi prediksi cabang dan tingkat hit cache . Tetapi cache hit rate tidak dapat diukur dengan baik dengan kapasitas cache melewati titik tertentu untuk sebagian besar beban kerja. Dan HW prefetching cerdas, tetapi tidak bisa yang pintar. Dan pada 8x IPC, prediktor cabang perlu menghasilkan 8x lebih banyak prediksi per siklus serta membuatnya lebih akurat.
Teknik saat ini untuk membangun eksekusi CPU yang tidak sesuai pesanan hanya dapat menemukan ILP dari jarak dekat . Misalnya, ukuran ROB Skylake adalah 224 domain-leburan uops, penjadwal untuk u-non-eksekusi adalah 97 domain-tidak-terpakai. Lihat Memahami dampak lfence pada loop dengan dua rantai ketergantungan panjang, untuk meningkatkan panjang untuk kasus di mana ukuran penjadwal adalah faktor pembatas dalam mengekstraksi ILP dari 2 rantai instruksi yang panjang, jika terlalu panjang. Dan / atau lihat ini jawaban yang lebih umum dan pengantar ).
Jadi menemukan ILP antara dua loop panjang yang terpisah bukanlah sesuatu yang bisa kita lakukan dengan perangkat keras. Rekompilasi biner dinamis untuk fusi loop dapat dimungkinkan dalam beberapa kasus, tetapi sulit dan bukan sesuatu yang benar-benar dapat dilakukan CPU kecuali mereka menggunakan rute Transmeta Crusoe. (Lapisan emulasi x86 di atas ISA internal yang berbeda; dalam hal ini VLIW). Tetapi desain x86 modern standar dengan cache uop dan decoder yang kuat tidak mudah dikalahkan untuk sebagian besar kode.
Dan di luar x86, semua ISA masih digunakan relatif mudah untuk memecahkan kode, sehingga tidak ada motivasi untuk kompilasi dinamis selain optimasi jarak jauh. TL: DR: berharap untuk kompiler ajaib yang dapat mengekspos lebih banyak ILP ke perangkat keras tidak berfungsi untuk Itanium IA-64 , dan tidak mungkin bekerja untuk CPU super-lebar untuk setiap ISA yang ada dengan model serial eksekusi.
Jika Anda memang memiliki CPU super-lebar, Anda pasti ingin itu mendukung SMT sehingga Anda dapat membuatnya tetap bekerja dengan menjalankan beberapa utas rendah-ILP.
Karena Skylake saat ini lebar 4 uops (dan mencapai IPC nyata 2 hingga 3 uops per jam, atau bahkan lebih dekat dengan 4 dalam kode throughput tinggi), CPU 8x yang lebih lebar secara hipotetis akan berukuran 32-lebar!
Mampu mengukir itu kembali ke 8 atau 16 CPU logis yang secara dinamis berbagi sumber daya eksekusi akan fantastis: utas yang tidak macet mendapatkan semua bandwidth front-end dan throughput back-end.
Tetapi dengan 8 core yang terpisah, ketika sebuah thread berhenti, tidak ada lagi yang bisa membuat unit eksekusi diberi makan; utas lainnya tidak mendapat manfaat.
Eksekusi sering meledak-ledak: ia berhenti menunggu cache gagal dimuat, lalu begitu yang tiba banyak instruksi secara paralel dapat menggunakan hasil itu. Dengan CPU super-lebar, burst itu bisa lebih cepat, dan sebenarnya bisa membantu dengan SMT.
Tetapi kita tidak dapat memiliki CPU super lebar ajaib
Jadi untuk mendapatkan throughput kita malah harus mengekspos paralelisme ke perangkat keras dalam bentuk paralelisme tingkat-benang . Umumnya kompiler tidak pandai mengetahui kapan / bagaimana menggunakan utas, selain untuk kasus sederhana seperti loop yang sangat besar. (OpenMP, atau gcc -ftree-parallelize-loops
). Masih dibutuhkan kepintaran manusia untuk mengolah kode agar dapat secara efisien menyelesaikan pekerjaan yang berguna secara paralel, karena komunikasi antar-thread mahal, dan begitu juga utas startup.
TLP adalah paralelisme berbutir kasar, tidak seperti ILP berbutir halus dalam satu utas eksekusi yang dapat dieksploitasi oleh HW.
CPU yang ditujukan untuk beban kerja interaktif (seperti Intel / AMD x86, dan core high-end Apple / ARM AArch64) pasti mendorong penurunan hasil penskalaan IPC, karena kinerja single-threaded masih sangat berharga ketika latensi penting, bukan hanya throughput untuk masalah paralel masif.
Mampu menjalankan 8 salinan game secara paralel pada 15fps masing-masing jauh lebih berharga daripada mampu menjalankan satu salinan pada 45fps. Vendor CPU mengetahui hal ini, dan itulah sebabnya CPU modern menggunakan eksekusi out-of-order meskipun biayanya besar dan mati. (Tetapi GPU tidak karena beban kerjanya paralel secara masif).
Perangkat keras banyak-inti Intel Xeon Phi (Knight's Landing / Knight's Mill) adalah titik setengah jalan yang menarik: eksekusi out-of-order yang sangat terbatas dan SMT untuk menjaga core 2-lebar yang diberi instruksi AVX512 SIMD untuk mengolah angka. Inti didasarkan pada arsitektur Silvermont berdaya rendah Intel. (Ex-of-order eksekutif tetapi dengan jendela menata ulang kecil, jauh lebih kecil dari keluarga inti Sandybridge. Dan pipa yang lebih sempit.)
BTW, semua ini ortogonal ke SIMD. Mengerjakan lebih banyak pekerjaan per instruksi selalu membantu, jika memungkinkan untuk masalah Anda.
Model harga
Model penentuan harga perangkat lunak didasarkan pada lanskap perangkat keras terkini.
Model lisensi per-inti menjadi lebih luas (dan relevan bahkan untuk desktop soket tunggal) dengan munculnya CPU multi-core. Sebelum itu, itu hanya relevan untuk server dan workstation besar.
Jika perangkat lunak tidak memerlukan banyak inti untuk berjalan dengan kecepatan tinggi, tidak akan ada cara untuk menjualnya lebih murah kepada orang-orang yang tidak mendapatkan banyak manfaat karena mereka menjalankannya pada CPU yang lebih lemah. Kecuali jika mungkin ekosistem perangkat lunak / perangkat keras mengembangkan kontrol pada "saluran SMT" yang memungkinkan Anda mengkonfigurasi lebar eksekusi maksimum untuk kode yang berjalan pada inti logis itu. (Sekali lagi membayangkan dunia di mana skala CPU dalam lebar pipa, bukan beberapa core terpisah.)