Speicherprobleme LV 2013

Hi

Ich versuche derzeit verhältnismäßig viele Daten gleichzeitig in Labview zu bearbeiten. Dazu wollte ich anfangs einen Cluster erstellen in dem sich 6 arrays mit 4096 Einträgen befinden und 6 2-D Arrays mit 4096x4096 Einträgen. Dieser Cluster liegt wiederum in einem Array mit 6 Einträgen. Als Datentyp habe ich für alle Einträge U32 gewählt. Summa Summarum sollte ich als Gesamtgröße für den Speicher einen Wert von:

4096*4096*4*6*6+4096*4*6*6 = 2.416.508.928 byte also etwa mehr als 2,4 GByte. Hört sich erst einmal viel an sollte, aber doch selbst mit dem 32 bit Labview zumindest zu erstellen sein. Allerdings gelingt mir nichtmal das. Setze ich für den äußersten Cluster kein Array an, kann ich die Datei immerhin Speichern. Auf der Platte gibt das aber nur schlappe 390 kByte. Durch Reduzierung des Arrays wird in der Summe ein theoretischer Speicher von nur 402 MByte benötigt. Als Fehlermeldung bekomme ich beim Speichern der erstellten Datei im übrigen: "Ende der Datei (EOF) festgestellt Speicherfehlercode 5: BD_Heap"

Ich frage mich langsam wie Labview intern die genannten Variablen speichert.

Ich habe das Ganze auch mit Labview 64bit getestet. Hier bekam ich zwar bei der Ausführung keinen Fehler, allerdings beim Speichern der Datei denselben Fehler wie im 32-bit Fall.

Habt ihr eine Idee wie ich mit den Datenmengen hantieren kann? Derzeit überlege ich mir die Daten binär in eine Datei zu schreiben und diese bei Bedarf wieder auszulesen. Das Ganze wird natürlich schreckens langsam werden.

Alternativ folgende Frage:
Ich habe vor die oben genannten Arrays als Histogramme zu verwenden. Anfangs habe ich die Histogrammfunktion in Labview benutzt und meinen immer größer werdenen Eingangsarray darüber laufen lassen. Allerdings wird irgendwann diese Funktion ebenfalls viel zu langsam weswegen ich auf oben genannte Verfahrensweise umgeschwenkt bin.

Danke im vorraus!

Anzeige

Ich finde die Datenmenge deines Clusters schon recht heftig, sind immerhin 480 MB, die du da 1x im Speicher belegst. Und wenn du das noch in ein Array packst, kann es gut sein, dass LabVIEW das als zusammenhängenden Speicherbereich anfordern will, i.e. 2880 MB. Nicht ohne. Und du musst bei solch großen Strukturen höllisch aufpassen, dass durch das Datenfluss-Prinzip von LabVIEW schnell mal Kopien angelegt werden. 1x Frontpanel-Element, Kopie. Einmal ein FlattenToString, um es binär abzuspeichern, Kopie. Einmal nicht sauber in die Datenstruktur reingehen, um ein Element zu ändern, Kopie.

Brauchst du wirklich so viele Zwischenspeicher im RAM?

Gruß, Jens

(13.06.2014 15:00 )jg schrieb:  Ich finde die Datenmenge deines Clusters schon recht heftig, sind immerhin 480 MB, die du da 1x im Speicher belegst. Und wenn du das noch in ein Array packst, kann es gut sein, dass LabVIEW das als zusammenhängenden Speicherbereich anfordern will, i.e. 2880 MB. Nicht ohne. Und du musst bei solch großen Strukturen höllisch aufpassen, dass durch das Datenfluss-Prinzip von LabVIEW schnell mal Kopien angelegt werden. 1x Frontpanel-Element, Kopie. Einmal ein FlattenToString, um es binär abzuspeichern, Kopie. Einmal nicht sauber in die Datenstruktur reingehen, um ein Element zu ändern, Kopie.

Brauchst du wirklich so viele Zwischenspeicher im RAM?

Gruß, Jens

Hall tschaka81,
ich kann Dein vi hier leider nicht öffnen LV2010.
Als Ergänzung zu Jens Beitrag. Beschäftige Dich mal mit der Inplace Struktur und den DVR (DataValueReference), die genau diese Kopien verhindert.
Die Grenze bei LabVIEW 32-bit liegt wohl bei 2300-2350MB (64-bit Win7 8/16 Gb RAM)

Gruß
Ralf

Hallo tschaka,

