32bit-Anwendung mit mehr als 4GB innerhalb 64bit-OS

[Markus Springweiler]

Hallo,

weiß jemand zufällig, ob ein 64-bit-Windows, mit z.B. 16 GiB RAM, schlau
genug ist, eine 10 GiB Datei, welche von einem 32-bit-Prozess mittels
Memory-Mapped-Files und entsprechend über den Speicherbereich wandernden
Mapping-Views verwendet wird, im Speicher zu behalten?

Theoretisch (und logisch gesehen) sollte das kein Problem darstellen, aber
man weiß ja nie.

Wenn jemand dazu noch positives oder negatives zur Performance weiß, würde
mich die Meinung auch interessieren. Oder wie groß ein Mapping-Fenster mit
einer IMAGE_FILE_LARGE_ADDRESS_AWARE-fähigen Win32-Anwendung sein würde,
hat da jemand praktische Erfahrungen?
(Optimal wäre natürlich 4GiB abzüglich der anderen Anwendungs-spezifischen
Resourcen.)

[Hans-Peter Diettrich]

Post by Markus Springweiler
weiß jemand zufällig, ob ein 64-bit-Windows, mit z.B. 16 GiB RAM, schlau
genug ist, eine 10 GiB Datei, welche von einem 32-bit-Prozess mittels
Memory-Mapped-Files und entsprechend über den Speicherbereich wandernden
Mapping-Views verwendet wird, im Speicher zu behalten?
Theoretisch (und logisch gesehen) sollte das kein Problem darstellen, aber
man weiß ja nie.

Wenn mehrere Prozesse das machen, reicht der Speicher nicht für alle.
Vermutlich fliegen alle nicht benutzten Seiten weiterhin aus dem
Speicher, wenn der für was anderes benötigt wird.

DoDi

[Markus Springweiler]

Hans-Peter,

Post by Hans-Peter Diettrich

Post by Markus Springweiler
weiß jemand zufällig, ob ein 64-bit-Windows, mit z.B. 16 GiB RAM, schlau
genug ist, eine 10 GiB Datei, welche von einem 32-bit-Prozess mittels
Memory-Mapped-Files und entsprechend über den Speicherbereich wandernden
Mapping-Views verwendet wird, im Speicher zu behalten?
Theoretisch (und logisch gesehen) sollte das kein Problem darstellen, aber
man weiß ja nie.

Wenn mehrere Prozesse das machen, reicht der Speicher nicht für alle.
Vermutlich fliegen alle nicht benutzten Seiten weiterhin aus dem
Speicher, wenn der für was anderes benötigt wird.

Wenn mehrere Prozesse dieselbe 10 GiB Datei bearbeiten sehe ich da noch
keine Probleme -- wenn andere Prozesse RAM reservieren, kann es
grundsätzlich passieren, daß ausgerechnet die eigenen Anwendung auf der
Strecke bleibt und nur noch mit Aus- und Einlagern beschäftigt ist.

Grundsätzlich hätten mich neben allgemeingültigen Weisheiten jetzt eher
echte Erfahrungswerte interessiert, also wie groß eine
MemoryMappedFile-View wirklich werden kann, oder ob Windows dort wieder
irgendwo versteckte Limits hat, selbst wenn der Prozess via
IMAGE_FILE_LARGE_ADDRESS_AWARE-Flag signalisiert, daß bei 31bit noch nicht
das Ende der Fahnenstange erreicht ist.

[Markus Springweiler]

Hans-Peter,

Post by Hans-Peter Diettrich

Post by Markus Springweiler
weiß jemand zufällig, ob ein 64-bit-Windows, mit z.B. 16 GiB RAM, schlau
genug ist, eine 10 GiB Datei, welche von einem 32-bit-Prozess mittels
Memory-Mapped-Files und entsprechend über den Speicherbereich wandernden
Mapping-Views verwendet wird, im Speicher zu behalten?
Theoretisch (und logisch gesehen) sollte das kein Problem darstellen, aber
man weiß ja nie.

Wenn mehrere Prozesse das machen, reicht der Speicher nicht für alle.
Vermutlich fliegen alle nicht benutzten Seiten weiterhin aus dem
Speicher, wenn der für was anderes benötigt wird.

Wenn mehrere Prozesse dieselbe 10 GiB Datei bearbeiten sehe ich da noch
keine Probleme -- wenn andere Prozesse RAM reservieren, kann es
grundsätzlich passieren, daß ausgerechnet die eigenen Anwendung auf der
Strecke bleibt und nur noch mit Aus- und Einlagern beschäftigt ist.

Grundsätzlich hätten mich neben allgemeingültigen Weisheiten jetzt eher
echte Erfahrungswerte interessiert, also wie groß eine
MemoryMappedFile-View wirklich werden kann, oder ob Windows dort wieder
irgendwo versteckte Limits hat, selbst wenn der Prozess via
IMAGE_FILE_LARGE_ADDRESS_AWARE-Flag signalisiert, daß bei 31bit noch nicht
das Ende der Fahnenstange erreicht ist.

[Hubert Seidel]

Hallo Markus,

