MATLAB Parfor ist langsamer als für - was ist los?

Question

der Code, den ich mit bin den Umgang hat Schleifen wie folgt aus:

bistar = zeros(numdims,numcases); 
parfor hh=1:nt  
    bistar = bistar + A(:,:,hh)*data(:,:,hh+1)' ; 
end 

für kleine nt (10).

Nach dem Timing ist es tatsächlich 100 mal langsamer als mit der normalen Schleife !!! Ich weiß, dass Parfor parallele Summen machen kann, also bin ich mir nicht sicher, warum das nicht funktioniert.

Ich betreibe

matlabpool 

mit den Out-of-the-box-Konfigurationen vor meinem Code ausgeführt wird.

Ich bin relativ neu zu Matlab, und gerade begonnen, die parallelen Funktionen zu verwenden, also bitte nicht davon ausgehen, dass ich nicht etwas dummes tun werde.

Danke!

PS: Ich habe den Code auf einem Quad Core ausgeführt, also würde ich erwarten, einige Verbesserungen zu sehen.

Answer 1

Die Partitionierung und Gruppierung der Ergebnisse (Overhead beim Teilen der Arbeit und Sammeln von Ergebnissen aus den verschiedenen Threads/Kernen) ist für kleine Werte von nt hoch. Dies ist normal, Sie würden Daten nicht für einfache Aufgaben partitionieren, die in einer einfachen Schleife schnell ausgeführt werden können.

Führen Sie immer etwas herausforderndes innerhalb der Schleife durch, das den Partitionierungsaufwand wert ist. Hier ist eine schöne introduction to parallel programming.

Die Threads kommen aus einem Thread-Pool, so dass der Overhead zum Erstellen der Threads nicht da sein sollte. Um jedoch die Teilergebnisse zu erzeugen, müssen n Matrizen aus der bistar Größe erstellt, alle Teilergebnisse berechnet und dann alle diese Teilergebnisse addiert werden (Rekombination). In einer geraden Schleife wird dies mit hoher Wahrscheinlichkeit vor Ort durchgeführt, es finden keine Zuordnungen statt.

Die vollständige Erklärung in der Hilfe (Danke für Ihren Link hierunter) ist:

Wenn die Zeit f, g zu berechnen, und h großen, parfor wird als die deutlich schneller entsprechend für Aussage, auch wenn n relativ klein ist. So

Sie sehen sie bedeuten genau das gleiche wie das, was ich meine, der Aufwand für kleine n Werte ist nur die Mühe wert, wenn das, was Sie in der Schleife zu tun ist komplex/zeitaufwendig genug.

Answer 2

Parfor kommt mit ein wenig Overhead. Wenn also nt wirklich klein ist und die Berechnung in der Schleife sehr schnell erfolgt (wie eine Addition), ist die parfor Lösung langsamer. Wenn Sie parfor auf einem Quad-Core ausführen, ist die Geschwindigkeitsverstärkung bei 1-3 Kernen nahezu linear, bei Verwendung von 4 Kernen jedoch geringer, da der letzte Kern auch Systemprozesse ausführen muss. Wenn Parfor mit 100 ms Overhead kommt, und die Berechnung in der Schleife dauert 5 ms, und wenn wir annehmen, dass die Geschwindigkeitsverstärkung linear bis zu 4 Kerne mit einem Koeffizienten von 1 ist (d. H.

).mit 4 Kernen ist die Berechnung 4-mal schneller), nt muss etwa 30 sein, damit Sie eine Geschwindigkeitsverstärkung mit parfor (150ms mit for, 132ms mit parfor) erreichen können. Wenn Sie nur 10 Iterationen ausführen würden, wäre parfor langsamer (50 ms mit for, 112 ms mit parfor).

Sie können den Overhead auf Ihrer Maschine berechnen, indem Sie die Ausführungszeit mit 1 Worker vs 0 Worker vergleichen. Sie können den Geschwindigkeitszuwachs abschätzen, indem Sie einen Liner durch die Ausführungszeiten mit 1 bis 4 Arbeitern anpassen. Dann wissen Sie, wann es sinnvoll ist, parfor zu verwenden.

Answer 3

Neben der schlechten Leistung wegen des Kommunikationsaufwands (siehe andere Antworten) gibt es einen weiteren Grund, in diesem Fall parfor nicht zu verwenden. Alles, was innerhalb der parfor in diesem Fall erfolgt, verwendet built-in multithreading. Angenommen, alle Worker laufen auf demselben PC, ist das kein Vorteil, da ein einzelner Aufruf bereits alle Kerne Ihres Prozessors nutzt.