Welche BG/L MPI Tuning Parameter können helfen?
Autor: M.Pütz, IBM
-
-env "BGLMPI_MAPPING=TXYZ"
dreht im VN Mode die Allozierungsreihenfolge von "2nd CPU last" to "2nd CPU first"Diese Umgebungsvariable kann nicht gesetzt werden, wenn bei mpirun ein explizites Mappingfile mittels -mapfile mitgegeben wird.
-
-env "BGLMPI_RVZ=X"
kontrolliert, ab welcher Nachrichtengröße X das MPI Rendevouz Protokoll verwendet wird-
Synonyme : BGLMPI_EAGER und BGLMPI_RZV
Der gegenwärtige Standardwert von X=1000 ist relativ klein gesetzt, um
- im Co-Prozessor Modus die 2. CPU für Kommunikation zu nutzen (nur für Rendevouz Nachrichten)
- Hot-Spots in ungeordneter P2P Kommunikation zu vermeiden (adaptives Routing)
Leider führt dies auch zu einer deutlichen Bandbreiteneinbuße für mittlere Nachrichtenlängen zwischen X und 100000 Bytes.
Sehr kleine Nachrichten ( < 256 Bytes) sind nicht betroffen, da diese immer ohne Rendevouz und in einem Packet versendet werden.
Nach meiner Erfahrung fahren viele Codes mit einem hohem BGLMPI_RVZ Schwellwert (z.B. 200000) deutlich besser, so dass das Rendevouz-Protokoll effektiv nur bei sehr großen Nachrichten zum Tragen kommt, wenn der Durchsatz von Eager- und Rendevouz-Protokoll nahezu gleich sind. Das gilt insbesondere dann, wenn das Problem gut auf den Torus gemappt werden kann, so dass P2P Kommunikation in erster Linie zwischen nächsten und übernächsten Nachbarn stattfindet.
Es gibt aber auch Anwendungen, bei denen BGLMPI_RVZ=0 sinnvoll ist, um so effektiv das Eager-Protokoll auszuschalten, insbesondere wenn die Anwendung sehr viele kleine Nachrichten quer durch den Torus feuert, die dann mit Nachrichten die über das Eager-Protokoll versendet werden Hotspots im Torus bilden können.
Zusammenfassend kann ich sagen, dass BGLMPI_RVZ=0 oder BGLMPI_RVZ > 100000 für mich bisher die besten Ergebnisse erbracht haben. Ein mittlerer Wert von 1000-10000 scheint beim gegenwärtigen MPI Layer auf BG/L fast immer schlechter zu sein, als die beiden Extreme.
last change 27.03.2006 |
