Jakich funkcji potrzebują użytkownicy interfejsu MPI C ++?

Wersja 3.0 standardu MPI formalnie usunęła interfejs C ++ (wcześniej był przestarzały). Chociaż implementacje mogą nadal go obsługiwać, funkcje nowe w MPI-3 nie mają interfejsu C ++ zdefiniowanego w standardzie MPI. Więcej informacji można znaleźć na stronie http://blogs.cisco.com/performance/the-mpi-c-bindings-what-happened-and-why/ .

Motywacją do usunięcia interfejsu C ++ z MPI było to, że nie miał on znaczącej wartości w stosunku do interfejsu C. Było bardzo niewiele różnic innych niż „s / _ / :: / g” i wiele funkcji, do których przyzwyczajeni są użytkownicy C ++, nie było wykorzystywanych (np. Automatyczne określanie typu za pomocą szablonów).

Jako ktoś, kto uczestniczy w Forum MPI i pracuje z wieloma projektami C ++, które zaimplementowały własny interfejs C ++ do funkcji MPI C, chciałbym wiedzieć, jakie są pożądane cechy interfejsu C ++ do MPI. Chociaż nic się nie zobowiązuję, chciałbym zobaczyć wdrożenie samodzielnego interfejsu MPI C ++, który spełnia potrzeby wielu użytkowników.

I tak, znam Boost :: MPI ( http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html ), ale obsługuje on tylko funkcje MPI-1, a model serializacji byłby niezwykle trudne do obsługi RMA.

