# [OT] Hauptspeicherbedarf 32bit vs 64bit

## TMiegel

Ok, während ich grade mein Gentoo für meinen neuen AMD64 am bootstrappen bin, hatte ich eine Diskussion mit einem Studienkollegen, was den Hauptspeicherbedarf eines 64-Bit-OS gegenüber einem 32-bit-OS betrifft:

Er habe bis jetzt noch kein 64-bit-OS installiert, weil dafür 512 MB nicht ausreichend wären (1024 sollte man haben)

Begründet hat er das damit, daß 64-bit-Speicherworte ja mehr Hauptspeicher belegen, als 32-bit lange.

- Stimmt das? Ist der Mehrbedarf wirklich in der Größenordnung mehrerer dutzend (hundert) MB?

- Oder ist der Mehrbedarf eher zu vernachlässigen?

- Oder spielt das gar keine Rolle?

Mich würd dann ja gleichzeitig auch noch interessieren, wie sich der Unterschied auf die Executables auswirkt? Sind die Dateigrössen unterschiedlich? Oder ist der Unterschied so gering, dass verschiedene -Ox -Flags da schon mehr ausmachen?

Also ich hab viel gelesen über die 64-Bit-Architektur (bevor ich selbst nun eine gekauft habe), aber alle Artikel, Infos dazu beschreiben halt immer nur den Unterschied bei der Adressierung von Speicher jenseit der 4GB Grenze...

----------

## SinoTech

Also hab mich damit noch nicht beschäftigt, aber meiner Meinung nach sollte der Speicherbedarf keiner größeren Schwankung unterliegen. Die 32 bzw. 64 Bit beziehen sich ja nur auf die Busbreite und nicht wie groß eine Variable im Speicher ist. Heißt ein "int" bleibt ein "int" und ein "float" bleibt ein "float". 

Sollte ich mit meiner Theorie daneben liegen dann mögt mich bitte verbessern  :Smile: 

Mfg

Sino

----------

## Carsti

 *SinoTech wrote:*   

> Also hab mich damit noch nicht beschäftigt, aber meiner Meinung nach sollte der Speicherbedarf keiner größeren Schwankung unterliegen. Die 32 bzw. 64 Bit beziehen sich ja nur auf die Busbreite und nicht wie groß eine Variable im Speicher ist. Heißt ein "int" bleibt ein "int" und ein "float" bleibt ein "float". 
> 
> Sollte ich mit meiner Theorie daneben liegen dann mögt mich bitte verbessern 

 

Naja ist das nicht absolut kompilerabhängig/systemabhängig wie mit den Datentypen umgegangen wird? So haben in der java-vm (32 Bit) doch auch kleinere Datentypen wie Byte eine Wortlänge von 32-Bit im Speicher? Was spricht dagegen das mit einer erweiterten Architektur zu vergrössern? Könnte man nicht zu dem Schluss kommen, dass nun in einer 64-Bit Umgebung auch die 64 Bit genutzt werden?

Und entspricht in C nicht die Länge eines ints der Wortlänge des Prozessers/(OS) ?

Gruß,

Carsten

----------

## SinoTech

 *Carsti wrote:*   

>  *SinoTech wrote:*   Also hab mich damit noch nicht beschäftigt, aber meiner Meinung nach sollte der Speicherbedarf keiner größeren Schwankung unterliegen. Die 32 bzw. 64 Bit beziehen sich ja nur auf die Busbreite und nicht wie groß eine Variable im Speicher ist. Heißt ein "int" bleibt ein "int" und ein "float" bleibt ein "float". 
> 
> Sollte ich mit meiner Theorie daneben liegen dann mögt mich bitte verbessern  
> 
> Naja ist das nicht absolut kompilerabhängig/systemabhängig wie mit den Datentypen umgegangen wird? So haben in der java-vm (32 Bit) doch auch kleinere Datentypen wie Byte eine Wortlänge von 32-Bit im Speicher? Was spricht dagegen das mit einer erweiterten Architektur zu vergrössern? Könnte man nicht zu dem Schluss kommen, dass nun in einer 64-Bit Umgebung auch die 64 Bit genutzt werden?
> ...

 