Post by Markus Springweiler
weiß jemand zufällig, ob ein 64-bit-Windows, mit z.B. 16 GiB RAM, schlau
genug ist, eine 10 GiB Datei, welche von einem 32-bit-Prozess mittels
Memory-Mapped-Files und entsprechend über den Speicherbereich

wandernden

Post by Markus Springweiler
Mapping-Views verwendet wird, im Speicher zu behalten?

Von welchem Betriebssystem gehst Du denn aus?
(Man kann bestimmt auch Win95 laufen lassen ;-)

Meine Einschätzung:
Ein 32-Bit-Prozess hat nur 32-Bit-Register und kann demnach
im auch nur max. 4GB linear, direkt ohne weitere Tricks ansprechen.

Nach etwas Recherche im Internet habe ich folgendes gefunden:
..."64-bit versions of Windows Server 2003 or Windows XP"...
http://support.microsoft.com/?scid=kb%3Ben-us%3B889654&x=10&y=13

Im oberen viertel der Seite steht in einer Tabelle bei 64-bit zu
"General memory limits" zu "Virtual address space per 32-bit process":
2 GB, 4 GB if the application is compiled with the /LARGEADDRESSAWARE
switch

Ich denke der Schalter "LARGEADDRESSAWARE" hat nix mit Delphi zu tun...

bzw. siehe auch:
"Comparison of 32-bit and 64-bit memory architecture for 64-bit editions
of Windows XP and Windows Server 2003"
http://support.microsoft.com/?scid=kb%3Ben-us%3B294418&x=9&y=10
Möglicherweise findest Du über die Seiten auch etwas zu Deinem
Betriebssystem, aber ich glaube mehr als 4GB wird ein 32-Bit-Prozess
einfach nicht (nie) direkt ansprechen können.

Post by Markus Springweiler
Theoretisch (und logisch gesehen) sollte das kein Problem darstellen, aber
man weiß ja nie.

Wie soll man theoretisch mit 32 Bit mehr als 32 Bit direkt Addressieren
können?

Post by Markus Springweiler
Wenn jemand dazu noch positives oder negatives zur Performance weiß, würde
mich die Meinung auch interessieren. Oder wie groß ein Mapping-Fenster mit
einer IMAGE_FILE_LARGE_ADDRESS_AWARE-fähigen Win32-Anwendung sein würde,
hat da jemand praktische Erfahrungen?
(Optimal wäre natürlich 4GiB abzüglich der anderen

Anwendungs-spezifischen

Post by Markus Springweiler
Resourcen.)

Bestimmt findest Du was bei den KB-Seiten dazu... ich will Dir ja nicht
den kompletten Recherche-Spaß nehmen ;-)

mfg.
Herby

[Ozan Ayyüce]

Post by Hubert Seidel
Im oberen viertel der Seite steht in einer Tabelle bei 64-bit zu
2 GB, 4 GB if the application is compiled with the /LARGEADDRESSAWARE
switch
Ich denke der Schalter "LARGEADDRESSAWARE" hat nix mit Delphi zu tun...

LARGEADDRESSAWARE ist ein Flag in der .exe Dateiinformation und wird
gesetzt wenn der Linker mit dieser Option ausgeführt wird.


Ozan

[Ozan Ayyüce]

Post by Hubert Seidel
Ein 32-Bit-Prozess hat nur 32-Bit-Register und kann demnach
im auch nur max. 4GB linear, direkt ohne weitere Tricks ansprechen.

Richtig.

Post by Hubert Seidel
Im oberen viertel der Seite steht in einer Tabelle bei 64-bit zu
2 GB, 4 GB if the application is compiled with the /LARGEADDRESSAWARE
switch
Ich denke der Schalter "LARGEADDRESSAWARE" hat nix mit Delphi zu tun...

LARGEADDRESSAWARE ist ein Flag in der .exe Dateiinformation und wird
gesetzt wenn der Linker mit dieser Option ausgeführt wird. Das hat
aber mit memory-mapped-files wenig zu tun.

Post by Hubert Seidel
Wie soll man theoretisch mit 32 Bit mehr als 32 Bit direkt Addressieren
können?

Indem man eine mapped-view der Datei erstellt, welche kleiner ist als
die 4GB, und dann darauf zugreift. Die Api-funktionen dafür nehmen
zwei DWORDS als Startadresse des Views, es geht also auch mit Dateien
die größer sind als 4GB.



Ozan

[Hubert Seidel]

Hallo Ozan,

Post by Ozan Ayyüce

Post by Hubert Seidel
Ein 32-Bit-Prozess hat nur 32-Bit-Register und kann demnach
im auch nur max. 4GB linear, direkt ohne weitere Tricks ansprechen.

Richtig.

Post by Hubert Seidel
Im oberen viertel der Seite steht in einer Tabelle bei 64-bit zu
"General memory limits" zu "Virtual address space per 32-bit
2 GB, 4 GB if the application is compiled with the /LARGEADDRESSAWARE
switch
Ich denke der Schalter "LARGEADDRESSAWARE" hat nix mit Delphi zu tun...

