Parallelisieren von Schleifen

Hallo,

das Tool zum finden ist super nur habe ich ein Überlegungsprobem mit den Schleifen "möglicherweise parallelisierbar" und da geht es um mögliche Nebenwirkungen (side effects) der beinhaltenden VIs.

1. *side effects* ich denke, wenn das VI bei seiner Rechnung nichts beeinflusst, dass den Input dieses VI beeinflusst sollte das gehen? Also Output der VIs und globale Variabe. - stimmt das?

2. Aber damit das beinhaltende VI mehrfach laufen kann muss ich es doch reentrant kompilieren? - richtig?

3. aber auch die komplette VI Kette, wenn sie in Schleifen Werte speichert, reentrant?

Bitte um Hilfe

Danke

Gottfried

Anzeige

(15.03.2013 11:01 )gottfried schrieb:  1. *side effects* ich denke, wenn das VI bei seiner Rechnung nichts beeinflusst, dass den Input dieses VI beeinflusst sollte das gehen? Also Output der VIs und globale Variabe. - stimmt das?

Sorry, verstehe deine Frage nicht.

(15.03.2013 11:01 )gottfried schrieb:  2. Aber damit das beinhaltende VI mehrfach laufen kann muss ich es doch reentrant kompilieren? - richtig?

Ja.

(15.03.2013 11:01 )gottfried schrieb:  3. aber auch die komplette VI Kette, wenn sie in Schleifen Werte speichert, reentrant?

Ja, wenn die SubVIs auch parallel laufen sollen.

Gruß, Jens

Hallo,

hier meine Erfahrungen:

* das in Frage kommende Programm mit Testdaten laufen lassen und das Resultat notieren
* mit dem Taskmanager schauen ob noch freie Kapazität da ist
* mit Profile die rechenzeitintensiven VIs ausfindig machen - die sind das Ziel der Parallelisierung
* die Schleife die diese VIs beinhaltet parallelisieren
* rechenzeitintensiven VIs reentrant machen (preallocate)
* alle sub VIs zwischen der Schleife und dem rechenintensiven VI müssen reentrant sein
* Programm noch einmal laufen lassen und sich freuen (oder wundern wieso etwas anderes herauskommt :-)
* Ist nun die Rechenzeit auf 100%? - OK

funktioniert toll.

Stolpersteine (für mich) waren:

* in VIs gespeicherte Werte - diese VIs sind grundsätzlich nicht parallelisierbar
* in Vision sind es die mit IMAQ_create eingegebenen (fixen) Namen. Da hilft sich die Referenz des VIs zu nehmen und nachzusehen ob das ein Clon ist und in diesem Fall den ClonNamen anzufügen.

Gottfried

PS.: vielleicht können noch Andere hier ihre Erfahrungen zu einem gemeinsamen Tutorium zusammenfügen.

Hört sich alles gut an. Aber bevor ich selbst nach diesem sagenhaftem Tool google: Ein Link oder sonstiger Finde-Hinweis wäre schon nicht schlecht. Oder bin ich hier der einzige Ahnunglose und blamiere mich jetzt mit dieser Amerkung bis auf die Knochen?

Dieses "Tool" ist Teil von LV:
Tools | Profile | find parallelizable Loops

So weit

Was mich aber irritiert (ich nicht erklären kann) ist warum die Anzeige "s/Function call" (unten) Schwachsinn ausgibt. Kannst Du das erklären?

Danke

Gottfried

Hallo Gottfried,

definiere "Schwachsinn"...

Anzeige

"Schwachsinn" lt. EDV-Duden von 1732 als definiert offensichtlich unzutreffendes Resultat einer Sequenz von Maschinenbefehlen die auf den ersten Blick richtig aussehen.

Hallo Gottfried,

du kennst das Spielchen doch schon: Welche Daten werden erwartet und welche werden stattdessen angezeigt?

Nur aufgrund der Aussage "Indicator zeigt Schwachsinn an", unterlegt mit einem Bildchen, kann hier wohl kaum jemand was substanzielles beitragen...

Hallo GerW,

Du hast _absolut_ recht. Der Effekt war (für mich) tatsächlich verblüffend: die angezeigte Rechenzeit ist gestiegen, gestoppt ist sie aber gefallen - daher meine Reaktion "Schwachsinn".

Nach einigem Abstand musste ich aber den Begriff "Schwachsinn" in eine selbstktitischere Nomenklatur "adaptieren": der gewählte Code zeigt die Rechenzeit in einem Thread, und das wird mehr wenn der Prozessor überbeschäftigt ist. Wenn ich die Zeitnehmung außerhalb der Schleife mache bekomme ich tatsächlich etwa 1/3 der Rechenzeit ohne Parallelisierung.

Gottfried hat sich geirrt nicht der Compiler ... wieder einmal ....

Danke

Gottfried

Hier noch einige Zusätze zu der weoter oben formulierten Punkteliste:

TEST:

* einen Durchlauf (aber mit heftiger CPU Last) ohne Parallelisierung investieren und einen mit
* wenn etwas anderes herauskommt die einzelnen Parallelisierungen einzeln ausschalten
* ... identische "Fälle" mehrfach "parallel" rechnen
* Paralellisierte Schleifen kann man im Prallelisierungs-Finde-Tool wieder finden
* zuerst die CPU Zeit messen und _dann_ erst Paralellisieren, "kleine" Schleifen machen diesbezüglich keinen Sinn

Gottfried