LabVIEWForum.de - parallele Ausführung von for-loops

LabVIEWForum.de

Normale Version: parallele Ausführung von for-loops
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo,

mir ist eher zufällig aufgefallen, dass in bestimmten Fällen die parallele Ausführung einer for-Schleife deutlich langsamer sein kann als die nicht-parallele. Aufgefallen ist mir dies bei der Auswertung eines sehr großen Datensatzes (einige 100.000 Werte). Die parallele Ausführung benötigte einige 100s. Eine nicht-parallele Ausführung benötigte nur etwa 1s, war also wesentlich schneller. Im angehangen Beispiel habe ich eine ähnliche Routine mit Zufallsdaten erstellt. Hier ist die nicht-parallele Schleife etwa 4mal schneller. Das Beispiel ist natürlich sinnlos, aber mir geht es um den Effekt. Real musste ich aus bestimmten Proben einige herausfiltern (am Probennamen (String) erkennbar). Mein PC (Win 7 / 64Bit) läuft mit einem i5-4590 (4 Kerne). Habe LabVIEW 2016 32Bit und LabVIEW 2016 64 Bit installiert.

Meine eigentlichen Fragen lauten: Ist dieses Problem bekannt? Wenn ja, gibt es irgendwelche Regeln bzw. ist es irgendwie erkennbar, ob die parallele Ausführung einer Schleife zu tatsächlich schnelleren Laufzeiten führt oder muss jedesmal getestet werden? Kann es sich um ein lokales Problem handeln?

Vielen Dank!
stsc
... wie das immer so ist, habe ich jetzt - nach (!) dem Erstellen des Themas - eine Antwort in der Hilfe gefunden:

"Beim Aktivieren paralleler Schleifeniterationen kommt es zu zusätzlichem Ausführungs-Overhead. For-Schleifen, die nicht rechenintensiv sind, sollten nicht parallel ausgeführt werden. Die Leistung kann nur verbessert werden, wenn gleichzeitig zum Overhead eine Verringerung der Ausführungszeit erfolgt."

Da die Schleife absolut nicht rechenintensiv ist, dominiert der Overhead die Ausführungszeit und bringt keine zeitliche Verbesserung.

Dennoch vielen Dank und sorry, dass ich nicht gründlich genug gelesen habe :-)
Hallo stsc,

Zitat:Das Beispiel ist natürlich sinnlos, aber mir geht es um den Effekt.
Dein Beispiel ist sinnlos - und dazzu noch äußerst schlecht gewählt.
Durch den ConditionalTunnel hebelst du die parallele Abarbeitung weitestgehend aus: jetzt muss LabVIEW nicht nur die parallel berechneten Daten wieder zum Ausgangsarray zusammenführen, sondern nebenbei auch noch mit verschieden großen "Ausgangs-Chunks" klarkommen!
Dazu dann noch eine Funktion, die wahrscheinlich schlecht parallelisierbar ist: RegEx verwenden im Hintergrund einen DLL-Aufruf…

Bei "simpler" Mathematik sieht die Welt schon ganz anders aus:
[attachment=60222]

Zusammenfassung:
Wenn du per paralleler FOR-Loop rechnen willst, bietet sich ein Benchmark an, um die Sinnhaftigkeit zu prüfen…
Hallo Gerd,

ja, das Beispiel erscheint sinnlos, aber es spiegelt genau mein Problem wieder. Ich musste ConditionalTunnel verwenden, da ich nur bestimmte Daten aus einem Array weiter verwenden durfte (es war ein 2D-Array und in der ersten Spalte stand der Inhalt für die Prüfung). In der Schleife fand die Prüfung statt (Muster im String der ersten Spalte) und nur bestimmte Werte (Zeilen des 2D-Arrays) wurden in das nun reduzierte Array übernommen. Daher der ConditionalTunnel. Ich wusste nicht, dass ich durch den ConditionalTunnel die parallele Ausführung ausheble. Und ich wusste nicht, dass die Funktion RegEx schwer parallelisierbar ist. Wahrscheinlich haben sich diese beiden Konflikte akkumuliert und daher war die parallele Schleife wesentlich langsamer. Danke für die Hinweise!

Viele Grüße,
st.
Hallo stsc,

Zitat:Ich wusste nicht, dass ich durch den ConditionalTunnel die parallele Ausführung ausheble.
1. Ganz so strikt würde ich es nicht formulieren, immerhin ist ja der ConditionalTunnel auch in parallelisierten FOR-Loops erlaubt.
Aber er führt dazu, dass LabVIEW dann eben nicht mehr gleich große Ergebnis-Arrays aus den parallelen Ausführungen wieder zusammenführen muss, sondern jetzt mit sehr Arrays variabler Größe hantieren muss.
(Bevor es die ConditionalTunnels gab, musste man mit Case-Struktur, BuildArray und Schieberegister arbeiten - damit war die Parallelisierung gleich komplett tabu…)

2. RegEx werden über die "PCRE-Bibliothek" geparst, das meinte ich mit "DLL-Aufruf". Die Funktion MusterSuchen scheint diese aber nicht zu verwenden, im Gegensatz zum deutlich langsameren MusterSuchenUndErsetzen… (Siehe LabVIEW-Hilfe)

Wichtig ist halt nur, dass man mit einem Benchmark prüft, ob die Parallelisierung überhaupt sinnvoll ist…
Hallo Gerd,

danke für die Tipps. In Zukunft werde ich genauer prüfen, ob eine Parallelisierung tatsächlich Verbesserungen bringt und nicht stur jede Schleife parallelisieren, welche parallelisierbar ist. So habe ich das nämlich bisher getan.

Vielen Dank und viele Grüße
st.
Referenz-URLs