Weiß nicht wie JAVA das handhabt, aber in C/C++ hat doch ein "short" zwei Byte im Speicher und ein "char" ein Byte (Unter Windows und Linux auf x86 Architekturen ... keine Ahnung ob das sonst wo anderst ist). Wieso soll sich das jetzt ändern ? Brauchen wir jetzt weniger 2 Byte und 4 Byte Datentypen wie vorher ? Könnte mir höchstens vorstellen das der Datentyp "long" jetzt 8 Byte bekommt, da dieser vorher (Auf x86 Systemen), genauso wie "int", nur 4 Byte hatte.

Mfg

Sino

EDIT:

Variablengröße ist natürlich Betriebssystem bzw. Compilresache. Unter Linux sind zum Beispiel Strukturen an 4 Bytegrenzen ausgerichtet, unter Windows nicht (Beispiel dafür weshalb der Gebrauch des "sizeof()" operators zu Problemen führen kann).

----------

## Fauli

In C gilt immer: sizeof (char) = 1 und sizeof (short) <= sizeof (int) <= sizeof (long). Das ist aber auch schon alles. Wenn du für AMD64 kompilierst, sind Zeiger und Longs statt 4 Bytes 8 Bytes groß. Also werden die Programm auch mehr Speicher verbrauchen. Ich bezweifle aber, dass man statt 512 MB nun plötzlich 1 GB RAM braucht.

EDIT: Auch der Microsoft C-Compiler richtet die Variablen an bestimmten Bytegrenzen aus, standardmäßig an einer durch 8 teilbaren Adresse. Das Problem mit dem Operator sizeof ist, dass eine Struktur größer sein kann, als die Summe der Größen ihrer Komponenten.

----------

## _hephaistos_

 *Fauli wrote:*   

> In C gilt immer: sizeof (char) = 1

 

gilt NICHT immer! sonst würde man ja auch 1 statt sizeof(char) verwenden.

das hängt nämlich von der maschine (prozessor) ab, wie die das handhabt.

weiters: die 64bit sind doch die wortgröße, die der prozessor auf einmal schluckt (verarbeiten kann) oder?

das hat ja mit dem hauptspeicher nichts zu tun....

cheers

----------

## Carsti

 *Fauli wrote:*   

> Also werden die Programm auch mehr Speicher verbrauchen. Ich bezweifle aber, dass man statt 512 MB nun plötzlich 1 GB RAM braucht.

 

Naja bei 512 MB Speicher ist ja 1024 MB der sinnvolle Nachfolger. Es ist so: Als ich in meinem Debian auf x86_64 umgestiegen bin, reichten meine 512 nicht mehr aus. Soll heissen, ich bewege mich sehr oft auf der SWAP-Partition. Mit dem gleichen System unter x86 hatte ich diese Schwierigkeiten nicht. Aber das kann natürlich auch andere Ursachen haben.

 *hephaistos6 wrote:*   

> 
> 
> weiters: die 64bit sind doch die wortgröße, die der prozessor auf einmal schluckt (verarbeiten kann) oder?
> 
> das hat ja mit dem hauptspeicher nichts zu tun.... 

  Weiss nicht genau, irgendwas stimmt da nicht.

----------

## m.b.j.

 *Quote:*   

> Also werden die Programm auch mehr Speicher verbrauchen. Ich bezweifle aber, dass man statt 512 MB nun plötzlich 1 GB RAM braucht

 

Stimmt, ich hab 512 mb und keine Probleme!

----------

## SinoTech

 *Fauli wrote:*   

> 
> 
> [...]
> 
> EDIT: Auch der Microsoft C-Compiler richtet die Variablen an bestimmten Bytegrenzen aus, standardmäßig an einer durch 8 teilbaren Adresse. Das Problem mit dem Operator sizeof ist, dass eine Struktur größer sein kann, als die Summe der Größen ihrer Komponenten.
> ...

 

Ok, mag sein das es unter windows auch ausgerichtet ist, aber mit Sicherheit nicht an einer 8 Bytegrenze. Hatte letztens das Problem den Header einer Bitmap Datei auszulesen. Das struct wurde unter Windows korrekt eingelesen (Mittels "sizeof()"), unter Linux gabs jedoch einen Crash, da "sizeof()" einen anderen Wert zurückgab. Folglich sind die Größen an denen ausgerichtet wird unterschiedlich (Falls unter Linux 8 Byte -> Windows 4 Byte, bzw. falls unter Linux 4 Byte -> Windows 2 Byte).

 * wrote:*   

