32bit vs. 64bit

Da nun anscheinend die halbe IT-Welt wahre Wunder von AMDs aktueller Prozessorgeneration verkünden scheint, habe ich mir gedacht, ich kann dem angeblichen Geschwindigkeitsgewinn ja auch mal selber auf den Zahn fühlen. Getreu dem Motto, glaube keinem Benchmark, den du nicht selber gefälscht hast.
Alles notwendige dafür ist ja vorhanden, sowohl die Hardware (Opteron 144), als auch die Software (Gentoo-Linux, welches es sowohl für x86, als auch für AMD64 gibt). Also frisch ans Werk, und eine möglichst einheitliche Testplattform aufgebaut. Die beiden Linux-Installationen wurden dafür mit folgenden Compilerflags übersetzt:

x86: CFLAGS="-O2 -march=athlon-xp -pipe -ftracer -msse2 -msse -mfpmath=sse -fweb"
AMD64: CFLAGS="-O2 -march=k8 -pipe -ftracer -fweb"

und das alles mit dem gcc-3.4.1

Einige Pakete sind mit anderen Flags übersetzt worden, weil sie nicht mit allen Flags laufen und sie somit eingeschränkt werden müssen.

Das ganze lief auf folgendem System:
Opteron 144 (1.8GHz)
512MB RAM DDR333 DualChannel
Tyan Tiger K8W S2875
Maxtor 6Y120M0 (120GB) an Silicon Image 3114

Der (vorläufige) Benchmarkparcour sah folgendermaßen aus:

POV-Ray:
als Benchmark kam das offiziell dafür vorgesehene Bild zum Einsatz

lame:
encoden einer 678MB großen wav-Datei ("A Night at the Opera" von Blind Guardian ) in ein 256kbs mp3,
um den Einfluß von file-I/O möglichst gering zu halten, wurde der output nach /dev/null umgeleitet

bzip2:
packen einer 1.7GB großen Datei (jede Menge Quelltext, die Linuxkernel von 2.60 bis 2.6.8 ), zwei Durchläufe, einmal nach /dev/null und dann in eine Datei

gzip:
das selbe Verfahren, wie bei bzip2, nur anderer Packer

SciMark:
SciMark ist ein benchmark, welcher aus fünf Teilbereichen besteht: Fast Fourier Transform, Jacobi Successive Over-relaxation, Monte Carlo integration, Sparse matrix multiply, dense LU matrix factorization
Also ein guter Test bezüglich number-crunching

UT2k4:
die Karten, auf denen getestet wurde, stehen unten,
aufgerufen wurden die Tests mit
"../ut2004 dm-asbestos?game=engine.gameinfo exec=../Benchmark/Stuff/flybyexec.txt -benchmark -seconds=71 -ini=../Benchmark/Stuff/benchmark.ini -userini=../Benchmark/Stuff/benchmarkuser.ini -nosound %1"
als Ergebnisse sind min/avg/max fps angeben

Dieser kleine Parcour hat erstmal folgende Ergebnisse gebracht:


Soweit, so durchwachsen. Die meisten Tests waren auf AMD64 schneller, bzip2 sogar extrem (nahezu 25%), manche waren langsamer. Daß lame auf AMD64 schlechter abgeschnitten hat, liegt wohl daran, daß dort handoptimierte Assemblercode enthalten ist, welcher noch nicht auf AMD64 portiert wurde, und dort nicht zur Verfügung steht. Warum gzip auf AMD64 schlechter abgeschnitten hat, kann ich mir noch nicht erklären. Da muß ich nochmal nachhaken. Im Allgemeinen kann man also schon sagen, daß AMD64 einen (deutlichen) Geschwindigkeitsvorteil, bei der Abarbeitung der Programme, bringt.
Mich hat hierbei neben der Ausführungsgeschwindigkeit aber noch ein zweiter Punkt interessiert, der Speicherverbrauch.


