Wie hoch ist der Arbeitsspeicherverbrauch für eine 64-Bit-Anwendung?

Lesezeit: 6 Minuten

Benutzeravatar von Petr
Petr

Aus dem, was ich bisher herausgefunden habe, ist klar, dass Programme, die für eine 64-Bit-Architektur kompiliert wurden, doppelt so viel RAM für Zeiger verwenden wie ihre 32-Bit-Alternativen – https://superuser.com/questions/56540/32-bit-vs-64-bit-systems.

Bedeutet das, dass Code, der für 64-Bit kompiliert wurde, im Durchschnitt zweimal mehr verwendet RAM als die 32-Bit-Version?

Ich bezweifle es irgendwie, aber ich frage mich, was der wirkliche Overhead ist. Ich nehme an, dass kleine Typen, wie short, byte und char sind in einer 64-Bit-Architektur gleich groß? Ich bin mir nicht sicher byte obwohl. Da viele Anwendungen mit großen Zeichenfolgen arbeiten (wie Webbrowser usw.), bestehen diese hauptsächlich aus char Arrays in den meisten Implementierungen ist der Overhead möglicherweise nicht so groß.

Also auch wenn numerische Typen wie int und long auf 64 Bit größer sind, würde es einen signifikanten Einfluss auf die RAM-Nutzung haben oder nicht?

  • byte ist nicht ein standardisierter Typ. Mit C99 oder besser, inkl <stdint.h> dann benutze uint8_t wenn Sie vorzeichenlose 8-Bit-“Bytes” benötigen.

    – Basile Starynkevitch

    19. März 2015 um 8:42 Uhr

  • Die Speicherauslastung wird zunehmen, sich aber (fast) nie verdoppeln

    – phuklv

    19. März 2015 um 8:50 Uhr

  • Der springende Punkt beim Erstellen neuer CPUs mit breiteren Adress- und Datenbussen ist Erhöhen Sie die Ausführungsgeschwindigkeit auf Kosten der Programmgröße und des RAM-Verbrauchs. Dies war von 8 bis 16 bis 32 bis 64 der Fall. Also nichts Neues hier.

    – Ludin

    19. März 2015 um 9:03 Uhr

  • @Lundin Mir ist klar, dass dadurch ein Overhead entsteht, aber ich würde gerne wissen, wie groß dieser Overhead ist. Einige Systeme müssen möglicherweise eher für den RAM-Verbrauch als für den CPU-Verbrauch optimiert werden

    – Petr

    19. März 2015 um 9:25 Uhr

  • Na sicher. RAM spielt keine Rolle, ein 64-Bit-Programm nutzt den Prozessor-Cache viel weniger effektiv. Nicht ganz doppelt so schlimm, hängt davon ab, was sonst noch so los ist. Ein int ist aus genau diesem Grund immer noch 32 Bit. Dank an AMD haben sie diesen Leistungsverlust kompensiert, indem sie alle richtigen Funktionen hinzugefügt haben, um ein vergleichbares Ergebnis zu erzielen. Beginnend mit zusätzlichen 8 Registern.

    – Hans Passant

    19. März 2015 um 10:09 Uhr

Benutzeravatar von glglgl
glglgl

Es hängt vom Programmierstil ab (und von der Sprache, aber Sie beziehen sich auf C).

  • Wenn Sie viel mit Zeigern arbeiten (oder viele Referenzen in einigen Sprachen haben), steigt der RAM-Verbrauch.
  • Wenn Sie viele Daten mit fester Größe verwenden, wie z double oder int32_tRAM-Verbrauch steigt nicht.
  • Für Typen wie int oder long, es hängt von der Architektur ab; Es kann Unterschiede zwischen Linux und Windows geben. Hier Sie sehen die Alternativen, die Sie haben. Kurz gesagt, Windows verwendet LLP64, was bedeutet, dass long long und Zeiger sind 64 Bit, während Linux LP64 verwendet, wobei longist auch 64bit. Andere Architekturen könnten machen int oder auch short 64 Bit auch, aber diese sind ziemlich ungewöhnlich.
  • float und double sollten in allen Fällen gleich groß bleiben.

Sie sehen also, es hängt stark von der Verwendung der Datentypen ab.

  • x86-64 hat auch die x32-ABI, die 32-Bit-Zeiger verwendet. Es hat gegenüber der Verwendung von 32-Bit-x86 den Vorteil, dass es eine mehr registerorientierte Aufrufkonvention hat und die zusätzlichen 8 GPRs (und zusätzlichen 8 SIMD/FP-Register) verwenden kann. Außerdem unterstützt GCC ILP32 auf AArch64.

    – Paul A. Clayton

    19. März 2015 um 11:25 Uhr

  • Also ist es wahrscheinlicher, dass Sprachen wie Java/C# diesen 2x-Effekt erzielen als C/C++ (insbesondere wenn Sie nicht viele Zeiger verwenden), richtig?

    – David sagt, Monica wieder einzusetzen

    19. März 2015 um 16:02 Uhr

  • @DavidGrinberg Auch hier kommt es auf die Daten an. Zum Beispiel ein Programm, das die meisten seiner Daten in einem nativen Array hat, wie z int[] oder double[], wird sich nicht viel ändern. Ein Programm, das mit vielen kleinen Objekten zurechtkommt, benötigt jedoch mehr RAM.

    – glglgl

    19. März 2015 um 20:14 Uhr

  • @DavidGrinberg Wegen komprimiert oopsJava-Programme, die weniger als ~4 GiB Heap verwenden, werden wahrscheinlich gleich bleiben.

    – Tavian Barnes

    19. März 2015 um 20:16 Uhr

  • @TavianBarnes Tatsächlich kann eine JVM 64 GB mit 32-Bit-Referenzen adressieren, indem sie eine Objektausrichtung von 8 oder 26 Bytes verwendet.

    – Peter Lawrey

    25. März 2015 um 3:21 Uhr

