+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: number crunching in LV = nix gut (/Thread-number-crunching-in-LV-nix-gut)
number crunching in LV = nix gut - gottfried - 13.12.2009 17:29
Hallo,
nur so eine Erfahrung: in LV realisierte Berechnung mit 200.000 Elementen Großen 3D Matritzen und einem Haufen Indexschaufelei (Formula Node) ist keine gute Idee:
Rechenzeit LV 650
Rechenzeit (alter) FOR Compiler 12
Das heisst der Compiler ist um den Faktor 55 schneller. Der Compiler ist sehr alt - hat keine Ahnung von mehreren Kernen! Ich rechne das auf meinem Laptop mit 2 Kernen.
Im übrigen ist die Formula Node sonderbar:
Die gibt Units weiter - na gut das stört nicht weiter aber
Array Index Fehler werden nicht bemerkt - das stört mich gewaltig
Viele Grüße
Gottfried
number crunching in LV = nix gut - jg - 13.12.2009 22:13
Wenn man jetzt wüsste, was genau du berechnest, dann könnte man dir bei der Optimierung vielleicht helfen. Denn wenn ich schon lese, Formula-Node und Arrays, da möchte ich bezweifeln, ob das wirklich optimal ist...
http://digital.ni.com/public.nsf/allkb/020...6256D0E006615E9
http://digital.ni.com/public.nsf/websearch...39?OpenDocument
Gruß, Jens
number crunching in LV = nix gut - rolfk - 14.12.2009 09:12
Die Formula Node ist ein veredelter Interpreter mit C Syntax. Wenn Du denkst die zu verwenden weil es schneller ist als die LabVIEW Built-in Nodes, dann hast Du Dir gewaltig in die Finger geschnitten. NI macht in dieser Hinsicht auch keinerlei Hoffnungen. Die Formula Node ist da, für die die sich mit Formeln halt einfach komfortabler fühlen, aber ist sicher kein integrierter optimalisierender C Compiler.
Was Out of Index angeht, C crasht oft einfach. Ein Crash in LabVIEW ist per Definition ein Bug (obwohl im Falle von Zugriff zu externem Code ein Bug in der Konfiguration der CIN or CLN oder ein Bug im externen Code, also ausserhalb der Kontrolle von LabVIEW selber).
Bei normalen Nodes ist es etwas schwieriger um Out of Index Operationen zu erreichen da sehr viel Operationen automatisch mit der kleineren Arraygrösse arbeiten, aber die Index Array Funktion liefert bei Out of Index Zugriffen auch einfach den Default-Default Wert zurück statt zu crashen
Vielleicht dass Dir Fortran hier schöne Exceptions zurückgibt, was eigentlich auch einfach ein Crash ist, wenn auch kontrolliert, aber das ist nicht wie LabVIEW arbeitet oder in irgendeiner Weise vorgesehen. Die LabVIEW Weise um mit so was umzugehen ist soviel möglich trotzdem etwas mehr oder weniger sinnvolles zu tun (Default-Default Wert in der Index Array Funktion beispielsweise) oder einen Runtime Error zu erzeugen. Dazu benötigte die Formula Node aber einen Error Cluster und das ist bis heute nicht implementiert und im Hinblick auf die neueren Formula Node Ersatzlösungen wie Script Node und Mathscript auch eher unwahrscheinlich um noch hinzugefügt zu werden.
number crunching in LV = nix gut - gottfried - 14.12.2009 10:36
Hallo,
danke für Eure Kommentare. In der Anlage seht Ihr meine Vorgangsweise. Das ist eine brute force Wärmeleitungsgleichung instationär in 3D.
Das Ganze in Array-arithmetik zu rechnen ist in LV sicher möglich aber ich müsste auch die verschobenen Arrays, also was ich mit x(1,j,k-1) etwa anspreche nochmals speichern. Ein Array hat aber 3,3M Elemente - diese Vorgangsweise fand ich nicht gangbar.
Das die Formula Node nicht kompiliert wird, war mir neu. Auch das das Ding irgendetwas mit units mach auch. Die Frage "wo steht das" geht wohl wie immer ins Leere....
Mathscript ist Quatsch (völliger! - keine Debugmöglichkeit für gerufene Functions), extrem langsam, muss extra bezahlt werden... was ich auch schon oft lautstark kundgetan habe.
Die Sache läuft, was ich noch interessant finde ist ein Versuch in Array-Arthmetik in FORTRAN.
Danke Euch
number crunching in LV = nix gut - rolfk - 14.12.2009 11:16
Ich wollte nicht sagen dass die Formula Node den Code interpretiert, ich dachte eigentlich eher nicht, aber dass das alles ausser ein optimalisiernder C Compiler ist. Moderne Bytecode Implementation (die ein Zwischending zwischen Interpreter und Compiler sind) können die Formulanode so wie sie heute besteht aber lange in den Schatten stellen. Es war auch nicht Ziel um in LabVIEW mit der Formulanode auch noch gleich einen C Compiler zu integrieren sondern halt einfach die Eingabe von Textformeln möglich zu machen. Der Code wird zwar meines Wissens in Maschinencode umgesetzt, aber nicht mit Hinblick auf Schnellheit sondern auf sichere Ausführbarkeit ohne Crash. Das heisst auch dass in Loops beispielsweise alle Arrayindexes jedesmal gecheckt werden um einen Crash unter allen Umständen zu vermeiden. Das kostet sehr viel Laufzeit.
Könnte NI die Formulanode optimalisieren? Natürlich!
Werden Sie es tun? Ich schätze die Chance dafür sehr klein. Das würde wohl ein weteres Redesign der ganzen Formulanode erfordern mit hinzufügen eines richtigen C Compilers in LabVIEW was die Komplexität für den Unterhalt und den Umfang von LabVIEW extrem vergrössern würde. Also wohl eher nicht.
number crunching in LV = nix gut - jg - 14.12.2009 21:07
Hallo, Gottfried,
wenn ich nichts falsch gemacht habe, sollte dies deine Formula-Node sein (allerdings ist bei mit die Matrix v1 komplett besetzt).
Durchlauf-Zeit bei 60x60x60-Arrays auf meinem Rechner ca. 50 ms
Und da ist sicher noch einige Optimierungsmöglichkeiten drin:
[attachment=23198]Mich würde ein Vergleich mit realen Arrays auf deinem Rechner interessieren.
Gruß, Jens
number crunching in LV = nix gut - gottfried - 16.12.2009 16:54
Du beeindruckst mich immer wieder.
Deine Lösung Laufzeit auf meinem Rechner 54ms.
Rechenzeit LV 650 mit Formula Node
Rechenzeit (alter) FORTRAN Compiler 12 (geschwindigkeitsoptimiert)
FORTRAN mit allen Debug Zeugs ca 60ms
Was man aber ehrlicherwiese sagen muss (sorry) die Textfassung ist ein wenig (ganz ganz ganz ganz klein wenig) leserlicher als der Datenfluss (um das Wort LabVIEW zu vermeiden)
ad rolfk: die FormulaNode mach überhaupt keine Arraychecks.
ad alle: was macht die (toll dokumentiere) Formulanode mit den Einheiten? Bitte Antworten ohne auszuprobieren
was mich noch juckt: die Rechenzeit in Arrayarithmetik
Danke
Gottfried
number crunching in LV = nix gut - rolfk - 16.12.2009 17:06
' schrieb:ad rolfk: die FormulaNode mach überhaupt keine Arraychecks.
Eben doch, anders würde es crashen. Was sie aber tut ist einfach einen Null-Wert verwenden für nicht vorhandene Arrayelemente. Das bedingt aber einen Arrayboundscheck und der ist bei nicht optimalisierter Codeerzeugung halt in jeder Iteration aufs Neue.
number crunching in LV = nix gut - gottfried - 17.12.2009 16:37
ad Jens: Du hast Dir viel Arbeit gemacht aber das VI ergibt nur Nullen. Der Eingang v1 ist bei Dir auch nicht verwendet.
Macht nichts - ich habe meine DLL. BTW wenn man das VI von Jens als SubVI einbindet braucht es um 6 bis 10ms länger. Das ist, so finde ich für einen call by Value von so vielen Daten eigentlich toll.
number crunching in LV = nix gut - jg - 18.12.2009 00:32
' schrieb:ad Jens: Du hast Dir viel Arbeit gemacht aber das VI ergibt nur Nullen.Wie das? Bsp mit Zufallszahlen zeigt doch, dass das Ausgangsarray v1 nicht nur Nullen enthält?!
' schrieb:Der Eingang v1 ist bei Dir auch nicht verwendet.Innerhalb der geposteten Formulanode verwendest du v1 doch gar nicht, v1 werden nur Werte zugewiesen... Das ist mein Ausgangsarray. Wenn du das immer wieder neu überschreiben willst, wo ist das Problem, einfach per ReplaceArraySubset machen...
Gruß, Jens