riesengroße Arrays > 2GB

[juelin]

Hallo zusammen,
ich habe ein Problem, bei dem Ihr mir vielleicht helfen könnt.
Ich brauche für mein Programm ein riesiges ARRAY.

"
type tfiguren = record
x: integer;
y: integer;
f: integer;
s: integer;
end;

type tframes = record
a: integer;
f: array [1..9999] of tfiguren;
end;

var frametab: array [1..131072] of tframes;
"

Nun bekomme ich die Fehlermeldung:
[dcc32 Fehler] Unit1.pas(123): E2100 Datentyp zu groß: 2 GB überschritten

Habt Ihr da eine Lösung?

Danke und Gruß
Jürgen

[Der schöne Günther]

Ein Array zeichnet sich dadurch aus dass die Daten am Stück vorliegen. Was du vorhast ist Wahnsinn.

Dein Typ "TFiguren" ist 16 Byte groß. Dein Typ "TFrames" ist 4 + 9998 * 16 Bytes groß. Also ca 160 KB. Und von denen willst du jetzt 131071 am Stück haben. Das ergibt 20971360000 Bytes, das sind 19,53 GB am Stück.

Eine 32Bit-Anwendung kann übrigens maximal 2 GB Arbeitsspeicher addressieren, mehr geht nicht.


Erst einmal musst du dir klar werden dass du so viele Daten nicht alle gleichzeitig brauchst. Wirklich nicht.

[bra]

http://docwiki.embarcadero.com/RADSt...ritten_(Delphi)

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1373300)

Eine 32Bit-Anwendung kann übrigens maximal 2 GB Arbeitsspeicher addressieren, mehr geht nicht.

Standardmäßig.
Per PE-Optionen kann man auch 3 bzw. 4GB aktivieren.
Aber selbst damit bleibt die maximale größe des Typs bei 2 GB, aber gibt ja noch anderen Speicherverbrauch im Programm.
Und als letzte Alternative eine 64 Bit-Anwendung.

ABER, in einer 32 Bit-Anwendung ist es schon schwer genug 700MB am Stück zu bekommen.
Stichwort Speicherfragmentierung, da der reservierte Arbeitsspeicher und die geladenen DLLs/EXE verstreut im virtuellen Speicher (RAM) rumliegen.

Und wenn man sowas

Delphi-Quellcode:

var frametab: array [1..131072] of tframes;

auch noch als lokale Variable verwenden wöllte, dann käme noch dazu, dass diese Variable dann im Stack läge und der ist standardmäßig nur ein paar MB groß.


Das Ding nicht als Array, sondern als verkettete Liste, aber zum Speichersparen vielleicht nicht die elemente verknüpfen, sondern das in "kleineren" Paketen (mehrere kleinere statisches Arrays in einer verketteten Liste oder als mehrdimensionales Array in einem übergeordnetem Array)
Bei deiner Struktur könntest du aber die beiden statischen Arrays in dynamische ändern und schon ist das nicht mehr als ein Stück im RAM, vorallem durch

Delphi-Quellcode:

f: array of tfiguren;

wird das schon stark aufgeteilt.

Bei der Menge:
* in Dateien auslagern und selber nur den Teil in den RAM holen, der grade nötig ist
* Memory Mapped File (MMF) ... kann man auch ohne Datei komplett im RAM haben, aber icht würde eine Datei empfehlen ... Windows hält dann dennoch viel im Windows File Cache
* Address Windowing Extensions (AWE)
* ...

[Der schöne Günther]

So weit wollte ich gar nicht erst ausholen, ich bin mir sicher dass er wirklich nicht 19,5 GB gleichzeitig braucht ;-)

[hstreicher]

Hallo
Wenn nicht alle Datenpunkte benutzt werden dann würde ich mir mal Sparse Arrays ansehen

Oder eben eine Datenbank

Mfg Hannes

[HolgerX]

Hmm..

oder zunächst mal aus tframes ein TObject statt Record machen

und aus frametab eine ObjectList.

Dadurch beinhaltet frametab nur 131072 Pointer auf tframes, die irgendwo 'verstreut' im Speicher liegen und somit nicht mehr zusammenhängend sein müssen.

[p80286]

Zitat:

Zitat von juelin (Beitrag 1373298)

Ich brauche für mein Programm ein riesiges ARRAY.

Sicher? zumindest Frametab sollte durch eine ???List ersetzt werden können.
Eine weitere Speichereffizente Lösung wöre die einfach verkettete Liste, die ist aber für wahlfreie Zugriffe denkbar ungeeignet.
Wofür brauchst Du diese Datenmenge?
ggf. gibt es effizentere Datenstrukturen?