> 
> 
> [...]
> 
> weiters: die 64bit sind doch die wortgröße, die der prozessor auf einmal schluckt (verarbeiten kann) oder?
> ...

 

Jep. Heißt es werden 32 Bit bzw. 64 Bit parallel über den Bus übertragen. Folglich kann der Prozessor auch 64 Bit aufeinmal schlucken.

Heißt aber auch das jetzt Beispielsweise der Datentyp "long" unter C/C++ 8 Byte bekommen kann (War ja ganze Zeit 4 Byte), da 64 Bit zur Recheneinheit übertragen werden können und somit direkt addiert , ... werden können. Denke mal das rechnen mit größeren Datentypen war bisher immer Softwaremäsig realisiert worden, da ja immer nur 32 Bit verarbeitet wurden. Auch Zeiger in C/C++ könnten jetzt größer werden ... Frage ist nur ob das Zeug wirklich so intensiv in programmen genutzt wird das das doppelte an Speicher benötigt wird  :Wink:  ... eher nicht.

Mfg

Sino

----------

## Carsti

Aber all das zeigt doch, das durchaus je nach Software und System durchaus Schwankungen möglich sind, bzw. definitiv vorkommen. Interessant wäre es also doch zu erfahren, in welchen Größenordnungen sich diese bewegen. Dass das Doppelte absolut unrealistisch ist klar, ... 

Wenn man sich also die Ausgangsfrage greift: was bedeutet das?

Ist der Unterschied vernachlässigbar klein? 

Gruß,

Carsten

----------

## Fauli

 *hephaistos6 wrote:*   

>  *Fauli wrote:*   In C gilt immer: sizeof (char) = 1 
> 
> gilt NICHT immer! sonst würde man ja auch 1 statt sizeof(char) verwenden.
> 
> das hängt nämlich von der maschine (prozessor) ab, wie die das handhabt.

 

Doch. A char (...) occupies exactly one byte.

 *hephaistos6 wrote:*   

> weiters: die 64bit sind doch die wortgröße, die der prozessor auf einmal schluckt (verarbeiten kann) oder?
> 
> das hat ja mit dem hauptspeicher nichts zu tun....
> 
> 

 

Wenn ein Programm ein malloc(sizeof(Strukturtyp)) macht und die Struktur unter 64-Bit-Systemen länger ist, weil die Strukturkomponenten größer sind, wird doch auch mehr Speicher verbraucht.

 *SinoTech wrote:*   

> Folglich sind die Größen an denen ausgerichtet wird unterschiedlich (Falls unter Linux 8 Byte -> Windows 4 Byte, bzw. falls unter Linux 4 Byte -> Windows 2 Byte).

 

Da hast du Recht. Die Strukturkomponenten sind an Bytegrenzen ausgerichtet, die ihrer Größe entsprechen. Shorts also an einer durch zwei teilbaren Adresse und chars können z. B. an jeder Adresse anfangen. Die Struktur selbst und auch andere Variablen außerhalb von Strukturen sind aber an 8-Byte-Grenzen ausgerichtet.

----------

## SinoTech

 *Fauli wrote:*   

> 
> 
> [...]
> 
>  *SinoTech wrote:*   
> ...

 

Ich habe das ganze nicht auf die Komponenten bezogen, sondern auf die Struktur selbst. Ich weiß nicht an genau welchen Grenzen ausgerichtet wird, jedoch sind diese bei Windows anders als bei Linux. Wie schon weiter oben geschrieben war ein "sizeof(BITMAPHEADER)" unter Windows kleiner als unter Linux, was dazu führte das mein Program unter Linux einem Speicherzugriffsfehler erlag  :Sad: .

Mfg

Sino

----------

## mrsteven

Kann nicht einfach mal einer, der einen 64-Bit-Rechner hat, nachschauen, wie groß denn ein int jetzt ist?

