Fitur apa yang dibutuhkan pengguna dari antarmuka MPI C ++?

Versi 3.0 dari standar MPI secara formal menghapus antarmuka C ++ (sebelumnya tidak digunakan lagi). Sementara implementasi mungkin masih mendukungnya, fitur-fitur yang baru di MPI-3 tidak memiliki antarmuka C ++ yang didefinisikan dalam standar MPI. Lihat http://blogs.cisco.com/performance/the-mpi-c-bindings-what-happened-and-why/ untuk informasi lebih lanjut.

Motivasi untuk menghapus antarmuka C ++ dari MPI adalah bahwa ia tidak memiliki nilai signifikan atas antarmuka C. Ada sedikit perbedaan selain "s / _ / :: / g" dan banyak fitur yang tidak biasa digunakan pengguna C ++ (misalnya penentuan tipe otomatis melalui templat).

Sebagai seseorang yang berpartisipasi dalam Forum MPI dan bekerja dengan sejumlah proyek C ++ yang telah mengimplementasikan antarmuka C ++ mereka sendiri ke fungsi MPI C, saya ingin tahu apa saja fitur yang diinginkan dari antarmuka C ++ ke MPI. Sementara saya berkomitmen untuk tidak melakukan apa pun, saya akan tertarik melihat implementasi antarmuka MPI C ++ mandiri yang memenuhi kebutuhan banyak pengguna.

Dan ya, saya kenal dengan Boost :: MPI ( http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html ) tetapi hanya mendukung fitur MPI-1 dan model serialisasi akan menjadi sangat sulit untuk mendukung RMA.

