Extreme Laufzeitkosten durch Dynamic Dispatching?

Hallo ihr wenigen LVOOP Nutzer *BNT zuwink*,

ich habe ein kleines Problem. Wollte mir ein Interpolationstool erstellen und um Rundungsfehlern / Fehlern bei prüfen auf Gleichheit etc. vorzubeugen habe ich mal eine einheitliche Number Klasse erstellt (dachte mir das wäre auch für andere Dinge ganz praktisch), die zweistufig erst über den allgemeinen Kindtyp Float, Signed und Unsigned auf die tatsächlichen Datentypen (U8,U16 etc. pp) als (Enkel) projiziert.

Initialisiert werden kann die Elternklasse "Number" über einen Variant alternativ jede Kindklasse mit dem korrekten Datentyp (U8 mit nem U8 etc. pp; typischerweise dürfte Initialisieren über Variant praktischer sein).

Soweit zur Architektur.

Jetzt habe ich darauf mal einen simplen Entwurf für Addition nachgebildet (es wird festgestellt ob die Datentypen identisch sind, wenn ja, wird einfach auf niederster Ebene die normale Addition durchgeführt. Aktuell ist das noch rudimentär implementiert, so dass ich die Laufzeit für die Kernfunktion addieren überprüfen kann (aktuell werden beliebige Datentypen für identisch gehalten; aber das stört ja nicht so lange die wirklich identisch sind).

Beim Testen (in der Number Klasse das VI "RuntimeTester") der Laufzeit kam dann der Schock. Mit Performanceeinbußen durch den Overhead (mehr Funktionen drumherum, mehr Speicherbedarf) hatte ich ja gerechnet, aber nach dem Tester zu urteilen liegen die Einbußen bei einem Faktor 1000 langsamer (etwa).

   

Und das kann ich mir überhaupt nicht erklären (intern macht der: Arrays mit Zahlen und "Number" Objekten Auswürfeln und dann einmal "normal" addieren und einmal mit der Klassenfunktion und gibt dafür die benötigte Zeit aus).
Hab auch schon rumgespielt mit Ablaufinvarianter Ausführung und höherer Priorität, aber von dem Faktor 1000 kommt man nicht wirklich deutlich weg.

Deswegen meine Frage: Produziert das immer so einen drastischen Overhead? Bin eigentlich beim LVOOP programmieren immer davon ausgegangen, dass ich im Zweifel lieber viele VIs mache als weniger, um die Wartbarkeit einzelner Komponenten besser zu gewährleisten. Muss man davon doch Abstand nehmen und nur Komplexe Dinge in Objekte packen? Und sich doch gedanken um den Zeitverbrauch machen... ?

Gruß Kiesch

Scheints BNT hat hier noch nicht wieder vorbeigeschaut...

Hat wenigstens irgendjemand von denen die das scheinbar auch getestet haben ne Meinung?

Wie gesagt, könnte auch an schlechter Ausführungsoptimierung liegen. Flaschenhals könnte dabei die nur sequentielle Ausführung der einzelnen VIs sein - Allerdings habe ich die schon auf Ablaufinvariant konfiguriert und das scheint auch einen gewissen Performancegewinn zu bringen. Parrallele Ausführung mehrere Iterationen macht scheinbar auch einen gewissen Performancegewinn.
Hat da noch jemand Ideen an welcher Ecke man drehen muss? Oder kann man die VIs vielleicht noch auf Performance optimieren? Vielleicht mache ich ja auch einfach einen simplen Denkfehler...

Mein Gedanke war, dass der einzige Overhead der entsteht im wesentlichen durch zusätzliche Abfragen (die Cases die Vergleichsoperationen machen etc.) Zustande kommt. Außerdem war ich davon ausgegangen, dass ich am besten im Originaldatentyp speichere (statt als Variant), weil dann die Konversion von Variant auf Zahl wegfällt. Ist das vielleicht auch ein Ansatzpunkt?
Oder ist das Hauptproblem wirklich einfach nur die Ladezeit für einzelne VIs? Wie gesagt, grundsätlich meint NI dazu, dass dynamic dispatching nicht wesentlich mehr Performance frisst als static dispatching - aber dabei bleibt eben trotzdem noch die Zeit übrig die es braucht die einzelnen SubVIs zu laden (im Gegensatz zu einer Inlineausführung wie beim Einfachen Addieren das als Zeitreferenz fungiert).

Vielleicht noch als Zusätliche Info: Beim kompilieren in eine *.exe scheint sich die Laufzeit nicht wirklich sichtbar zu ändern. Hätte da schon etwas mehr Optimierung vom Compiler erwartet, gerade da hier offensichtlich sehr viel Luft für Optimierung ist...

Hallo Kiesch,

Zitat:Vielleicht noch als Zusätliche Info: Beim kompilieren in eine *.exe scheint sich die Laufzeit nicht wirklich sichtbar zu ändern. Hätte da schon etwas mehr Optimierung vom Compiler erwartet, gerade da hier offensichtlich sehr viel Luft für Optimierung ist...

Wieso? Auch in der Entwicklungsumgebung führst du doch kompilierten Code aus! LabVIEW ist KEIN Interpreter!
Der AppBuilder packt den dann nur noch in eine andere Struktur (EXE) und führt nur minimale Änderungen durch (Debugging entfernen etc.)...

Hi Kiesch
Ich habe Urlaub, daher schaue ich zur Zeit nur selten rein.

Du schilderst einen interessanten Fall. Ich bin mir aber nicht sicher, ob der Vergleich der Performance von nativen elementaren mathematischen Operationen und der Implementierung solcher mit LVOOP geeignet ist, um die Performance von dynamic-dispatching zu beurteilen.

Schon die Addition von zwei Double-Array's würde man doch einfacher und performanter implementieren, indem man Sie mit Hilfe das Add-Operators addiert, ohne Schleife! Ich weis auch nicht genau, ob der Compiler das Schleifen-Konstrukt erkennt und wegoptimiert. Es könnte sogar sein, dass der Compiler erkennt, dass in dem ersten Fall in der While-Schleife zwei konstante Arrays addiert werden, diese Addition nur genau einmal vor der Ausführung der Schleife berechnet und das Ergebnis in die Sequenz einsetzt. Darauf könnte die Ausführungszeit von 0 ms hindeuten.

Auch ist die Zeitmessung nicht gut implementiert. Jeder der beiden Algorithmen sollte zwischen den Timern vielfach ausgeführt werden. Um den Optimizer auszuschalten, würde ich auch Zufallszahlen zu den Array-Elementen addieren.

Weiteres:
- In zweiten einen Fall versuchst Du die Schleife zu parallelisieren, in dem ersten Fall nicht.
- In zweiten einen Fall gibt es eine Case-Struktur, in dem ersten Fall nicht.

Der obige Vergleich hinkt also schon aus grundsätzlichen Gründen.

Ich habe in Deine Klassen-Implemetierung noch nicht wirklich reingeschaut. Versuch doch erst einmal die obigen Kritikpunkte zu beseitigen. Dann sehen wir weiter.

Gruß Holger

---

Hi Kiesch
bei der ersten Durchsicht der Klassen-Implementierung ist mir aufgefallen, dass Du z.B. I8 + I8 = I8 rechnest. Was ist das Ergebnis von 127 + 127 = ?

Ich würde doch besser als Ergebnis ein I16 annehmen, um Probleme mit Wertebereichsüberschreitungen zu vermeiden. Falls das explizit nicht erwünscht ist, solltest Du aber eine entsprechende Warnung zurückgeben!

Gruß Holger

Hi,

Sorry falls ich jetzt grad nicht exakt auf meinen Code bezug nehmen kann, da mir das Update tool Labview auf dem Rechner hier geschossen hat und mein Laptop dummerweise zuhause steht. Sollte ich Müll erzählen korrigier ich das heute abend ^^

Zur Sache:

@Gerd

Hatte eher daran gedacht, das in der Kompilierten exe die Interne Struktur ja nicht mehr zwingend aufrecht erhalten werden muss, sprich: das die SubVIs inlined werden können und die Ausführung dadurch deutlich beschleunigt. Aber da hab ich dann wohl entweder den Fehler gemacht, zu denken das die Äußere Präsentation auch dem entspricht was unter der Haube passiert, oder Labview optimiert an der Stelle einfach nicht so brutal wie nur möglich.
Achso, wozu mir nebenbei auch grade einfällt das mir bei dem Projekt Labview auch paarmal abgeraucht ist wenn ich nach ner Testausführung am Tester VI den Code geändert hab... (festgefressen beim neu compilieren schien mir).

(11.12.2012 13:34 )BNT schrieb:  Hi Kiesch
Ich habe Urlaub, daher schaue ich zur Zeit nur selten rein.

Du schilderst einen interessanten Fall. Ich bin mir aber nicht sicher, ob der Vergleich der Performance von nativen elementaren mathematischen Operationen und der Implementierung solcher mit LVOOP geeignet ist, um die Performance von dynamic-dispatching zu beurteilen.

Ja okay, ist vielleicht unglücklich formuliert. Letztlich läuft es darauf hinaus, das der Laufzeitverlust eben vom Weggehen von nativen LV Funktionen herrührt und vom Wechsel auf mindestens ein VI das dynamisch dispatched wird (ergo: im Zweifel ein VI Aufruf zusätzlich). Aber ich werde auch gerne einen passendere Titelvorschlag akzeptieren.

Zitat:Schon die Addition von zwei Double-Array's würde man doch einfacher und performanter implementieren, indem man Sie mit Hilfe das Add-Operators addiert, ohne Schleife! Ich weis auch nicht genau, ob der Compiler das Schleifen-Konstrukt erkennt und wegoptimiert. Es könnte sogar sein, dass der Compiler erkennt, dass in dem ersten Fall in der While-Schleife zwei konstante Arrays addiert werden, diese Addition nur genau einmal vor der Ausführung der Schleife berechnet und das Ergebnis in die Sequenz einsetzt. Darauf könnte die Ausführungszeit von 0 ms hindeuten.

Anmerkung: Die Schleife / Arrays dienen natürlich im Grundsatz nur zum Ausdehnen der Laufzeit zu Testzwecken. Sonst kriegt man die Laufzeit ja eh nicht vernünftig gemessen.

Zitat:Auch ist die Zeitmessung nicht gut implementiert. Jeder der beiden Algorithmen sollte zwischen den Timern vielfach ausgeführt werden. Um den Optimizer auszuschalten, würde ich auch Zufallszahlen zu den Array-Elementen addieren.

Die habe ich doch bewusst jeweils vor und hinter die For Schleife gesetzt (?) für mich ist der Testfall addieren n mal ausführen. Zufallszahlen wollte ich deswegen nicht innerhalb der Schleifen addieren (sondern eben vorher auswürfeln) um zu vermeiden dass die Initialisierung der Testfälle in die Laufzeit einberechnet wird (hab da ehrlich gesagt auch bei meiner Klasse noch nicht getestet wie effizient die initialisiert; mir war aber wichtiger das die schnell rechnet). Könnte ich aber vielleicht mal nur beim "normalen" Addieren dazupacken, damit der die Schleife nicht wegoptimieren kann.

Zitat:Weiteres:
- In zweiten einen Fall versuchst Du die Schleife zu parallelisieren, in dem ersten Fall nicht.
- In zweiten einen Fall gibt es eine Case-Struktur, in dem ersten Fall nicht.

Der obige Vergleich hinkt also schon aus grundsätzlichen Gründen.

Die Parallisierung war ein erster Optimierungsversuch am Klassencode um zu schauen wo es hackt (sprich: Wie das potentiell schneller geht). In praktischer Anwendung würde das ja typischerweise auch parralel statt sequentiell verwendet. Das hab ich natürlich für Elementare Addition nicht übernommen da die eh schon performant läuft (gehe auch davon aus, dass die im Zweifel deutlich weniger davon profitiert da sehr viel hardwarenaher implementiert und entsprechend die Totzeiten beim laden etc. kleiner ausfallen sollten.
Die Case Struktur machte bei meinen Test keinen signifikanten Unterschied (diente nur dazu den Code rauszuwerfen um zu schauen wie viel Zeit die Elementare Addition braucht (ab ~100.000 - 1.000.000 Zahlen sieht man so langsam ne messbare Laufzeit - das wäre sonst nicht Testbar gewesen). Hätte ich allerdings für den Upload wieder rauswerfen sollen *Asche über mein Haupt*.

Zitat:Ich habe in Deine Klassen-Implemetierung noch nicht wirklich reingeschaut. Versuch doch erst einmal die obigen Kritikpunkte zu beseitigen. Dann sehen wir weiter.

Gruß Holger

---

Hi Kiesch
bei der ersten Durchsicht der Klassen-Implementierung ist mir aufgefallen, dass Du z.B. I8 + I8 = I8 rechnest. Was ist das Ergebnis von 127 + 127 = ?

Ich würde doch besser als Ergebnis ein I16 annehmen, um Probleme mit Wertebereichsüberschreitungen zu vermeiden. Falls das explizit nicht erwünscht ist, solltest Du aber eine entsprechende Warnung zurückgeben!

Gruß Holger

Was die Implementierung angeht: Hatte mich für den ersten laufzeitoptimierten Versuch (Cases sparen ^^) dafür entschieden das explizit nicht zu behandeln (Labview macht da ja auch nen Überlauf). Wenn dann die Laufzeitkosten nicht zu groß sind, hätte ich das eher nach einer Art try - catch system gemacht (Addition probieren - wenn überlauf - das ganze in nen I16 wandeln bzw. jeweils in den nächstumfangreicheren). Meist ist das ja nicht notwendig. Aber das war auch die weitere Überlegung. Division wollte ich zum Beispiel so implementieren, dass man wenn möglich auf den natürlichen Zahlen bleibt (Modulo und wenn das nicht funktioniert dann das ganze in nen double und echte Division etc.)
Bin mir da der Implikationen durchaus bewusst. Deswegen auch erstmal "nur" die Implementation die für identische Datentypen funktioniert (wie man leicht im Code sieht macht die aktuell Scheiße (zumindest nicht das was sie sollte) wenn verschiedene Datentypen reingehen; zum Testen für identische Zahlentypen war das aber erstmal egal; und ich wollte auch nicht enormen Aufwand in Fehlerbehandlung packen und "fertige" Durchimplementierung wenn das von vorneherein nicht performant genug ist damit mans nutzen kann.

*kurz noch die Designideen die noch implementiert werden müssen:

- Gerechnet wird immer mit dem "Umfangreichsten" Datentyp von beiden (ergo: I16 + DBL gibt nen DBL, I16+I64 gibt nen I64; I32 + U64 müsste ich genau drüber nachdenken (da ist nicht generell entscheidbar was ob man den größeren Zahlenbereich des U64 gegenüber I64 braucht, oder doch die negativen Zahlen...; vermutlich aber würde das dann auch auf I64 gehen).

- Gleichzeitig wird versucht den Datentyp möglichst klein zu halten (sprich: Ich speicher das nicht einfach Intern alles als EXT, I64 und U64; und "merke" mir nur was der Nutzer haben will).

- potentiell Überläufe abfangen

- automatische Verwendung einer möglichst genauen Division (sprich: Wenn möglich werden Integers erhalten)

Wenn das ganze dann erstmal funktioniert wie ganz normale Zahlen kann man dann weiter dran arbeiten und alles was man gerne hätte implementieren.

Gruß Kiesch

P.S: Was mir noch aufgefallen ist: Die Ausführungszeit scheint am Anfang abzusinken (Faktor 2). Liegt das an irgendwelchen Laufzeitoptimierungen von Labview?

*edit* Achso, danke schonmal BNT werd da jetzt nochmal genauer reinschauen und den Code dann auch nochmal überarbeiten.

Hi Kiesch

Vielleicht noch eine grundsätzliche Bemerkung zum Vergleich. Die Performance des dynamic dispatching sollt man besser mit statischen SubVI Aufrufen vergleichen. Das wäre doch etwas fairer.

SubVI Aufrufe haben im Vergleich zur Anwendung der elementaren Funktionen halt einen deutlichen Overhead.

Alternative Implementierung zu OO: Hast Du mal über die Implementierung Deiner Anforderungen mit Hilfe von polymorfic VIs nachgedacht? Diese können auch als inline deklariert werden und so die maximale Performance ermöglichen.

Anzeige

Mal ein kleines Update von mir:

Der Jahreswechsel hat mal wieder zugeschlagen und aktuell bin ich so zugeschüttet mit anderer Arbeit, dass ich mich gerade um das Problem nicht kümmern kann. Wenns wieder weniger wird häng ich mich da wieder dran. Die OO Sektion ist ja eh übersichtlich genug dass das oben bleibt.

Was die Benutzung von Polymorphen VIs angeht: Ziel war es die Funktionalität in einer Number Oberklasse zu kapseln, so dass ich Daten zum Beispiel auch in Arrays einfach als "Number" handhabe und da dann auch gleichzeitig Integers und Double Zahlen drin haben und handhaben kann (und die entsprechend nicht in mehreren Arrays Datentyprein trennen muss). Entsprechend soll auch nicht zur Programmierzeit spezifiziert werden müssen, mit was da eigentlich gerechnet wird (ausser das "Startformat", in dem man die Numbers einmal erstellt). Nebenbei könnte man damit auch die häufig auftauchenden Probleme bei Vergleichen von Floats von vorneherein vermeiden indem man die Vergleichsfunktion der Klasse entsprechend richtig über eine Differenzbildung definiert.

Gruß Kiesch

P.S: Meld mich wieder wenns was neues gibt.

Hab mal den Vorschlag ausprobiert in der For Schleife erst zufallszahlen zu erzeugen die ich addiere. Wie bereits vermutet wird dann die Laufzeit im wesentlichen durch die Erzeugung der Zufallszahlen bestimmt und nicht mehr durch die Addition (bei der Elementaren Addition). Für die "Number" Klasse wäre das natürlich noch Laufzeitintensiver (da die auch beim Initialisieren einer Nummer länger braucht als für das reine Zahlenauswürfeln).

P.S: Bin schon wieder auf ne Praktische Anwendung dafür gestoßen, neben der Tatsache, dass man da nette Sicherheitseinstellungen implementieren könnte (Überlaufcheck, Konservierung von Integers sofern möglich) - man könnte damit vernünftig und zu großen Aufwand die Rechenoperationen auf Vektoren und Matrizen erweitern.


Wie auch immer, das Hauptproblem steht also immer noch: Wie kriege ich den Rechner dazu mit sowas performant umzugehen? Ich komm aktuell an dem Rechner hier etwa auf ne Laufzeit von einer Sekunde für 100.000 Number Additionen. Das sind immerhin 10Mikrosekunden pro Addition. Der Rechner dürfte 3GHz haben - macht also ganz grob übern Daumen immerhin 30k Rechenzyklen pro Rechenoperation.

Das ist nicht wirklich befriedigend. Gerade da ich die Operationen nunmal so Elementar wie möglich definieren muss um das auch wirklich nützlich zu machen...

Frage daher auch: Kann das überhaupt schneller gehen?

Für mich stellt sich der Fall so dar:

Der reine Aufruf des VIs scheint enorm Zeit zu brauchen (und macht vermutlich letztlich die Laufzeit aus die ich sehe). Das wäre soweit nicht weiter schlimm, wenn ich beliebige viele davon erzeugen könnte und dann parralel arbeite (der Aufruf an sich dürfte ja nicht wirklich Rechenintensiv sein denke ich).
Simpel gesagt: Ne Laufzeit von 10Mikrosekunden wäre okay, wenn ich dafür 1000 Instanzen davon gleichzeit parrallel aufrufen kann (und somit Effektiv im Mittel alle 10ns eine Rechenoperation abschließe).

Nur wie kriege ich das dahin? Wie schon gesagt haben meine bisherigen Versuche der Parrallelisierung nichts signifikantes gebracht (mit gutem Willen vielleicht um nen Faktor 2 schneller).

Ich teste mal weiter.

*edit*
Anmerkung: Theoretisch würde ich vermuten, dass Ablaufinvariante Ausführung mit vorbelegter Kopie am schnellsten ist; allerdings steht mir das wegen dynamic dispatching nicht zur Verfügung.

Achja und laut NI:

Zitat:SubVI-Overhead
Wenn Sie ein SubVI aufrufen, ist damit ein bestimmter Overhead verbunden. Dieser Overhead ist ziemlich gering (im zweistelligen Mikrosekundenbereich), besonders im Vergleich zum I/O- und Anzeige-Overhead, der im zweistelligen Millisekundenbereich liegen kann. Trotzdem kann sich dieser Overhead in manchen Fällen summieren. Wenn Sie beispielsweise ein SubVI 10.000 Mal in einer Schleife aufrufen, kann der Overhead die Ausführungsgeschwindigkeit bedeutend beeinträchtigen. In diesem Fall ist es ratsam, die Schleife im SubVI einzubetten.

Das passt also grundsätzlich zu den Zeiten die ich messe. Heist für mich auch, dass die Lösung wirklich nur in parrallelisierung liegen kann.

Bearbeiten kann ich glaube nichtmehr daher neuer Post:

Habe mal getestet mit der elementaren Addition als SubVI --> da komm ich auf ~5-6ms für 100k operationen. Das Starten des SubVIs bewegt sich also im 50-60ns Bereich (sic!). Der Compiler optimiert das offensichtlich auch nicht weg, da die reine Elementare Addition nochmal um nen Faktor 10 (grob geschätzt; Zeitmessung springt für 100k Operationen zwischen 1 und 0 ms) schneller ist.

Was auch auffällt:

1. Laut Taskmanager schaft es das TestVI beide Kerne meines Rechners zu 100% auszulasten. Daher: Parralelität scheint zu funktionieren, der Geschwindigkeitszuwachs den man zu sehen scheint kommt dabei einfach aus dem zweiten Kern. Scheint also auch das tatsächlich nur die Rechenleistung die Ausfürungszeit limitiert.

2. Der Overhead fällt offenbar als CPU Zeit an und zwar bei irgendwas was spezifisch fürs dynamic dispatching sein dürfte. Hatte bisher eigentlich dynamic dispatching von der Behandlung her eher als bessere Case Struktur eingeordnet (Die Klasse ist quasi der Case Selektor, ansonsten wird eben einfach nur je nach Klasse der innere Teil des Case ausgeführt). Das scheint offenbar von der Internen Behandlung weit entfernt (da ja Cases gemeinhin als relativ performant gelten - ist ja letztlich auf niederster Ebene nur ne selektive Sprunganweisung).


Hat noch jemand Ideen wie man den Rechenaufwand reduzieren könnte?

Achja, hier noch nen anderer Post zum Thema von der NI Seite:

http://forums.ni.com/t5/LabVIEW-Idea-Exc...-p/2031778

Wobei ich auch nicht genau weis ob das wirklich noch nen Laufzeitgewinn bringen würde in meinem Fall.