Asynchrones finites Differenzschema mit MPI_Put

8

Ein Papier von Donzis & amp; Aditya schlägt vor, dass es möglich ist, ein finites Differenzenschema zu verwenden, das eine Verzögerung in der Schablone haben könnte. Was bedeutet das? Ein FD-Schema könnte verwendet werden, um die Wärmeleitungsgleichung zu lösen, und liest (oder eine Vereinfachung davon)

%Vor%

bedeutet, dass der Wert beim nächsten Zeitschritt von dem Wert an der gleichen Position und seinen Nachbarn im vorherigen Zeitschritt abhängt.

Dieses Problem kann leicht parallellisiert werden, indem die (in unserem Fall 1D) Domäne auf die verschiedenen Prozessoren aufgeteilt wird. Für die Berechnung der Randknoten an einem Prozessor benötigen wir jedoch eine Kommunikation, da das Element u[t,i+-1] nur auf einem anderen Prozessor verfügbar ist.

Das Problem wird in der folgenden Grafik veranschaulicht, die dem zitierten Papier entnommen ist.

Eine MPI-Implementierung verwendet möglicherweise MPI_Send und MPI_Recv für die synchrone Berechnung. Da die Berechnung selbst relativ einfach ist, kann die Kommunikation zu einem möglichen Engpass werden.

Eine Lösung für das Problem ist in dem Papier angegeben:

Anstelle eines synchronen Prozesses nehmen Sie einfach die verfügbare Begrenzungsnotiz, obwohl dies der Wert eines früheren Zeitschritts sein könnte. Die Methode konvergiert dann (unter bestimmten Annahmen) immer noch

Für meine Arbeit möchte ich den asynchronen MPI-Fall implementieren (der nicht Teil der Arbeit ist). Der synchrone Teil, der MPI_Send und MPI_Recv verwendet, funktioniert ordnungsgemäß. Ich erweiterte den Speicher um zwei Elemente als Geisterzellen für die benachbarten Elemente und sendete die benötigten Werte per Senden und Empfangen. Der folgende Code ist im Wesentlichen die Implementierung der obigen Abbildung und wird während jedes Zeitschritts vor der Berechnung durchgeführt.

%Vor%

Ich bin kein MPI-Experte. Ich fand heraus, dass MPI_Put möglicherweise das ist, was ich für den asynchronen Fall benötige und lese ein wenig, ich kam mit der folgenden Implementierung.

Vor der Zeitschleife:

%Vor%

Innerhalb der Zeitschleife:

%Vor%

setzt die benötigten Elemente in das Fenster, nämlich boundary (Array mit zwei Elementen) auf die benachbarten Prozessoren und übernimmt die Werte u[0] und u[NpP+1] vom Array boundary selbst. Diese Implementierung funktioniert und ich bekomme das gleiche Ergebnis mit MPI_Send/Recv . Dies ist jedoch nicht wirklich asynchron, da ich immer MPI_Win_fence verwende, was, soweit ich es verstanden habe, die Synchronisation gewährleistet.

Das Problem ist: Wenn ich die MPI_Win_fence herausnehme, werden die Werte innerhalb von boundary niemals aktualisiert und behalten die ursprünglichen Werte bei. Mein Verständnis war, dass man ohne MPI_Win_fence irgendeinen Wert nehmen würde, der in boundary verfügbar ist, der von einem benachbarten Prozessor aktualisiert wurde (oder auch nicht).

Hat jemand eine Idee, die Verwendung von MPI_Win_fence zu vermeiden und gleichzeitig das Problem zu lösen, dass die Werte in boundary niemals aktualisiert werden?

Ich bin mir auch nicht sicher, ob der von mir bereitgestellte Code ausreicht, um mein Problem zu verstehen oder irgendwelche Hinweise zu geben. Wenn das der Fall ist, zögern Sie nicht zu fragen, da ich versuchen werde, alle Teile hinzuzufügen, die fehlen.

    
k1next 10.10.2014, 12:20
quelle

2 Antworten

2

Die folgenden Arbeiten scheinen für mich im Sinne einer korrekten Ausführung zu funktionieren - eine kleine 1d-Wärmeleitungsgleichung, die aus einem unserer Tutorials stammt und für die RMA-Sachen verwendet wird:

%Vor%

Im Code habe ich sogar Ränge, die jedes Mal um weitere 10ms warten, um sicherzustellen, dass die Dinge nicht mehr synchron sind. Aber wenn man Spuren betrachtet, sieht es tatsächlich so aus, als würden die Dinge ziemlich synchronisiert bleiben. Ich weiß nicht, ob dieser hohe Grad an Synchronität durch die Optimierung des Codes behoben werden kann, oder ist eine Einschränkung der Implementierung (IntelMPI 5.0.1), oder passiert einfach, weil die Zeit, die in der Berechnung verstreicht, zu wenig und Kommunikationszeit ist ist dominierend (aber in Bezug auf das letzte scheint das Anlassen des usleep-Intervalls keinen Effekt zu haben).

%Vor%     
Jonathan Dursi 13.10.2014, 01:19
quelle
1

Dies ist ein Klon von Jonathen Dursis Post, aber mit Änderungen für die MPI-3-RMA-Synchronisation ...

%Vor%     
Jeff 05.04.2015 00:06
quelle