```

cat << EOF > test.c

#include <stdio.h>

int main(void)

{

  printf("sizeof(int) = %u\n", sizeof(int));

  return 0;

}

EOF

gcc test.c -o test

./test

```

Ich denke mal, das müssten 8 Byte sein, weil int normalerweise die Größe eines Maschinenwortes hat.

----------

## ThePsycho

http://www.planet3dnow.de/vbulletin/showthread.php?t=181589

Bißchen nach unten scrollen, der Speicherverbrauch wird auch berücksichtigt.

Man beachte aber das Datum (viel wird sich aber wohl nicht geändert haben, denke ich).

----------

## Carsti

 *ThePsycho wrote:*   

> http://www.planet3dnow.de/vbulletin/showthread.php?t=181589
> 
> Bißchen nach unten scrollen, der Speicherverbrauch wird auch berücksichtigt.
> 
> Man beachte aber das Datum (viel wird sich aber wohl nicht geändert haben, denke ich).

 

Was sollte sich da geändert haben? Ein paar Kleinigkeiten im Compiler, aber viel wird das nicht gebracht haben. Jedenfalls fühle ich mich nun bestätigt. Habe ja bereits geschrieben, dass ich einige Probleme mit x86-64 bei 512MB habe, die ich mit x86 nicht hatte.

Gruß,

Carsten

----------

## tropical

Ich hatte für eine paar Wochen ein 64bit Gentoo installiert und es mir ausgeben lassen, ints sind tatsächlich weiterhin nur 4 Byte lang. Laut Standard ist es dem Compilerbauer überlassen sinnvolle Größen für short, int und long zu wählen, und da ist es wohl auch sinnvoller diese Typen auf 16, 32 und 64 bit zu verteilen, als int und long mit 64 bit wieder gleich groß zu machen und dann keinen 16 bzw. 32bit -Typ mehr zu haben.

----------

## Tobiking

Also ich hab mal kurz gegooglet und bin da auf http://msdn2.microsoft.com/library/3b2e7499(en-us,vs.80).aspx gestoßen. Das ist zwar auf Windows bezogen aber es wird denke ich mal bei Linux nicht großartig anders sein. Auf der Seite steht nämlich das trotz 64-Bit OS int und long trotzdem 32 bit Werte bleiben werden. Es steht nicht für alle datentypen dort aber es wird sicherlich ähnlich gehandhabt. Es gibt bestimmt software die auf die 32 bit grenze von int werten abhängig ist und sowas ist dann leichter zu portieren. Und es ändert sich dabei dann in dieser hinsicht nichts am speicherverbrauch.

----------

## MatzeOne

 *mrsteven wrote:*   

> Kann nicht einfach mal einer, der einen 64-Bit-Rechner hat, nachschauen, wie groß denn ein int jetzt ist?
> 
> ```
> 
> cat << EOF > test.c
> ...

 

sizeof(int) = 4

----------

## franzf

Was ich dann nicht verstehe:

Java wird ja der Vorteil zugesprochen, dass sich ein Programm auf mehreren Plattformen identisch verhält, was die Zahlen-Typen angeht. Wenn das bei C/C++ ebenso ist, versteh ich diese "Propaganda" nicht.

Ich weiß es nicht mehr genau, aber als längerer Datentyp hab ich entweder long long oder long64 schon mal gesehen. Weiß da jemand genaueres?

Grüße

Franz

----------

## SinoTech

 *MatzeOne wrote:*   

>  *mrsteven wrote:*   Kann nicht einfach mal einer, der einen 64-Bit-Rechner hat, nachschauen, wie groß denn ein int jetzt ist?
> 
> ```
> 
> cat << EOF > test.c
> ...

 

und was sagt

```

printf("sizeof(long) = %u\n", sizeof(long)); 

```

?

Mfg

Sino

----------

## oscarwild

Um mit einem riesengroßen Missverständnis aufzuräumen, wenn Leute von der Größe von Datentypen sprechen:

Die "Datentypen", von denen ihr redet, gibt es ausschließlich in Programmiersprache wie C. C definiert z.B.:

- char: muss Platz bieten, um ein "Zeichen" abbilden zu können, mehr ist nicht definiert. Das geht sowohl mit 8 aber auch mit 16 Bits (und nebenbei soll es 12 Bit Architekturen geben)