Jeden interfejs C ++ do MPI, który mi się podoba, to interfejs Elemental ( https://github.com/poulson/Elemental/blob/master/src/core/imports/mpi.cpp ), więc być może ludzie mogą podać jakieś pro i con wrt, że podejście. W szczególności myślę, że MpiMap rozwiązuje istotny problem.

Pozwól mi najpierw odpowiedzieć, dlaczego uważam, że interfejsy C ++ do MPI na ogół nie były zbyt udane, ponieważ długo zastanawiałem się nad tym problemem, próbując zdecydować, czy powinniśmy po prostu użyć standardowych powiązań C MPI, czy też budować na czymś wyższym :

Kiedy patrzysz na rzeczywiste kody MPI (powiedzmy PETSc lub w moim przypadku deal.II), okazuje się, że być może, co zaskakujące, liczba wywołań MPI w rzeczywistości nie jest bardzo duża. Na przykład w 500k liniach transakcji. II jest tylko ~ 100 połączeń MPI. Konsekwencją tego jest to, że ból związany z korzystaniem z interfejsów niższego poziomu, takich jak wiązania MPI C, nie jest zbyt duży. I odwrotnie, nie można wiele zyskać, używając interfejsów wyższego poziomu.

Moje drugie spostrzeżenie jest takie, że wiele systemów ma zainstalowanych wiele bibliotek MPI (różne implementacje MPI lub różne wersje). Stanowi to znaczną trudność, jeśli chcesz użyć, powiedzmy, boost :: mpi, które nie składają się tylko z plików nagłówkowych: albo musi być wiele instalacji tego pakietu, albo trzeba go zbudować jako część projekt, który korzysta z boost :: mpi (ale to znowu problem sam w sobie, biorąc pod uwagę, że boost korzysta z własnego systemu kompilacji, co nie jest niczym innym)

Sądzę więc, że wszystko to sprzysięgło się w stosunku do obecnego zbioru interfejsów C ++ do MPI: stare wiązania MPI C ++ nie oferowały żadnych korzyści, a zewnętrzne pakiety miały problemy ze światem rzeczywistym.

To wszystko powiedziało, oto, jak myślę, funkcje zabójcy, które chciałbym mieć z interfejsu wyższego poziomu:

• Powinien być ogólny. Konieczność określenia typu danych zmiennej zdecydowanie nie jest podobna do C ++. Oczywiście prowadzi to również do błędów. Klasa MpiMap firmy Elemental byłaby już dobrym pierwszym krokiem (chociaż nie mogę zrozumieć, dlaczego ta MpiMap::typezmienna nie jest stałą statyczną, więc można uzyskać do niej dostęp bez tworzenia obiektu).

• Powinien mieć możliwości przesyłania strumieniowego dowolnych typów danych.

• Operacje wymagające MPI_Opargumentu (np. Redukcje) powinny być ładnie zintegrowane z std::functioninterfejsem C ++ , aby łatwo było po prostu przekazać wskaźnik funkcji (lub lambda!), Zamiast konieczności niezgrabnego rejestrowania czegoś.

boost :: mpi faktycznie spełnia wszystkie z nich. Myślę, że gdyby to była biblioteka tylko z nagłówkami, byłaby o wiele bardziej popularna w praktyce. Pomógłby również, gdyby obsługiwał funkcje post-MPI 1.0, ale bądźmy szczerzy: obejmuje to większość tego, czego potrzebujemy przez większość czasu.

Aby uruchomić piłkę, oto dwie moje potrzeby:

• Interfejs powinien być w stanie wyeliminować zbędne lub niepotrzebne argumenty, np. MPI_IN_PLACE.
• Interfejs powinien automatycznie wykrywać wbudowane typy danych alpi Elemental's MpiMap.
• Jeśli / kiedykolwiek jest to możliwe, dla klas należy konstruować typy danych zdefiniowane przez użytkownika.

Moja lista nie ma określonej kolejności preferencji. Interfejs powinien:

• być tylko nagłówkiem, bez żadnych zależności, ale <mpi.h>i biblioteką standardową,
• być ogólne i rozszerzalne,
• nie blokuj tylko (jeśli chcesz blokować, to blokuj jawnie, nie domyślnie),
• pozwalają na ciągłe łączenie operacji nieblokujących,
• obsługa rozszerzalnej i wydajnej serializacji (np. Boost.Fusion, dzięki czemu współpracuje z RMA),
• mieć zerową karę abstrakcji (tj. być co najmniej tak szybka jak interfejs C),
• bądź bezpieczny (destruktor niegotowej przyszłości nazywa się? -> std :: terminate!),
• mieć mocny DEBUGtryb z mnóstwem twierdzeń,
• wyjątkowo bezpieczny dla typów (koniec ints / void * dla wszystkiego, do cholery chcę, żeby tagi były typami!),
• powinien działać z lambdami (np. wszystkie redukuj + lambda),
• konsekwentnie używaj wyjątków jako mechanizmu raportowania i obsługi błędów (koniec kodów błędów! koniec argumentów wyjściowych funkcji!),
• MPI-IO powinien oferować nieblokujący interfejs I / O w stylu Boost.AFIO,
• i postępuj zgodnie z dobrymi nowoczesnymi praktykami projektowania interfejsu C ++ (definiuj typy regularne, funkcje nieprzyjazne dla innych członków, baw się dobrze semantyką ruchu, operacje zakresu wsparcia, ...)

Dodatki:

• pozwól mi wybrać wykonawcę środowiska MPI, to znaczy, której puli wątków używa. W tej chwili możesz mieć aplikacje z mieszanką OpenMP, MPI, CUDA i TBB ... w tym samym czasie, gdzie każdy czas działania uważa, że ​​jest właścicielem środowiska, i dlatego pytaj system operacyjny o wątki za każdym razem, gdy mają na to ochotę to. Poważnie?

• użyj konwencji nazewnictwa STL (i Boost). Czemu? Każdy programista w C ++ o tym wie.

Chcę napisać taki kod:

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

Pomyśl, jak można połączyć wszystkie te operacje za pomocą MPI_C request. Będziesz musiał przetestować na wielu (lub na każdym) pośrednim kroku przez wiele niepowiązanych kodów, aby sprawdzić, czy możesz przyspieszyć swój łańcuch bez blokowania .

Osobiście nie mam nic przeciwko wywoływaniu długich funkcji w stylu C z dokładnie tego powodu, o którym wspomniał Wolfgang; jest naprawdę niewiele miejsc, do których trzeba do nich zadzwonić, a nawet wtedy prawie zawsze otacza je jakiś kod wyższego poziomu.

Jedynymi rzeczami, które naprawdę przeszkadzają mi w MPI w stylu C, są niestandardowe typy danych i, w mniejszym stopniu, niestandardowe operacje (ponieważ używam ich rzadziej). Jeśli chodzi o niestandardowe typy danych, powiedziałbym, że dobry interfejs C ++ powinien być w stanie obsługiwać ogólny i wydajny sposób obsługi tego, najprawdopodobniej poprzez serializację. Jest to oczywiście trasa, boost.mpiktórą obrałeś, a jeśli będziesz ostrożny , zaoszczędzisz dużo czasu.

Jeśli chodzi boost.mpio dodatkowe zależności (zwłaszcza, że boost.serializationsam nie jest tylko nagłówkiem), ostatnio natknąłem się na bibliotekę serializacji C ++ zawierającą tylko nagłówki, zwaną zbożem, która wydaje się obiecująca; przyznano, że wymaga kompilatora zgodnego z C ++ 11. Warto przyjrzeć się i wykorzystać jako podstawę czegoś podobnego do boost.mpi.

Projekt github easyLambda zapewnia interfejs wysokiego poziomu do MPI z C ++ 14.

Myślę, że projekt ma podobne cele i da pewne wyobrażenie o tym, co może być i co jest robione w tej dziedzinie przy użyciu nowoczesnego C ++. Kierowanie innymi wysiłkami, a także sama easyLambda.

Początkowe testy wydajności i wierszy kodu wykazały obiecujące wyniki.

Poniżej znajduje się krótki opis funkcji i interfejsu, który zapewnia.

Interfejs oparty jest na programowaniu przepływu danych i funkcyjnych operacjach listowych, które zapewniają nieodłączną równoległość. Równoległość jest wyrażona jako właściwość zadania. Przydziału procesu i dystrybucji danych dla zadania można zażądać za pomocą właściwości .prll (). Istnieje wiele przykładów na stronie internetowej i repozytorium kodów, które obejmują dynamikę molekularną LAMMPS po przetworzeniu, wyraźne rozwiązanie różnic skończonych do równania ciepła, regresję logistyczną itp. Jako przykład problem dyfuzji ciepła omawiany w artykule HPC umiera ... można wyrazić w ~ 20 wierszach kodu.

Mam nadzieję, że można podawać linki zamiast dodawać tutaj więcej szczegółów i przykładowych kodów.

Disclamer: Jestem autorem biblioteki. Uważam, że nie robię nic złego, mając nadzieję uzyskać konstruktywną informację zwrotną na temat obecnego interfejsu easyLambda, który może być korzystny dla easyLambda i innych projektów realizujących podobne cele.