Hab mal da ne Frage...

Zitat von gandro

Wir reden hier allerdings von Kilobytes.

Das einzige, was grösser wird, sind Pointer, die anstatt von 4 dann 8 Bytes belegen. Und massiv (im Sinne der Menge) zur Anwendung kommen Pointer eh nur in objektorientierten Sprachen, und dort hat man in der Regel auch sonst einen gewissen Overhead.

Nachtrag: Gut, Integer werden je nach dem auch grösser, aber massiv zum Einsatz kommen die nirgendwo.

Hinzukommt dass du auch immer 64bit lesen tust, auch wenn nur 32 nötig wären. Bei vielen kleinen Operatoren (Kleinvieh macht auch Mist) könnte das evtl schon ins Gesicht fallen. Mit Betohnung auf könnte, ich möchte mich hier nicht festlegen. Man hört unterschiedliche Aussagen (allerdings selten qualifizierte) und letztendlich kommt es auf den Einsatzzweck an. Wenn ich mir ein Embeddedsystem zusammenstelle, kann es schon einen Unterschied darstellen, ob nun der Kernel ein paar MB grösser oder kleiner ist und jede Applikation ein paar KB mehr oder weniger frisst. (OK, schlechtes Beispiel, für ein Embeddedsystem benutzt man nicht unbedingt eine 64bit CPU, aber ich glaube es sollte klar sein was ich hinnaus will: Grundsätzliche Aussagen sind grundsätzlich falsch.)

Was bisher vergessen wurde: Die neue 64bit-Architektur bringt mehr, als nur 64bit und damit mehr Speicher:

Standardmässiges SSE, mehr Register, keine Speichersegmentierung mehr. Das NX-Bit kommt auch dazu, wobei das meines Wissens im 32bit-Modus auch verfügbar ist.

Das sind alles Features, die im 32bit-Modus nicht vorhanden sind, auch wenn man einen 64bit-Prozessor verwendet. Gerade wenn der Compiler SSE vorraussetzen kann (was 32bit-Programme selten tun, weil ein Pentium III oder ein Athlon-XP dann als Mindestanforderung zählt), kann er viele Dinge spürbar optimieren.

Die zusätzlichen Register und die weggefallene Segmentierung bringen ebenfalls spürbare Vorteile, auch wenn mir da das Fachwissen fehlt, um das jetzt genauer zu erkären.

Im Überigen: Zwar benötigt ein 64bit-Integer 4Byte mehr Speicher, kann dafür vom Prozessor schneller verarbeitet werden, als ein gleichwertiger long-Wert im 32bit-Modus.

Nachtrag: "Hinzukommt dass du auch immer 64bit lesen tust, auch wenn nur 32 nötig wären. Bei vielen kleinen Operatoren (Kleinvieh macht auch Mist) könnte das evtl schon ins Gesicht fallen." - Warum sollten 32bit-Operatoren schneller sein, wenn die Anbindung eh 64bit ist? Ein 64bit-Prozessor kann eine 64bit-Anweisung genau so schnell aufnehmen wie ein 32bit-Prozessor seine 32bitige Anweisung.

Mh ... dann scheint wohl 64bit tatsächlich noch einige Vorteile zu bieten ... wenn Hardware und verwendete Software damit problemlos klarkommen.

Wenn aber alle Zugriffe eh mit doppelter Breite stattfinden, selbst wenn bei den Daten auch 32 Bit ausreichend breit wäre, nutzen aber x MB Cache nur noch die Hälfte, sodaß die Missrate steigt, was performance kostet.

Naaajaa. Weniger Speicher frisst ja nur dann (messbar) Performance, wenn zuwenig Speicher vorhanden ist, und da glaube ich reichen die 12 MB moderner Prozessoren dann doch aus. Wobei das wieder ein Bereich ist, wo ich leider zu wenig Fachwissen verfüge - da vertraue ich dann allerdings wieder den Herstellern, schliesslich ist der x86er nicht der erste Prozessor, der erfolgreich seine Bitzahl verdoppelt hat.

Zitat von gandro

... schliesslich ist der x86er nicht der erste Prozessor, der erfolgreich seine Bitzahl verdoppelt hat.

Das 64bit schlecht ist sagt auch niemand. (Bei der SPARC-Archidektur wird ja seit Uhrzeit 64bit verwendet.) Ich frag mich einfach ob es nicht gewissen Szenarien 32bit der 64bit-Archidektur performancemässig überlegen ist.

Zitat von chessboi

Ich frag mich einfach ob es nicht gewissen Szenarien 32bit der 64bit-Archidektur performancemässig überlegen ist.

Ja, das ist schon eine berechtigte Frage, die ich auch grad nicht zu beantworten weiss (Prozessorkunde gehört zu den Dingen, die ich mir unbedingt noch aneignen will).

Zumindest gibt es Szenarien, wo 64bit wegen der Breite Vorteile bietet: So ein 32bit-Integer ist schon seit Jahren zu klein, damit kann man nur Zahlen bis 4 Milliarden bzw. 4 Gigabyte ansprechen, mit intelligenten Design geht zwar die Adressierung von mehr als 4GB durchaus (wobei man bei Festplatten die 4GB meistens einfach multipliziert, und dann jeweils bei 8, 32 und 128 GB Probleme bekommen hat (demnächst bei 2TB bei Systemfestplatten)), aber Rechnen lässt sich mit solchen Zahlen auf einem 32bit einfach nicht effizient.

wird spätestens nach Windows 7 eh uninteressant.
Wofür auch 32bit noch wirklich supporten?
Hat man im Jahr 2000 noch wirklich 16 bit unterstüzt? ne!

Zitat von Världer

Hat man im Jahr 2000 noch wirklich 16 bit unterstüzt? ne!

Aber ja, WIN-Me (ein 16/32-Bit-Hybrid) kam in 2000 heraus, und solange die aktuell verfügbaren 32-Bit-Windowsen noch das 16-Bit-Subsystem sogar incl. DOS-Emulation haben, kann man wohl noch von Unterstützung sprechen. Erst in den 64-Bit-Versionen wurden die 16-Bit-Subsysteme (sowohl WIN16 als auch DOS) ersatzlos entfernt.

Zitat von Igor Todeshure

Wenn aber alle Zugriffe eh mit doppelter Breite stattfinden, selbst wenn bei den Daten auch 32 Bit ausreichend breit wäre, nutzen aber x MB Cache nur noch die Hälfte, sodaß die Missrate steigt, was performance kostet.

Haut mich, dass ich den Thread nochmals ausgrabe, aber bei Nachforschungen für den IA-64-Thread bin ich auf dieses PDF hier gestossen: http://www.fefe.de/itanic-hammer.pdf

Ich versteh davon zwar wie gesagt nicht die Hälfte, aber es geht auf Seite 8-15 um AMD64 (aka. Hammer). Unter anderem auch um 64bit-Adressierung: Man übergibt dem Prozessor bei AMD64 nicht die vollen 64bit-breiten Adressen zusammen mit den Instruktionen, sondern kurze, aber relative (32bit Breite) Adressen (auch ein Feature von AMD64 was x86 nicht hat). Man bläht also den Code nicht auf.