Satu antarmuka C ++ ke MPI yang saya sukai adalah Elemental ( https://github.com/poulson/Elemental/blob/master/src/core/imports/mpi.cpp ) jadi mungkin orang dapat menyediakan beberapa pro dan kontra yang pendekatan. Secara khusus, saya pikir MpiMap memecahkan masalah penting.

Biarkan saya jawab dulu mengapa saya pikir antarmuka C ++ ke MPI pada umumnya tidak terlalu berhasil, setelah memikirkan masalah ini untuk waktu yang lama ketika mencoba memutuskan apakah kita harus menggunakan binding C standar MPI atau membangun sesuatu di level yang lebih tinggi :

Ketika Anda melihat kode MPI dunia nyata (katakanlah, PETSc, atau dalam kasus saya. II), orang menemukan bahwa mungkin secara mengejutkan, jumlah panggilan MPI sebenarnya tidak terlalu besar. Sebagai contoh, dalam garis 500k kesepakatan. II, hanya ada ~ 100 MPI panggilan. Konsekuensi dari ini adalah bahwa rasa sakit yang terlibat dalam menggunakan antarmuka tingkat rendah seperti ikatan MPI C, tidak terlalu besar. Sebaliknya, seseorang tidak akan mendapatkan banyak dengan menggunakan antarmuka tingkat yang lebih tinggi.

Pengamatan kedua saya adalah bahwa banyak sistem memiliki banyak pustaka MPI yang diinstal (implementasi MPI yang berbeda, atau versi yang berbeda). Ini menimbulkan kesulitan yang signifikan jika Anda ingin menggunakan, katakanlah, boost :: mpi yang tidak hanya terdiri dari file header: perlu ada beberapa instalasi dari paket ini juga, atau orang perlu membangunnya sebagai bagian dari proyek yang menggunakan boost :: mpi (tapi itu masalah tersendiri lagi, mengingat boost itu menggunakan sistem build sendiri, yang tidak seperti yang lain).

Jadi saya pikir semua ini telah bersekongkol melawan arus antarmuka C ++ ke MPI: Binding MPI C ++ yang lama tidak menawarkan keuntungan, dan paket eksternal mengalami kesulitan dengan dunia nyata.

Ini semua berkata, inilah yang saya pikir akan menjadi fitur pembunuh yang ingin saya miliki dari antarmuka tingkat yang lebih tinggi:

• Itu harus generik. Harus menentukan tipe data variabel jelas tidak seperti C ++. Tentu saja, itu juga mengarah pada kesalahan. Kelas MpiMap Elemental sudah akan menjadi langkah pertama yang bagus (meskipun saya tidak tahu mengapa MpiMap::typevariabel tidak konst statis, sehingga dapat diakses tanpa membuat objek).

• Seharusnya memiliki fasilitas untuk streaming tipe data yang berubah-ubah.

• Operasi yang membutuhkan MPI_Op argumen (misalnya, reduksi) harus diintegrasikan dengan baik dengan std::functionantarmuka C ++ , sehingga mudah untuk hanya melewatkan pointer fungsi (atau lambda!) Daripada harus dengan cepat mendaftarkan sesuatu.

boost :: mpi sebenarnya memenuhi semua ini. Saya pikir jika itu hanya pustaka header, ini akan menjadi jauh lebih populer dalam praktiknya. Ini juga akan membantu jika mendukung fungsi-fungsi pasca-MPI 1.0, tetapi mari kita jujur: ini mencakup sebagian besar dari apa yang paling kita butuhkan.

Untuk memulai, ada dua kebutuhan saya:

• Antarmuka harus dapat menghilangkan argumen yang berlebihan atau tidak perlu, misalnya MPI_IN_PLACE.
• Antarmuka harus secara otomatis mendeteksi datatypes bawaan ala Elemental's MpiMap.
• Jika / bila memungkinkan, tipe data yang ditentukan pengguna harus dibangun untuk kelas.

Daftar saya tanpa urutan preferensi tertentu. Antarmuka harus:

• hanya sundulan, tanpa ketergantungan apa pun kecuali <mpi.h> , dan pustaka standar,
• menjadi generik dan dapat dikembangkan,
• non-blocking hanya (jika Anda ingin memblokir, kemudian blok secara eksplisit, tidak secara default),
• memungkinkan rangkaian operasi non-pemblokiran berbasis kelanjutan,
• mendukung serialisasi yang dapat dikembangkan dan efisien (seperti Boost.Fusion, sehingga berfungsi dengan RMA),
• memiliki penalti abstraksi nol (yaitu setidaknya secepat antarmuka C),
• aman (penghancur masa depan yang tidak siap disebut? -> std :: terminate!),
• memiliki DEBUGmode yang kuat dengan banyak pernyataan,
• sangat type-safe (tidak ada ints / void * untuk semuanya, huh saya ingin tag menjadi tipe!),
• itu harus bekerja dengan lambdas (mis. semua mengurangi + lambda),
• gunakan pengecualian secara konsisten sebagai mekanisme pelaporan kesalahan dan penanganan kesalahan (tidak ada lagi kode kesalahan! tidak ada lagi argumen fungsi keluaran!),
• MPI-IO harus menawarkan antarmuka I / O non-blocking dalam gaya Boost.AFIO,
• dan ikuti saja praktik desain antarmuka C ++ modern yang bagus (tentukan tipe reguler, fungsi non-anggota non-anggota, bermain baik dengan semantik gerakan, operasi rentang dukungan, ...)

Ekstra:

• izinkan saya untuk memilih pelaksana lingkungan MPI, yaitu kumpulan utas yang digunakan. Saat ini Anda dapat memiliki aplikasi dengan campuran OpenMP, MPI, CUDA, dan TBB ... semuanya pada saat yang sama, di mana setiap run-time berpikir itu memiliki lingkungan dan dengan demikian meminta sistem operasi untuk utas setiap kali mereka merasa seperti saya t. Serius?

• gunakan konvensi penamaan STL (dan Boost). Mengapa? Setiap programmer C ++ mengetahuinya.

Saya ingin menulis kode seperti ini:

auto buffer = some_t{no_ranks};
auto future = gather(comm, root(comm), my_offsets, buffer)
              .then([&](){
                /* when the gather is finished, this lambda will 
                   execute at the root node, and perform an expensive operation
                   there asynchronously (compute data required for load 
                   redistribution) whose result is broadcasted to the rest 
                   of the communicator */
                return broadcast(comm, root(comm), buffer);
              }).then([&]() {
                /* when broadcast is finished, this lambda executes 
                   on all processes in the communicator, performing an expensive
                   operation asynchronously (redistribute the load, 
                   maybe using non-blocking point-to-point communication) */
                 return do_something_with(buffer);
              }).then([&](auto result) {
                 /* finally perform a reduction on the result to check
                    everything went fine */
                 return all_reduce(comm, root(comm), result, 
                                  [](auto acc, auto v) { return acc && v; }); 
              }).then([&](auto result) {
                  /* check the result at every process */
                  if (result) { return; /* we are done */ }
                  else {
                    root_only([](){ write_some_error_log(); });
                    throw some_exception;
                  }
              });

/* Here nothing has happened yet! */

/* ... lots and lots of unrelated code that can execute concurrently 
   and overlaps with communication ... */

/* When we now call future.get() we will block 
   on the whole chain (which might have finished by then!).
*/

future.get();

Pikirkan bagaimana seseorang dapat menghubungkan semua operasi ini menggunakan MPI_C's request. Anda harus menguji beberapa langkah perantara (atau setiap langkah tunggal) melalui banyak kode yang tidak terkait untuk melihat apakah Anda dapat memajukan rantai Anda tanpa memblokir .

Secara pribadi, saya tidak keberatan memanggil fungsi gaya C panjang untuk alasan yang tepat yang disebutkan Wolfgang; benar-benar ada beberapa tempat Anda perlu memanggil mereka dan bahkan kemudian, mereka hampir selalu dibungkus oleh beberapa kode tingkat yang lebih tinggi.

Satu-satunya hal yang benar-benar mengganggu saya dengan MPI C-style adalah tipe data khusus dan, pada tingkat yang lebih rendah, operasi khusus (karena saya jarang menggunakannya). Sedangkan untuk tipe data khusus, saya akan mengatakan bahwa antarmuka C ++ yang baik harus dapat mendukung cara umum dan efisien dalam menangani ini, kemungkinan besar melalui serialisasi. Ini tentu saja rute yang boost.mpitelah ditempuh, yang jika Anda hati - hati , adalah penghemat waktu yang besar.

Adapun boost.mpimemiliki dependensi tambahan (terutama boost.serializationyang itu sendiri bukan header-saja), saya baru-baru ini menemukan perpustakaan serialisasi hanya C + + header yang disebut sereal yang tampaknya menjanjikan; diberikan itu membutuhkan compiler C ++ 11 compliant. Mungkin layak untuk dilihat dan digunakan sebagai dasar untuk sesuatu yang mirip boost.mpi.

Proyek github easyLambda menyediakan antarmuka tingkat tinggi ke MPI dengan C ++ 14.

Saya pikir proyek ini memiliki tujuan yang sama dan akan memberikan beberapa gagasan tentang hal-hal yang dapat dan sedang dilakukan di bidang ini dengan menggunakan C ++ modern. Membimbing upaya lain serta easyLambda sendiri.

Tolok ukur awal pada kinerja dan garis kode telah menunjukkan hasil yang menjanjikan.

Berikut ini adalah deskripsi singkat fitur dan antarmuka yang disediakannya.

Antarmuka didasarkan pada pemrograman aliran data dan operasi daftar fungsional yang menyediakan paralelisme yang melekat. Paralelisme diekspresikan sebagai properti dari suatu tugas. Alokasi proses dan distribusi data untuk tugas dapat diminta dengan properti .prll (). Ada sejumlah contoh yang baik di halaman web dan repositori-kode yang meliputi LAMMPS dinamika molekul pasca pemrosesan, solusi beda hingga eksplisit untuk persamaan panas, regresi logistik dll. Sebagai contoh masalah difusi panas yang dibahas dalam artikel HPC sedang sekarat ... dapat diekspresikan dalam ~ 20 baris kode.

Saya harap tidak masalah untuk memberikan tautan daripada menambahkan rincian dan contoh kode di sini.

Disclamer: Saya adalah penulis perpustakaan. Saya percaya saya tidak melakukan kesalahan dengan berharap mendapatkan umpan balik yang konstruktif pada antarmuka easyLambda saat ini yang mungkin bermanfaat bagi easyLambda dan proyek lain yang mengejar tujuan yang sama.