Gruß
K-H

[Ghostwalker]

Zitat:

Zitat von HolgerX (Beitrag 1373360)

Hmm..

oder zunächst mal aus tframes ein TObject statt Record machen

und aus frametab eine ObjectList.

Dadurch beinhaltet frametab nur 131072 Pointer auf tframes, die irgendwo 'verstreut' im Speicher liegen und somit nicht mehr zusammenhängend sein müssen.

Für was ein Objekt, das wesentlich mehr Speicher verbrät ?

Besser:

Delphi-Quellcode:

  Type
    PFrames = ^TFrames

und dann schlicht mit einer TList arbeiten.

[HolgerX]

Hmm..

Zitat:

Zitat von Ghostwalker (Beitrag 1373368)

Zitat:

Zitat von HolgerX (Beitrag 1373360)

Hmm..

oder zunächst mal aus tframes ein TObject statt Record machen

und aus frametab eine ObjectList.

Dadurch beinhaltet frametab nur 131072 Pointer auf tframes, die irgendwo 'verstreut' im Speicher liegen und somit nicht mehr zusammenhängend sein müssen.

Für was ein Objekt, das wesentlich mehr Speicher verbrät ?

Besser:

Delphi-Quellcode:

  Type
    PFrames = ^TFrames

und dann schlicht mit einer TList arbeiten.

Ich glaube kaum, dass

Delphi-Quellcode:

type tframes = class
a: integer;
f: array [1..9999] of tfiguren;
end;

anstelle von

Delphi-Quellcode:

type tframes = record
a: integer;
f: array [1..9999] of tfiguren;
end;

Wirklich wesendlich mehr an Speicher verbraucht. Das gro an Speicher braucht das 'array [1..9999] of tfiguren;' und nicht das TObject.
Ich bin zwar kein Spezialist was Speichermanagment angeht, sollten eigentlich nur ein, zwei Pointer mehr an Speicher sein, wenn überhaupt.


Aber egal..

Ja man kann TList direkt mit Pointer auf Records verwenden, jedoch dann darauf achten, das mit AllocMem/GetMem immer der Speicher des Records geholt wird und zum Schluss schön mit FreeMem wieder freigegeben wird.

Bei Objectlist würde sich durch ownsobject die Liste selber um die (saubere) Freigabe kümmern.

Edit:
Habe mal durch Delphi die Größen ermitteln lassen:

Record 159988 Bytes (mit SizeOf)
Object 159992 Bytes (mit Object.InstanceSize)

Somit macht dass bei 32Bit gerade mal 4 Bytes mehr pro Object! Bei 159988 Bytes ist das wohl nicht Wesendlich mehr. ;)

Hochgerechnet auf 131072 Objecten macht das ein Mehrverbrauch von 524288 Bytes also 512 Kb..
Und das ist bei den eh schon 19 Gb wohl zu vernachlässigen ;)

[hoika]

Hallo,
ich werfe mal Memory Mapped files ins Rennen.

[Mavarik]

New / Dispose...

Btw: Ist Euch aufgefallen, dass der TE nicht mehr geantwortet hat?

Das ist wieder so ein Thread der sich selber am Leben hält...

Mavarik :coder:

[himitsu]

Zitat:

Zitat von Mavarik (Beitrag 1373376)

Btw: Ist Euch aufgefallen, dass der TE nicht mehr geantwortet hat?

51 Logins in 11 Jahren ... statistisch in spätestens 78 Tagen wird eine Antwort schon noch kommen :D

[Ghostwalker]

Zitat:

Zitat von HolgerX (Beitrag 1373371)

Hmm..

Zitat:

Zitat von Ghostwalker (Beitrag 1373368)

Zitat:

Zitat von HolgerX (Beitrag 1373360)

Hmm..

oder zunächst mal aus tframes ein TObject statt Record machen

und aus frametab eine ObjectList.

Dadurch beinhaltet frametab nur 131072 Pointer auf tframes, die irgendwo 'verstreut' im Speicher liegen und somit nicht mehr zusammenhängend sein müssen.

Für was ein Objekt, das wesentlich mehr Speicher verbrät ?

Besser:

Delphi-Quellcode:

  Type
    PFrames = ^TFrames

und dann schlicht mit einer TList arbeiten.

Ich glaube kaum, dass

Delphi-Quellcode:

type tframes = class
a: integer;
f: array [1..9999] of tfiguren;
end;

anstelle von

Delphi-Quellcode:

