Ich schreibe Matlab-Code, um ein 3-dimensionales Integral auszuführen:
%Vor% für die zugehörige int3d_par (parfor) Version, öffne ich einen Matlab-Pool und ersetze einfach for durch parfor . Ich bekomme ziemlich gute Beschleunigung, indem ich es auf mehr Kernen laufen lasse (meine Tests sind von 2 bis 8 Kerne).
Wenn ich jedoch die gleiche Integration im Batch-Modus mit:
ausführe %Vor% Ich merke, dass es viel, viel schneller ist. Warum sollte diese Integration im Batch-Modus anders sein als in parfor ?
Als Referenz teste ich den Code mit N aus kleinen Zahlen wie 10 und 20 (um die Konstante in der polynomischen Approximation der Laufzeit zu erhalten) zu größeren Zahlen wie 1000 und 2000. Dieser Algorithmus wird kubisch skalieren, da ich den Anzahl der Integrationsknoten in der Richtung theta und phi als konstantes Vielfaches der gegebenen N .
Für 2000 Knoten dauert die parfor Version etwa 630 Sekunden, während die gleiche Anzahl an Knoten im Batch-Modus etwa 19 Sekunden benötigt (wobei etwa 12 Sekunden einfach Overhead-Kommunikation sind, die wir auch für 10 Integrationsknoten erhalten) / p>
Nachdem ich mit Mathworks support gesprochen habe, scheint es mir ein grundlegendes Missverständnis zu geben, wie parfor funktioniert. Ich hatte den Eindruck, dass parfor wie openMP funktioniert, während der Batch-Modus wie mpi in Bezug auf geteilten vs verteilten Speicher funktioniert.
Es stellt sich heraus, dass parfor tatsächlich auch verteilten Speicher verwendet. Wenn ich zum Beispiel 4 Batch-Funktionen erstelle, passiert der Overhead für die Erstellung eines neuen Prozesses viermal. Ich dachte, dass die Verwendung von parfor dazu führen würde, dass dieser Overhead nur einmal auftritt und dass parfor dann im selben Speicherbereich stattfinden würde. Dies ist nicht der Fall.
In meinem Beispielcode stellt sich heraus, dass ich für jede Iteration von parfor tatsächlich den Overhead erhalte, einen neuen Thread zu erstellen. Wenn ich "Äpfel mit Äpfeln" vergleiche, sollte ich wirklich die gleiche Anzahl von Stapelaufrufen erstellen wie Iterationen in der parfor -Schleife. Das war der Grund, warum die Funktion parfor so viel länger benötigte - ich hatte viel mehr Aufwand für Multiprocessing.
Tags und Links performance matlab runtime parfor