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.
Ich möchte, dass es weiterhin auf älteren Rechner läuft und möchte diese und meine Anwendung ungerne umstellen.
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.
@Bastler Und selber machen würdest du dann auch wie im AWE-Beispiel?
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. ;-)
:
Bearbeitet durch User
Win16 hatte damals Handle Pointer. Die Library müsste sich doch noch finden lassen.
Es sollte in C++ übrigens eine relativ simple Fingerübung sein, virtuelle Arrays beliebiger Grösse zu implementieren.
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.
Auslagern auf die Platte, z.B. mit dieser Wrapper-Klasse: http://www.codeproject.com/Articles/364/CFile-File-System-Wrapper
> 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.
Ansonsten gibt es ja auch noch CreateFileMapping, MapViewOfFile und Artverwandtes.
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...
Wobei die Bemerkung von Vlad nicht unbeachtet bleiben sollte! Je nach Art der Daten kann eine Datenbank tatsächlcih die bessere Alternative sein.
> 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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.