Liebe Leute,

ich bin etwas verwundert: ich habe ein Tool geschrieben, dass komplexe Listenoperationen durchführt. Auf meinem alten PC mit 4GB RAM war das kein Problem; auf dem neuen System mit 16GB RAM erhalte ich jetzt plötzlich bei den gleichen Operationen die Fehlermeldung, es sei nicht genügend Arbeitsspeicher verfügbar. Wie kann das sein?!?

Danke Euch und schöne Grüße,
frieder

PS: An den Systemen hat sich nichts 'zum Schlechteren' geändert, dachte ich zumindest.. (vorher Intel I4 - Desktop-PC, 64Bit, jetzt eine neue Dell-Workstation mit 12-Kernproz.)

Wann tritt der Fehler auf? -> Etwas Source-Code mit Stelle des Fehlers wäre bestimmt auch dem einen oder anderen hilfreich

Da dein Programm ein 32-Bit Executable ist steht dem eh nur 2 (bzw. 3 GB wenn entsprechend Compiliert) zur verfügung.

Ich tipp mal darauf das auf deinem neuen PC viele kleine "Helferlein" dafür sorgen das der Adressraum jeder geladenen 32-Bit Anwendung schon mit DLLs "zerstückelt" ist dein Programm dann keine größeren Adressräume mehr En-Block zur verfügung stehen hat.

Zitat von friedemann2009:

PS: An den Systemen hat sich nichts 'zum Schlechteren' geändert, dachte ich zumindest.. (vorher Intel I4 - Desktop-PC, 64Bit, jetzt eine neue Dell-Workstation mit 12-Kernproz.)

Gibts wirklich einen Intel I4? Wenn dann einen alten P4, oder einen i3 oder i5

Egal, back to Topic...

Zitat von Bernhard Geyer:

Da dein Programm ein 32-Bit Executable ist steht dem eh nur 2 (bzw. 3 GB wenn entsprechend Compiliert) zur verfügung.

Compilierst du eine 32-Bit-Exe oder 64-Bit?

Zitat von Bernhard Geyer:

Ich tipp mal darauf das auf deinem neuen PC viele kleine "Helferlein" dafür sorgen das der Adressraum jeder geladenen 32-Bit Anwendung schon mit DLLs "zerstückelt" ist dein Programm dann keine größeren Adressräume mehr En-Block zur verfügung stehen hat.

Bist du sicher mit der Vermutung? sowas sollte doch Windows für einen handeln. Ein Programm schreibt doch eh nur in einen virtuellen Block und da spielt es doch keine Rolle, ob der Block wirklich zusammenhängend ist oder nicht.

Zitat von s.h.a.r.k:

Gibts wirklich einen Intel I4? Wenn dann einen alten P4, oder einen i3 oder i5

*Hüstel*, könnte auch ein i3 gewesen sein, bin ich mir nicht mehr sicher..

Zitat von s.h.a.r.k:

Compilierst du eine 32-Bit-Exe oder 64-Bit?

Ist als 32-Bit compiliert, aber das war auf dem alten System auch kein Problem. Was mir auch aufgefallen ist: die Anwendung braucht auf dem neuen System viel viel länger (etwa 6:1) zum Laden und die Rechenoperationen dauern ebenfalls länger (gefühlt, habe es nicht gemessen). Kann so etwas sein, obwohl das neue System von der Hardware her im Grunde viel mehr Power haben müsste (Laden läuft auf meinem 32bit-Netbook sogar schneller!)?

Code kann ich leider gerade nicht liefern, weil D (noch) nicht auf dem neuen System läuft..

Danke und schöne Grüße,
frieder

EDIT:

Zitat:

Da dein Programm ein 32-Bit Executable ist steht dem eh nur 2 (bzw. 3 GB wenn entsprechend Compiliert) zur verfügung.

Ich tipp mal darauf das auf deinem neuen PC viele kleine "Helferlein" dafür sorgen das der Adressraum jeder geladenen 32-Bit Anwendung schon mit DLLs "zerstückelt" ist dein Programm dann keine größeren Adressräume mehr En-Block zur verfügung stehen hat.

Ok, das ist krass, das wusste ich nicht. - Aber das erklärt dennoch nicht den Unterschied zwischen den beiden (!) 64-Bit-Systemen!

