Pustaka paralel bersama-memori berbasis tugas di Scientific Computing


10

Dalam beberapa tahun terakhir, beberapa proyek perpustakaan / perangkat lunak telah muncul yang menawarkan beberapa bentuk atau paralelisme memori bersama untuk keperluan umum yang didorong oleh data.

Gagasan utamanya adalah bahwa alih-alih menulis kode yang diulir secara eksplisit, pemrogram mengimplementasikan algoritme mereka sebagai tugas yang saling tergantung yang kemudian dijadwalkan secara dinamis oleh middleware tujuan umum pada mesin memori bersama.

Contoh perpustakaan tersebut adalah:

  • QUARK : Awalnya dirancang untuk perpustakaan aljabar linier paralel MAGMA , tampaknya telah digunakan untuk Metode Multipole Cepat paralel juga.

  • Cilk : Awalnya proyek berbasis MIT, sekarang didukung oleh Intel, diimplementasikan sebagai ekstensi bahasa / kompiler ke C, digunakan dalam perangkat lunak catur komputer Cilkchess dan secara eksperimental dalam FFTW .

  • Superscalar SMP : Dikembangkan di Barcelona Supercomputing Center, mirip dengan Cilk dalam banyak hal, berdasarkan #pragmaekstensi.

  • StarPU : "Codelet" berbasis perpustakaan serupa yang dapat dikompilasi dan dijadwalkan pada beberapa arsitektur yang berbeda, termasuk GPU.

  • Tugas OpenMP: Pada versi 3.0, OpenMP memperkenalkan "tugas" yang dapat dijadwalkan secara tidak sinkron (lihat Bagian 2.7 dari spesifikasi).

  • Blok Bangunan Threading Intel : Menggunakan kelas C ++ untuk membuat dan meluncurkan tugas asinkron, lihat Bagian 11 dari Tutorial.

  • OpenCL : Mendukung paralelisme berbasis tugas pada multi-core.

Meskipun ada banyak literatur yang menggambarkan kerja dalam dari perpustakaan / ekstensi bahasa ini dan aplikasinya untuk masalah-masalah spesifik, saya hanya menemukan sedikit sekali contoh yang digunakan dalam praktiknya dalam aplikasi komputasi ilmiah.

Jadi, inilah pertanyaannya: Apakah ada yang tahu kode komputasi ilmiah yang menggunakan pustaka / ekstensi bahasa ini, atau yang serupa, untuk paralelisme memori bersama?


Apakah Anda mencari paralelisme berbasis tugas? Apakah ada alasan Anda melewatkan OpenCL dan Intel TBB? Saya harus mengakui bahwa saya tidak tahu persis apa yang Anda cari di sini.
Aron Ahmadia

1
@AronAhmadia: Ketidaktahuan, terutama ... :) Saya telah menambahkan TBB dan OpenCL ke daftar, tetapi pertanyaannya masih sama: Apakah ini, yaitu komponen berbasis tugas mereka, telah digunakan dalam setiap bagian signifikan dari perangkat lunak untuk ilmiah komputasi?
Pedro

Bagaimana perasaan kita tentang mengubah pertanyaan ini dan jawabannya menjadi komunitas-wiki vs. mencoba memperluasnya?
Aron Ahmadia

@AronAhmadia: Saya agak khawatir jika saya meninggalkan format pertanyaan, ini akan dengan cepat berubah menjadi diskusi panjang tentang keuntungan / kerugian dari pemrograman berbasis tugas dan / atau memori bersama pada umumnya. Saya akan, bagaimanapun, akan mendukung beralih setelah mendapat beberapa jawaban lagi.
Pedro

Judulnya tidak tepat. Pertanyaan ini adalah tentang paralelisme tugas, bukan memori bersama.
Jeff

Jawaban:


8

deal.II menggunakan Blok Bangunan Threading di seluruh perpustakaan dan pada umumnya kami cukup senang dengan itu. Kami telah melihat beberapa alternatif, khususnya OpenMP karena semua orang tampaknya menggunakan itu untuk kode yang lebih sederhana, tetapi ternyata kurang. Secara khusus, OpenMP memiliki kelemahan besar bahwa model tugasnya tidak memungkinkan Anda untuk menangani tugas yang Anda mulai, dan akibatnya sulit untuk mengakses keadaan tugas (misalnya menunggu sampai selesai) atau mengembalikan nilai dari fungsi yang Anda jalankan pada tugas yang terpisah. OpenMP terutama baik untuk memparalelkan loop paling dalam tetapi Anda mendapatkan efisiensi paralel dengan memaralelkan loop terluar , kompleks, dan OpenMP bukan alat untuk itu sementara TBB cukup baik untuk itu.


Terima kasih telah menunjukkan ini, saya belum melihat kesepakatan. II! Apakah ada publikasi atau dokumentasi yang berhubungan dengannya. Penggunaan TBB II dijelaskan secara rinci?
Pedro