LARGEADDRESSAWARE ist ein Flag in der .exe Dateiinformation und wird
gesetzt wenn der Linker mit dieser Option ausgeführt wird. Das hat
aber mit memory-mapped-files wenig zu tun.

Richtig. Hat mit Delphi nix zu tun, ist eine
Sache welches das Betriebssystem berücksichtigt.

Post by Ozan Ayyüce

Post by Hubert Seidel
Wie soll man theoretisch mit 32 Bit mehr als 32 Bit direkt

Addressieren

Post by Ozan Ayyüce

Post by Hubert Seidel
können?

Indem man eine mapped-view der Datei erstellt, welche kleiner ist als

Das ist dann ja eben nicht mehr _direkt_.

Post by Ozan Ayyüce
die 4GB, und dann darauf zugreift. Die Api-funktionen dafür nehmen
zwei DWORDS als Startadresse des Views, es geht also auch mit Dateien
die größer sind als 4GB.

Nur dann ist ja nicht die "Anwendung mit mehr als 4GB" zugange.
(Jedenfalls nicht, wenn ich das auf die Goldwaage lege)

Und wenn ich gerade dabei bin mir die API-Funktion MapViewOfFile ansehe,
dann sehe ich das die gemappte Byte-Anzahl ein DWORD (32 Bit) ist:

LPVOID MapViewOfFile(
HANDLE hFileMappingObject, // file-mapping object to map into
address space
DWORD dwDesiredAccess, // access mode
DWORD dwFileOffsetHigh, // high-order 32 bits of file offset
DWORD dwFileOffsetLow, // low-order 32 bits of file offset
DWORD dwNumberOfBytesToMap // number of bytes to map
);

Es kann also offensichtlich nicht mehr als 32 Bit gleichzeitig (im RAM,
wo auch sonst auch ;-) angesprochen werden.

Und dabei bestimmt nur innerhalb von lpMinimumApplicationAddress und
lpMaximumApplicationAddress.

