Großen Speicherbereich allocieren



  • Hallo,

    ich bräuchte viel Speicherplatz für __int32. Am besten im Giga-Bereich. On Board hab ich 4GB. Kann ich mehr Speicherplatz reservieren wenn ich die benötigte Menge in kleinere Teile allociere, um evtl. Fracmentierungen zu nützen?
    Oder gibt es sonst noch einen Trick?

    gruß Rudi



  • Du wirst kaum 2GB an einem Stück allozieren können. Daher ist bei derart großen Mengen eigentlich unvermeidbar, kleinere Häppchen anzufordern und dann intern eben zu verwalten.

    Erster Schritt wäre aber, die eigenen Datenstrukturen zu optimieren, falls das überhaupt möglich ist 😉

    Eventuell könnte es direkt nach einem Server-Neustart gehen, dass du einen größeren Block allokierst und den auch behälst, selbst wenn du zwischenzeitlich weniger Speicherplatz benötigst.... Aber wie gesagt: hätte, könnte, sollte... 😃

    Probier es einfach mal aus, wieviel geht und ob das für dich reicht.



  • It0101 schrieb:

    Eventuell könnte es direkt nach einem Server-Neustart gehen, dass du einen größeren Block allokierst und den auch behälst, selbst wenn du zwischenzeitlich weniger Speicherplatz benötigst.... Aber wie gesagt: hätte, könnte, sollte... 😃

    was hat das mit einem neustart zu tun? ob der speicher fragmentiert ist/wird spielt für einen neuen prozess doch keine rolle, der bekommt doch immer einen sauberen speicherbereich. wenn man sich dann natürlich nicht entscheiden kann, ob man etwas nun braucht oder nicht, geht einem auf einem 32bit system schon mal der zusammenhängende speicher aus 😃



  • Weil nach einem Neustart der Speicher vielleicht noch etwas weniger "verwüstet" ist...

    Ich würde mal vermuten, nach einem Neustart ist die Wahrscheinlichkeit, einen großen Speicherbereich allokiert zu bekommen, größer als wenn die Kiste schon 10 Tage läuft und 1000 Applikationen zwischenzeitlich ihren Dreck abgeladen haben 😃



  • Hallo,

    Wenn der Speicher nicht am Stück sein muss bietet sich hier evtl. deque an. Die verwaltet den Speicher normalerweise aufgeteilt in einzelne chunks.



  • Braunstein schrieb:

    Hallo,

    Wenn der Speicher nicht am Stück sein muss bietet sich hier evtl. deque an. Die verwaltet den Speicher normalerweise aufgeteilt in einzelne chunks.

    Kommt darauf an.
    Gerade für sehr viele kleine Objekte ist std::deque völlig nutzlos. Bei den beiden Implementationen, die ich bisher benutzt habe (STLport und Dinkumware) ist der Verwaltungsoverhead so riesig, dass er in keinem sinnvollen Verhältnis zu den Nutzdaten steht.

    Warum musst du denn so viele Daten im Speicher halten? Lässt sich das Problem nicht anders lösen? Kannst du es in Teilprobleme unterteilen?



  • Danke schon mal,

    ich möchte ein möglichst großes Bild berechnen, am liebsten mit 100 000 Pixel hoch 2. Die einxelnen Pixel als __int32 verwalte ich bisher als eindimensionales Array mit einem Pointer. Ich glaube der geringste Programmieraufwand wäre, dieses Bild Zeilenweise zu speichern. Der Zugriff sollte auch schnell gehen. Allerdings bräuchte ich dann noch ein 100 000er Array für die Zeilenpointer.
    Alternativ wäre auch ein Tempfile denkbar, aber weil die Pixeladressen sehr durcheinander gebraucht werden, ist mir das zu langsam.
    Allerdings werden vom Bildarray nicht alle Pixel gebraucht, dann wäre sowas wie Hash-zugriff denkar, ich weiß aber nicht im voraus wieviel % der Pixel nötig sind.



  • rudiM schrieb:

    ich möchte ein möglichst großes Bild berechnen, am liebsten mit 100 000 Pixel hoch 2.

    Es gibt Libs, die mit so großen Bildern klar kommen, z.B.
    http://www.openexr.com/index.html
    **Edit:**Bin nicht mehr ganz sicher, ob es das war. Hatte mich mal mit jemanden unterhalten, der mit riesigen (Satelliten-) Bildern arbeitete. Da war u.a. diese Lib im Einsatz. Aber nicht auf Rechnern mit 4 GB.

    Ist der neue 64-Bit Compiler im Builder schon gut genug für solche Anwendungen ? Der alte Compiler ist sicher nicht das richtige dafür.



  • Und was nachst du mit dem Riesenbild? Angucken wird wohl schlecht gehen.



  • Da hast Du wohl recht. Aber dieses Bild brauch ich nur zur temporären Erstellung eines normalen druckbaren Bildes. Wenn ich diese Vorlage in der selben Größe, wie das endgültig Bild mache, hab ich soviel Moirè drin, dass es nicht mehr schön ist. Selbst wenn ich die Auflösung 20 mal feiner mach, ist immernoch was da. Ich fürchte, es geht nie ganz weg, und interpolieren will ich auch nicht.



  • Hab gerade mal in der Doku von OpenEXR nachgeschaut

    Tiled image files allow random-access to rectangular sub-regions of an image.

    Die zerlegen die Bilder also in Kacheln und laden die Teile bei Bedarf.



  • Ich hab mir mal die Sache mit dem Resourcenmonitor angesehen. Obwohl ich da noch gut 3GB frei habe, kann ich maximal 2GB allocieren. (auch nach Neustart). Liegt das an BCB 2009?



  • rudiM schrieb:

    Ich hab mir mal die Sache mit dem Resourcenmonitor angesehen. Obwohl ich da noch gut 3GB frei habe, kann ich maximal 2GB allocieren. (auch nach Neustart). Liegt das an BCB 2009?

    Welches OS?
    Bei sämtlichen Windows 32Bit Betriebssystemen sind normalerweise 2GB für den Kernel reserviert, damit bleiben für deine Anwendung nur 2GB zur Verfügung. Daher bekommst auch maximal 2GB Speicher, allerhöchstwahrscheinlich sogar nicht am Stück, sondern irgendwie fragmentiert.

    Edit:
    Es wird übrigens niemals allociert. Man kann allozieren, etwas ungebräuchlicher auch allokieren.



  • Für mehr Speicher brauchst du schon XE3 und ein 64-Bit-Programm.

    Da haben sich die Leute zumindest schon über viel größere Speicherblöcke unterhalten:
    https://forums.embarcadero.com/thread.jspa?threadID=81133&tstart=525

    C++ 64 bit does not allocate more than 4GB of memory in one piece. Why?

    new double[1000000000]; // This code does not work. 8GB memory is not allocated
    realloc(0, 8000000000); // This code does not work. 8GB memory is not allocated

    /// This code works correctly. 8GB of memory is allocated two pieces
    new int[1000000000];
    new int[1000000000];

    /// This code works correctly too. 8GB of memory is allocated two pieces
    realloc(0, 4000000000);
    realloc(0, 4000000000);

    /// This Delphi code works correctly too. 8GB of memory is allocated one pieces
    GetMem(p, 8000000000);

    The issues was tracked down to the code that reroutes the C++ allocation
    routines to the Delphi memory management API. So this problem should not
    occur in apps that don't use VCL or FMX. And in cases where the Delphi
    runtime was used, I believe the problem only showed up if the app links
    statically.

    The issue has been resolved internally and the fix will be made available in
    an update soon.


Log in to reply