32bit Anwendungen aufgrund von kürzeren Speicheradressen schneller!?

[Tersus]

Guten Abend,

letztens habe ich mal wieder gehört, dass 64bit Anwendungen oft langsamer sind, weil der Prozessor statt einer 32bit Adresse, eine 64bit Adresse verarbeiten muss ...
Klingt so erstmal für jemanden, der von Prozessorarchitekturen nicht viel Ahnung hat, plausibel. Ich halte mich für so einen Ahnungslosen.

Dennoch macht mich die Aussage stutzig. Ein 64bit Prozessor besitzt doch, mal ganz simpel gehalten, 64bit Register. Ob er pro Register nun eine 64bit Adresse lädt oder 32bit Adresse, ist ihm doch egal, oder? Bzw. werden 32bit Adressen doch intern sicher mit Nullen aufgefüllt. Soll heißen, dass der 64bit Prozessor tatsächlich nur 64bit Adressen kennt. Richtig?

Ich weiß es nicht besser, also bitte ich um Aufklärung.

 

[Voyager10]

Bei heutiger Geschwindigkeit von CPU und RAM ist das reiner nonens , Leute die sowas behaupten gehen immernoch davon aus das die Speicherverwaltung ein Pentium 1 überfordern wurde bzw. wertvolle Rechenzeit abknappsen würde, wenn man noch das Jahr 1990 schreiben würde.
Aber wir wir wissen ist das 25 Jahre her...

 

[Arzaiel]

Das ist auch sehr schwer zu vergleichen, da 64-Bit Programme einen ganz anderen Befehlssatz verwenden als ihre 32-Bit Pendants. Kann sein, dass bestimmte Vorgänge auf der einen Platform mehr oder weniger Instruktionen benötigt als auf der anderen.

Was aber auf jeden Fall stimmt ist das 64-Bit Programme häufig größer sind und etwas mehr RAM-Platz benötigen aufgrund der längeren Adressen.

 

[ronny_kruse]

das stimmt so nicht. allerdings sind 64bit befehle doppelt so groß (Arzaiel hats schon anklingen lassen). das heisst, sie brauchen nicht nur doppelt so viel platz wie ein 32bit-befehl, sondern bei gleicher speicherbandbreite natürlich auch die doppelte zeit, um ausgelesen zu werden. das zieht sich vom speicherzugriff auf den ram bis zum L1, 2 oder 3 cache so durch. (was nicht heissen soll, dass dieser nachteil nicht durch andere vorteile mehr als wett gemacht wird)

 

[jownes]

oft sind aktuelle rechenintensive programme in 64 bit geschrieben
also wird ein Vergleich fast unmöglich sein
an sich macht es keinen Unterschied ob die Programme in 64 oder 32 bit geschrieben sind
auch wenn der ganze hype wieder losgeht, weil apple propangiert, dass ihre 64 bit cpu schneller sei (steigerung nicht durch 64 bit sondern durch vergrößerung des cache und andere optimierungen)

 

[asdfman]

gleicher speicherbandbreite natürlich auch die doppelte zeit, um ausgelesen zu werden.

Ich bin jetzt kein Hardwareexperte, deshalb bitte nicht auslachen, aber: Eine 64Bit CPU wird doch wohl auch 64 Drähte zum RAM haben (im Gegensatz zu den 48 bei x86). Wieso soll das denn dann länger dauern? :X

 

[jownes]

Ich bin jetzt kein Hardwareexperte, deshalb bitte nicht auslachen, aber: Eine 64Bit CPU wird doch wohl auch 64 Drähte zum RAM haben (im Gegensatz zu den 48 bei x86). Wieso soll das denn dann länger dauern? :X

ich bin auch kein experte
aber meines wissens nach dauert es bei aktuellen CPUs gleich lang, da sie in einem Takt den befehl verarbeiten, egal ob 32 oder 64bit

 

[ronny_kruse]

Ich bin jetzt kein Hardwareexperte, deshalb bitte nicht auslachen, aber: Eine 64Bit CPU wird doch wohl auch 64 Drähte zum RAM haben (im Gegensatz zu den 48 bei x86). Wieso soll das denn dann länger dauern? :X

die speicheranbindung hat doch nichts mit dem befehlssatz zu tun (oder?)
aber zumindest hast du recht: ddr1 bis ddr3 jedenfalls sind pro kanal mit 64bit angebunden. ich hätte das halt jetzt so interpretiert, dass pro takt somit 64 bit übertragen werden können. welche bits das sind tut ja zunächst nichts zur sache: das können also 2 32bit befehle sein oder eben 1 64 bit befehl.
nur so: wie kommst du auf 48?

Ergänzung (4. November 2014)

@ jownes: ja das ist ja unbestritten der fall uns gings jetzt glaub ich um den weg vom speicher zur cpu

 

[powerfx]