Zitat:Alternativ folgende Frage: Ich habe vor die oben genannten Arrays als Histogramme zu verwenden.

Ich kann dein VI mit LV2013-32bit auf WinXP-32bit schon mal gar nicht öffnen, selbst dabei kommt ein Fehler…

Zur Alternativ-Frage: Erläutere doch mal genauer, was du mit diesen Arrays vor hast!
Was willst du dort wie als Histogramm verwenden?
Wozu 2D-Arrays?
Wozu das Ganze 36mal (6 Cluster mit je 6 Arrays)?

Hi

Sorry für die späte Antwort.

Was will ich eigentlich machen: Eigentlich wollte ich versuchen das Problem zu umgehen, da die Experimentstruktur ziemlich kompliziert ist. Mal schauen wie gut ich das zusammenfassen kann:

1. Ich bekomme (nach Bearbeitung meiner Daten) eine Liste mit Daten die etwa folgender Struktur ähnelt:

ADC1, TDC1, ADC2, TDC2, Kanal

das heißt einen Array mit 5 Einträgen pro Zeile. Jeder Wert ist ein 12-bit Wert, außer Kanal, der von 0 bis 5 geht.
Jetzt möchte ich ein Histogramm sowohl aus den einzelnen Spalten erstellen (ok ganz einfach), als auch ein 2D-Histogramm über 2 Spalten hinweg. Da meine Datenmenge mit der Zeit immer größer wird, will ich das 1. Array nicht immer mitschleppen und erneut auswerten, da die Rechenzeit für dieses Problem immer größer wird.

Daher hatte ich mich dazu entschlossen das 2D-Histogramm direkt in einem Hauptarray abzuspeichern. Das sind dann die einzelnen 2D-Arrays im Cluster. Genauso handhabe ich das mit den 1D-Arrays.
Weil ich in Labview nicht genug Speicher zuweisen kann, habe ich mich derzeit dazu entschlossen von 12-bit auf 10-bit zu wechseln. Damit kann Labview noch wunderbar arbeiten. In diesem Programm arbeite ich auch bereits mit Inplace Strukturen.

So die Ausgangslage.

Wie ich in meinem Anfangsthread aber schon vorgerechnet habe, sollte die Initialisierung des Clusters einen Speicher von 2,4 GByte schlucken. Also definitiv kleiner als die 16 Gbyte RAM die in der 64bit Version möglich ist. Aber selbst in dieser Version klappt schon das nackte erstellen des Clusters nicht. Ich suche im Moment eher nach einer Erklärung für das Verhalten. Vielleicht ist ja intern ein Speicherlimit für Arrays oder Cluster festgelegt!?

Man sollte auch darn denken: jeder Verzweigunspunkt oder Überganspunkt (in eine Struktur) im Blockdiagramm entspricht einer neuen Datenkopie. Da kommt als Spiecherplatzbedarf ganz leicht ein Vielfaches der eigentlichen Datenmenge heraus.
Man kann ja statt aller Daten auf einmal auch einzelne Zeilen einer Datei lesen, und auf dieser Grundlage mit riesengroßen Datenmengen umgehen, ohne das Memory entsprechend zu belasten. Es besteht aber ein weit verbreitetes Vorurteil, dass wegen der viele Festplattenzgriffe dann das Programm unakzeptabel langsam wird. Irrtum: Sowohl alle modernen Festplatte als auch das Betriebssystem haben große Zwischenbufferr, aus denn der Zugriff nicht oder nicht viele langsamer ist als das Lesen direkt aus dem Memory.
Vorschlag: Poste Dein Programm, und ich (oder jemand anders) stellen es um, entsprechend diesem Vorschlag.

Anzeige

Hi

Ich habe jetzt einfach mal das VI im Anhang eingefügt. Fühlt euch frei Kritik an der Speicherverwaltung zu äußern. Ich hoffe ihr blickt in meinem Durcheinander durch. Die Datei ist noch im Beta-Status

Hallo tschaka,

Zitat:Ich hoffe ihr blickt in meinem Durcheinander durch.

Nein, das BD ist für mein Laptop (1280×800 px) viel zu groß und durch viel zu viele Sequenzen verschachtelt…

Die subVIs hättest du auch aufräumen können!
Und die offensichtlichen RubeGoldbergs zu entfernen sollte auch nicht so schwer sein, z.B. im "Reset Data":
   