Hier kommt also der Pferdefuß. Mit einer Ausnahme war der Speicherbedarf bei AMD64 deutlich größer, meist doppelt so groß, wie bei x86. Ein weiterer Test mit Mozilla-Firefox zum Speicherbedarf ergab einen mehr als 5x so hohen Verbrauch bei AMD64 wie bei x86. Für die Praxis bedeutet das, daß der Geschwindigkeitsvorteil, von der Ausführung einzelner Programme, sehr schnell durch den immensen Speicherbedarf wieder zunichte gemacht werden kann. Wenn der Hauptspeicher voll ist, und das OS anfangen muß mit swappen, läßt sich das durch keinen Geschwindigkeitsgewinn bei der Ausführung wieder rein holen. Genau das läßt sich auch beim alltäglichen arbeiten feststellen, daß der Rechner (mit 512MB RAM) sehr schnell an die Grenze stößt und sehr träge wird. Unter Debian als 32bit-Linux war dies nicht zu beobachten. Dort waren die Reserven bei gleichem/ähnlichen Einsatz ausreichend.

Das Fazit für mich lautet damit, daß 64bit am Desktop weder notwendig, noch nützlich sind, sondern zumeist sogar kontraproduktiv. 1GB RAM mag für Spielerechner vielleicht schon normal sein, aber beim einfachen Arbeitsplatz sind sie es (noch) nicht. Mal davon abgesehen wird auch der Speicherbedarf der Spiele durch 64bit steigen, so daß dort die 1GB möglicherweise schon eng werden.

PS: Ich werde den Benchmark die nächste Tage wohl noch etwas erweitern um Video-Konvertierung und UT2004, sowie die eigentlich obligatorische Kernelcompilierung, sofern ich es endlich schaffe, unter 64bit einen 32bit-Kernel zu bauen.

Wow, da hast Du echt tolle Fleißarbeit gemacht! Zu Deinem Fazit möchte ich gerne noch etwas hinzufügen: auch wenn die AMD64-Architektur hier anscheinend nicht so den rechten "Durchbruch" bringt, so sollte das niemanden davon abhalten, den Athlon64 zu kaufen; schliesslich ist diese CPU auch ein hervorragender 32Bit-Prozessor. Gegenüber dem AthlonXP bringt er neben einer verbesserten Gesamtarchitektur die Features Cool'n'Quiet (für leisere Rechner) und auch SSE2 mit. Solche Dinge wie "transcode" rennen auf dem Athlon64 unter 32Bit-Betrieb richtig davon.

Die Software für die AMD64-Architektur gewinnt in Zukunft bestimmt auch noch an Geschwindigkeit, wenn der Compiler und die im Benchmark angesprochenen Assembler-Code-Stücke besser daran angepasst worden sind.

@Puck

hehe du warst wohl gestern vom Compilerbench (gcc{3.3;3.4;4.0} vs. ICC8.1) inspririert?

sehr schoener Ueberblick der wunderbar zeigt, dass man, wenn fuer eine Software der Umstieg auf 64Bit geplant ist, sehr genau gucken sollte ob es sich lohnt.
Fest steht ja nach einiger Zeit eines: Performancegewinn ist beim Umstieg nicht selbstverstaendlich, und Ergebnisse sollten fuer die jeweilige Software sehr genau evaluiert werden, denn das kann leicht in die Hose gehen *auf den Ramverbrauch zeig*.

Ich hoffe du konntest dem "64Bit = mehr Performance"-Wahn ein bischen entgegenwirken, und zeigen, dass die Situation ein bischen bunter ist als oft angenommen.

Ok dass hat ja überzeugt.
Aber woher kommt diese Speicherverbrauch?

P.S.: Wenn du mir schnell die Flags -ftracer -fweb erklären könntest und ob die viel Geschwindigkeit bringen wäre ich dir sehr dankbar.

http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/Optimize-Options.html

hier duerftest du eine antwort auf zumindest den teil deiner frage bekommen, was die flags bedeuten.

Original geschrieben von Tom24
Ich hoffe du konntest dem "64Bit = mehr Performance"-Wahn ein bischen entgegenwirken, und zeigen, dass die Situation ein bischen bunter ist als oft angenommen.

Zum Vergrößern anklicken....

