Hallo zusammen,
ich habe in einem WIN32 C++ - Programm ein Array, dass ich zum Start der
Anwendung allokiere. Dieses Array ist aufgrund gestiegener Anforderungen
mittlerweile recht groß und soll noch größer werden.
Ist es vllt möglich, dass ich manuell in Pages auslager und die
Informationen des Arrays in die Pages schreibe und im virtuellen
Speicher ein Array von Pointern anlege die auf die Pages zeigen und ein
weiteren virtuellen Speicher alokiere um die Informationen der Pages zu
verarbeiten.
Das "largeaddressspaceawarenessflag" möchte ich nur ungerne benutzen, da
dieses das Problem nur kurzfristig lösen würde.
Vielen Dank für die Antworten.
Felix T. schrieb:> Dieses Array ist aufgrund gestiegener Anforderungen> mittlerweile recht groß und soll noch größer werden.
Hört sich irgendwie nach beschissener Programmierung an. Was packst du
da alles rein???
@ A. K. (prx)
Hast du Erfahrungen damit unter Win32?
Weil die Funktion: MapUserPhysicalPages() hat ja folgenden Zusatz:
64-bit Windows on Itanium-based systems: Due to the difference in page
sizes, MapUserPhysicalPages is not supported for 32-bit applications.
Deswegen gibt es 64Bit Maschinen. Nicht primär wegen großen Zahlen,
sondern wegen großem Adressraum. Einfach die Virtualisierung von
Speicher dem OS überlassen, denn das haben in der Regel Leute gebaut,
die davon was verstehen. Da kommt der Durchschnittsprogrsmmiermichel
nicht mit. Und dann Speichermäsig aus dem Vollen schöpfen. Nur wenn ich
nur 31(31,5) Bit virtuelle Adressen hab, dann muß ALLES in 2(/3) GB
passen. Also entweder 64Bit OS, oder alles selber machen.
F. L. schrieb:> Hast du Erfahrungen damit unter Win32?
Nein, weiss nur dass es das gibt, oder gab. Kam mir seit jeher ähnlich
elegant vor wie EMS unter DOS. Und ist im Zeitalter von 64-Bit Systemen
genauso schräg wie deine circa 20 Jahre zu spät kommende Frage.
> 64-bit Windows on Itanium-based systems:
Diese deine Sorge setzt der Sache die Krone auf. Sich für den Fall eines
IA64 Systems Sorgen drum machen, ob dessen Win32 Emulation mit AWE klar
kommt. ;-)
A. K. schrieb:> Es sollte in C++ übrigens eine relativ simple Fingerübung sein,> virtuelle Arrays beliebiger Grösse zu implementieren.
Wie meinst du das?
> Und selber machen würdest du dann auch wie im AWE-Beispiel?
Neben der Tatsache, daß das nur bei Server-Versionen von Windows
wirklich unterstützt wird, würde ich mir lieber ein 64Bit OS (gibt's
sogar für umme) besorgen, als EMS die n-te anzutun.
> 64-bit Windows on Itanium-based systems: Due to the difference in page sizes,
MapUserPhysicalPages is not supported for 32-bit applications.
> Ich möchte, dass es weiterhin auf älteren Rechner läuft und möchte diese und
meine Anwendung ungerne umstellen.
@F.L.: alte PC's enthalten sehr selten Itanium. Und das Mappen
physikalischer Seite setzt diese in Hardware voraus. Beides hat mit
deinem Problem nur in soweit zu tun, daß die Tatsache, daß du danach
fragst, die Wahrscheinlichkeit daß du dein Problem gelöst bekommst
senkt.
Kannst du nicht ein bischen mehr erzählen mit was du die 2GByte füllst?
Wenn du wirklich mehr als 2GByte Daten nutzen willst, dann kommst du
nicht darum herum, die Daten in eine Datei zu schreiben und immer nur
den aktuell benötigten Teil im RAM zu halten. Der Nutzer darf aber kein
FAT12/16/32 Dateisystem mehr haben, denn dort können die Dateien auch
nur maximal 4GByte groß sein. Und selbst mit NTFS ist das Einlesen einer
so großen Datei sicher nicht trivial.
Wenn die Datenmenge langfristig also immer weiter ansteigt, dann kommst
du um 64 Bit nicht herum.
Sebastian Hepp schrieb:> Und selbst mit NTFS ist das Einlesen einer> so großen Datei sicher nicht trivial
warum soll das schwerer als bei 2kbyte sein?
man braucht nur die seek64 Funktion zu verwenden, read und write muss
nicht angepasst werden.
Sebastian Hepp schrieb:> Der Nutzer darf aber kein FAT12/16/32 Dateisystem mehr haben
Wenn man den Speicher zerhackt, dann kann man das auch mit den Files
machen.
> Wenn die Datenmenge langfristig also immer weiter ansteigt, dann kommst> du um 64 Bit nicht herum.
Wird bloss immer umständlicher und ineffizienter.
Bei Daten dieser Größe könnte man sich überlegen, ob man nicht eine
Datenbank benutzt, die sich um die Speicherung kümmert. Das muss nicht
unbedingt eine client-server Architektur sein, sondern kann auch was
integriertes, wie sqlite oder so sein. Je nach Anwendungsfall KANN
dies eine äußerst sinnvolle Lösung sein.
Die Frage ist halt, was du mit den Daten machst.
F. L. schrieb:> Ist es vllt möglich, dass ich manuell in Pages auslager und die> Informationen des Arrays in die Pages schreibe und im virtuellen> Speicher ein Array von Pointern anlege die auf die Pages zeigen und ein> weiteren virtuellen Speicher alokiere um die Informationen der Pages zu> verarbeiten.
Genau so musst Du es machen.
Die Rohdaten liegen in einer Virtuellen Datei. Da gehst Du mit einem
Parser drüber, der Dir die eigentlichen Datenblöcke raussucht.
Für jeden Datenblock legst Du einen Zeiger an. Den schreibst Du in eine
andere virtuelle Datei. Dann kannst Du nämlich bequem von verschiedenen
Threads (oder auch Prozessen) drauf zugreifen.
Die eigentliche Analyse der Daten und auch die Ausgabe machst Du in
deinem Hauptprogramm. Aber nur das Auswerten, was Du auch wirklich
brauchst. 30.000 Datensätze in einem Listview kommt nämlich garnicht gut
an.
Bastler schrieb:> Neben der Tatsache, daß das nur bei Server-Versionen von Windows> wirklich unterstützt wird, würde ich mir lieber ein 64Bit OS (gibt's> sogar für umme) besorgen, als EMS die n-te anzutun.
Und das würde ich schonmal garnicht machen. Es sei denn, Du brauchst
mehr als 2 GByte Speicher am Stück, und selbst dann nicht.
Wenn Du nämlich in C++ für 32 programmierst, dann läuft das auf 32 Bit
und 64 Bit und Du hast alles abgehakt. Bei 64 Bit ist das nicht so.
Sebastian Hepp schrieb:> Wenn die Datenmenge langfristig also immer weiter ansteigt, dann kommst> du um 64 Bit nicht herum.
Das seh ich anders. Was hindert mich, einfach eine weitere Virtuelle
Datei mit 2 GBytes anzulegen?
fb schrieb:> Ansonsten gibt es ja auch noch CreateFileMapping, MapViewOfFile und> Artverwandtes.
Genau so ist es! Virtuelle Datei. Sag ich doch.
Gruß Klaus
fb schrieb:> Ansonsten gibt es ja auch noch CreateFileMapping
Memory Mapped Files gibt es unter verschiedenen Betriebssystemen und
Sprachen. Es ist halt blöd, wenn man über 2 GB auf Disk auslagern muss,
während der Rechner womöglich 16 GB RAM hat - da könnte man auf die Idee
kommen, sowas altmodisches wie eine RAM-Disk einzurichten, aber das ist
dann um so viele Ecken konstruiert, dass das ins Horrorkabinett
überdrehter Programmierer gehört. Ein 64-Bit-System ist viel einfacher.
Georg
F. L. schrieb:> ich habe in einem WIN32 C++ - Programm ein Array, dass ich zum Start der> Anwendung allokiere. Dieses Array ist aufgrund gestiegener Anforderungen> mittlerweile recht groß und soll noch größer werden.>> Ist es vllt möglich, dass ich manuell in Pages auslager und die> Informationen des Arrays in die Pages schreibe und im virtuellen> Speicher ein Array von Pointern anlege die auf die Pages zeigen und ein> weiteren virtuellen Speicher alokiere um die Informationen der Pages zu> verarbeiten.
Ja. Lies' die Doku zu den API-Funktionen "CreateFileMapping" und
"MapViewOfFile". Das macht genau, was du brauchst und benutzt dazu genau
die Mechanismen, die das ganze System sowieso ständig für den Zugriff
auf virtuellen Speicher benutzt. D.h.: du kannst davon ausgehen, daß die
Scheiße prinzipiell funktioniert und dich bei der Fehlersuche voll auf
deinen eigenen Code konzentrieren...
> Kannst du nicht ein bischen mehr erzählen mit was du die 2GByte füllst?
Wenn es eben ganz geheim wär, um was es sich bei den Daten handelt, dann
könnte man vielleicht entdecken, daß das eigentliche Problem schon
existiert, bevor es 2 GB groß abgelegt wird.
Die einzig sinnvolle Frage an den TO ist hier:
Vlad T. schrieb:> Die Frage ist halt, was du mit den Daten machst.
bevor man nicht weiss was er da verarbeiten will, ist es müßig nach
einer passenden Lösung zu suchen.
Wenn er ein Array von 10000 * 10000 Structs oder Objekten anlegt, obwohl
99% der Plätze nie belegt werden, dann sieht eine sinnvolle Lösung ganz
anders aus, als wenn er eine 4 GByte große XML oder TextDatei bearbeiten
und suchen/wahlfrei schreiben muss.
Ist wieder das alte Problem:
Nicht die angebliche Lösung, sondern das eigentliche Problem
beschreiben. Siehe dazu die Netiquette unter Problembeschreibung