Theorie ist eine Sache, aber in der Praxis sind solche Überlegungen vielleicht weniger wert. Ein 64-Bit-Windows kann z.B. nativ keine 32-Bit-Anwendungen ausführen. Es wird ein zusätzliches Subsystem (quasi Emulator) benötigt. Das macht 32-Bit-Anwendungen auf einem 64-Bit-System schon mal langsamer als auf einem 32-Bit-System.

Das Meiste hängt aber wohl vom Compiler ab. Die sind nicht 1:1 vergleichbar und somit gibt es auch keine vergleichbaren Anwendungen in 32- und 64-Bit.
Im Optimalfall sind 64-Bit natürlich schneller. Aber dazu muss eben einiges gegenüber 32-Bit optimiert sein.

 

[goldmomo]

Hi,

technisch gesehen macht es natürlich einen Unterschied, ob ich z.B. arithmetische Instruktionen in 32 Bit berechnen muss oder in 64 Bit. Allerdings sind Teile der ALUs (z.B. x86-64) schon auf 64 Bit ausgelegt, d.h. sie werden mit <64 Bit (32,16,8) nicht (unbedingt) schneller.

Unter dem Link findest du einige Daten:

http://www.agner.org/optimize/instruction_tables.ods

Da kann man erkennen, dass z.B. die Latenz bei einem IDIV unter 64 Bit natürlich größer ist als unter 32 Bit. Bei den meisten Integer-Befehlen ist sie aber gleich zu 64 Bit.

Bei float/double (einfache, doppelte Genauigkeit FK) Befehlen ist es ja auch nicht anders, du brauchst einfach mehr Logik/Latenz bei mehr Rechenbreite.

Es kommt am Ende immer auf das Design an, pauschal ist es schwierig eine Aussage zu treffen (da gibt es noch Unmengen anderer wichtiger Faktoren). In der Theorie kann man durch weniger Logik beim Rechnen die Latenz verkürzen und/oder den Takt bei 32 Bit, im Gegensatz zu 64 Bit, erhöhen.

Ist halt auch die Frage, ob 64 Bit für das System wichtig sind, bei einem PC möchte man schon mehr als 4GB nativen Adressraum benutzen. Ob das bei einem Smartphone SOC wichtig ist, ich glaub es nicht, aber für die Werbung ist wohl wichtig

 

[Daaron]

Na ja, eine 64Bit-CPU bietet auch eine höhere Entropie, vor allem für ASLR. Da wird es schon wieder interessant. Mit Entropie ist es wie mit Hubraum.... *G*

 

[asdfman]

nur so: wie kommst du auf 48?

http://de.wikipedia.org/wiki/Physical_Address_Extension

Ergänzung (5. November 2014)

Subsystem (quasi Emulator) benötigt.

Ein Subsystem hat überhaupt nichts mit Emulation zu tun, sondern damit, wie sich das Betriebssystem gegenüber der laufenden Software sichtbar macht.
Es gibt das native (NT)-Subsystem. Es gibt ein UNIX-Subsystem, es gab mal ein OS/2 Subsystem und es gibt ein Win32 Subsystem und WOW64 und bestimmt noch viele mehr.

€: EINSCHUB HIER: Als Erklärung, was ich damit meine: Das Win32-Subsystem lässt das Betriebssystem aussehen, als sei es Windows (Obwohl es in Wirklichkeit NT ist) und
das UNIX-Subsystem lässt das Betriebssystem aussehen, als sei es UNIX (Obwohl es in Wirklichkeit NT ist). Das ist aber keine Emulation, sondern nur eine Schnittstelle zwischen
dem Betriebssystem und der jeweiligen laufenden Software.

Software für jedes Subsystem wird nativ und direkt auf dem Prozessor ausgeführt. Emuliert wird überhaupt nichts. 64bit Code wird im Long Mode ausgeführt und wenn zu einem
WOW64-Prozess gewechselt wird, schaltet der Prozessor in den Protected Mode. Das einzige, was nicht mehr nativ möglich ist, ist der Real Mode. Das ist der Grund, warum es
unter aktuellen Versionen von Windows keinen Support für DOS mehr gibt. Der 16Bit Modus ist, wenn man einmal in den Long Mode (64Bit) geschaltet hat, nicht mehr zugänglich.
Wenn Subsystems Emulatoren wären, wie du behauptest, dann könnte man immer noch 16Bit Code ausführen. Kann man aber nicht. 32Bit-Code jedoch schon.

Zusatzgeschwurbel hier: http://en.wikipedia.org/wiki/NTVDM

 

[S.Kara]

32 Bit kann tatsächlich schneller sein als 64 Bit, da letzteres mehr Speicher benötigt und bei der gleichen Menge an RAM und Chache so seltener etwas nachgeladen werden muss. Einen anderen Geschwindigkeitsvorteil gibt es nicht und selbst dieser eine dürfte unter einem Prozent liegen.

Geht es um rechenintensive Anwendungen hat ein 32 Bit Programm gegen ein 64 Bit Programm natürlich keine Chance.

 

[chithanh]

Wenn der Code viel mit Speicheradressen hantiert, dann ist 32 bit häufig schneller als 64 bit. Bei x86 jedoch ging der Umstieg auf 64 bit mit architekturellen Verbesserungen einher, die den 64 bit Code doch wieder schneller machen. Andere Architekturen wie SPARC oder PowerPC haben bis auf den größeren Adressraum praktisch keinen Vorteil von 64 bit.

Intel hat versucht, mit "x32" einen Standard für 32 bit Programme zu schaffen, der die verbesserte Architektur auch mit 32 bit Programmen nutzen kann. In speziellen Szenarien (Mobilplattformen mit geringer Speicherbandbreite) konnten sie in einigen synthetischen Benchmarks einen Geschwindigkeitsvorteil von 5-8% gegenüber x86-64 erreichen.

 

[daemon777]

32 Bit kann tatsächlich schneller sein als 64 Bit, da letzteres mehr Speicher benötigt und bei der gleichen Menge an RAM und Chache so seltener etwas nachgeladen werden muss. Einen anderen Geschwindigkeitsvorteil gibt es nicht und selbst dieser eine dürfte unter einem Prozent liegen.

Geht es um rechenintensive Anwendungen hat ein 32 Bit Programm gegen ein 64 Bit Programm natürlich keine Chance.

Kleine Werte (<32bit), die oft wiederauftauchen (im Optimalfall alles in den Cache)? Da sollte das 32bit-Programm schon punkten, obwohl es rechenaufwendig ist. Es kommt eben ein bisschen drauf an, was man hier für eine Anwendung hat.

 

[dcc22]

64 Bit ist auch schneller, wenn darauf opitmiert wird. Alleine schon der adressierbare RAM...
Die Optimierungen übernimmt der Compiler/OS, das wird da schon nicht kreuz und quer das RAM beschreiben sondern ordnen.

Wer in C stdint.h nutzt der wird auch keine Einbußen sehen.Da Bytes in Folge hintereinander an Speicheradressen geschrieben werden, sind unnötig große Datentypen eben langsamer, da mehr gelesen werden muss. Man stelle sich also ein Array in Größe 3 (uint8_t array[3]) mit 1 Byte Datentypen vor:
[*-*-*]
und eines in 2 Byte Datentypen (uint16_t) auch mit Größe 3:
[**-**-**]

Das Ding auszulesen dauert halt länger und ist langsamer. Wenn dies nicht im Code bedacht wurde, werden diese Adressen Architektur bedingt beim kompilieren größer als man wollte. Denn ein Integer ist auf 16, 32 und 64 Bit ohne weitere Spezifikation durchaus verschieden groß, was auch zur Inkompatibilität führt. D.h. schreibt man große Zahlen rein wo man mit einem 64 Bit Integer keine Probleme hatte, wechselt dann auf 16 Bit und merkt es passt nicht rein. Umgekehrt verschwendet man Rechenzeit und Speicher . Aber als 64 Bit kam wurde auch die Hardware zeitgleich schneller, daher merkt man eh nichts von.

Daher immer schön stdint.h in C nutzen, damit sagt man exakt was man haben will und lässt es nicht vom Compiler interpretieren was denn nun ein Integer sein soll

 

[S.Kara]

Ich habe grad mal einen einfachen Test ausgeführt um zu sehen ob es einen merkbaren Unterschied zwischen x86 und x64 gibt und bin erschocken wie deutlich dieser ausfällt.

Funktion:

Spoiler

array[0] = 1;
for (int j = 1; j < ARRAY_LENGTH; j++) {
	for (int i = 1; i < ARRAY_LENGTH; i++) {
		array[i] = array[i - 1]++;
	}
}

32 Bit:

int8: 	3635
int16: 	3807
int32: 	3837
int64: 	17909

64 Bit:

int8: 	1591
int16: 	1685
int32: 	1685
int64: 	1687

Werte in Millisekunden.

Funktion 2:

Spoiler

for (int j = 1; j < ARRAY_LENGTH; j++) {
	array[0] = j;
	for (int i = 1; i < ARRAY_LENGTH; i++) {
		array[i] = array[i - 1]++;
	}
}

32 Bit:

int8: 	3635
int16: 	3791
int32: 	3822
int64: 	17609

64 Bit:

int8: 	733
int16: 	749
int32: 	733
int64: 	749

Werte in Millisekunden.

 

[powerfx]

Ein Subsystem hat überhaupt nichts mit Emulation zu tun, sondern damit, wie sich das Betriebssystem gegenüber der laufenden Software sichtbar macht.

Dann definierst du Emulation vermutlich anders. Windows und WOW ist von Microsoft. Microsoft schreibt:

WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows.

 

[Nai]

Ich habe grad mal einen einfachen Test ausgeführt um zu sehen ob es einen merkbaren Unterschied zwischen x86 und x64 gibt und bin erschocken wie deutlich dieser ausfällt.

Gesamtes Testprogramm dafür bitte

 

[rene87]

in der Vorlesung Prozessorarchitektur wurde uns gesagt, das die meisten CPUs heutzutage nur noch mit 64Bit rechnen, dass heißt 32 Bit befehle werden auf 64Bit aufgefüllt.