Tidak ada publikasi, tetapi ini dapat membantu: dealii.org/developer/doxygen/deal.II/group__threads.html
Wolfgang Bangerth

4

Menurut pendapat saya, sistem ini relatif tidak berhasil terutama karena alasan berikut.

  • Perspektif naif bahwa komputasi paralel adalah tentang memparalelkan perhitungan (misalnya jepit) lebih dari mengekspos lokalitas memori dan menghilangkan titik sinkronisasi. Meskipun beberapa masalah, seperti algoritma matriks padat, masih terbatas pada FP, yang hanya terjadi setelah pertimbangan cermat dari subsistem memori dan sebagian besar kernel komputasi (terutama di dunia PDE) lebih sensitif terhadap memori. Antrian kerja cenderung memperdagangkan lokalitas memori untuk keseimbangan jepit yang lebih naif dan lebih banyak operasi memori atom (karena sinkronisasi melalui antrian).
  • Mengandalkan dekomposisi berlebihan untuk keseimbangan beban dinamis dengan mengorbankan skalabilitas yang kuat. Tugas umumnya memiliki ketergantungan data yang tumpang tindih (nilai hantu). Ketika ukuran interior menyusut, rasio hantu / interior meningkat. Bahkan ketika ini tidak menyiratkan pekerjaan yang berlebihan, itu menyiratkan peningkatan gerakan memori. Pengurangan yang signifikan dalam persyaratan bandwidth memori dapat dimiliki dengan pendekatan seperti prefetch kooperatif di mana beberapa utas berbagi cache L1 atau L2 dengan prefetching perangkat lunak untuk tetangga mereka (yang secara implisit membuat grup utas sekitar koheren). Ini persis kebalikan dari dekomposisi berlebihan.
  • Performa yang tidak dapat diprediksi, sebagian besar disebabkan oleh masalah terkait memori di atas.
  • Kurangnya komponen yang ramah perpustakaan. Ini hampir dapat diringkas sebagai tidak memiliki analog MPI_Commyang memungkinkan pustaka yang berbeda untuk melakukan operasi yang kaya tanpa bertabrakan, serta untuk melewatkan konteks antara pustaka dan memulihkan atribut yang diperlukan. Abstraksi yang disediakan oleh "komunikator" penting untuk komposisi perpustakaan terlepas dari apakah memori bersama atau didistribusikan digunakan.

Saya mungkin salah paham jawaban Anda, tetapi poin pertama persis kebalikan dari apa yang ditunjukkan Buttari, Kurzak, Dongarra, dan lainnya dengan MAGMA, pustaka memori bersama berbasis tugas untuk aljabar linier padat ... Juga, di poin kedua Anda Anda merujuk pada data yang tumpang tindih, yaitu nilai hantu, dan rasio permukaan-ke-volume, tetapi ini adalah penahanan dari skema dekomposisi domain memori-terdistribusi. Saya sendiri bekerja dengan metode seperti itu untuk kode berbasis partikel, dan saya mendapatkan kinerja yang jauh lebih baik daripada implementasi paralel berbasis MPI.
Pedro

Pertanyaannya, bagaimanapun, adalah pertanyaan yang berbeda ... Apakah Anda tahu ada proyek perangkat lunak komputasi ilmiah yang menggunakan pendekatan ini?
Pedro

1. Ada beberapa proyek yang menggunakan sistem ini, tetapi saya tidak berpikir pendekatannya dapat dianggap "berhasil". 2. Ketergantungan masih tumpang tindih dalam memori bersama. Lihatlah cara tcmalloc atau kernel Linux membuat utas lebih mandiri untuk menghindari kemacetan seperti sinkronisasi melalui atom. Ruang alamat bersama tidak menyiratkan Anda harus beroperasi seolah-olah Anda memiliki memori yang seragam atau Anda harus menganggap atom menjadi murah.
Jed Brown

3. Saya tidak tahu "perbandingan adil" apa yang ingin Anda kutip , tetapi PLASMA hanya mendapatkan sekitar 25% dari FPU puncak (misalnya slide 5 dari hpcgarage.org/cscads2012/Luszczek-UTK-PowerTools.pdf ) yang akan menjadi sangat buruk untuk operasi yang sama dalam memori terdistribusi di mana setidaknya 70% dari puncak akan diharapkan. Aljabar linier padat adalah kasus terikat FPU yang saya kutip secara khusus sebagai pengecualian, tetapi meskipun ukuran matriksnya sangat besar, PLASMA jelas jauh dari terikat dengan FPU.
Jed Brown

Pedro, sebagian besar fisika memiliki komponen jarak jauh, sehingga partikel digabungkan dengan pembaruan yang tunduk pada efek permukaan-ke-solume di atas (PPPM, partikel vortex, dll.)
Matt Knepley
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.