- int: ein integraler Datentyp, der mindestens so groß wie char ist

- float: Fließkomme, das Format ist allerdings überhaupt nicht definiert!

Dazu kommen noch die Zusätze short und long.

Wie das auf den Speicher abgebildet  wird, bestimmt allein der Compiler und dessen Einstellungen! Aus diesem Grund wird übrigens im Embedded-Bereich oft die Verwendung der eigentlichen Compilerdatentypen verboten. Wenn M$ sagt, dass long auch auf 64-Bit Systemen 32 Bit lang ist, dann mag das für Visual C gelten, sicher aber nicht zwingend für den gcc.

Die CPU kennt keine "Datentypen", lediglich Bytes, Worte, Doppelworte etc. Die FPU kennt zusätzlich ein oder mehrere Fließkommadarstellungen, mit der sie nativ, also ohne Softwareemulation, umgehen kann. Ein vernünftiger Compiler nutzt die Fließkommadarstellung der FPU, ein dummer Compiler emuliert Fließkommazahlen aber trotzdem in Software...

Zu der Speicherbedarfsfrage: Je nachdem, wie der Bus der CPU ausgelegt ist, kann es günstiger sein, wenn die Daten im Speicher ein bestimmtes Alignment aufweisen, d.h., so ausgerichtet sind, dass die CPU optimal darauf zugreifen kann. Wer noch die Motorola 68K-Welt kennt, kann ein Lied davon singen, dort war Alignment das Problem schlechthin.

Ohne die 64-Bit Architekturen genauer zu kennen, bin ich mir relativ sicher, dass es dort ähnliche Effekte gibt. Natürlich kann man den 32-Bit Modus verwenden, dann ändert sich praktisch nichts - aber man hat dann auch wenig Vorteile von der 64 Bit Architektur. Der absolute Worst Case, wenn die 64 Bit Architektur genutzt wird, liegt beim doppelten Speicherverbrauch, kommt aber so nicht ständig vor. Realistisch schätze ich jetzt mal +25%.

----------

## Carsti

Das wars dann wohl. Vielleicht hat jemand noch einen ähnlichen Link wie http://www.planet3dnow.de/vbulletin/showthread.php?t=181589, oder eigene Erfahrungen um diese Werte zu verifizieren? Ich muss zugeben, dass dass es es mir zu auwändig ist, das gleiche System in 32-Bit neu aufzusetzen.

Habe ich schon erwähnt, dass ich der oben genannte Studienkollege bin?

 *TMiegel wrote:*   

> Er habe bis jetzt noch kein 64-bit-OS installiert, weil dafür 512 MB nicht ausreichend wären (1024 sollte man haben) 

 

War zwar eher provizierend formuliert, schliesslich habe ich schon seit Monaten ein 64-Bit System, aber das lag wohl eher daran, dass ich nicht zum Kreis der erlauchten Gentoo user gehöre. Da wird man wohl ausgegrenzt  :Wink: 