Nun ja, die Diskussion über den Sinn von 64bit hatten wir ja schon. Es sind ja die anderen Architekturmerkmale, die dem K8 den Performancegewinn geben, also die zusätzlichen Register. Der Test hat aber auch gezeigt, daß selbst Anwendungen, die mit 64bit arbeiten (hier das Dateisystem), nicht unbedingt durch den 64bit-Modus profitieren. Wäre dem so, hätten bzip2/gzip mit file-I/O deutlich unterschiedliche Zeiten zwischen x86 und AMD64 bringen müssen. Ich nutze hier XFS, und das ist ja nun ein echtes 64bit Dateisystem.

hehe du warst wohl gestern vom Compilerbench (gcc{3.3;3.4;4.0} vs. ICC8.1) inspririert?

Zum Vergrößern anklicken....

Der Test war schon länger geplant, allerdings hat der Compilerbench wirklich den Ausschlag gegeben, das jetzt zu tun.

Aber woher kommt diese Speicherverbrauch?

Zum Vergrößern anklicken....

Das kann durchaus am gcc liegen, welcher z.Z. noch alles andere, als optimalen Code für AMD64 erzeugt. Das wird sich dann mit der Zeit zeigen, spätestens wenn WinXP64 auf dem Markt ist. Intel hat den icc ja nun auch für AMD64 fit gemacht, und wenn MS noch einen eigenen Compiler auf den Markt schmeißt, kann man da nochmal den Speicherbedarf zwischen unterschiedlichen Compilern ermitteln.

Hallo PuckPoltergeist,

danke für deine Mühe. Die Ergebnisse sind interessant.

Das nicht jedes Programm / Anwendung von 64 Bit profitiert war abzusehen. Da sind noch eine Menge Optimierungs/Portierungsarbeiten zu erledigen. Zudem steht ja in der Zukunft der Wechsel auf Dualcore CPU's ins Haus und somit auch wieder zusätzliche Optimierungs- und Portierungsarbeiten. Das ganze wird sich wohl noch einige Jahre hinziehen bis es bei den meisten Programmen so läuft wie von Anfang an erwartet.


MFG

Operations

Das Problem mit den Dua-core CPUs ist in der Windows-Welt allerdings im einiges krasser als bei anderen (skalierbaren Systemen)

*flamebait*

Ich habe gerade die Folien eines frühen Vortrags von Jan Hubicka, einem der GCC-Entwickler beim K8-Port, durchgesehen. Dort wurde die Möglichkeit eines Tiny-Models für den Speicher (32bit Pointer im 64bit Mode) angesprochen, allerdings auch verworfen (wg. Aufwand). Neben vielen Zahlen sind z.B. diese interessant (einfach mal herausgegriffen):
KDE startup from disk - 18,1% schneller
KDE startup from cache - 14,6% schneller
./configure - 4,3% langsamer

SPECfp2000 hat viel mehr von 64bit profitiert als SPECint2000. Einige Gründe (waren nicht angegeben, kann man sich aber herleiten): Int-Code nutzt viel Pointer und die kurzen Befehlslatenzen verursachen weniger Löcher in der Pipeline, die bei FP-Code viel öfter der Fall sind und mit mehr parallelisierbarem Code (dank den zusätzlichen Registern) gefüllt werden können. Ok, ich schweife ab..


Weiter zum Speicherverbrauch
konqueror: +28%
gimp: +15%
mozilla: +22%

Um diesen Mehrverbrauch zu vermeiden kann man zumindest bei Anwendungen, wo 32bit-Performanz (ja, das deutsche Wort gibt es ) und der bei 32bit nutzbare Speicher ausreichen, die 32bit-Version auch einsetzen.

Original geschrieben von Dresdenboy
Ich habe gerade die Folien eines frühen Vortrags von Jan Hubicka, einem der GCC-Entwickler beim K8-Port, durchgesehen. Dort wurde die Möglichkeit eines Tiny-Models für den Speicher (32bit Pointer im 64bit Mode) angesprochen, allerdings auch verworfen (wg. Aufwand). Neben vielen Zahlen sind z.B. diese interessant (einfach mal herausgegriffen):
KDE startup from disk - 18,1% schneller
KDE startup from cache - 14,6% schneller
./configure - 4,3% langsamer

Zum Vergrößern anklicken....