Win64 hat eine etwas andere Speicherverwaltung und außerdem haben sich einige System-DLLs verändert, womit diese auch noch etwas mehr RAM belegen können.
Allein schon die größeren Dateien vrauchen zwar nicht mehr physischen RAM, aber im virtuellen Arbeitsspeicher wird dennoch mehr Platz belegt.

Wie sah denn die Speicherauslastung auf dem alten System aus?
Waren da die 2 GB auch schon fast randvoll?

Du mußt dir unbedingt klar machen, daß es einen Unterschied zwischen physischem RAM, Auslagerungsdatei (Pagefile) und virtuellem Speicher gibt.
Im System sind vielleich x GB an RAM verbaut und dazu kommt dann noch die Auslagerungsdatei.
Somit hat man zusammen x GB für alle Programme zur Vergügung.

Dein Programm besitzt aber bei 32 Bit nur 2 GB virtuellem RAM (3 GB, wenn man eine gewisse Option aktiviert, im Windows und in der EXE).
Maximal kann von den 2 GB aber nur soviel belegt werden, wie physisch (RAM+Pagefile) zur Verfügng stehen (frei sind).

In diesen 2 GB gibt es dann noch Bereiche, wo man nichts ablegen kann (die ersten 64 KB) und dann liegen auch noch überall die gemappten Teile der DLLs und der EXE (z.B. Programmcode und Resourcen), welche meistens direkt von der Festplatte im virtuellen Speicher abgebildet sind, aber keinen physischen RAM belegen (das selbe gilt für MMF) und dann können Programme gleiche DLLs/EXEn sich teilen, womit diese nur einmal für Alles im physischem RAM liegen und nur in den Virtuellen reingemappt werden.

Und der Restliche virtuelle Speicher ist quasi dich. Aber auch da kann man nur speicher reservieren, wenn man ein Stückchen findet, das groß genug ist.
Will man z.B. ein Array mit 1 GB erstellen, dann braucht man dafür einen Speicherblock, welcher zusammenhängend mindestens 1 GB groß ist, was nicht so einfach wird, wenn wild verteilt sonstwas darin rumliegt.

Puh, erst mal vielen Dank für die Infos. Es wird also wirklich Zeit, mich von D5 (ja, ich weiß..) zu verabschieden; wollte mir die neu erschiedenene RAD Studio XE3 besorgen.

Ganz klar ist mir allerdings immer noch nicht, warum die selbe 32bit-Exe auf dem einen 64-Bit-System (mit weniger Rechenpower) besser läuft als auf anderen (und besseren) 64-Bot-System (beide Win7 übrigens). Das läuchtet mir nach Euren Erklärungen noch nicht ein.

Taskmanager hatte ich beobachtet: sowohl virt. als auch physischer Arbeitsspeicher waren, wenn ich nicht total blöd bin, nicht komplett ausgelastet (zumindest in dem Moment der Fehlermeldung). Waren im einen Fall ~8GB, im anderen Fall etwa 2GB "frei".

Schöne Grüße,
frieder

Zitat von s.h.a.r.k:

Zitat von Bernhard Geyer:

Ich tipp mal darauf das auf deinem neuen PC viele kleine "Helferlein" dafür sorgen das der Adressraum jeder geladenen 32-Bit Anwendung schon mit DLLs "zerstückelt" ist dein Programm dann keine größeren Adressräume mehr En-Block zur verfügung stehen hat.

Bist du sicher mit der Vermutung? sowas sollte doch Windows für einen handeln. Ein Programm schreibt doch eh nur in einen virtuellen Block und da spielt es doch keine Rolle, ob der Block wirklich zusammenhängend ist oder nicht.

Kommt darauf an was genau "komplexe Listenoperationen" bedeutet. Hier kann man mit großen dynamischen Arrays ziemlich leicht probleme bekommen.

Ok, ich sehe schon: ich sollte einfach mal 64bit compilieren und auf dem neuen System via XE3 durchtesten.

Danke für Hilfe und schönes WE,
frieder

Zitat von friedemann2009:

Ok, ich sehe schon: ich sollte einfach mal 64bit compilieren und auf dem neuen System via XE3 durchtesten

Nein, solltest du nicht. Du solltest den entsprechenden Quellcodeteil posten damit wir dir sagen können welches grundsätzlichen Fehler/falschen Ansatz du hast der solche Probleme verursachen kann.