Paradigma pemrograman apa yang harus saya investasikan jika saya ingin kode saya berjalan di mesin petascale di masa depan?

36

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?

Aron Ahmadia
sumber
5
Saya tidak melihat pertanyaan ini dicakup dengan benar. Dari faq, "Pertanyaan Anda harus dibatasi. Jika Anda dapat membayangkan seluruh buku yang menjawab pertanyaan Anda, Anda terlalu banyak bertanya." Bahkan setiap konferensi SuperComputing yang pernah saya kunjungi memiliki banyak panel tentang topik ini dan ada puluhan hingga ratusan buku yang didedikasikan untuk paradigma pemrograman yang berbeda
aterrel
terkait secara tangensial: cs.stackexchange.com/questions/891/…
naught101
5
Bola kristal tidak tersedia, daun teh jatuh.
dmckee

Jawaban:

34

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

  • Chip Tujuan Khusus: Pikirkan unit vektor besar seperti akselerator (lihat didukung oleh Bill Dally dari Nvidia)
  • Chip Daya Rendah: Cluster berbasis ARM (untuk mengakomodasi anggaran daya)
  • Tiling of Chips: think tiling of chips dengan spesifikasi berbeda (karya Avant Argwal )

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:

  • Kembangkan algoritme Anda agar sesuai dengan setidaknya tiga level hierarki paralel.
  • Rancang algoritma Anda dalam hal kernel yang dapat dipindahkan di antara heirarki.
  • Santai kebutuhan Anda untuk setiap proses berurutan, semua efek ini akan terjadi secara tidak sinkron karena eksekusi sinkron tidak mungkin.

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

aterrel
sumber
2
Bagus, tetapi bagaimana Anda bisa mengabaikan vektorisasi, yang merupakan faktor tunggal terbesar untuk kinerja on-node?
Matt Knepley
Sangat benar (saya benar-benar menganggapnya sebagai bagian dari node komputasi khusus, baru saja berdiskusi panjang dengan Dr. Bandwidth tentang bagaimana vendor benar-benar menyarankan orang mematikan unit vektor untuk kode seri), saya juga mengabaikan sistem memori, dan saya /Hai. Kira saya akan menambahkan itu sekarang.
aterrel
Apakah co-array di Fortran kira-kira setara dengan UPC?
Ondřej Čertík
Sejauh yang saya tahu mereka adalah konsep yang sama tetapi saya belum menggunakan kedua perpustakaan secara luas.
aterrel
Dalam artian CAF dan UPC sama-sama PGAS, ya. Dan tidak ada perpustakaan, btw. Ada banyak informasi di Internet untuk menjawab pertanyaan ini secara lebih rinci.
Jeff
8

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.

Matt Knepley
sumber
Saya juga berpikir pendekatan CUDA / OpenCL memiliki masa depan yang cerah ... tetapi yang mana yang menang, CUDA atau OpenCL? Apakah kegagalan AMD baru-baru ini akan membahayakan OpenCL?
PhDP
2
Akhirnya akan ada standar terbuka yang digunakan semua orang. Mungkin akan OpenCL 2.0. Untuk saat ini, CUDA sedikit lebih maju, tetapi saya dapat dengan mudah menerjemahkan 95% dari kode saya.
Matt Knepley
7

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.

Wolfgang Bangerth
sumber
4

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:

  1. latensi,
  2. bandwidth, dan
  3. konkurensi.

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.

Jeff
sumber
4
Anda dapat memposting pertanyaan tentang menerapkan konstruksi gaya PGAS di MPI-3 sendiri (dan menjawabnya sendiri), selama itu merupakan masalah nyata yang Anda hadapi di masa lalu (yang saya asumsikan). Kami mengizinkan pengguna untuk menjawab posting mereka sendiri.
Geoff Oxberry
1
Ini adalah salah satu pertanyaan scicomp paling populer, saya senang jawaban Jeff hadir di sini. EDIT: Saya mengerti maksud Anda di sana @ GeoffOxberry - ya, ia harus memposting pertanyaannya sendiri dan membalasnya :)
Aron Ahmadia
Oke, saya akan mencoba menyisihkan waktu untuk menulis hardcore "Apa hubungan antara PGAS dan MPI-3 RMA" tanya-jawab dalam satu atau dua minggu ke depan.
Jeff
3

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.

mbq
sumber
2

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.

MRocklin
sumber
1
Itu terlalu fatalistis - masa depan ada di sini, hari ini. Pertanyaannya adalah tentang petascale, di mana kita berada saat ini. Jika Anda tidak memikirkan bagaimana Anda dapat menjalankan 100.000 prosesor saat ini, Anda tidak akan membuat banyak kemajuan dengan 100.000.000 core besok.
Wolfgang Bangerth
1

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.

Pedro
sumber
1
Saya setuju bahwa OpenMP adalah paradigma yang mengerikan dan merugikan komunitas. Tetapi pada saat yang sama itu tidak benar bahwa alternatifnya adalah mengelola utas, kumpulan utas, antrian kerja, dll sendiri - sebenarnya ada perpustakaan yang sangat baik yang melakukan ini untuk Anda. Blok Bangunan Threading Intel adalah yang paling terkenal. Kami telah menggunakannya selama bertahun-tahun di bawah tenda dalam kesepakatan. Saya dan itu bekerja cukup baik.
Wolfgang Bangerth
Hmm, saya sudah mencari aplikasi atau perpustakaan yang kuat yang menggunakan TBB untuk memverifikasi bahwa implementasi BG kami berfungsi. Saya hanya menemukan cise.ufl.edu/research/sparse/SPQR sebelumnya. Apakah ada kemungkinan Anda akan mencoba menjalankan deal.II pada BGP atau BGQ menggunakan wiki.alcf.anl.gov/parts/index.php/BlueTBB jika saya memberikan alokasi?
Jeff
@ WolfgangBangerth: Hanya memicu perhatian bagi Anda karena saya percaya itulah yang dimaksudkan komentar Jeff. Meskipun saya tidak keberatan akses ke BlueGene sendiri;)
Pedro
@ Jeff: Saya bersedia mencobanya tetapi mungkin tidak akan dapat mengalokasikan jumlah waktu yang mengerikan. Jangan ragu untuk menghubungi saya secara offline. (@Pedro: Terima kasih atas semuanya!)
Wolfgang Bangerth