Das "fatale" an diesen Benchmarks ist, daß sie eigentlich nie im Gesamtkontext gesehen werden. Wenn durch den Mehrverbrauch der Speicher voll ist (die wenigsten werden ja beim Umstieg auf AMD64 gleich auch den Speicher aufrüsten), nützen all die schönen Geschwindigkeitsgewinne nichts mehr, weil das OS swappen muß.

Weiter zum Speicherverbrauch
konqueror: +28%
gimp: +15%
mozilla: +22%

Zum Vergrößern anklicken....

Soll das noch angegangen werden, oder wird sich daran nicht mehr groß was ändern?

Um diesen Mehrverbrauch zu vermeiden kann man zumindest bei Anwendungen, wo 32bit-Performanz (ja, das deutsche Wort gibt es ) und der bei 32bit nutzbare Speicher ausreichen, die 32bit-Version auch einsetzen.

Zum Vergrößern anklicken....

Das ist zum Teil nicht wirklich praktikabel, weil man sonst sehr schnell einen ziemlichen Mischmasch von 32bit und 64bit Software auf dem Rechner hat, was natürlich auch die Platte zumüllt, und erstmal verwaltet werden will. Ich bräuchte z.B. eine 32bit und eine 64bit Version von X11, wenn ich KDE in 32bit nutzen wollte. Das frißt nicht unerheblich Speicher, erst recht, wenn sowohl 32bit X11-Applikationen laufen, wie 64bit.

Original geschrieben von PuckPoltergeist
Das "fatale" an diesen Benchmarks ist, daß sie eigentlich nie im Gesamtkontext gesehen werden. Wenn durch den Mehrverbrauch der Speicher voll ist (die wenigsten werden ja beim Umstieg auf AMD64 gleich auch den Speicher aufrüsten), nützen all die schönen Geschwindigkeitsgewinne nichts mehr, weil das OS swappen muß.

Zum Vergrößern anklicken....

Wäre mir mit 256MB (wie ich sie im XP1800+ hatte) sicher auch passiert. Aber es ist sicher nicht so tragisch für die Gesamtsituation:

Wohl nicht mal 1% der verkauften A64 gehen an Leute, die ihren alten Rechner aufrüsten. Die dabei den Speicher nicht aufrüsten, werden noch viel weniger sein. Auch nutzen noch gar nicht soviel A64-Besitzer ein 64bit-OS. Und mittlerweile sind 512MB bis 1GB RAM in so einem System Standard. Ich brauchte schon deshalb mehr RAM, weil ich ab und zu auch Java im 32bit-OS nutze, so wie hier auf Arbeit auch.

Jetzt darf man zur Einschätzung der Problematik aber nicht den Fakt "20MB gesamter Speicherverbrauch" sehen, sondern z.B. "8MB zusätzlicher Speicherverbrauch bei der 64bit-Anwendung". Somit benötigt diese App bei 1GB RAM nicht einmal 1% mehr Speicher. Zusammen mit KDE, Kernel, Treibern und sonstigem im 64bit-Mode laufenden Code, ist die gesamte Differenz auch nicht so dramatisch.

Original geschrieben von PuckPoltergeist
Soll das noch angegangen werden, oder wird sich daran nicht mehr groß was ändern?

Zum Vergrößern anklicken....

Wohl nicht. Wenn man damit fertig wäre (die ganzen Bibliotheken usw. müssen auch für diesen Modus vorhanden sein, wie auch entspr. Kernelmodifikationen), sind vielleicht schon 2GB RAM Standard.

Original geschrieben von PuckPoltergeist
Das ist zum Teil nicht wirklich praktikabel, weil man sonst sehr schnell einen ziemlichen Mischmasch von 32bit und 64bit Software auf dem Rechner hat, was natürlich auch die Platte zumüllt, und erstmal verwaltet werden will. Ich bräuchte z.B. eine 32bit und eine 64bit Version von X11, wenn ich KDE in 32bit nutzen wollte. Das frißt nicht unerheblich Speicher, erst recht, wenn sowohl 32bit X11-Applikationen laufen, wie 64bit.

Zum Vergrößern anklicken....

Funktioniert 64bit-Applikation oder -KDE nur mit einem 64bit-X11 bzw. eine 32bit-App oder -KDE nur auf 32bit-X11?

Original geschrieben von Dresdenboy
Wäre mir mit 256MB (wie ich sie im XP1800+ hatte) sicher auch passiert. Aber es ist sicher nicht so tragisch für die Gesamtsituation:

Wohl nicht mal 1% der verkauften A64 gehen an Leute, die ihren alten Rechner aufrüsten. Die dabei den Speicher nicht aufrüsten, werden noch viel weniger sein. Auch nutzen noch gar nicht soviel A64-Besitzer ein 64bit-OS. Und mittlerweile sind 512MB bis 1GB RAM in so einem System Standard. Ich brauchte schon deshalb mehr RAM, weil ich ab und zu auch Java im 32bit-OS nutze, so wie hier auf Arbeit auch.

Jetzt darf man zur Einschätzung der Problematik aber nicht den Fakt "20MB gesamter Speicherverbrauch" sehen, sondern z.B. "8MB zusätzlicher Speicherverbrauch bei der 64bit-Anwendung". Somit benötigt diese App bei 1GB RAM nicht einmal 1% mehr Speicher. Zusammen mit KDE, Kernel, Treibern und sonstigem im 64bit-Mode laufenden Code, ist die gesamte Differenz auch nicht so dramatisch.

Zum Vergrößern anklicken....

Kleines Mißverständnis. Ich meinte, daß Leute sich einen AMD64 holen, und erstmal darauf ein 32bit OS einsetzen, mit 32bit Software. Da reichen auch 512MB heute noch ganz gut aus. Wenn dann auf 64bit Software geupdatet wird, werden die 512MB verdammt knapp. Ich sehe das hier bei mir. Der Rechner verhält sich teilweise sehr träge. Ich kann mich darauf verlassen, daß wenn ich dann nachsehe, er bei swappen ist. Das war unter 32bit lange nicht so extrem.

Wohl nicht. Wenn man damit fertig wäre (die ganzen Bibliotheken usw. müssen auch für diesen Modus vorhanden sein, wie auch entspr. Kernelmodifikationen), sind vielleicht schon 2GB RAM Standard.

Zum Vergrößern anklicken....

Hm ok, hatte ich schon fast erwartet.

Funktioniert 64bit-Applikation oder -KDE nur mit einem 64bit-X11 bzw. eine 32bit-App oder -KDE nur auf 32bit-X11?

Zum Vergrößern anklicken....

Da Qt, welches KDE zu Grunde liegt, gegen die Xlibs gelinkt wird, und KDE wiederum gegen Qt, funktioniert es nur, wenn entweder alles 32bit oder 64bit ist. Will ich nun KDEin 32bit nutzen, und habe noch 64bit Programme für X11, wie z.B. UT2k4 (welches ja schon einen deutlichen Vorteil von 64bit hat), brauche ich X11 in beiden Versionen, sowie sämtliche Software, von der X11 abhängt. Das ist am Ende nicht wenig, was da doppelt installiert werden muß. Zusätzlich ist keine der Linuxdistributionen (die AMD64 unterstützen) dafür ausgerichtet, einen Großteil der Major-Apps als 32bit zu installieren. Die haben zwar alle einen Kompatibilitätsschicht (32bit), welche aber nur dafür gedacht ist, einen kleine Teil (propritärer) Software laufen zu lassen, welche man nicht als 32bit bekommt. Das wilde mischen der Software ist da eigentlich nicht vorgesehen.

So, habe noch die Ergebnisse aus demut2k4-Test hinzu gefügt. Wie zu sehen, profitiert auch dieses von AMD64, wenn auch nicht überragend. Den Speicherverbrauch habe ich nicht mit angegeben, weil ich den während des Benchmarks bis jetzt nicht überprüfen konnte. Ein kurzer Test mit ONS-Crossfire (Spiel kurz gestartet) hat aber das schon bekannte Bild bestätigt. Auf x86 hat sich UT2k4 etwas unter 250MB gegönnt, als AMD64-Version wollte es fast 600MB.

Test mit mencoder und avidemux folgt, sobald ich etwas Zeit dazu habe.

ut2004demo,

x86 360 MiB
amd64 405 MiB.

Original geschrieben von Desti
ut2004demo,

x86 360 MiB
amd64 405 MiB.

Zum Vergrößern anklicken....

Hm, also bei amd64 bin ich mir doch sehr sicher, da hatte ich gestern nochmal nachgesehen. Direkt nach dem laden der Karte, war der Speicherbedarf bei rund 600MB. Für die x86-Version werde ich nochmal nachmessen.

Original geschrieben von PuckPoltergeist
Hm, also bei amd64 bin ich mir doch sehr sicher, da hatte ich gestern nochmal nachgesehen. Direkt nach dem laden der Karte, war der Speicherbedarf bei rund 600MB. Für die x86-Version werde ich nochmal nachmessen.

Zum Vergrößern anklicken....

Es geht nur um die Relation, die absoluten Werte sind ja eh je nach Konfiguration und Map unterschiedlich.

Original geschrieben von Desti
Es geht nur um die Relation, die absoluten Werte sind ja eh je nach Konfiguration und Map unterschiedlich.

Zum Vergrößern anklicken....

Ich weiß, deswegen habe ich auch mit der gleichen Map "gemessen", jeweils direkt nach dem sie geladen wurde. Kann sein, daß sich bei x86 ein Fehler eingeschlichen hat, zumal sich der Rechner dann kurz danach auch aufgehangen hat.
Ich werde mir das auf jeden Fall nochmal ansehen.

So, da ich das bis jetzt nicht geschrieben habe, und um (weiteren) Missverständnissen vorzubeugen, der Speichermehrverbrauch der 64bit-Anwendungen kommt durch den Datenbereich. Der Zuwachs im Codebereich ist meist marginal.

Schöne Benchmarks , einen Krittikpunkt hab ich allerdings :

Der Speicherverbrauch bei AMD64 wird praktisch nie mehr als 2mal so hoch sein wie bei IA32, bei UT und Firefox muss bei der Messung irgendwas schief gelaufen sein.

Bei Firefox könnte ich mir den Cache im RAM vorstellen, bei UT2k4 weis ich es ehrlich gesagt auch net.


Was mich mal interessieren würde: Worauf ist eigentlich der int gestellt? int ist an sich ja kein eindeutig definierter Datentyp, es gibt short ints, long ints und long long ints. So wie ich das bisher mitbekommen hab wird int auf den für die Architektur üblichen Wert gesetzt, also 32bit bei IA32, 16bit bei IA16 usw. - wenn der bei AMD64 auf 64bit steht wird dort massenweise Speicher verschwendet, der int ist ja sozusagen die am häufigsten genutzte Variable.

Original geschrieben von i_hasser
Schöne Benchmarks , einen Krittikpunkt hab ich allerdings :

Der Speicherverbrauch bei AMD64 wird praktisch nie mehr als 2mal so hoch sein wie bei IA32, bei UT und Firefox muss bei der Messung irgendwas schief gelaufen sein.

Bei Firefox könnte ich mir den Cache im RAM vorstellen, bei UT2k4 weis ich es ehrlich gesagt auch net.

Zum Vergrößern anklicken....

Ich weiß es ehrlich gesagt auch nicht. top und ps zeigen mir aber definitv diesen Speicherverbrauch an. Was ich mir vorstellen kann, sind Zeiger (von 32bit auf 64bit gewachsen) sowie das alignment. Dass das so viel ausmacht, glaube ich zwar auch nicht, aber ich kann auch nur das hinschreiben, was angezeigt wird.

Was mich mal interessieren würde: Worauf ist eigentlich der int gestellt? int ist an sich ja kein eindeutig definierter Datentyp, es gibt short ints, long ints und long long ints. So wie ich das bisher mitbekommen hab wird int auf den für die Architektur üblichen Wert gesetzt, also 32bit bei IA32, 16bit bei IA16 usw. - wenn der bei AMD64 auf 64bit steht wird dort massenweise Speicher verschwendet, der int ist ja sozusagen die am häufigsten genutzte Variable.

Zum Vergrößern anklicken....

Nein, int ist 32bit gebliegen. Was auf 64bit verdoppelt wurde, sind Zeiger. Ist auch ein hübscher Fallstrick bei Portierungen, weil da bei Konvertierungen die Breite nicht mehr stimmt, und unter Umständen Daten abgehackt werden.

http://www.x86-64.org/documentation/abi-0.95.pdf