Aber wie sieht jetzt mit denen vno unicorn beschriebenen Arrays aus? Also ein 1D-Array aus cluster mit 2D-Arrays. Landen die auch am Stück im Speicher oder hat LV hier die Möglichkeit, die 2D-Arrays besser im Speicher zu verteilen?
' schrieb:Hmm, ein 2D Array mit 8 Kanalen a 1MS verbraucht genau 8 * 10^6 * 8 + 8 Bytes und noch etwa 16 Byte LabVIEW Handle overhead (~64'000'024 Bytes). Ein 1D Array das dieselben Daten enthalten kann würde 8 * 10^6 * 8 + 4 Bytes und den LabVIEW handle overhead belegen (~64'000'020 Bytes). Beides ist ein kontinuierlicher Bereich im Speicher. Es erscheint mir sehr unwahrscheinlich dass die 4 Bytes Unterschied einen merkbaren Unterschied darstellen! 
Das Problem ist nicht 2D, 3D oder nD Arrays sondern der einfache Fakt dass mit solchen Arrays sehr schnell sehr viel Speicher alloziert werden muss ohne dass der Benützer das direkt sieht. Aber der Trick um alles in ein 1D Array zu stopfen bringt nichts wenn man die gleichen Daten darin haben will. Der einzige Vorteil liegt darin, das man dazu erst wirklich gut nachdenken muss und schnell sieht dass das enorme Daten ergibt und dadurch vielleicht gezwungen wird das ganze Design zu überdenken.
Rolf Kalbermatter
Ok, das hört sich ja logisch an, aber warum bekomme ich einen Error (Not enough Memory) wenn ich ein 3D-Array benutze und mit einem 1D-Array nicht? Das kapiere ich nicht wirklich.
Gruß, Andreas
' schrieb:Aber wie sieht jetzt mit denen vno unicorn beschriebenen Arrays aus? Also ein 1D-Array aus cluster mit 2D-Arrays. Landen die auch am Stück im Speicher oder hat LV hier die Möglichkeit, die 2D-Arrays besser im Speicher zu verteilen?
Jedes Array in LabVIEW ist ein Handle (Pointer auf einen Pointer). Was Du also bei mehreren Arrays in einem Cluster erhältst, sind seperate Arrays und damit auch seperate Speicherbereiche. Grundsätzlich ist das sicher einfacher für den Memorymanager da die Chance dass genügend individuelle Speicherlöcher bestehen die gross genug sind für jedes der einzelenen Arrays, grösser ist.
Aber die Lösung hat auch Nachteile. Jedes Array hat einen Overhead in LabVIEW (und nochmals im OS) da das auch Informationen über jeden Pointer verwalten muss. Das sind zwar nur etwa 100 Bytes oder so aber das kann mit der Zeit doch zählen. Zudem verwendet auch der Cluster selber nochmals einen Speicherbereich was auch nicht soviel auf einmal ist aber doch auch wieder so um die 32 Bytes plus den Speicherpointeroverhead von LabVIEW und dem OS. Und nicht zu vergessen die Speicherdeskriptoren die auch nur endlich sind, vor allem bei Verwendung des /3GB boot.ini Switches.
Der grösste Nachteil ist aber dass Du auf diese Weise schnell ein unübersichtliches Diagramm bekommst, da Du für jede Operation auf eines der Arrays ein Unbundle benötigtst, dann die Arrayoperation und dann wieder ein Bundle. Auch wird es umständlicher um Inplaceness zu erhalten, weil das nur noch durch die entsprechenden Inplaceoperatoren in LabVIEW 8.6 zu erreichen ist. Ohne Inplaceoperationen bricht Dir die Performance schrecklich zusammen.
Und nicht zu vergessen dass eine solche Lösung überhaupt nicht scalierbar ist. Ein extra Kanal hinzufügen? Au Backe, dann muss ich den Cluster ändern, alle VIs die darauf angewendet werden anpassen und so weiter!!!!
Bei einer reinen 2D Arraylösung die sauber programmiert ist setze ich die Funktion die die Daten acquiriert einfach so dass Sie einen Kanal mher einliest und alles andere geht automatisch. Eventuel muss im UI noch etwas angepast werden um den extra Kanal auch einstellbar zu machen und darzustellen (Grpahenlegende zum Beispiel). Aber das ist es dann schon.
' schrieb:Irgendwo habe ich gelesen, dass LV Speicher nur am Stück allokieren kann. Wie LV darin den Speicher verwaltet weiß ich glaube dir, dass die von dir genannte Methode besser klappt. Eigentlich auch logische, denn die Array innerhalb der Clusterelemente können unterschiedlich groß sein. LV kann somit keinen aneinanderhängenden Speicher belegen sondern setzt nur einen Pointer auf das Array rein. Wie LV dann vorgeht, um dieses Array zu speichern, weiß ich nicht. Es kann allerdings nicht irgendwo im Speicher liegen, da LV wie gesagt nur einen Bereich verwalten kann.
Um nochmal das Thema aufzugreifen. Letzte Woche war ich bei NI und habe mit einigen Dozenten über das Thema großer Datensätze in LabVIEW diskutiert. NI verwies mich auf den Kurs Performance Guide, wo eine Methode vorgestellt wird, um herauszufinden wie groß der größte zusammenhägende Speicher momentan beträgt. Dazu muss man sich bei Microsoft etwas herunterladen, leider konnte mir der Dozent nicht sagen was. Hat von euch jemand diesen Kurs besucht und weiß was man sich herunterladen muss?
THX
Hi Abrissbirne,
habe den Kurs im Frühling besucht - leider wurde diese "Methode" nicht erwähnt. Zumindestens nicht in meinem Kurs... Oder kann sich evtl. Y-P dran erinnern?
Grundaussage des Kurses: Je einfacher die Datenstruktur gehalten wird, desto besser die Performance
Und wie jede Grundaussage ist es einfach das, eine Grundaussage. Im Prinzip meist korrekt aber nicht in allen Fällen und unter allen möglichen Umständen.
' schrieb:Um nochmal das Thema aufzugreifen. Letzte Woche war ich bei NI und habe mit einigen Dozenten über das Thema großer Datensätze in LabVIEW diskutiert. NI verwies mich auf den Kurs Performance Guide, wo eine Methode vorgestellt wird, um herauszufinden wie groß der größte zusammenhägende Speicher momentan beträgt.
ich denke, das ist dasselbe Thema.
siehe
http://www.LabVIEWforum.de/index.php?showt...ost&p=90445