Cukup jelas dari survei top500 bahwa industri ini cenderung meningkat secara eksponensial dalam core pemrosesan . Superkomputer terbesar semua menggunakan MPI untuk komunikasi antar node, meskipun tampaknya tidak ada tren yang jelas untuk paralelisme on-node, dengan pendekatan yang paling sederhana (tetapi tidak harus paling efisien) untuk memetakan proses MPI tunggal untuk setiap inti, otomatis paralelisasi dari kompiler, OpenMP, pthreads, CUDA, Cilk, dan OpenCL.
Saya adalah salah satu dari sekelompok ilmuwan yang memelihara dan mengembangkan kode yang berpotensi untuk digunakan pada beberapa superkomputer terbesar di dunia. Dengan asumsi waktu pengembang yang terbatas, bagaimana saya bisa membuktikan diri di masa depan sehingga saya dapat memanfaatkan kinerja mesin paling kuat di dunia? Asumsi apa yang harus saya buat tentang arsitektur proses interkoneksi? Paradigma apa yang akan diderita ketika kita memasuki era manycore? Apakah bahasa Ruang Alamat Global yang dipartisi akan tersedia "dalam produksi" pada mesin petascale?
sumber
Jawaban:
Perspektif Sejarah
Sangat tidak mungkin mengatakan seperti apa paradigma baru di masa depan, misalnya perspektif sejarah yang baik yang saya sarankan untuk membaca Ken Kennedy's Rise and Fall of HPF . Kennedy memberikan laporan tentang dua pola yang muncul, MPI versus kompiler pintar, dan merinci bagaimana MPI memiliki jumlah pengguna awal yang tepat dan fleksibilitas untuk mendominasi. HPF akhirnya memperbaiki masalahnya tetapi sudah terlambat.
Dalam banyak hal, beberapa paradigma, seperti PGAS dan OpenMP, mengikuti tren HPF yang sama. Kode awal belum cukup fleksibel untuk digunakan dengan baik dan meninggalkan banyak kinerja di atas meja. Tetapi janji untuk tidak harus menulis setiap sedikitpun dari algoritma paralel adalah tujuan yang menarik. Jadi pengejaran model baru selalu dikejar.
Hapus Tren di Perangkat Keras
Sekarang keberhasilan MPI sering dikutip karena terkait erat dengan bagaimana memodelkan perangkat keras yang digunakannya. Secara kasar setiap node memiliki beberapa proses dan meneruskan pesan ke point-to-point lokal atau melalui operasi kolektif terkoordinasi dengan mudah dilakukan di ruang cluster. Karena itu, saya tidak percaya siapa pun yang memberikan paradigma yang tidak mengikuti tren perangkat keras baru, saya benar-benar yakin dengan pendapat ini dari karya Vivak Sarakar .
Sesuai dengan itu di sini adalah tiga tren yang jelas membuat kemajuan dalam arsitektur baru. Dan saya jelaskan, sekarang ada dua belas arsitektur berbeda yang dipasarkan di HPC. Ini naik dari kurang dari 5 tahun yang lalu hanya menampilkan x86, sehingga beberapa hari mendatang akan melihat banyak peluang untuk menggunakan perangkat keras dengan cara yang berbeda dan menarik
Model saat ini
Model saat ini sebenarnya dalam 3 level. Meskipun ada banyak kode yang menggunakan dua level ini dengan baik, tidak banyak yang muncul menggunakan ketiganya. Saya percaya bahwa untuk pertama-tama mencapai exascale, seseorang perlu berinvestasi dalam menentukan apakah kode Anda dapat dijalankan pada ketiga level. Ini mungkin jalan paling aman untuk beralih dengan baik dengan tren saat ini.
Biarkan saya beralih pada model dan bagaimana mereka perlu berubah berdasarkan pada perkiraan perangkat keras baru.
Didistribusikan
Para pemain di tingkat terdistribusi sebagian besar jatuh ke bahasa MPI dan PGAS. MPI adalah pemenang yang jelas saat ini, tetapi bahasa PGAS seperti UPC dan Chapel sedang menuju kemajuan. Salah satu indikasi yang baik adalah Tantangan Benchmark HPC. Bahasa PGAS memberikan implementasi tolok ukur yang sangat elegan.
Poin paling menarik di sini adalah bahwa sementara model ini saat ini hanya berfungsi pada level node, itu akan menjadi model penting di dalam node untuk arsitektur Tiled. Salah satu indikasi adalah chip Intel SCC, yang secara fundamental bertindak seperti sistem terdistribusi. Tim SCC menciptakan implementasi MPI mereka sendiri dan banyak tim yang berhasil memindahkan perpustakaan komunitas ke arsitektur ini.
Tapi jujur saja, PGAS benar-benar punya cerita bagus untuk masuk ke ruang ini. Apakah Anda benar-benar ingin memprogram MPI internode dan kemudian harus melakukan trik intranode yang sama? Satu masalah besar dengan arsitektur ubin ini adalah bahwa mereka akan memiliki kecepatan clock yang berbeda pada chip dan perbedaan besar dalam bandwidth ke memori sehingga kode pemain harus mempertimbangkan ini.
Memori bersama on-node
Di sini kita melihat MPI sering "cukup baik", tetapi PThreads (dan perpustakaan yang berasal dari PThreads seperti Intel Parallel Building Blocks) dan OpenMP masih sering digunakan. Pandangan umum adalah bahwa akan ada waktu di mana ada cukup memori bersama thread yang model soket MPI akan rusak untuk RPC atau Anda membutuhkan proses yang lebih ringan berjalan pada inti. Anda sudah dapat melihat indikasi sistem IBM Bluegene mengalami masalah dengan MPI memori bersama.
Seperti komentar Matt, peningkatan kinerja terbesar untuk kode intensif komputasi adalah vektorisasi kode serial. Sementara banyak orang menganggap ini benar dalam akselerator, itu juga penting untuk mesin on-node juga. Saya percaya Westmere memiliki 4 FPU lebar, jadi kita hanya bisa mendapatkan seperempat dari flops tanpa vektorisasi.
Sementara saya tidak melihat OpenMP saat ini melangkah ke ruang ini dengan baik, ada tempat untuk chip bertenaga rendah atau ubin untuk menggunakan lebih banyak utas yang ringan. OpenMP memiliki kesulitan menggambarkan bagaimana aliran data bekerja dan karena lebih banyak utas digunakan, saya hanya melihat tren ini menjadi lebih berlebihan, lihat saja contoh-contoh apa yang harus dilakukan untuk mendapatkan prefetching yang tepat dengan OpenMP.
OpenMP dan PThread pada tingkat yang cukup dapat mengambil keuntungan dari vektorisasi yang diperlukan untuk mendapatkan persentase puncak yang baik, tetapi melakukan hal itu membutuhkan penguraian algoritma Anda sedemikian rupa sehingga vektorisasi itu alami.
Prosesor bersama
Akhirnya kemunculan co-prosesor (GPU, MIC, Cell acclerators) telah berlangsung. Menjadi jelas bahwa tidak ada jalan menuju exascale akan lengkap tanpa mereka. Di SC11, setiap kontestan hadiah Bell menggunakannya dengan sangat efektif untuk mencapai petaflops rendah. Sementara CUDA dan OpenCL telah mendominasi pasar saat ini, saya memiliki harapan untuk kompiler OpenACC dan PGAS memasuki ruang.
Sekarang untuk mencapai exascale, satu proposal adalah memasangkan chip bertenaga rendah ke banyak co-prosesor. Ini akan cukup mematikan lapisan tengah tumpukan saat ini dan menggunakan kode yang mengelola masalah keputusan pada chip utama dan mengalihkan pekerjaan ke co-prosesor. Ini berarti bahwa agar kode berfungsi cukup efektif seseorang harus memikirkan kembali algoritma dalam hal kernel (atau codelet), yaitu potongan paralel tingkat instruksi tanpa cabang. Sejauh yang saya tahu, solusi untuk evolusi ini cukup terbuka lebar.
Bagaimana ini memengaruhi pengembang aplikasi
Sekarang untuk menjawab pertanyaan Anda. Jika Anda ingin melindungi diri dari kerumitan mesin exascale yang akan datang, Anda harus melakukan beberapa hal:
Jika Anda ingin menjadi pemain hari ini, MPI + CUDA / OpenCL sudah cukup baik tetapi UPC sedang menuju ke sana sehingga bukan ide yang buruk untuk mengambil beberapa hari dan mempelajarinya. OpenMP membantu Anda memulai tetapi mengarah ke masalah begitu kode perlu di refactored. PThreads membutuhkan penulisan ulang kode Anda sepenuhnya sesuai gayanya. Yang menjadikan MPI + CUDA / OpenCL model terbaik saat ini.
Apa yang tidak dibahas di sini
Sementara semua pembicaraan tentang exascale ini bagus, sesuatu yang tidak benar-benar dibahas di sini adalah mendapatkan dan mematikan data dari mesin. Meskipun ada banyak kemajuan dalam sistem memori, kami tidak melihatnya di cluster komoditas (terlalu mahal). Sekarang komputasi intensif data menjadi fokus besar dari semua konferensi komputasi super, pasti akan ada pergerakan yang lebih besar ke ruang bandwidth memori yang tinggi.
Ini membawa ke tren lain yang mungkin terjadi (jika agen pendanaan yang tepat terlibat). Mesin akan menjadi semakin khusus untuk jenis komputasi yang dibutuhkan. Kita sudah melihat mesin "data-intensif" didanai oleh NSF, tetapi mesin ini berada di jalur yang berbeda dari 2019 Exascale Grand Challenge.
Ini menjadi lebih lama dari yang diharapkan, minta referensi di mana Anda membutuhkannya di komentar
sumber
Mari kita mulai dengan membahas strategi untuk kode intranode (komputasi yang tidak menyentuh interkoneksi), karena saya pikir MPI adalah pilihan yang baik untuk kode internode. Saya pikir tidak masuk akal untuk berbicara tentang node dengan kurang dari 100 core, jadi setidaknya GPU atau MIC saat ini.
Ini fakta bahwa pthreads saja tidak dapat membuat Anda mendapatkan kinerja maksimum pada setiap chip modern, karena Anda harus mengambil keuntungan dari unit vektor (benar sejak Cray pertama). Pada Intel dan AMD Anda dapat menggunakan intrinsik, tetapi ini tidak portabel, dan menurut saya kikuk. CUDA dan OpenCL memiliki vektorisasi yang dibangun ke dalam perpustakaan dan membuatnya mudah untuk mendapatkan kinerja maksimal. Semua perangkat keras baru yang saya ketahui memiliki persyaratan vektor ini, jadi solusi apa pun harus mempertimbangkan hal ini. Bagi saya, CUDA / OpenCL adalah cara saat ini untuk pergi.
Selanjutnya, semua mesin ini akan menjadi NUMA, yang lebih sulit untuk diprogram, tetapi saya pikir strategi kernel berfungsi. Anda membagi pekerjaan dan data menjadi unit-unit kecil. Ini mungkin akan dijadwalkan secara otomatis, seperti yang terjadi saat ini di CUDA dan OpenCL, tetapi Anda dapat menentukan dependensi. Untuk masalah yang sesuai dengan paradigma streaming, chunking ini juga dapat dilakukan secara otomatis. Intel TBB melakukan ini, tetapi saya lebih suka pendekatan perpustakaan tingkat tinggi yang dicontohkan oleh Thrust dan Cusp , yang dapat menargetkan CUDA atau (segera) TBB.
sumber
Saya akan mencoba jawaban yang lebih pendek daripada beberapa rekan saya yang terhormat di utas ini ;-)
Pesan saya untuk semua siswa saya adalah bahwa waktu pengembang lebih berharga daripada waktu CPU. Itu berarti bahwa jika Anda punya waktu untuk mengkonversi 100% kode pada efisiensi 80% untuk berjalan di mesin besar - menggunakan pendekatan tingkat tinggi -, maka Anda lebih baik daripada ketika Anda menggunakan tingkat rendah yang memakan waktu pendekatan yang memberi Anda efisiensi 100% pada 20% kode Anda. Akibatnya, saya penggemar berat perpustakaan tingkat tinggi. Favorit saya di bidang ini adalah blok bangunan threading (TBB) karena memungkinkan saya untuk melihat algoritma di loop terluar dan pada tingkat tinggi. Hal ini juga dapat melakukan semua hal yang mungkin ingin Anda lakukan dengan pthreads tanpa harus berurusan dengan fungsi OS, dll. Saya bukan penggemar pendekatan yang melihat loop paling dalam karena itulah level yang salah untuk mengeksploitasi sumber daya paralel intranode - - jadi tidak ada OpenMP,
Saya tidak dapat berbicara dengan otoritas tentang OpenCL, CUDA, dll.
sumber
Jawaban yang sebelumnya diposting sangat baik tetapi sebagian besar berfokus pada arsitektur node, yang saya pikir mencerminkan fakta bahwa MPI umumnya dianggap cukup sebagai model pemrograman internode dalam banyak kasus dan itu adalah paralelisme intranode di mana kita berjuang.
Berikut adalah upaya saya untuk menjawab dua pertanyaan yang belum dijawab atau dijawab dengan cara yang relatif terbatas:
Asumsi apa yang harus saya buat tentang arsitektur proses interkoneksi?
Saya akan mempertimbangkan tiga sifat jaringan:
Latensi berbanding terbalik dengan frekuensi. Kita tahu bahwa penskalaan frekuensi telah mandek. Oleh karena itu, orang dapat menyimpulkan bahwa latensi tidak mungkin berkurang secara signifikan di masa depan. Latensi send-recv MPI pada Blue Gene / Q adalah sekitar 2 us, yang sesuai dengan 3200 siklus. Lebih dari setengah dari latensi itu adalah perangkat lunak, tetapi sebagian yang baik diperlukan oleh standar MPI; penyetelan ekstensif mungkin mengurangi latensi mendekati 1 kita, terutama jika seseorang dapat menyatakan bahwa wildcard MPI tidak akan digunakan.
Bagaimanapun, latensi perangkat keras untuk injeksi paket pada sistem Blue Gene dan Cray sekitar 1 us. Jika ada, meningkatkan konkurensi tingkat simpul membuatnya sulit untuk menjaga angka ini tetap rendah, tetapi saya optimis bahwa perancang perangkat keras akan menemukan cara untuk menjaga latensi di bawah 5 kita untuk masa yang akan datang.
Bandwidth jaringan secara sepele meningkat dengan meningkatkan jumlah tautan jaringan. Namun ini hanya sebagian dari cerita. Satu meletakkan 1000 link keluar pada sebuah node dan tidak dapat menggunakannya jika prosesor tidak dapat menggerakkan jaringan pada bandwidth penuh. Sebagai contoh, beberapa superkomputer mengalami hambatan dalam bus (mis. HyperTransport) daripada jaringan, dalam hal bandwidth injeksi.
Tidak ada batasan mendasar untuk bandwidth jaringan, hanya yang praktis. Bandwidth membutuhkan uang dan daya. Perancang sistem harus memperhitungkan pertukaran antara bandwidth jaringan dan bagian lain dari alat berat saat mengembangkan sistem di masa depan. Banyak kode yang tidak dibatasi bandwidth jaringan, jadi sepertinya tidak mungkin bahwa kita akan melihat mesin dengan bandwidth per-koneksi yang lebih dramatis di masa depan. Namun, bandwidth per node harus meningkat sebanding dengan daya hitung sehingga perlu ada beberapa koneksi per node untuk ditingkatkan.
Properti ketiga dari jaringan yang sering diabaikan dalam model formal adalah berapa banyak pesan yang dapat dikirim dalam satu waktu. Memiliki jaringan dengan latensi 1 dan / atau bandwidth 1 TB / s yang hanya dapat mengirim 1 pesan pada satu waktu akan sama sekali tidak berguna untuk sebagian besar penggunaan. Penting untuk dapat mengirim banyak pesan dari banyak utas pada saat yang sama dan agar jaringan tidak runtuh karena pertikaian. Baik sistem Cray dan Blue Gene sekarang mencapai lebih dari 1 MMPS (juta pesan per detik). Saya tidak dapat mengingat angka pastinya, tetapi keduanya mampu mencapai sebagian besar bandwidth puncak dengan pesan kecil. Jaringan yang ideal mungkin dapat mencapai bandwidth puncak dengan pesan ukuran apa pun, tetapi dalam praktiknya hal ini tidak mungkin karena header paket dan overhead pembukuan terkait. Namun,
Ini adalah jawaban yang tidak lengkap dan tidak sempurna. Yang lain dipersilahkan untuk mencoba memperbaikinya atau menyarankan hal-hal yang harus saya perbaiki.
Apakah bahasa Ruang Alamat Global yang dipartisi akan tersedia "dalam produksi" pada mesin petascale?
Sistem Cray XE, XK dan XC memiliki kompiler UPC dan CAF berkualitas-produksi. Sistem Blue Gene dapat dikirim dengan XLUPC dan XLCAF tetapi tidak ada yang meminta ini sehingga tidak dikirimkan. PERCS memiliki kompiler XLUPC dan XLCAF tingkat produksi tetapi tidak ada instalasi skala besar yang dapat diakses oleh komunitas ilmiah.
Coarrays adalah bagian dari Fortran 2008, meskipun implementasi dalam Intel dan GNU Fortran belum berkualitas tinggi. Implementasi Intel terkenal bekerja tetapi juga cukup lambat (ada makalah di PGAS12 tentang hal itu).
Adapun model pemrograman PGAS (karena model pemrograman - bukan bahasa pemrograman - adalah subjek dari pertanyaan awal), pustaka Array Global adalah perkiraan yang masuk akal untuk kualitas produksi dalam banyak kasus. Sebagai runtime, ini tidak sekuat MPI, tetapi MPI cukup unik dalam hal kualitas implementasi. Implementasi ARMCI-MPI dari ARMCI membuat Global Array jauh lebih stabil, meskipun dalam beberapa kasus lebih lambat.
Relatif mudah untuk menerapkan konstruksi gaya PGAS dengan cara kualitas produksi menggunakan RMA MPI-3. Jika seseorang memposting pertanyaan baru tentang ini, saya akan dengan senang hati menjawabnya.
sumber
Jumlah inti yang sangat besar juga membuka perspektif sepele namun mengejutkan bermanfaat - hanya untuk menggunakannya untuk menjalankan banyak iterasi dari keseluruhan simulasi.
Bagian penting dari penelitian komputasi saat ini bermuara pada pemindaian beberapa ruang parameter, menyaring kumpulan besar kondisi awal atau menghitung distribusi dari beberapa hasil secara resampling; semua tugas itu secara paralel memalukan, demikian Amdahl-proof.
sumber
Saya menduga bahwa jawaban yang paling baik sekalipun untuk pertanyaan ini akan usang dalam lima hingga sepuluh tahun. Mengingat ketidakpastian paradigma pemrograman di masa depan, mungkin tidak ada gunanya menghabiskan banyak waktu sebelum mengoptimalkan basis kode Anda.
sumber
Saya baru saja memposting jawaban ini untuk pertanyaan ini , tetapi ditutup sebagai duplikat dari yang ini, jadi begini:
Ini mungkin terdengar agak Solomonik, tetapi dalam pengalaman saya, masa depan milik pendekatan hybrid di mana beberapa node multi-memori bersama yang menjalankan kernel multi-threaded dihubungkan melalui paradigma memori-didistribusikan seperti MPI.
Namun, ada beberapa masalah, dan mereka tidak melibatkan perangkat keras sama sekali. Pertama-tama, kebanyakan programmer paralel banyak berinvestasi dalam kode tipe MPI dan sangat enggan untuk menjadi yang pertama untuk mengimplementasikan kembali bagian-bagian, atau semua, basis kode mereka menggunakan paradigma baru. Kurangnya orang yang menggunakan pendekatan shared-memory menyebabkan kemajuan lebih lambat dalam algoritma untuk area itu, yang membuat investasi apa pun tampak lebih tidak berguna.
Masalah kedua adalah bahwa semua orang mengaitkan paralelisme memori bersama dengan OpenMP . Sementara OpenMP adalah cara cepat dan kotor yang bagus untuk memecahkan masalah kecil dan sederhana pada sejumlah kecil prosesor, ini adalah model pemrograman yang benar-benar mengerikan untuk paralelisme memori bersama yang nyata . Meskipun kita semua, pada titik tertentu, telah mempelajari sejumlah paradigma pemrograman paralel yang sederhana dan efisien, misalnya kumpulan Thread atau Penjadwal , ini tidak mudah untuk diimplementasikan menggunakan OpenMP dan, jujur saja, ini bukan jenis paralelisme yang OpenMP membujuk pemrogram untuk menggunakan.
Singkatnya, penghalang untuk bergerak dari memori yang murni didistribusikan ke paradigma memori murni / sebagian dibagi cukup tinggi. Jika Anda ingin menggunakan utas secara efisien, Anda harus melupakan OpenMP dan mengelola sendiri utas dan konkurensi (hello pthreads , selamat tinggal Fortran).
Tapi mengapa pindah ke pendekatan hibrida sama sekali? Yah, meskipun MPI skala ke ribuan inti, model yang mendasarinya adalah salah satu sinkronisitas kunci-langkah dan pola komunikasi statis. Ini bagus untuk beberapa masalah, misalnya simulasi miliar partikel, tetapi kurang optimal untuk masalah yang lebih sulit atau berbutir halus. Paradigma shared-memory membuat penyeimbangan muatan dinamis dan / atau komunikasi asinkron jauh lebih mudah, tetapi melakukan melibatkan upaya pemrograman utama.
sumber