Bir MPI C ++ arayüzünden kullanıcıların hangi özelliklere ihtiyacı var?

MPI standardının 3.0 sürümü C ++ arayüzünü resmen silmiş (daha önce kullanımdan kaldırılmıştır). Uygulamalar hala destekleyebilirken, MPI-3'te yeni olan özellikler, MPI standardında tanımlanan bir C ++ arayüzüne sahip değildir. Daha fazla bilgi için http://blogs.cisco.com/performance/the-mpi-c-bindings-what-happened-and-why/ adresini ziyaret edin.

C ++ arayüzünü MPI'dan kaldırma motivasyonu C arayüzüne göre önemli bir değere sahip değildi. "S / _ / :: / g" dışında çok az fark vardı ve C ++ kullanıcılarının alışık olmadığı birçok özellik kullanılmadı (örneğin, şablonlar aracılığıyla otomatik tip belirleme).

MPI Forumuna katılan ve kendi C ++ arabirimini MPI C işlevlerine uygulayan bir dizi C ++ projesiyle çalışan biri olarak, bir C ++ arabiriminin MPI için istenen özelliklerinin ne olduğunu bilmek istiyorum. Hiçbir şey yapmama rağmen, birçok kullanıcının ihtiyaçlarını karşılayan bağımsız bir MPI C ++ arayüzünün uygulanmasını görmek isterim.

Ve evet, Boost :: MPI ( http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html ) ile tanıştım ama sadece MPI-1 özelliklerini destekliyor ve seri hale getirme modeli RMA'yı desteklemek oldukça zor.

