Hallo @ all Labview Nutzer,
ich habe ein kleines Testprogramm geschrieben. Dies rechnet aus zufällig erzeugten Daten die FFT aus. Mit dem Testprogramm will ich die maximal möglich Speichernutzung ermitteln. Ich habe das gleiche Programm mit Labview 2009 und Labview 2011 gestestet. Parallel habe ich den Taskmanager von Windows benutzt und abgelesen bei wie viel RAM das Labview Programm aussteigt.
Bei beiden Labviewversionen (2009 und 2011) kommt bei ca. 2,5GByte verwendeter Arbeitsspeicher ein Popup, das die Ausführung des Labviewprogramms anhält, da angeblich nicht genügend Speicher zur verfügung steht.
Wenn ich Labview 2010 64Bit benutze dann kann ich den kompletten Arbeitsspeicher vom PC nutzen. In meinem System sind 8GByte verbaut und ich benutze Windows 7 64Bit.
Jedoch bringt die Labview 64Bit Version auch sehr viele Nacchteile mit sich. Ich kann z.B. viele alte DLLs nicht mehr verwenden da diese für 32Bit Versionen sind. Somit muss ich alles auf 64Bit umstellen. Dieser Aufwand ist mir jedoch zu groß.
Deshalb meine Frage kann ich mit der Labview 32Bit Version unter einen 64Bit Betriebssystem den vollen Arbeitsspeicher also mehr als 2,5GByte nutzen und wenn ja wie?
Ich habe das Testprogramm mit in den Anhang gepackt (ist für Labview 2009)
Unter Windows 64bit kannst du theoretisch 4GB mit LV 32bit nutzen. Allerdings hängt da viel davon ab, wie du versuchst den Speicher anzufordern.
Bei großen zusammenhängenden Blöcken wird es schnell eng... mit kleineren Brocken geht es eher.
[
attachment=35022]
Damit ist bei ca 3.5GB auf meinem System Schluß.
Was hast du eigentlich vor? Weil z.B. dein 2D Array wird, selbst wenn es nur 1GB groß wäre, schnell sehr unhandlich bzw. da musst du dann höllisch auf mögliche Kopien achten.
Bitte
. Da steht noch LabVIEW 8.5 drin und Du hast laut Deinem Post schon LabVIEW 2011. Danke.
Gruß Markus
Ich verwende sehr viele Versionen von Labview. Heute habe ich mal die neue Version 2011 ausprobiert.
Ich bekomme einen konstanten Datenfluss von einer High Speed DAQ. Ich schreibe 2D Arrays in eine Queue. Es entstehen dadurch 3D Bilder die recht groß werden. Da ich diese dann bearbeiten muss geht schnell der Speicher aus. Dies ist bei der 64Bit Version halt nicht der Fall.
Ich wollte halt wissen ob ich einen Fehler mache oder ob die Speichermenge bei der 32Bit Labviewversion begrentzt ist.
3D Arrays von Elementardatentypen sind besonders anfällig für Speicherprobleme, da sie als zusammenhängender Speicher angelegt werden. Das sorgt mit etwas Speicherfragmentierung schnell zu "Speicher voll". (siehe auch:
Thread-grosse-Datenmengen-in-LV-8-5-1)
Wie so oft... man bekommt im Zweifel nichts geschenkt. Entweder .dll auf 64bit portieren und bequem mit 3d Arrays arbeiten oder .dll weiter benutzen und Datenstrukturen und Algorithmen auf z.B. 1d Array von 2d Arrays ändern.
... und die aktuellste sollte in Deinem Profil stehen.
Gruß Markus
(03.08.2011 22:14 )joedoe1979 schrieb: [ -> ]Ich verwende sehr viele Versionen von Labview.
Hi,
Eine „Teil“ – Alternative mal im Anhang:
Grundlage ist macmarvin´s Beispiel.
Die „LabVIEW-Speichergröße“ kann vorgegeben werden, wenn diese überschritten, wird in TDMS gespeichert.
Dies ändert zwar nicht die physikalischen bzw. Win-Begebenheiten sowie die Tatsache dass diese Vorgehensweise langsamer ist, jedoch für einige Fälle könnte dies vielleicht hilfreich sein.
Das Beispiel ist noch nicht perfekt. Kritik und Anregungen willkommen.
Gruß
Ralf
Danke rasta, für die Erweiterung (und bugfixing) der ursprünglichen Idee.
Da ich selbst immer etwas misstrauisch gegenüber den TDMS-Funktionen bin, habe ich deine Idee um einfache Binärdateien erweitert.
Anbei das Ganze mit LVOOP-basierter Unterscheidung zwischen verschiedenen Speicherarten.
[
attachment=35091]
Edit:
Noch erweiterte Fassung.
Unterstützt jetzt:
- byValue
- DVR
- Single Element Queue (blockierend)
- Single Element Queue (nicht blockierend)
- TDMS
- Binärfile
[
attachment=35095]
Hi macmarvin,
Meine LVOOP-Kenntnisse sind <=0,1%
jedoch soll sich dies bald ändern und da ist dieses Beispiel für mich
sehr gut geeignet. Danke.
Die einfache Binärdatei - Variante ist trotz Erstellung eines jeden "Iterations-Files" (oder deshalb?) schneller im Schreibe sowie im Lesevorgang als TDMS mit Gruppen bzw. Kanälen und geöffneter File-Ref- interessant.
Es gibt weiterhin viel zu verstehen.
Gruß
Ralf
(05.08.2011 18:29 )rasta schrieb: [ -> ]Meine LVOOP-Kenntnisse sind <=0,1% jedoch soll sich dies bald ändern und da ist dieses Beispiel für mich
sehr gut geeignet. Danke.
Die einfache Binärdatei - Variante ist trotz Erstellung eines jeden "Iterations-Files" (oder deshalb?) schneller im Schreibe sowie im Lesevorgang als TDMS mit Gruppen bzw. Kanälen und geöffneter File-Ref- interessant.
Hi rasta,
ja das Timing hat mich auch weiter interessiert. Das TDMS langsamer ist, war zu erwarten, da die API um einiges mehr macht als nur lesen.
Freut mich, daß dir das LVOOP Beispiel gefällt. Ich habe es noch etwas erweitert um verschiedene Zugriffsarten. Das geht durch den LVOOP Ansatz glücklicherweise recht einfach bzw. ohne viel Aufwand.
Warum z.b. das Lesen von geschlossenen Dateien (InFilesPath.lvclass) fast immer schneller ist als das der noch geöffneten Dateien (InFiles.lvclass) ist mir auch noch nicht ganz klar. Mglw. braucht das setzen des Filepointers bei der offenen Datei recht lange.
[
attachment=35145]