Jedenfalls ist es mir speziell bei der Java-Programmierung aufgefallen, dass mein System mit Eclipse in die Knie gegangen ist. Anfangs habe ich es auf den Java5/Eclipse Bug geschoben; bis ich mal den RSS aller Programme genau betrachtet habe. Nur hatte ich keine Vergleichsdaten mehr ... ;(

Gruß,

Carsti

----------

## platinumviper

 *TMiegel wrote:*   

> Begründet hat er das damit, daß 64-bit-Speicherworte ja mehr Hauptspeicher belegen, als 32-bit lange.

 

Stimmt, das hat aber (fast) nur zur Folge, dass halb so viele Speicherzugriffe und halb so viele Rechenoperationen erforderlich sind, der RAM Bedarf wird dadurch nicht wesentlich beeinflusst. Ein Byte in einer beliebigen Datei bleibt ein Byte, die Größe der Opcodes hat sich auch nicht geändert. Die Größe von /usr/bin/Xorg (6.8.2-r1) auf einem Athlon64: 2571842 Bytes, einem AthlonMP: 2194449, einem Pentium4: 2157551 (alle mit unterschiedlichen USE-Flags).

Installier einfach weiter und bild Dir Deine eigene Meinung.

platinumviper

P.S.

Einer der ersten (oder war es der erste?) 64-Bit Desktops, die SGI Indy, wurde vor 12 Jahren mit 32 bis maximal 256 MB verkauft. Trotz sehr üppiger Hardwareausstattung (SCSI, Ethernet, ISDN, Video (Webcam im Lieferumfang) und Digital Audio auf dem Motherboard, 3D Grafikkarte als Steckkarte) lies sich damit sehr zügig arbeiten.

----------

## Anarcho

 *Quote:*   

> Einer der ersten (oder war es der erste?) 64-Bit Desktops, die SGI Indy, wurde vor 12 Jahren mit 32 bis maximal 256 MB verkauft. Trotz sehr üppiger Hardwareausstattung (SCSI, Ethernet, ISDN, Video (Webcam im Lieferumfang) und Digital Audio auf dem Motherboard, 3D Grafikkarte als Steckkarte) lies sich damit sehr zügig arbeiten.

 

Genau!

Son ding steht bei mir auch rum, hat 32 MB RAM und läuft wirklich recht flott. Allerdings muss ich jetzt mal auf IRIX 6.5 upgraden...oder vielleicht doch auch Gentoo drauf, mal sehen.

----------

## Eistaucher

Das stimmt schon, dass DATEN-Worte bei 64 Bit doppelt so groß sind. 

Allerdings besteht der Speicherinhalt ja (neben Daten) auch aus Befehlen 

und die sind meistens genauso kurz, wie bei 32 Bit Systemen. Also den 

doppelten Speicher braucht man gar nicht, weil Deine Daten (Bilder, 

Texte, Videos, Soundfiles) sich nicht ändern. Und die liegen ja auch im 

Speicher.

----------

## Anarcho

Ich weiss überhaupt nicht was ihr alle habt, auf meinem 64 Bit System habe ich folgende Werte:

```
sizeof(char) = 1

sizeof(short) = 2

sizeof(int) = 4

sizeof(long) = 8

sizeof(long long) = 8

sizeof(float) = 4

sizeof(double) = 8

sizeof(long double) = 16
```

und auf meinem 32 Bit System diese:

```
sizeof(char) = 1

sizeof(short) = 2

sizeof(int) = 4

sizeof(long) = 4

sizeof(long long) = 8

sizeof(float) = 4

sizeof(double) = 8

sizeof(long double) = 12
```

Wie man also sieht unterscheiden sich nur long  und long double. Ausserdem sind diese Werte auf die Sprache C beschränkt. In anderen Sprachen sieht das anders aus. 

Ansonsten unterscheiden sich AFAIK nur die Speicheradressen, diese sind jetzt 64 Bit lang.

Ausserdem ändert sich nur was, wenn ihr es auch als 64 Bit executable compiliert habt. 

Wenn ihr z.b. OpenOffice-bin verwendet, dann ändert sich da garnichts, denn meine test-exec ergibt als 32 Bit ELF auf dem 64 Bit System die gleichen Werte wie auf dem 32 Bit System. Das sollte man mitbeachten.

----------

## Carsti

 *Anarcho wrote:*   

> 
> 
> Ausserdem ändert sich nur was, wenn ihr es auch als 64 Bit executable compiliert habt. 
> 
> Wenn ihr z.b. OpenOffice-bin verwendet, dann ändert sich da garnichts, denn meine test-exec ergibt als 32 Bit ELF auf dem 64 Bit System die gleichen Werte wie auf dem 32 Bit System. Das sollte man mitbeachten.

 

Aber man profitiert beim Mischen von 32-Bit und 64-Bit Anwendungen, nicht mehr durch die shared-libaries ... auch das sollte man beachten. Oder?

Gruß,

Carsten

----------

## Anarcho

Ja, das ist richtig. Ich wollte damit auch in keinsterweise das mischen von 32Bit und 64Bit für gut befinden.

----------

## MatzeOne

Long ist 8

Edit: Da hat ja schon jemand alles durchgestestet  :Wink: 

----------

## Carlo

 *MatzeOne wrote:*   

> Long ist 8

 

Praktisch ja, aber nicht zwangsläufig.

----------