Beğendiğim MPI'ye bir C ++ arayüzü Elemental'a ait ( https://github.com/poulson/Elemental/blob/master/src/core/imports/mpi.cpp ) bu yüzden belki de insanlar biraz profesyonelce olabilir. yaklaşım. Özellikle, MpiMap'in önemli bir sorunu çözdüğünü düşünüyorum.

İlk önce neden MP ++ CI arabirimlerinin genellikle aşırı derecede başarılı olmadığını, neden MPI'nin standart C bağlaçlarını kullanıp kullanmayacağımıza mı karar vermeye çalıştığımda, uzun süredir düşünmeye çalıştığımı düşünüyorum. :

Gerçek dünyadaki MPI kodlarına baktığınızda (diyelim ki, PETSc ya da benim durumumda. II), belki de şaşırtıcı bir şekilde, MPI çağrılarının sayısının gerçekten çok büyük olmadığını buluyor. Örneğin, 500k anlaşma satırında. II, yalnızca ~ 100 MPI çağrısı var. Bunun bir sonucu, MPI C bağlamaları gibi daha düşük seviyeli arayüzlerin kullanımında rol alan ağrının çok büyük olmamasıdır. Tersine, daha yüksek seviyeli arayüzleri kullanarak bu kadar kazanamayacaksınız.

İkinci gözlemim, birçok sistemde çoklu MPI kütüphanelerinin kurulu olduğu (farklı MPI uygulamaları veya farklı sürümler) olduğu. Yalnızca başlık dosyalarından ibaret olmayan, artırma :: mpi kullanmak istemeniz durumunda bu önemli bir zorluk yaratır: ya bu paketin birden fazla kurulumunun da olması gerekir, ya da birinin bir parçası olarak oluşturulması gerekir. boost kullanan proje: mpi (ancak bu, başka hiçbir şeye benzemeyen kendi derleme sistemini kullandığı için bu yine kendi başına bir sorun).

Bu nedenle, bunların tümünün şu anki C ++ arayüzleri ürününün MPI ile uyumlu olduğunu düşünüyorum: Eski MPI C ++ bağları herhangi bir avantaj sunmuyordu ve dış ambalajların gerçek dünya ile ilgili zorlukları vardı.

Bunların hepsi, daha yüksek seviye bir arayüzden sahip olmak istediğim katil özellikler olacağını düşündüğüm şey:

• Genel olmalı. Bir değişkenin veri türünü belirtmek zorunda kalmayacağı kesin olarak C ++ 'a benzemez. Tabii ki, aynı zamanda hatalara yol açar. Elemental'ın MpiMap sınıfı zaten iyi bir ilk adım olurdu ( MpiMap::typedeğişkenlerin neden statik const olmadığını, bir nesne oluşturmadan erişilebilmelerini sağlamak için neden bulamıyorum ).

• İsteğe bağlı veri türleri akışı için olanaklara sahip olmalıdır.

• Bir MPI_Opargüman gerektiren işlemler (örneğin, azaltmalar) C ++ 'ın std::functionarayüzü ile iyi bir şekilde bütünleşmelidir , böylece bir şeyi gizlice kaydetmek zorunda kalmak yerine bir işlev göstergesini (veya bir lambda!) Geçmek kolaydır.

boost :: mpi aslında bunların hepsini tatmin ediyor. Bence sadece bir başlık kitaplığı olsaydı, pratikte çok daha popüler olurdu. MPI 1.0 işlevlerini desteklemesi durumunda da yardımcı olabilir, ancak dürüst olalım: bu çoğu zaman ihtiyacımız olan şeylerin çoğunu kapsar.

Topu yuvarlamak için, benim ihtiyaçlarımdan ikisi:

• Arayüz, gereksiz veya gereksiz argümanları ortadan kaldırabilmelidir, örn. MPI_IN_PLACE.
• Arayüz, Elemental's MpiMap’in dahili veri tiplerini otomatik olarak algılamalıdır.
• Mümkünse / mümkün olduğunda, sınıflar için kullanıcı tanımlı veri tipleri oluşturulmalıdır.

Listem belirli bir tercih sırasına göre değil. Arayüz gerekir:

• bağımlılık olmadan sadece başlık, ancak <mpi.h>standart kütüphane,
• genel ve genişletilebilir olmak,
• sadece engelleme yapmamak ( engellemek istiyorsanız, daha sonra varsayılan olarak değil, açıkça engelleyin),
• bloke edici olmayan işlemlerin devam temelli zincirlemesine izin vermek,
• Genişletilebilir ve verimli serileştirme desteği (RMA ile çalışacak şekilde Boost.Fusion gibi),
• sıfır soyutlama cezasına sahip olmak (yani en azından C arayüzü kadar hızlı olmak),
• güvende olun (hazır olmayan bir geleceğin yıkıcısına? -> std :: terminate!),
• DEBUGtonlarca iddia ile güçlü bir mod var,
• son derece güvenli yazı (her şey için daha fazla giriş / boşluk * yok, heck, etiketlerin tür olmasını istiyorum!),
• lambdalarla çalışması gerekir (örn. hepsi azaltılır + lambda),
• İstisnaları sürekli olarak hata raporlama ve hata işleme mekanizması olarak kullanmak (daha fazla hata kodu yok! artık fonksiyon çıkışı argümanı yok!),
• MPI-IO, Boost.AFIO tarzında engelleyici olmayan bir G / Ç arayüzü sunmalıdır.
• ve sadece iyi modern C ++ arayüz tasarım uygulamalarını takip edin (düzenli türleri, üye olmayan arkadaş olmayan işlevleri tanımlayın, hareket anlambilimiyle iyi oynayın, destek aralığı işlemlerini yapın,…)

Ekstralar:

• MPI ortamının uygulayıcısını seçmeme izin ver, yani hangi iş parçacığını kullanır. Şu anda, OpenMP, MPI, CUDA ve TBB ... karışımlarını içeren uygulamalara sahip olabilirsiniz. Aynı zamanda, her çalışma zamanının çevreye sahip olduğunu düşündüğü ve böylece işletim sisteminden istedikleri zaman iş parçacığı isteyebilecekleri o. Ciddi anlamda?

• STL (ve Boost) adlandırma kurallarını kullanın. Niye ya? Her C ++ programcısı bunu bilir.

Böyle bir kod yazmak istiyorum:

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();

Birinin tüm bu işlemleri MPI_C'ler kullanarak nasıl zincirleyebileceğini düşünün request. Zincirinizi bloke etmeden ilerletip ilerletemeyeceğinizi görmek için çok sayıda (veya her bir) orta adımda çok sayıda ilgisiz kod üzerinden test yapmanız gerekir .

Şahsen, Wolfgang'ın bahsettiği gerçek nedenden ötürü uzun C tarzı işlevler çağırmayı gerçekten umursamıyorum; onları aramanız gereken çok az yer var ve o zaman bile, neredeyse her zaman bazı üst düzey kodlarla sarılıyorlar.

C tarzı MPI ile beni gerçekten rahatsız eden şeyler özel veri türleri ve daha az derecede özel işlemlerdir (çünkü daha az kullanıyorum). Özel veri tiplerine gelince, iyi bir C ++ arayüzünün, muhtemelen seri hale getirme yoluyla bunun genel ve verimli yolunu destekleyebilmesi gerektiğini söyleyebilirim. Bu elbette, boost.mpieğer dikkatli olursanız büyük bir zaman kazandıran , alınan rota .

boost.mpiEkstra bağımlılıklara gelince (özellikle boost.serializationkendisi yalnızca başlık değil), geçenlerde ümit verici görünen tahıl gevreği adı verilen yalnızca başlık C ++ serileştirme kitaplığıyla karşılaştım ; C ++ 11 uyumlu bir derleyici gerektirir. Benzer bir şey için araştırmaya ve bir temel olarak kullanmaya değer olabilir boost.mpi.

Github projesi easyLambda , C ++ 14 ile MPI'ya yüksek düzeyde bir arayüz sağlar.

Projenin benzer amaçları olduğunu düşünüyorum ve modern C ++ kullanarak bu alanda yapılabilecekler ve yapılabilecekler hakkında bir fikir verecektir. EasyLambda'nın kendisi gibi diğer çabalara rehberlik etmek.

Performans ve kod satırlarındaki ilk kriterler ümit verici sonuçlar göstermiştir.

Aşağıdaki özellikler ve sağladığı arayüz kısa bir açıklamasıdır.

Arayüz veri akışı programlama ve içsel paralellik sağlayan fonksiyonel liste işlemlerine dayanmaktadır. Paralellik bir görevin özelliği olarak ifade edilir. Görev için işlem tahsisi ve veri dağıtımı .prll () özelliğiyle istenebilir. Bulunan örneklerin iyi vardır web sayfası ve kod deposu makale tartışılan ısı difüzyon problemi Örnek olarak moleküler dinamik sonrası işleme, ısı denklemi için açık sonlu farklar çözümü, lojistik regresyon vb LAMMPS dahil HPC ölüyor ... ~ 20 kod satırıyla ifade edilebilir.

Buraya daha fazla ayrıntı ve örnek kod eklemek yerine link vermenin iyi olacağını umuyorum.

Feragatname: Ben kütüphanenin yazarıyım. EasyLambda'nın şu anki arayüzü hakkında, easyLambda ve benzer hedefleri takip eden herhangi bir proje için avantajlı olabilecek yapıcı bir geri bildirim alma umuduyla herhangi bir zarar vermediğime inanıyorum.