type tframes = record
a: integer;
f: array [1..9999] of tfiguren;
end;

Wirklich wesendlich mehr an Speicher verbraucht. Das gro an Speicher braucht das 'array [1..9999] of tfiguren;' und nicht das TObject.
Ich bin zwar kein Spezialist was Speichermanagment angeht, sollten eigentlich nur ein, zwei Pointer mehr an Speicher sein, wenn überhaupt.


Aber egal..

Ja man kann TList direkt mit Pointer auf Records verwenden, jedoch dann darauf achten, das mit AllocMem/GetMem immer der Speicher des Records geholt wird und zum Schluss schön mit FreeMem wieder freigegeben wird.

Bei Objectlist würde sich durch ownsobject die Liste selber um die (saubere) Freigabe kümmern.

Edit:
Habe mal durch Delphi die Größen ermitteln lassen:

Record 159988 Bytes (mit SizeOf)
Object 159992 Bytes (mit Object.InstanceSize)

Somit macht dass bei 32Bit gerade mal 4 Bytes mehr pro Object! Bei 159988 Bytes ist das wohl nicht Wesendlich mehr. ;)

Hochgerechnet auf 131072 Objecten macht das ein Mehrverbrauch von 524288 Bytes also 512 Kb..
Und das ist bei den eh schon 19 Gb wohl zu vernachlässigen ;)

ok...ich mein ich hab da was gelesen das " = Class" und " = Class(TObject)" unterschiedlich gehandhabt werden. von daher könntest du recht haben.

Was ich aber meinte ist:

Delphi-Quellcode:

TYPE
   pfiguren = ^tfiguren;
   tfiguren = record
              x,y,f,s : integer;
             end;
   pframes = ^tframes;
   tframes = record
               a : integer;
               f : TList;
             end;
var
  frametab : TList;

oder (so würd ich das machen)

Delphi-Quellcode:

TYPE
   pfiguren = ^tfiguren;
   tfiguren = record
              x,y,f,s : integer;
             end;
   pframes = ^tframes;

   tframes = Class
   private
      pa : integer;
      pf : TList;

      procedure ClearAll;

   public
       :
       function Add(x,y,f,s:integer):integer;
       procedure Del(index:integer);

       property f[index:integer]:TFiguren read GetF write SetF;
   published
       property a : integer read pa write pa;
   end;
var
  frametab : TObjectlist;

:stupid:

[HolgerX]

Das

f: array [1..9999] of tfiguren;

ebenfalls zu einer TList zu machen, ist auch OK, nur dann hättest Du gleich je TFiguren * 4 Byte mehr für die Pointer in der TList.
Entspricht dann: 10000 * 4 * 131072 = 4,8 Gb..

Und das währe dann wirklich wesendlich mehr ;)

Es ging mir in meinem Vorschlag darum, die 19 Gb am Stück aufzuteilen und dazu genügt es schon aus tframes eine Klasse zu machen..

Denn für 159992 Bytes am Stück ist es einfacher Speicher zu bekommen, statt für 19 Gb. ;)

Lt meinem Wissen ist
" = Class" und " = Class(TObject)" identisch, zu mindestens bei Delphi 6 ;)

Das " = Class" stellt nur eine verkürzte Schreibweise da.

[Ghostwalker]

Nö.

TFiguren ist ein Zeiger auf einen Record. D.h. ich hab pro Element ledigilich 4 Byte die am Stück benötigt werden (+ 16 Byte irgendwo im Speicher). Wie weiter oben schon erwähnt wurde, ist hier das entscheidende, das ein Array den Speicher am Stück brauchen.

d.h. das das Array (mit den 10000 Elementen) im 1. Fall 156 MB am Stück braucht, in meinem Fall 39 MB (Also bei TFiguren als Zeiger). Die 156 MB verteilen sich in kleine Häpchen über den Speicher (je nach dem wo der Speichermanager das grad hinpackt.)

Aber egal wie nu, wir dürften uns einig sein, das hier einfach viel zu viele Daten im Speicher gehalten werden (bzw. versucht wird das zu tun).

[freimatz]

Zitat:

Zitat von himitsu (Beitrag 1373382)

Zitat:

Zitat von Mavarik (Beitrag 1373376)

Btw: Ist Euch aufgefallen, dass der TE nicht mehr geantwortet hat?

51 Logins in 11 Jahren ... statistisch in spätestens 78 Tagen wird eine Antwort schon noch kommen :D

Hm, ich überlege was ich fragen könnte :twisted: ... und mich dann zurücklehnen und die Antworten genießen :lol: popcorn