procedure TForm1.Button1Click(Sender: TObject);
var
si:TSystemInfo;
begin
GetSystemInfo(si);
with Memo1 do
begin
Clear;
with Lines do
begin
Add('dwOemId ....................... : $'+IntToHex(si.dwOemId,8));
Add('wProcessorArchitecture ........ :
'+IntToStr(si.wProcessorArchitecture));
Add('dwPageSize .................... : '+IntToStr(si.dwPageSize));
Add('lpMinimumApplicationAddress ... :
$'+IntToHex(Integer(si.lpMinimumApplicationAddress), 8));
Add('lpMaximumApplicationAddress ... :
$'+IntToHex(Integer(si.lpMaximumApplicationAddress), 8));
Add('dwActiveProcessorMask ......... :
$'+IntToHex(si.dwActiveProcessorMask, 8));
Add('dwNumberOfProcessors .......... :
'+IntToStr(si.dwNumberOfProcessors));
Add('dwProcessorType ............... :
'+IntToStr(si.dwProcessorType));
Add('wProcessorLevel ............... :
'+IntToStr(si.wProcessorLevel));
Add('wProcessorRevision ............ :
'+IntToStr(si.wProcessorRevision));
Add('dwAllocationGranularity ....... :
'+IntToStr(si.dwAllocationGranularity));
end;
end;
end;

Ein "Fensterln", bzw. verschieben des sichtbaren bereichs wird bestimmt
von irgendwelchen File-Caches o.ä. abhängig sein. Wenn die File-Caches
groß genug sind und das Betriebssystem nicht auf die Idee kommt zurück
zu schreiben, bleiben Daten evtl. ja noch eine Zeit lang im RAM.

(
Solltest Du die Frage anders gemeint haben, also rein auf die
Dateigröße, dann kann man bestimmt problemlos mit Win95 ein FileMapping
virtualisieren welches über mehrere Terrabyte gehen (FileOffset mit z.b.
256 Bit), und einer Fenstergröße von nur 1MB... aber ich bin mir sicher,
das ist nicht gefragt.
)

mfg.
Herby

[Hans-Peter Diettrich]

Post by Hubert Seidel
Von welchem Betriebssystem gehst Du denn aus?
(Man kann bestimmt auch Win95 laufen lassen ;-)

Von welchem System gehst Du aus?

Post by Hubert Seidel
Ein 32-Bit-Prozess hat nur 32-Bit-Register und kann demnach
im auch nur max. 4GB linear, direkt ohne weitere Tricks ansprechen.

x86 Prozessoren haben zusätzlich noch Segmentregister, die prinzipiell
einen weit größeren Adressraum als nur 4 GB erlauben, auch wenn dies von
den meisten 32 Bit CPUs nicht unterstützt wird. Immerhin gab es schon
vor Einführung der 64 Bit Architektur Chipsets mit 36 Bit
(physikalischen) Adressen. Selbst die 16 Bit Versionen konnten ja schon
mehr als nur 64 KB adressieren, sowohl logisch als auch physikalisch.

DoDi

[Hubert Seidel]

Hallo DoDi,

Post by Hans-Peter Diettrich

Post by Hubert Seidel
Von welchem Betriebssystem gehst Du denn aus?
(Man kann bestimmt auch Win95 laufen lassen ;-)

Von welchem System gehst Du aus?

Wieso ???ICH???

Zudem habe ich ja geschrieben zu welchem Betriebssystem ich was
gefunden habe... (Wer lesen kann, ist klar im Vorteil ;-)

Zitat:
..."64-bit versions of Windows Server 2003 or Windows XP"...

Post by Hans-Peter Diettrich

Post by Hubert Seidel
Ein 32-Bit-Prozess hat nur 32-Bit-Register und kann demnach
im auch nur max. 4GB linear, direkt ohne weitere Tricks ansprechen.

x86 Prozessoren haben zusätzlich noch Segmentregister, die prinzipiell
einen weit größeren Adressraum als nur 4 GB erlauben, auch wenn dies von

...

Jaja... nur geht es ja darum was das Betriebssystem zur Verfügung
stellt.

Post by Hans-Peter Diettrich
den meisten 32 Bit CPUs nicht unterstützt wird. Immerhin gab es schon
vor Einführung der 64 Bit Architektur Chipsets mit 36 Bit
(physikalischen) Adressen. Selbst die 16 Bit Versionen konnten ja schon
mehr als nur 64 KB adressieren, sowohl logisch als auch physikalisch.

Nur mit welcher API-Funktion ist es der Applikation gestatte die
Segment-Register wirklich auf andere Bereiche zu manipulieren?

Ich habe jetzt nicht nachgesehen, aber ich bin mir sehr sicher das bis
auf das FS-Segment-Register alle auf den Anfang des jew. Prozesses
zeigen
und durch die Applikation nicht geändert werden sollen.

Zumindest glaube ich an ziemliche Seiteneffekte, wenn man glaubt
stabile Applikationen mit derartigen Konstukte zu bauen:

push ax
push es

mov ax, es
add ax, 8 { anderen Selektor auswählen }
mov es, ax

mov ax,[es:ax+$400000] <== Hier wird's wohl knallen...

pop es
pop ax

Es würde natürlich nicht knallen, wenn es der Applikation tatsächlich
erlaubt sein sollte auf Fremde Bereits zugreifen zu dürfen.


mfg.
Herby

[Markus Springweiler]

Hallo Herby,

Post by Hubert Seidel
Von welchem Betriebssystem gehst Du denn aus?
(Man kann bestimmt auch Win95 laufen lassen ;-)

Wenn du mir, gemäß Überschrift, ein 64-bit-Win95 zukommen lassen kannst,
wäre das einen Versuch wert.

Post by Hubert Seidel
Ein 32-Bit-Prozess hat nur 32-Bit-Register und kann demnach
im auch nur max. 4GB linear, direkt ohne weitere Tricks ansprechen.

Das ist klar. Aber das umgebende 64-bit OS kann ja sicherlich etwas
mitdenken, so genug RAM zur Verfügung steht.
Die Frage war eher, wie schlau sich die MemoryMappedFiles-API anstellt,
wenn man mit LARGEADDRESSAWARE arbeitet.

Post by Hubert Seidel
Ich denke der Schalter "LARGEADDRESSAWARE" hat nix mit Delphi zu tun...

Doch sicher:
{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}
und ob es wirklich funktioniert, hängt natürlich auch von der Qualität der
Fremdkomponenten ab.

Post by Hubert Seidel
Möglicherweise findest Du über die Seiten auch etwas zu Deinem
Betriebssystem, aber ich glaube mehr als 4GB wird ein 32-Bit-Prozess
einfach nicht (nie) direkt ansprechen können.

Ein 32bit-OS kann bis zu 64GiB verwalten (bei Microsoft Windows allerdings
nur ab Server-DataCenter-Edition).

Und mittels Special-API kann man die 4GiB Grenze auch überwinden:
http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx
aber prinzipiell wäre die Lösung mittels MMF einfacher und allgemeiner.

Post by Hubert Seidel
Wie soll man theoretisch mit 32 Bit mehr als 32 Bit direkt Addressieren
können?

Eben über gleitende Ausschnitte.

Post by Hubert Seidel
Bestimmt findest Du was bei den KB-Seiten dazu... ich will Dir ja nicht
den kompletten Recherche-Spaß nehmen ;-)

Letztenendes werde ich um eine Testanwendung nicht herumkommen -- nur
mangelt es derzeit an 64bit: Hardware wie OS.

[Hubert Seidel]

Hallo Markus,

Post by Markus Springweiler

Post by Hubert Seidel
Von welchem Betriebssystem gehst Du denn aus?
(Man kann bestimmt auch Win95 laufen lassen ;-)

Wenn du mir, gemäß Überschrift, ein 64-bit-Win95 zukommen lassen kannst,
wäre das einen Versuch wert.

Wenn man (nach den neuesten Erklärungen davon absieht das
alles gleichzeitig im RAM sein muss) davon ausgehen dann
das MapViewOfFile bereits mit Win95 eingeführt wurde...
also so mal ganz theoretisch, müsste ja MapViewOfFile auch
unter Win95 funktionieren. Möglicherweise eben nicht wenn
es sich um eine lokale Datei auf einem eigngeschränkten
eigenen Win95-Dateisystem handelt, aber auf einem anderen
Rechner via Netzwerk und entsprechend großer Datei?

Post by Markus Springweiler

Post by Hubert Seidel
Ein 32-Bit-Prozess hat nur 32-Bit-Register und kann demnach
im auch nur max. 4GB linear, direkt ohne weitere Tricks ansprechen.

Das ist klar. Aber das umgebende 64-bit OS kann ja sicherlich etwas
mitdenken, so genug RAM zur Verfügung steht.

Ich vermute, eine Sache des File-Caches...
zudem ist es dann aber eben nicht sicher gestellt.
Außerdem könnte das Betriebssystem dazu angehalten sein, zu gunsten
der Datensicherheit und intigrität nicht benötigte Bereiche
"bei Langeweils" schnellstens wieder auf Platte zu schreiben...

Post by Markus Springweiler
Die Frage war eher, wie schlau sich die MemoryMappedFiles-API

anstellt,

Post by Markus Springweiler
wenn man mit LARGEADDRESSAWARE arbeitet.

Wenn ich das richtig verstanden habe, dann wird damit gesteuert in wie
fern das Betriebssystem seine Teile im RAM der Applikation sichtbar hat.
(z.b. am der 2GB-, 3GB- oder ?4GB-Grenze?)
Und genau bei letzterem wird es Haarig.
Ich könnte mir vorstellen das zu gunsten der "kompletten?" 4GB
das Betriebssystem ja wissen muß wann z.b. eine Systemfunktion
oder ähnliches aufgerufen werden will!
Ode man kann die 4GB evtl. nur mit einem bestimmten
Segment-Register ansprechen?
Kann mir dazu gut das Segment-Register GS vorstellen.
Dieses wird meinen Erfahrungen nach nur selten wo genutzt.
Ich glaube im Delphi-Code habe ich das bisher noch nie gesehen.
Maximal CS, DS, ES und SS.

Post by Markus Springweiler

Post by Hubert Seidel
Ich denke der Schalter "LARGEADDRESSAWARE" hat nix mit Delphi zu tun...

{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}
und ob es wirklich funktioniert, hängt natürlich auch von der Qualität der
Fremdkomponenten ab.

Aha... dazu habe ich folgendes gegoogelt:

http://209.85.129.132/search?q=cache:1L-ak8c-HjQJ:docs.codegear.com/docs/radstudio/radstudio2007/RS2007_helpupdates/HUpdate4/DE/html/devcommon/increaseaddressspace_xml.html+%22%7B%24SetPEFlags+IMAGE_FILE_LARGE_ADDRESS_AWARE%7D%22&hl=de&ct=clnk&cd=5&gl=de

Interessant dürfte dieses Zitat aus dem o.g. Link sein, was die 4GB-Idee
als gesamtes zugreifen zu können, zu nichte macht:
<Zitat>
Anmerkung: Die Standardgröße für den Adressraum für den Benutzermodus
für eine Win32-Anwendung beträgt 2 GB, er kann aber optional auf 3 GB
unter 32-Bit-Windows und auf 4 GB unter 64-Bit-Windows erweitert werden.
Der Adressraum ist immer ein wenig fragmentiert. Daher ist es
unwahrscheinlich, dass eine GetMem-Anforderung auf einen einzelnen
zusammenhängenden Block größer als 1 GB erfolgreich sein wird - auch
nicht bei einem Adressraum von 4 GB
</Zitat>

Post by Markus Springweiler

Post by Hubert Seidel
Möglicherweise findest Du über die Seiten auch etwas zu Deinem
Betriebssystem, aber ich glaube mehr als 4GB wird ein 32-Bit-Prozess
einfach nicht (nie) direkt ansprechen können.

Ein 32bit-OS kann bis zu 64GiB verwalten (bei Microsoft Windows allerdings
nur ab Server-DataCenter-Edition).

Ja, nur die Frage ist, wieviel stellt das OS einem einzelnen Prozess zur
Verfügung?

Post by Markus Springweiler
http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx
aber prinzipiell wäre die Lösung mittels MMF einfacher und

allgemeiner.

Post by Markus Springweiler

Post by Hubert Seidel
Wie soll man theoretisch mit 32 Bit mehr als 32 Bit direkt

Addressieren

Post by Markus Springweiler

Post by Hubert Seidel
können?

Eben über gleitende Ausschnitte.

Wie bereits gesagt: Ist nicht _direkt_.
Also mit direkt meine ich eben ohne verzögerung/nachladen.

Post by Markus Springweiler

Post by Hubert Seidel
Bestimmt findest Du was bei den KB-Seiten dazu... ich will Dir ja nicht
den kompletten Recherche-Spaß nehmen ;-)

Letztenendes werde ich um eine Testanwendung nicht herumkommen -- nur
mangelt es derzeit an 64bit: Hardware wie OS.

Ähm... gibt es nicht eine Funktion einen Speicherbereich gegen auslagern
zu sichern?

Ich hätte da dann nämlich folgende Idee, wenn es darum geht z.b. 10GB
einer 32Bit-Applikation garantiert ohne Plattenzugriff zur Verfpgung zu
stellen:

Angenommen man hat 16GB, und möchte einer 32-Bit-Applikation 10GB
für einen (relativ) schnellen Zugriff zur Verfügung stellen.

Die eine Applikation startet 10 Prozesse, welche jeweils 1GB
(oder falls Fragmentierung stört, 20 Prozesse mit je 500MB)
und kommuniziert via IPC miteinander.
Welcher IPC-Mechanismus dann da der Beste ist, hängt von der Anforderung
ab.
Entweder man nehme wieder MemoryMappedFiles, oder eben was anderes.
Evtl. reicht es ja für jeden Prozess mit je 500MB ein
Fenster von nur 1 MB zu haben?
Dann stünde der einen Verwalter-Applikation auch genügend Speicher
für "eigene Dinge" zur Verfügung...

mfg.
Herby

[Markus Springweiler]

Hubert,

Post by Hubert Seidel
Ich hätte da dann nämlich folgende Idee, wenn es darum geht z.b. 10GB
einer 32Bit-Applikation garantiert ohne Plattenzugriff zur Verfpgung zu
Angenommen man hat 16GB, und möchte einer 32-Bit-Applikation 10GB
für einen (relativ) schnellen Zugriff zur Verfügung stellen.
Die eine Applikation startet 10 Prozesse, welche jeweils 1GB
(oder falls Fragmentierung stört, 20 Prozesse mit je 500MB)
und kommuniziert via IPC miteinander.

Interessanter Ansatz, könnte allerdings im Taskmanager etwas seltsam
aussehen ;)

Ist jetzt nur die Frage was schneller geht: 20 Prozesse wasserdicht
synchronisieren oder auf einen 64-bit Compiler warten oder umsteigen.

[Hubert Seidel]

Hallo Markus,

"Markus Springweiler" <***@gmx.de> schrieb im Newsbeitrag news:***@sihv.de...

...

Post by Markus Springweiler

Post by Hubert Seidel
Die eine Applikation startet 10 Prozesse, welche jeweils 1GB
(oder falls Fragmentierung stört, 20 Prozesse mit je 500MB)
und kommuniziert via IPC miteinander.

Interessanter Ansatz, könnte allerdings im Taskmanager etwas seltsam
aussehen ;)

Wie es im Taskmanager aussieht, dürfte mir (Dir) ja schnuppe sein :-)
Hauptsache es funktioniert!

Post by Markus Springweiler
Ist jetzt nur die Frage was schneller geht: 20 Prozesse wasserdicht
synchronisieren oder auf einen 64-bit Compiler warten oder umsteigen.

Die Prozesse müssen sich überhaupt nicht synchronisieren.
Der Haupt-Prozess spricht den Prozess aus dem jew. Adressraum an.

Angenommen die 20 Prozesse mit jew. 512MB sind 0..19 nummeriert:
0000000000000000-000000001FFFFFFF (Prozess 0)
0000000020000000-000000003FFFFFFF (Prozess 1)
0000000040000000-000000005FFFFFFF (Prozess 2)
...
0000000260000000-000000027FFFFFFF (Prozess 19)


Wenn nun der Haupt-Thread auf 4 MB ab Adresse 000000001FF00000
lesen möchte, dann muss dieser wissen bzw. berücksichtigen
das zuerst 1 MB von Prozess 1 ab 000000001FF00000-000000003FFFFFFF,
und anschl. 3MB von Prozess 2 ab 0000000020000000-0000000020300000
gelesen wird.
Da der jew. Prozess sein Adressraum kennt, und dieser sicht _nicht_
mit den anderen überschneidet, müssen die sich untereinander
nicht synchronisieren.

Man kann das ja "im kleinen" auch auf einem normalen Win32-System
mit z.b. 20 * 512KB (für nur 1MB) ausprobieren.

Das ganze könnte man sogar in ein einziges Executable packen
indem der Haupt-Thread das eigene Exe mit besonderen Parameter
nachstartet (für den jew. Adressraum-Abschnitt)

Als IPC-Mechanismus würde ich evtl. für den Anfang einfach Messages
via WM_COPYDATA nehmen (synchronisiert das Betriebssystem bereits :-)
Oder?

mfg.
Herby

[Hubert Seidel]

fugbix:

"Hubert Seidel" <***@hubert-seidel.de> schrieb im
Newsbeitrag news:gnovas$40u$01$***@news.t-online.com...

...

Post by Hubert Seidel
Wenn nun der Haupt-Thread auf 4 MB ab Adresse 000000001FF00000
lesen möchte, dann muss dieser wissen bzw. berücksichtigen
das zuerst 1 MB von Prozess 1 ab 000000001FF00000-000000003FFFFFFF,

und anschl. 3MB von Prozess 2 ab 0000000020000000-00000000202FFFFF

natürlich ein Bytes weniger :)

mfg.
Herby

[Robert Kochem]

Post by Markus Springweiler
Wenn jemand dazu noch positives oder negatives zur Performance weiß, würde
mich die Meinung auch interessieren. Oder wie groß ein Mapping-Fenster mit
einer IMAGE_FILE_LARGE_ADDRESS_AWARE-fähigen Win32-Anwendung sein würde,
hat da jemand praktische Erfahrungen?

Praktische Erfahrungen habe ich nicht, aber da Microsoft selber dieses Flag
insbesondere bei Server-Software wie MS Exchange und MS-SQL nutzt denke ich
nicht, dass es da große Nachteile gibt.

Post by Markus Springweiler
(Optimal wäre natürlich 4GiB abzüglich der anderen Anwendungs-spezifischen
Resourcen.)

Da du schon das IMAGE_FILE_LARGE_ADDRESS_AWARE Flag erwähnt hast brauche
ich dich sicherlich nicht mehr darauf hinzuweisen, dass dies illusorisch
ist, da du normalerweise max 2GB pro Prozess und mit LARGE_ADDRESS_AWARE
und /3GB-Switch max 3GB pro Prozess nutzen kannst?

BTW: Bist du dir sicher, dass Delphi überhaupt mit 3GB Prozess-Speicher
umgehen kann? Was ich bisher so gelesen habe ist das nicht ganz
unproblematisch und erfordert mehr als nur das Einfügen von
{$SetPeFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

Robert

[Markus Springweiler]

Robert,

Post by Robert Kochem

Post by Markus Springweiler
(Optimal wäre natürlich 4GiB abzüglich der anderen Anwendungs-spezifischen
Resourcen.)

Da du schon das IMAGE_FILE_LARGE_ADDRESS_AWARE Flag erwähnt hast brauche
ich dich sicherlich nicht mehr darauf hinzuweisen, dass dies illusorisch
ist, da du normalerweise max 2GB pro Prozess und mit LARGE_ADDRESS_AWARE
und /3GB-Switch max 3GB pro Prozess nutzen kannst?

Und 4GB unter allen 64bit-Windows Versionen.

Post by Robert Kochem
BTW: Bist du dir sicher, dass Delphi überhaupt mit 3GB Prozess-Speicher
umgehen kann? Was ich bisher so gelesen habe ist das nicht ganz
unproblematisch und erfordert mehr als nur das Einfügen von
{$SetPeFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

Da habe ich bisher wohl noch nicht die richtigen und vorallem
Delphi-spezifischen Resourcen gefunden. Immerhin ergben ein älterer Test
von DoublePics mit /3GB und knapp über 2,5GiB Nutzdaten jedenfalls keine
Instabilitäten (was natürlich noch kein Beweis ist).

[Hans-Peter Diettrich]

Post by Robert Kochem
BTW: Bist du dir sicher, dass Delphi überhaupt mit 3GB Prozess-Speicher
umgehen kann? Was ich bisher so gelesen habe ist das nicht ganz
unproblematisch und erfordert mehr als nur das Einfügen von
{$SetPeFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

Das hat nichts mit Delphi zu tun, sondern wieviel Adreßraum nach dem
Laden aller benötigten DLLs übrig bleibt.

DoDi

[Markus Springweiler]

Hans-Peter,

Post by Hans-Peter Diettrich

Post by Robert Kochem
BTW: Bist du dir sicher, dass Delphi überhaupt mit 3GB Prozess-Speicher
umgehen kann? Was ich bisher so gelesen habe ist das nicht ganz
unproblematisch und erfordert mehr als nur das Einfügen von
{$SetPeFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

Das hat nichts mit Delphi zu tun, sondern wieviel Adreßraum nach dem
Laden aller benötigten DLLs übrig bleibt.

Naja, *wenn* der Delphi-Memory-Manager irgendwo das 32ste Bit als Flag für
irgendwas missbrauchen würde, wäre LARGEADDRESSAWARE für Delphi Programme
nicht zu gebrauchen -- oder wenn irgendwo ein Pointer in Integer anstatt
Cardinal gecastet wird, und anschließend ein >0 Vergleich stattfindet, also
quasi anstatt "if assigned(ptr) then" ein "if integer(ptr) > 0 then", dann
würden alle Adressen >2GiB als nil behandelt werden.

[Hubert Seidel]

Hallo Markus,

Post by Markus Springweiler
Hans-Peter,

Post by Hans-Peter Diettrich

Post by Robert Kochem
BTW: Bist du dir sicher, dass Delphi überhaupt mit 3GB

Prozess-Speicher

Post by Markus Springweiler

Post by Hans-Peter Diettrich

Post by Robert Kochem
umgehen kann? Was ich bisher so gelesen habe ist das nicht ganz
unproblematisch und erfordert mehr als nur das Einfügen von
{$SetPeFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

Das hat nichts mit Delphi zu tun, sondern wieviel Adreßraum nach dem
Laden aller benötigten DLLs übrig bleibt.

Naja, *wenn* der Delphi-Memory-Manager irgendwo das 32ste Bit als Flag für

*wenn* der Delphi-Memory-Manager tatsächlich das 32ste Bit als Flag für

Post by Markus Springweiler
irgendwas missbrauchen würde, wäre LARGEADDRESSAWARE für Delphi Programme

das geringste Problem.

Nein, bei jedem Zugriff müsste das Bit maskiert werden da dieser
Wert ja so nicht als Adresse oder sonstige Vergleiche heran
gezogen werden könnte.
Nachdem Delphi sonst ziemlich aufgeräumt und performant ist,
kann ich mir so ein "Feature" nur sehr schwer vorstellen...

Post by Markus Springweiler
nicht zu gebrauchen -- oder wenn irgendwo ein Pointer in Integer anstatt
Cardinal gecastet wird, und anschließend ein >0 Vergleich stattfindet, also
quasi anstatt "if assigned(ptr) then" ein "if integer(ptr) > 0 then", dann
würden alle Adressen >2GiB als nil behandelt werden.

Genau aus solchen Gründen glaube ich kaum das jemand
ein Bit in einer Adresse als Flag verwendet.

mfg.
Herby

[Hans-Peter Diettrich]

Post by Hubert Seidel
Genau aus solchen Gründen glaube ich kaum das jemand
ein Bit in einer Adresse als Flag verwendet.

Soll schon vorgekommen sein, allerdings mit den niederwertigen Bits.
Garbage Collection fällt mir dazu spontan ein.

DoDi

[Hubert Seidel]

Hi DoDi,

Post by Hans-Peter Diettrich

Post by Hubert Seidel
Genau aus solchen Gründen glaube ich kaum das jemand
ein Bit in einer Adresse als Flag verwendet.

Soll schon vorgekommen sein, allerdings mit den niederwertigen Bits.
Garbage Collection fällt mir dazu spontan ein.

Bei Delphi?

mfg.
Herby

P.S:
Es soll schon mal vorgekommen sein das in China ein Sack Reis umgefallen
ist ;-)

[Hans-Peter Diettrich]

Post by Hubert Seidel

Post by Hans-Peter Diettrich
Garbage Collection fällt mir dazu spontan ein.

Bei Delphi?

Ja, hab ich schon mal so gemacht.

DoDi

[Hubert Seidel]

Hallo DoDi,

Post by Hans-Peter Diettrich

Post by Hubert Seidel

Post by Hans-Peter Diettrich
Garbage Collection fällt mir dazu spontan ein.

Bei Delphi?

Ja, hab ich schon mal so gemacht.

Ja wenn "DU" das so machst, ist das Dein Ding, Dein Risiko.
Nur was "DU" in Delphi machst, stelle ich nicht gleich mit dem was
"Delphi" von sich aus macht.
Wenn Du Dir ein Loch in's Knie schießst, kann ja Delphi nix dazu ;-)

mfg.
Herby

[Hans-Peter Diettrich]

Post by Hubert Seidel
Nur was "DU" in Delphi machst, stelle ich nicht gleich mit dem was
"Delphi" von sich aus macht.

Es ging nur darum, wozu Bits in Pointern verwendet werden (können). Ich
habe nie behauptet, daß Delphi selbst irgendetwas in dieser Richtung macht.

DoDi

[Hubert Seidel]

Hallo DoDi,

Post by Hans-Peter Diettrich

Post by Hubert Seidel
Nur was "DU" in Delphi machst, stelle ich nicht gleich mit dem was
"Delphi" von sich aus macht.

Es ging nur darum, wozu Bits in Pointern verwendet werden (können). Ich
habe nie behauptet, daß Delphi selbst irgendetwas in dieser Richtung macht.

AufDieGoldwaageLeeeeeg...

Naja... also im Beitrag news:gnmnjq$83f$03$***@news.t-online.com ging es
um
<Zitat>
(Markus)

Post by Hans-Peter Diettrich

Post by Hubert Seidel
Naja, *wenn* der Delphi-Memory-Manager irgendwo das 32ste Bit als

Flag

Post by Hans-Peter Diettrich
für

(ich)

Post by Hans-Peter Diettrich
*wenn* der Delphi-Memory-Manager tatsächlich das 32ste Bit als Flag für

</Zitat>

worauf Di in news:***@mid.individual.net antwortetest:
<Zitat>
(ich)

Post by Hans-Peter Diettrich

Post by Hubert Seidel
Genau aus solchen Gründen glaube ich kaum das jemand
ein Bit in einer Adresse als Flag verwendet.

(Du)

Post by Hans-Peter Diettrich
Soll schon vorgekommen sein, allerdings mit den niederwertigen Bits.
Garbage Collection fällt mir dazu spontan ein.

</Zitat>

worauf ich in news:gnon7m$g35$02$***@news.t-online.com extra nochmals
Frage:
<Zitat>

Post by Hans-Peter Diettrich
Bei Delphi?

</Zitat>

Worauf Du antwortest in news:***@mid.individual.net :
<Zitat>

Post by Hans-Peter Diettrich
Ja, hab ich schon mal so gemacht.

</Zitat>

Naja... und Du bist halt nicht Delphi :-)
und ein "Ja" auf "Bei Delphi?" sieht ja schon so aus als wenn Du das
behaupten würdest
(Auch wenn das sich gerade zu "habe _ich_ schon gemacht" wiederspricht
;-)

und zum "können"...
... in China _kann_ schon mal ein Sack Reis umfallen... ;;;---)))
lolololll

(so zumindest meine Interpretation des Threads in diesem Zweig)

mfg.
Herby