Benutzeravatar von VAndrei
Vandrei

Es gibt einige Gründe für den Anstieg des Speicherverbrauchs. Der Overhead von 64b gegenüber 32b hängt jedoch von einer App zur anderen ab.

  • Hauptgrund ist Verwenden Sie viele Zeiger in Ihrem Code. Ein dynamisch zugewiesenes Array in einem Code, der für 64-Bit kompiliert wurde und auf einem 64-Bit-Betriebssystem ausgeführt wird, hätte jedoch die gleiche Größe wie das Array, das auf einem 32-Bit-System zugewiesen wird. Nur die Adresse des Arrays wird größer, die Inhaltsgröße bleibt gleich (außer wenn sich die Schriftgröße geändert hat – das sollte jedoch nicht passieren und sollte gut dokumentiert werden).

  • Eine weitere Fußabdruckerhöhung wäre fällig Speicherausrichtung. Im 64-Bit-Modus muss die Ausrichtung eine 64-Bit-Adresse berücksichtigen, sodass ein kleiner Overhead hinzugefügt werden sollte.

  • Wahrscheinlich die Größe des Codes wird zunehmen. Auf einigen Architekturen könnte die 64-Bit-ISA etwas größer sein. Außerdem müssten Sie jetzt Anrufe an 64-Bit-Adressen tätigen.

  • Beim Laufen in 64bit Register sind größer (64bit) Wenn Sie also viele numerische Typen verwenden, kann der Compiler sie genauso gut in Register platzieren, sodass dies nicht unbedingt bedeuten sollte, dass Ihr RAM-Fußabdruck steigen würde. Double-Variablen verwenden führt wahrscheinlich zu einer Erhöhung des Speicherbedarfs, wenn sie nicht in 64b-Registern gespeichert werden.

  • Beim Benutzen JIT-kompilierte Sprachen wie Java, .NET ist es wahrscheinlich, dass der Fußabdruck von 64b-Code größer wäre, da die Laufzeitumgebung zusätzlichen Overhead durch Zeigerverwendung, versteckte Kontrollstrukturen usw. erzeugen würde.

Es gibt jedoch keine magische Zahl, die den Overhead des 64-Bit-Speicherbedarfs beschreibt. Das muss von einer Anwendung zur anderen gemessen werden. Von dem, was ich gesehen habe, Ich habe nie mehr als 20% mehr Fußabdruck bekommen für eine Anwendung, die auf 64-Bit ausgeführt wird, im Vergleich zu 32-Bit. Dies basiert jedoch ausschließlich auf den Anwendungen, auf die ich gestoßen bin, und ich verwende hauptsächlich C und C++.

  • Ein Sprung ist typischerweise relativ 32 Bit. Sie können nicht mit einem einzigen jmp-Befehl zu einer absoluten 64-Bit-Adresse springen

    – phuklv

    19. März 2015 um 8:50 Uhr

  • Die einzige Anweisung, die eine 64-Bit-Direktadresse hat, ist movabs, daher können Sie auch keine Funktion mit einer 64-Bit-Direktadresse aufrufen

    – phuklv

    19. März 2015 um 9:05 Uhr

  • Ich bin mir ziemlich sicher, dass Sie eine absolute 64b-Adresse anrufen können. Überprüfe hier: intel.com/content/dam/www/public/us/en/documents/manuals/…

    – Vandrei

    19. März 2015 um 9:19 Uhr

  • Auch ein Sprung mit einem 64-Bit-Offset ist gemäß derselben Referenz möglich.

    – Vandrei

    19. März 2015 um 9:25 Uhr

  • du liest etwas falsch. „Im 64-Bit-Modus sind Immediate und Displacements im Allgemeinen nur 32 Bit breit. NASM kürzt daher die meisten Displacements und Immediate auf 32 Bit. nasm.us/doc/nasmdo11.html

    – phuklv

    19. März 2015 um 13:31 Uhr

Ich denke, es kann einen anderen Grund geben, der weit zurückreicht, dass Variablen im Speicher an einer 64-Bit-Grenze an einer Adresse gespeichert werden müssen, die … xxxxx000 ist, um in einem Biss gelesen zu werden, wenn dies nicht der Fall ist, muss sie in einem Byte gelesen werden zu einer Zeit.

1405130cookie-checkWie hoch ist der Arbeitsspeicherverbrauch für eine 64-Bit-Anwendung?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy