Speicher für große Daten allokieren funktioniert nicht

WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Partner:

Forum

Option

[Erweitert]

• Diese Seite per Mail weiterempfehlen

Gehe zu:

medtech

Forum-Fortgeschrittener


	Beiträge: 59

	Anmeldedatum: 21.04.16

	Wohnort: ---

	Version: ---

Verfasst am: 08.07.2017, 18:29 Titel: Speicher für große Daten allokieren funktioniert nicht

Hallo Zusammen,

ich arbeite an einem Projekt, bei dem ich mit XML Datensätzen und .bin Einträgen arbeite.
Hierbei ist das grundsätzliche Vorgehen, dass ich zunächst den Speicherplatz eines Datensatzes mittels der Funktions zeros() allokiere und anschließend einen Datensatz im Ganzen in die variable lade und ggf. nach bearbeite.
Für kleinere Datensätze, etwa der Größe 1 GB, funktioniert alles einwandfrei.
Für mich nicht nachvollziehbar wird es allerdings, wenn ich Datensätze im Bereich von 3 GB verwende.
Hierbei bekomme ich eine Fehlermeldung beim Versuch zu allokieren, in der es heißt, dass ich vor habe etwa 7,9 GB Speicherplatz zu allokieren und das zu viel wäre.
Lade ich den Datensatz direkt ohne den allokiervorgang in eine Variable funktioniert es.
Hier etwas Beispielcode.

Code:

%measurement_duration=Messdauer ,mapped_data_set(k).s_entries_s_rates{2,p}=Abtastrate ergibt also Anzahl der Dateneinträge im Array
prealloc=floor(measurement_duration*mapped_data_set(k).s_entries_s_rates{2,p});
%An dieser Stelle erscheins die Fehlermeldung
data.bin=zeros(1,prealloc);
%Laden der .bin Daten, das funktioniert
[data.bin, j_entry] = unisens_get_data(Pfad,'beispiel.bin','all');

Funktion ohne Link?

Ich habe die Einzelnen Variablen geprüft ohne Erfolg. Also die Abtastrate und die Messdauer, mit der ich mir dir Anzahl der Einträge berechne stimmen mit der Anzahl der Werte überein, wenn ich sich ohne Allokation lade.
Zusatz: Ich habe 8GB RAM verbaut, auch wenn Windows viele Prozesse standardmäßig am Laufen hat sollte der Platz locker ausreichen zumal der ganze Datensatz knapp 3GB hat und ich ja immer nur Teile davon lade.
Vielen Dank für eure Hilfe

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 10.07.2017, 14:39 Titel: Re: Speicher für große Daten allokieren funktioniert nicht

Hallo medtech,

Bitte poste immer eine Kopie der vollständigen Fehlermeldung, anstatt sie grob nachzuerzählen. Manchmal sind bestimmte Details der Meldung wichtig.

Die Art der Allozierung ist nicht sinnvoll:

Code:

prealloc = floor(measurement_duration*mapped_data_set(k).s_entries_s_rates{2,p});
data.bin=zeros(1,prealloc);
[data.bin, j_entry] = unisens_get_data(Pfad,'beispiel.bin','all');

Funktion ohne Link?

In der letzten Zeile wird auf der rechnen Seite das Array eingelesen, bevor es das mit Nullen pre-allozierte Array überschreibt. Kurzfristig liegen also beide Arrays im Speicher und folglich ist die eben keine Pre-Allocation, sondern nur ein Blockieren von RAM mit einem Haufen Nullen.

Eine Pre-allocation wird benötigt, um zu vermeiden, dass ein Array iterativ wächst. Das könnte in Deinem Fall innerhalb von unisens_get_data erforderlich sein, aber nicht außerhalb.

Zitat:

Zusatz: Ich habe 8GB RAM verbaut, auch wenn Windows viele Prozesse standardmäßig am Laufen hat sollte der Platz locker ausreichen zumal der ganze Datensatz knapp 3GB hat und ich ja immer nur Teile davon lade.

Nun kommt es darauf an, wie groß der importierte Datensatz genau ist. Das File ist 3GB groß, aber werden die Zahlen auch binär gespeichert? Ansonsten muss man berücksichtigen, dass z.B. eine "1" 8 Bytes belegt, wenn man sie als DOUBLE speichert.
Man benötigt nicht nur X-Bytes freien Speicher, sondern dieser muss auch noch in einem Block frei sein. Wenn man alle 10'000 Bytes ein Byte im RAM belegt hat, sind das zwar nur 0.01% des RAMs, man findet trotzdem keinen Platz mehr, um einen DOUBLE Vektor mit 1250 Elementen zu speichern.

Gruß, Jan

medtech

Themenstarter

Forum-Fortgeschrittener


	Beiträge: 59

	Anmeldedatum: 21.04.16

	Wohnort: ---

	Version: ---

Verfasst am: 10.07.2017, 15:55 Titel:

Hallo Jan,
es lag am Datentyp. Das speichern der float Variablen im Mtalab Standardtyp double hat meinen RAM ''gesprengt''.
Habe dies mit dem Speichern im Datentyp Single umgehen können.
Ok dann habe ich da etwas falsch verstanden bezüglich der Allokierung. Ich dachte durch die Nullen würde der ganze Prozess schneller von statten gehen.
Wäre es dann besser, wenn ich die Nutzdaten zuerst in eine Variable speichere und im anschluss einen typecast durchführe?
also:

Code:

x=Nutzdaten;
single(x);

Funktion ohne Link?

Vielen Dank für deine Antwort Jan

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 12.07.2017, 19:32 Titel:

Hallo medtech,

Zitat:

Ok dann habe ich da etwas falsch verstanden bezüglich der Allokierung. Ich dachte durch die Nullen würde der ganze Prozess schneller von statten gehen.

Das macht es unter Umständen auch:

Code:

x = zeros(1, 1e6);
for k = 1:1e6
x(k) = k;
end

Funktion ohne Link?

Hier werden die elemente des pre-allozierten Arrays verwendet. Hier aber nicht:

Code:

x = zeros(1, 1e6);
x = rand(1, 1e6);

Funktion ohne Link?

Zitat:

Wäre es dann besser, wenn ich die Nutzdaten zuerst in eine Variable speichere und im anschluss einen typecast durchführe?

Der Befehl "single(x)" erzeugt ein Single-Array, macht aber nichts damit. Man muss die Ausgabe schon speichern:

Code:

x = single(Nutzdaten);

Funktion ohne Link?

Dafür liegen dann aber das DOUBLE-Array "Nutzdaten" und das SINGLE-Array "x" gleichzeitig im Speicher. Dann wäre es sinnvoller, die Nutzdaten gleich im richtigen Format zu erzeugen.

Gruß, Jan


Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:	Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen

Impressum | Nutzungsbedingungen | Datenschutz | FAQ |

RSS

Hosted by:

Copyright © 2007 - 2024 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.