Berechnung mit CLF-Knoten schneller?

' schrieb:alles klar ...danke ...mit den exe-Dateien stelle ich auch (fast) keinen Unterschied mehr fest....das hätten sie ja auch irgendwie mal ins Buch reinschreiben können, da wird groß angekündigt, dass es mit der Einbindung des C++-Codes schneller geht ...aber dann kein weiterer Satz warum oder weshalb....nicht so tragitsch aber schön wäre es gewesen ^^...

mfg

LabVIEW selber ist auch ein Compiler. Das was Du im Diagramm zeichnest wird direkt in Maschinencode umgesetzt und dann ausgeführt. In diesem Licht sind die meisten Claims dass LabVIEW prinzipiel langsamer ist als C absolut nicht wahr.
Aber in C kannst Du denn Compiler anweisen um hoch-optimalisierten Code zu erzeugen, LabVIEW optimalisiert auch aber hat durch die Datenfluss-Programmierung ganz andere Bedürfnisse in gewissen Gebieten. Ein C Compiler kann ganz einfach davon ausgehen dass der Code immer linear abläuft und dass wenn etwas parallel ausgeführt werden kann der C Programmierer schon damit Rechnung hält und wenn nicht dann ist es halt Pech gewesen und das Programm schmiert ab oder produziert falsche Ergebnisse.

LabVIEW hat durch die Datenflussprogrammierung inherent parallele Ausführung eingebaut und muss damit zu jedem Zeitpunk Rechnung tragen (und tut das auch extrem gut). Das hat aber auch zur Folge, dass nicht jede Optimalisierung die ein C Compiler durchführen kann für LabVIEW legitim ist. Und manchmal muss LabVIEW sogar extra Code einfügen um Kollisionen von ausführemdem Code zu verhindern. Das kann dazu führen dass der LabVIEW Code langsamer abläuft dann der durch einen hoch optimalisierten C Compiler erzeugten Code. Aber hier sprechen wir in den meisten Fällen über Prozente der Ausführungszeit nicht über Faktoren.

Wo es oftmals falsch geht in LabVIEW ist nicht im erzeugten Code selber, aber in der Verwendung eines suboptimalen Algorithmus im LabVIEW Diagramm oder einer suboptimalen Implementation eines Algorithmus. In C muss sich der Programmierer selber um jedes Byte kümmern dass im Speicher angelegt, verschoben und wieder freigegeben wird. In LabVIEW tut man überhaupt nichts dergleichen. LabVIEW alloziert und realloziert Speicher wann immer das nötig ist für uns. Und Speicherallozierung und Kopieren ist eine sehr langsame Operation im Verhältnis zu anderen Dingen. Wenn also jetzt jemand einen Algorithmus schreibt in dem er in einer Schlaufe mit BuildArray in jedem Durchlauf ein oder mehrere Elemente an das im Schieberegister gehaltene Array anfügt, wird in jedem Schleifendruchlauf dieses Array vergrössert, was fast immer mit einer Neuallokation mit anschliessendem Kopieren der Daten im Speicher und Deallozieren des alten Arrays verbunden ist. So ein Algorithmus ist EXTREM langsam, nicht weil LabVIEW schlechten Code erzeugt, sondern weil der Programmierer schlecht programmiert hat.
Das Problem ist hier eigentlich dass Programmieren in LabVIEW fast zu einfach ist. Man kann ohne überhaupt etwas von Programmierung zu verstehen immer noch ein Programm schreiben das mehr oder weniger das zu tun scheint (mit Nachdruck auf dem scheint) was man eigentlich wollte, auch wenn die Art und Weise wie das getan wird eigentlich katastrophal zu nennen ist.

Rolf Kalbermatter