Zitat:Wie ich in meinem Anfangsthread aber schon vorgerechnet habe, sollte die Initialisierung des Clusters einen Speicher von 2,4 GByte schlucken. Also definitiv kleiner als die 16 Gbyte RAM die in der 64bit Version möglich ist. Aber selbst in dieser Version klappt schon das nackte erstellen des Clusters nicht. Ich suche im Moment eher nach einer Erklärung für das Verhalten. Vielleicht ist ja intern ein Speicherlimit für Arrays oder Cluster festgelegt!?

Mit LV32bit wirst du hier immer an Probleme stoßen.
Bei 64bit sollte es theoretisch funktionieren, da hier mehr Speicher adressiert werden kann. Aber: das OS muss diese Speicherblöcke erstens generell für LabVIEW bereithalten und zweitens muss dieser Speicher dazu noch unfragmentiert vorhanden sein. Ist beides bei dir gegeben?
Ein internes Speicherlimit gibt es nicht, man kann theoretisch Arrays mit 2^31-1 Elementen anlegen (Indizes sind I32-Werte)…

Nunja, auf diese simple Methode bin ich beim programmieren leider nicht gekommen. Alles andere: Wie gesagt Beta-Stadium.

Ich habe das Programm derzeit im Betrieb. Mit LV32bit kommen ab und an Speicherprobleme, allerdings nur beim Start und auch das ziemlich selten. Mit LV64bit hatte ich bisher keine Probleme wie du schon gesagt hast.

Aber nochmal zum Thema Speicher

Wenn ein 32-bit großes Array erstellt werden kann sind das 2^31-1 Elemente. Selbst wenn ich da drinnen nur einen 1 Byte Wert stehen habe ist der Gesamtspeicher für dieses Array 16 Gbyte. Unabhängig davon das LV32bit mit soviel Speicher nicht umgehen kann erwarte ich für LV64bit ähnliche Probleme. Wie oben im Thread erklärt konnte ich im ersten Versuch nicht einmal die benötigten Arrays initialisieren und das ohne restliches Programm! Im übrigen funktionierte dies auch nicht in der 64bit Version. Ich bin mir im klaren das die Speichernutzung durch schlechtes Programmieren nur noch schlimmer werden kann. Allerdings ist dies hier nicht das Problem.

Ich hatte im übrigen bemerkt, dass Labview bei der Ausführung der Datei anfangs relativ viel Speicher von Windows beansprucht dann aber innerhalb von Sekunden den Speicher wieder freigibt. Für den Fall der Initialisierung der 4096 Arrays war das beim Initialisieren knapp 7-8 Gbyte (fällt auf 2,5 Gbyte ist aber nicht speicherbar und LV stürzt beim Autospeichern ab)... Im Falle von den 1024 Arrays sind es nur noch 2,4 Gbyte (fällt auf 1,5 Gbyte). Beides in LV64bit. Ich bin mir noch nicht klar was ich daraus lernen kann. Zumindest glaube ich derzeit das die Speicherverwaltung von Labview seine eigenen Limits dem System vorzieht. In meinem Rechner sind im übrigen 20 Gbyte RAM verbaut.

Schöne Grüße

Hallo tschaka,

Zitat:Wenn ein 32-bit großes Array erstellt werden kann sind das 2^31-1 Elemente. Selbst wenn ich da drinnen nur einen 1 Byte Wert stehen habe ist der Gesamtspeicher für dieses Array 16 Gbyte.

Ein Array mit 2^31(-1) Elementen des Typs U8 (=Byte) ist eben 2^31 Byte groß. Oder auch 2*2^30= 2 GiB…

Zitat:Zumindest glaube ich derzeit das die Speicherverwaltung von Labview seine eigenen Limits dem System vorzieht. In meinem Rechner sind im übrigen 20 Gbyte RAM verbaut.

- Die Speicherverwaltung von LabVIEW wird versuchen, den nötigen Speicher vom OS zu bekommen.
- Auch wenn dein Rechner 20GB RAM verbaut hat, heißt das nicht, dass deinem VI eben diese 20GB (oder gar mehr dank VirtRAM) zur Verfügung stehen. Insbesondere nicht als zusammenhängender Block, wie du ihn für diese großen Arrays benötigst!
- Ich kenne mich mit der Speicherverwaltung von Windows nicht wirklich aus und weiß nur ein paar Eckdaten, insbesondere für die 32bit-Versionen. Ob und wie Win64bit andere Limits setzt, musst du dir von einem Experten erläutern lassen…