Nicht blockierende Version von MPI

8

Ich habe eine Reihe von MPI-Prozessen, die Anforderungsnachrichten hin und her austauschen. Prozesse wissen nicht, welche anderen Prozesse ihnen Nachrichten senden oder wie viele. In dieser Situation möchte ich auf effiziente Weise feststellen, ob alle anderen Prozesse das Senden von Nachrichten für erledigt halten.

Dies würde perfekt durch die folgende nicht blockierende Version von MPI_Barrier erreicht, die wir MPI_Ibarrier nennen werden:

int MPI_Ibarrier(MPI_Comm comm, MPI_Request* request);

MPI_Ibarrier würde sofort zurückkehren, und Standardoperationen für das Anforderungsobjekt würden uns wissen lassen, wenn die Barriere von allen erreicht wurde.

Gibt es eine Möglichkeit, dieses Verhalten in MPI 2 effizient zu simulieren (dh ohne offizielle nicht blockierende Kollektive)?

mpi

— Geoffrey Irving
quelle

Tatsächlich ist MPI_Ibarrier in Bezug auf die MPI 3-Arbeitsgruppe überall in Google vertreten. Jetzt brauchen wir nur noch die Zukunft ...

— Geoffrey Irving

Ich sehe nicht, wie das funktionieren würde. Vermutlich planen Sie, MPI_Ibarrier für einen Prozess aufzurufen, wenn die Nachrichten für diese Iteration fertig sind, und dann MPI_Wait aufzurufen, wenn? Wenn Aufgaben nach MPI_Ibarrier ausgeführt werden, wie weit dürfen sie kommen, bevor sie MPI_Wait aufrufen müssen? Wenn sie so weit kommen dürfen, bevor sie wissen müssen, dass alle Prozesse abgeschlossen sind, warum nicht einfach MPI_Barrier an diesen Punkt setzen? IME, MPI_Barrier ist fast immer falsch, Ihren Code einzugeben, außer zu Debugging-Zwecken. Es gibt fast immer eine effizientere Möglichkeit, den Code zu strukturieren.

— Bill Barth

In diesem Fall halte ich MPI_Ibarrier für den optimalen Weg, da Nachrichten aus der nächsten Kommunikationsepoche nicht gestartet werden können, ohne einen sehr großen Speicherbereich freizugeben und einen neuen zuzuweisen. Die Barriere wird benötigt, um zu wissen, wann dieser Speicher freigegeben werden kann, und nicht direkt, wann zukünftige Nachrichten gesendet werden können.

— Geoffrey Irving

11

Bemerkenswerterweise MPI_Ibarrierist dies eine sehr nützliche Routine. Sie können beispielsweise eine unstrukturierte Runde von Nachrichten an Ränge senden, die nicht wissen, wie viele Nachrichten empfangen werden sollen, indem Sie mit senden MPI_Issend(ja, eine seltene Verwendung des synchronen Sendens ) und dann eine abwechselnde Schleife eingeben MPI_Testall(um zu sehen, ob die Sendungen abgeschlossen sind). und MPI_Iprobe(um eingehende Nachrichten zu verarbeiten). Wenn der Sendevorgang abgeschlossen ist, veröffentlichen Sie MPI_Ibarrierdie Barriere und testen sie alternativ auf eingehende Nachrichten. Torsten Hoefler hat ein Papier dazu, in dem er die Optimalität der Kommunikation unter Beweis stellt, siehe Algorithmus 2: http://unixer.de/publications/img/hoefler-dsde-protocols.pdf

Beachten Sie, dass eine Barriere nicht sicherstellt, dass Punkt-zu-Punkt-Nachrichten oder andere nicht blockierende Kollektive, die vor Abschluss der Barriere veröffentlicht wurden, abgeschlossen sind. Wenn Sie möchten, dass sie abgeschlossen sind, müssen Sie sicherstellen, dass sie abgeschlossen sind, bevor Sie die Barriere veröffentlichen. Wie Bill sagt, ist (Blockieren) MPI_Barrierin den meisten Fällen falsch / unnötig. Eine Ausnahme ist die Kommunikation über Seitenkanäle wie das Dateisystem.

Obwohl es keine ähnlich performante Möglichkeit gibt, MPI_Ibarriermit MPI-2 zu simulieren , bietet MPICH2 MPIX_Ibarrierim 1,5-Zweig (Strom). Lieferantennetzwerke unterstützen diese Vorgänge im Allgemeinen, sodass die Lieferantenimplementierungen (die im Allgemeinen von MPICH2 abgeleitet sind) nur eine Schnittstelle benötigen. Sobald ihre Patches auf 1.5 MPI_Ibarrierverschoben werden, sollten andere nicht blockierende Kollektive unterstützt werden. Der Open MPI-Entwicklungszweig hat eine Implementierung MPI_Ibarrierbasierend auf libNBC.

— Jed Brown
quelle

Ich denke, Sie können dies mit einer Flag-Nachricht / einem speziellen Tag implementieren, das effizienter ist, als es eine Barriere jeglicher Art sein könnte. Haben Sie einen Link zu Hoeflers Artikel?

— Bill Barth

@ BillBarth Denken Sie daran, dass dies unstrukturiert ist und Sie nicht wissen, wie viele Nachrichten Sie empfangen müssen. Wer würde den Tag an wen senden? Am Ende implementieren Sie Ihre eigene Ibarrier über Punkt-zu-Punkt, was langsamer ist als eine native Implementierung. Das Papier ist wahrscheinlich auf seiner Website. Wir haben vor ein paar Monaten darüber gesprochen.

— Jed Brown

Die Implementierung meiner eigenen Baumreduktion über Punkt-zu-Punkt ist genau das, was ich letztendlich getan habe. Es gibt nur 36 Barrier Calls im gesamten Programm, daher sollte die Verlangsamung nicht problematisch sein.

— Geoffrey Irving

8

Siehe http://www.unixer.de/research/nbcoll/ , insbesondere http://www.unixer.de/research/nbcoll/libnbc/ , die Referenzimplementierung, die über MPI-1 liegt. Wie Jed sagte, hat MPICH2 1.5 bereits NBC und die Implementierung ähnelt der von Torsten (obwohl dies aufgrund des geringeren Overheads mit ziemlicher Sicherheit schneller ist).

— Jeff
quelle

Nicht blockierende Version von MPI_Barrier in MPI 2