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.
/
Extreme Laufzeitkosten durch Dynamic Dispatching?
