64 Bit

wolfsbein

Jerseymac
Registriert
29.06.05
Beiträge
448
Da bist Du nicht alleine... ich denke mal, dass er sich vertippt hat.

Hat er nicht. Seine Aussage bezog sich auf die Auslastung des Arbeitsspeichers, der beim Poster bereits mehrere GB betraegt. Da kommt einiges dazu, wenn sich jede Referenz und die meisten primitiven Datentypen in der Groesse verdoppeln.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Nein, das ist bei den meisten CPU-Plattformen so. Bei einigen CPUs wurden bei der Definition der 64Bit Umgebung eine Erweiterung der ISA vorgenommen, so daß der Compiler hier mehr optimieren kann (das triftt auf IA32 vs. IA32-64 zu). Allgemein gilt aber, daß Programme im 32Bit Modus wegen der kleineren Datentypen etwas schneller sind, wenn die CPU dieselbe ISA für 32bit und 64Bit Modus verwendet. Das trifft auf MIPS und UltraSPARC zu,bei HP-PA gibt es ebenfalls eine andere ISA im 64Bit Modus.

Richtig schlimm ist es bei IA64, da gibt es einen Hardware Emulator für IA32 Code, der absolut bescheiden ist. Nativ arbeitet eine IA64 CPU nur im IA64 Modus. Aber das ist die große Ausnahme.

Der PPC ist von Beginn an eine 64-Bit-__Architektur__ mit einem 32-Bit-Subset. Daher laufen 32-Bit-Programme auf 64-Bit-PPC-CPUs im 32-Bit computation mode nur unwesentlich langsamer als 64-bittige Programme; sie können die Hardware beinahe ebenso ausreizen.
Bei Intel Core 2 Duo ist das anders: Dort stehen 64-Bit-Programmen zusätzliche Register zur Verfügung, die 32-Bit-Programme nicht verwenden können. Daher laufen 64er Programme auf dem Core 2 Duo schneller als ihre 32er Kollegen.

Der Itanium ist eine völlig andere Geschichte. Er unterstützt zwei vollkommen artverschiedene Instruktions-Familien: Seine eigene (VLIW / EPIC) und eine _emulierte_ und darum langsame vom x86 (CISC).
 

Tengu

Apfel der Erkenntnis
Registriert
05.02.07
Beiträge
721
Mhh.... 64 Bit auf Linux sind meist leicht arbeitsam. Ob OS X das nötig vereinfachen kann und alte Anwendungen kompatibel bleiben, wird sich zeigen.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Wie Du zum ungewöhnlichen Schluß kommst, 32Bit Software würde auf einem 32/64Bit Prozessor langsamer laufen als 64Bit Software für die gleiche ISA.

Beispiel für G5:
Wenn ein 32-Bit-Programm mehr als 4GB Speicher nutzen will, dann muß es verschiedene Speicherfenster verwenden, zwischen denen es mit mmap() und munmap() wechselt. Für 64er Programme macht das _komplette_ Paging der OS X-Kernel.

Beispiel für Core 2 Duo:
Den 32er Programmen stehen dort weniger Register zur Verfügung als den 64ern.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Mhh.... 64 Bit auf Linux sind meist leicht arbeitsam. Ob OS X das nötig vereinfachen kann und alte Anwendungen kompatibel bleiben, wird sich zeigen.

Auf OS X die passende Compiler-Option verwenden und das Fat-Binary läuft mit allen Architekturen, weil für jede ein Executable im "Universal" Binary enthalten sein kann: x86-32, x86-64, PPC-32, PPC-64. Ist so leicht, wie einem Baby den Schnuller zu klauen.
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.057
Beispiel für G5:
Wenn ein 32-Bit-Programm mehr als 4GB Speicher nutzen will, dann muß es verschiedene Speicherfenster verwenden, zwischen denen es mit mmap() und munmap() wechselt. Für 64er Programme macht das _komplette_ Paging der OS X-Kernel.
Das hat aber relativ wenig mit der CPU zu tun, sondern mit der Anwendung von bestimmten Softwaretechniken, um die Unzulänglichkeiten einer Laufzeitumgebung zu umgehen. Solche Krücken halte ich seit der Einführung von 32Bit Systemen für nicht mehr Zeitgemäß. Es wurden rechtzeitig neue Rechner in den Markt eingeführt, für die die 64Bit Adreßraum brauchten. Selbst auf dem Desktop waren die CPUs rechtzeitig verfügbar. Es ist schon ärgerlich, daß MS und Apple sich so viel Zeit gelassen haben ihre OS auf 64Bit umzustellen. OSF/1 V1.2 (1992) für Alpha wurde schon vor Ewigkeiten auf den Markt gebracht, genauso wie der MIPS R4000 (1991).
Beispiel für Core 2 Duo:
Den 32er Programmen stehen dort weniger Register zur Verfügung als den 64ern.
Da werden zwei verschiedene ISAs genutzt.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Das hat aber relativ wenig mit der CPU zu tun, sondern mit der Anwendung von bestimmten Softwaretechniken, um die Unzulänglichkeiten einer Laufzeitumgebung zu umgehen. ...

Wenn ein Programm nur 32-bittig ist, dann muß es halt so einen Eiertanz machen, um mehr als 4 GB zu nutzen. Die Laufzeitumgebung kann ja schlecht die fehlenden Bits raten, oder?
Wenn man es (zusätzlich oder ausschließlich) als 64-Bitter compiliert, dann braucht man den Eiertanz nicht dafür.
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.057
Wenn ein Programm nur 32-bittig ist, dann muß es halt so einen Eiertanz machen, um mehr als 4 GB zu nutzen.
Wenn man die falsche Softwareplattform für die eigenen Anforderungen auswählt, dann muß man auch den Preis dafür zahlen. Da ich 64Bit von UNIX kenne, kann ich über so ein Gefrickel nur den Kopf schütteln.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Was ist denn am 64-Bit-Leopard frickelig?

Nachtrag: Es ging ja darum, zu zeigen, warum 32er Apps langsamer sein können als 64er trotz "gleicher ISA". Man konnte auch unter Tiger schon in den notwendigen, typischen Bereichen 64er Apps schreiben. So war auch Tiger eine super Plattform insbesondere für 64er Unix-Apps.
 
Zuletzt bearbeitet: