32 vs 64 Bit - wie würdet Ihr vergleichen?

Ich habe hier auf meinem Laptop parallel:

1x Debian Sarge (32Bit, i386)
1x Kanotix 2005-3 (64Bit, x86_64)

Ich möchte nun empirisch überprüfen, wo die eigentlichen Geschwindigkeitsunterschiede sind.
Dazu möchte ich nicht mit Stoppuhr neben einem Kompiliervorgang sitzen, sondern am liebsten ein Benchmark-Programm verwenden.

Kennt jemand da etwas?

nbench, ubench
die sind aber schon aaaaallt und für 64bit gibt es das auch nicht, da musst du selbst kompillieren

ich würde auch irgend ein brenchmark besorgen...

Man kann doch auch mit dem time-Befehl herausfinden wie lange ein Vorgang braucht. Einfach mal was großes compilen, aber dann mit 'time make'.
Allerdings kann man sicher nicht die gesamte Leistungmessung auf Compilevorgänge stützen, das sehe ich genauso.

Michael schrieb:

Ich habe hier auf meinem Laptop parallel:

1x Debian Sarge (32Bit, i386)
1x Kanotix 2005-3 (64Bit, x86_64)

Ich möchte nun empirisch überprüfen, wo die eigentlichen Geschwindigkeitsunterschiede sind.
Dazu möchte ich nicht mit Stoppuhr neben einem Kompiliervorgang sitzen, sondern am liebsten ein Benchmark-Programm verwenden.

Kennt jemand da etwas?

Zum Vergrößern anklicken....

schau mal ob du hier was passendes findest

Der Time-Befehl ist sicher eine gute Idee. Kompilieren oder einfach mal große Programme starten, dafür wäre es aber eventuell besser, wenn die gleiche Distribution, nur eben einmal in 32bit und 64bit, benutzt wird. Eventuell benutzen die verschiedenen Distributionen ja andere Compilereinstellungen um die rpms zu erstellen, das könnte dann nämlich unterschiedliche Ergebnisse liefern.
Man könnte auch einfach mal gucken wieviel Frames glxgears bringt
Spielebenchmarks von Quake etc. würden nur den Unterschied des Kernels und der Treiber darstellen, da die Spiele selber nicht in 64bit vorliegen. Vielleicht gibts da ja trotzdem eine Überraschung
MP3s codieren könnte man auch noch mal testen.

mfg
aki

Ich hab einfach mal mit time + zip (apt-get install zip) eine fies gepackte ISO-Datei von Kanotix gezippt.

Hier die Ergebnisse:

War das Ergebnis vorhersehbar?

-=TeuTaTes=- schrieb:

schau mal ob du hier was passendes findest

Zum Vergrößern anklicken....

Boah, die Qual der Wahl.

bedingt. das packen einer iso ist vielweniger von der cpu und dem speicher abhängig als vielmehr von der puren io-leistung. da aber in beiden fällen die gleiche iosysteme drunterliegen, musstest du nahezu zwangsläufig zu diesem ergebnis kommen, desweiteren ist ein integerproblem. bei solchen bietet die architektur nicht so die großen vorteile.
einen echten unterschied dürftest du daher eher mit cpu lastigen programmen erhalten. hier wirst du aber auch feststellen, dass die ergebnisse je nach anwendung variieren, da die eine anwendung durch die zusätzlichen register beschleunigt wird (insbesondere in der fpu. ich sach nur stack vs. freiewählbare register) und die andere wegen starker zeigerlastigkeit ein höheres io aufkommen hat und so langsamer wird.

ghorst schrieb:

bedingt. das packen einer iso ist vielweniger von der cpu und dem speicher abhängig als vielmehr von der puren io-leistung. da aber in beiden fällen die gleiche iosysteme drunterliegen, musstest du nahezu zwangsläufig zu diesem ergebnis kommen.

Zum Vergrößern anklicken....

Ich habe nebenbei gkrellm laufen lassen und mir die Grafiken bezüglich CPU-Auslastung, hda-Transfer etc. anzeigen zu lassen. Bottleneck war hier eindeutig die Festplatte.
Was ich aber festgestellt habe ist, dass "apt-get" wesentlich flotter vonstatten geht. Aber wirklich messbar ist das nicht.

kannst ja mal fette 3d-grafik ohne beschleunigung sonder nur mit mesa ausprobieren. da müsste die 64bit architektur eigentlich eine richtigen vorsprung rausholen. (wobei ich nicht genau weiß wie sauber die bei mesa gearbeit haben und damit die anzahl der float rechnungen reduziert haben, was natürlich den vorsprung wider dahin schmelzen lassen würde )

vergleichen kann man das momentan meines erachtens nicht wirklich, der code mag zwar in 64bit kompiliert worden sein, trotzdem sind viele sachen von grund auf aber auf 32bit ausgelegt, am besten profitiert man da bei datenbankservern, die gehen unter 64bit richtig ab

die normale software die du momentan so nutzt, wird viel schneller sein, manchmal sogar langsamer...
hatte da auch mal irgendwann mal so nen test gesehen, nur wo...

(Wenn Bombwurzel das liest, dann wird er mir heftigst widersprechen )

Der Hauptunterschied eines 64Bit Systems gegenüber einem 32Bit System ist, dass 2^64 Byte Hauotspeicher adressiert werden kann (theoretisch), anstelle von 2^32 Byte. Das ist 4 Milliarden mal so viel.

Ein solches System wird aber nicht schneller, nur weil auf der Packung 64 anstelle 32 steht.

Interessanter ist da aber der interne Datenbus. Also die Größe eines Datenblocks, die der Prozessor in einem Stück be-/verarbeiten kann.
Ich mag mich täuschen, aber schon die (Ur)Pentiums konnten schon mit 64 Bit großen Blöcken umgehen. Es waren aber 32 Bit Prozessoren!

Wie groß der prozessorinterne Bus bei den heutigen AMd/Intel 64Bit-fähigen CPUs ist weiß ich nicht.

Wenn diese Prozessoren schneller sind als ältere liegt es aber hauptsächlich daran, dass das gesamte Design der CPU besser geworden ist.
Vergleich: ein 40 Jahre alter PKW Motor ist trotz gleicher Leitung (KW) nicht so effizient wie ein aktueller Motor selber Leistung.

Auf einem normalen PC wird wohl kein relevanter Unterschied messbar sein.
Mit "relevant" meine ich "Der Standard-PC-User spürt etwas".

@boron
das ist so schon richtig. allerdings gibt es so schon datenblöcke die in 32bit immer aufgeteilt werden müssen und somit 2 zyklen belegen, was mit einem 64bit prozessor in einem zyklus verarbeitet werden kann. allerdings muss die software noch optimiert werden dass sie die 64bit busbreite immer ausnutzt. daher ist das resultat sehr unterschiedlich. während einige kaum merkbar sind ist bei anderen deutlich der unterschied spürbar. leider ist das eher selten.

ein bei sochen sachen gerne unter tisch geworfener fakt ist, dass für die adressierung der doppelte platz im bus gebraucht wird...
was die optimierung auf 64bit angeht, dieses ist bei manchen programmen weder sinnvoll noch möglich. wenn man die 64bit speicher nicht braucht, verbraucht jeder zeiger völlig sinnlos den doppelten speicher (er reserviert nicht die doppelte menge, sondern verbraucht die doppelte. was bei so manch einer kleineren strukturen oder klassen mal schnell einen erheblichen anteil an speicherverbrauch darstellen kann). aus meiner sicht gibt es zur zeit keinen sinnvollen grund mit dem desktop auf 64bit umzusteigen, da die speicherprobleme hier nicht existieren und es mit dem 36bit speicheradressierung sogar hierfür einen gangbaren weg gibt. (ich weiß selbst das die programmierung auf os-ebene damit nicht lustig ist.) auf servern ist das was anderes aber auch da muss mal ernsthaft schauen, wer braucht eigentlich mehr als 3gb speicher (1gb fällt bekanntlich wegen des pci's flach) bzw. irgendwas über 30gb dank 36bit adressierung. da fallen auch schon wider diverse systeme raus. ich weiß das immer noch eine reihe von rechner überbleiben nur ist das dann halt eine sehr überschaubare liste.
was für den umstieg spricht ist nur die neue architektur intern, also die menge an neuen registern in der cpu intern und die bessere fpu. (das sind die beiden punkte die wirklich für leistung sorgen, nicht die 64bit.) nur diese design dinge könnte man eigentlich auch der 32bit serie zu kommen lassen. was wahrscheinlich hier einen größeren leistungsvorteil bringen würde, da die aufwendigere adressierung wegfallen würde. nur wahrscheinlich würd das nicht passieren, da es dann keinen sinnvollen grund mehr gebe die neue 64bit zu verwenden.

Ich sehe aber, dass bei x86_64 zumindest auf die Architektur passende Pakete erstellt werden. Mein Sarge baut noch auf i386. An und für sich kein Problem. Ich erinnere mich aber mal einen Athlon A 1200MHz gehabt zu haben. Wenn ich für den mplayer kompilierte, mußte ich auf Athlon optimieren, weil ansonsten die Video-Wiedergabe ruckelte wie doll. Das war das letzte Mal, dass mir eine Architektur-Optimierung notwendige Verbesserung brachte.
Alles in allem ist das Arbeiten (Starten von Programmen etc.) genau so schnell/langsam wie auf der i386-Architektur.
Das sagt mir jedenfalls meine gefühlte Erfahrung.

x86_64 hat aber immer noch viele Nachteile, was die Verfügbarkeit von Programmen und Treibern angeht. Es gibt zum Beispiel immer noch keinen vernünftigen Shockwave Flash Player ;-) - aber das wird langsam...

Flash ist auch weird und will niemand.

MfG

Michael schrieb:

Das war das letzte Mal, dass mir eine Architektur-Optimierung notwendige Verbesserung brachte.

Zum Vergrößern anklicken....

das war keine neue architektur sondern ein neuer prozessor. beim x86_64 hat sich wie schon erwährt die art und anzahl der normalen register und das komplette verhalten der fpu verändert. man könnte sogar fast sagen, da gibt es zwei architekturen die zufällig einen ähnlichen namen haben und in einem gewissen rahmen die selben befehle habe. das x86_64 zufällig 64bit ist quasi ein bonus bei einer architektonischen revolution.

marcelcedric schrieb:

Flash ist auch weird und will niemand.

MfG

Zum Vergrößern anklicken....

Flashblock ist das erste, was ich nach Firefox installiere
Aber leider greifen immer mehr auf Flash zurück (Menüs etc.). Die reine Grafik funzt meist auch, aber sobald Ton dazu kommt, gehts in die grütze. Man hört dann nur noch ein Stottern (tack tack tack tack tack), welches sich nur durch wechseln der Seite oder minimieren des Tons (inkl. XMMS) abstellen läßt
Beispiel: SuperDuperSumos

Wäre SuperPi eine Vergleichsmöglichkeit für dich?

*klick*

Oder gehts dir nur ums kompalieren?

Alternativ natürlich SETI...

OT

Michael schrieb:

Aber leider greifen immer mehr auf Flash zurück (Menüs etc.). Die reine Grafik funzt meist

Zum Vergrößern anklicken....

dann wollen die betreiber der seiten nicht, dass man sie besucht. lass es einfach . man kommt auch ohne gut zurecht. hab' noch nie unter linux 'nen flashplayer installiert und lebe immer noch. hab' auch nicht den eindruck, dass mir dadurch etwas wesentliches engangen ist.