MacBook 32 bit oder 64 bit

[Obithereal]

hab in mehreren foren auch schon gelesen das der akku länger hält und temperatur der cpu niedriger is.

Schnappszahl: 33

 

[Thaddäus]

Halte ich für ein Gerücht, aber wer es glauben mag...

Mein XServe kann dank 64-Bit nun auch Kaffe kochen...

 

[Kaffeeschlampe]

Jetzt bin ich aber etwas verwirrt...

ich habe ein System (MacBook 5,1) das 64-Bit tauglich ist, eine OS Hersteller, der propagiert, das 64-Bit schöner/besser/toller ist und im Endeffekt wird trotzdem per Firmware auf 32-Bit limitiert. Der 6&4 Trick bzw. die SW helfen hierbei nicht.

Und zur Krönung liefert Apple auch noch 64-Bit Windows 7 Treiber fürs BootCamp. Da klappt's denn auch mit den 64-Bit Kernel.

KaffeeSchlampe

 

[StephanG]

ich habe ein System (MacBook 5,1) das 64-Bit tauglich ist, eine OS Hersteller, der propagiert, das 64-Bit schöner/besser/toller ist und im Endeffekt wird trotzdem per Firmware auf 32-Bit limitiert. Der 6&4 Trick bzw. die SW helfen hierbei nicht.

64-Bit ist ja auch schöner, besser und toller... und genau aus dem Grund gibt es 64-Bit schon seit Ewigkeiten mit Leopard. System läuft in 64-Bit, die Applikationen können in 64-Bit laufen, Applikationen können mehr als 4GB adressieren, usw., usw.

Das alles gab es schon mit Leopard. Jetzt gibt es Snow Leopard und der Kernel selbst ist 64-Bit, nicht nur das System was auf dem Kernel aufsetzt. Das macht natürlich verdammt viel Sinn, denn so ein Kernel ist ja oft weit über 4GB groß... da braucht man schon einen echten 64-Bit Kernel. (Achtung! Ironie!).

Das Marketing funktioniert hier mal wieder fantastisch, denn alle reden darüber und kaum einer weiss was dahinter steckt und wie es funktioniert. Ich empfehle mal einen Blick in "Modern Operating Systems" von Tanenbaum zu werfen. Da wird wunderbar beschrieben was ein Kernel ist, was der so macht, warum man ihn braucht, usw. usw. Man kann sich dann auch mal daran machen selbst ein Betriebsystem mit eigenem Kernel zu schreiben. Spätestens danach wird einem klar was ein 64-Bit Kernel aktuell in einem Snow Leopard bringt... nämlich genau gar nichts.

Die normalen Kerneländerungen von Leopard (32-Bit) zu Snow Leopard (32-Bit) sind da viel gravierender.

 

[below]

Nur weil da ein 64-Bit Kernel verwendet würde heisst das noch lange nicht, dass das System schneller wird. Es kann lediglich mehr Speicher vom System adressiert werden.

So nicht ganz richtig. Der Speicher konnte schon vorher addressiert werden, aber jetzt kann der Kern selbst mehr als 4GB addressieren -- und es ist etwas leichter, Daten per DMA in 64 Bit Applikationen zu verschieben.

Weil nicht alle Treiber von Consumergeräten als 64-Bit kext vorliegen.

Vollkommen richtig.

Spätestens danach wird einem klar was ein 64-Bit Kernel aktuell in einem Snow Leopard bringt... nämlich genau gar nichts.

Das kann man so sagen, daher aktiviert Apple den 64 Bit Kern ja (wenn ich nicht falsch liege) nur in den XServes -- der normale Anwender hat davon nichts.

Aber es ist ein Weckruf für die Entwickler, 64 Bit Treiber zu bauen. Denn so wie wir heute mit einem Lächeln auf 16 Bit Systeme kucken, werden wir morgen 32 Bit Systeme nur noch im Museum sehen.

Alex

 

[MacMark]

… was ein 64-Bit Kernel aktuell in einem Snow Leopard bringt... nämlich genau gar nichts. …

Falsch.

Ein Programm mit x86_64-Bit-Code (auch der Kernel) kann auf 64-Bit-Intel doppelt soviele Register nutzen wie ein 32-Bit-Programm und zusätzliche schnellere 64-Bit-Befehle, die seiner 32er-Version nicht zur Verfügung stehen. Darum ist der 64er Kernel schneller.

…gibt es 64-Bit schon seit Ewigkeiten mit Leopard. System läuft in 64-Bit…

Falsch. Das "System" ist das, was in 10.5 als einziges noch nicht 64-bittig war.

 

[below]

Falsch.

Ein Programm mit x86_64-Bit-Code (auch der Kernel) kann auf 64-Bit-Intel doppelt soviele Register nutzen wie ein 32-Bit-Programm und zusätzliche schnellere 64-Bit-Befehle, die seiner 32er-Version nicht zur Verfügung stehen. Darum ist der 64er Kernel schneller.

In der Theorie. In der Praxis würde ich das gerne sehen (abgesehen von 64 Bit DMA).

Alex

 

[Jamsven]

Weil nicht alle Treiber von Consumergeräten als 64-Bit kext vorliegen.

Die Crux wird auf jeden Fall die ganze legacy Peripherie sein, wo die HW Hersteller absehen 64 bittige Treiber zu entwickeln.

 

[MacMark]

In der Theorie. In der Praxis würde ich das gerne sehen (abgesehen von 64 Bit DMA).

Alex

In der Praxis, denn das ist eine Besonderheit von Intels x86-64-CPUs.

Die Crux wird auf jeden Fall die ganze legacy Peripherie sein, wo die HW Hersteller absehen 64 bittige Treiber zu entwickeln.

Entwickeln? Es ist eine Compiler-Option, die man nutzt.

 

[nate]

wie kann ich jetzt schauen ob mein iMac unter 32bit oder 64 bit läuft auch wenn es nichts bringt, würde es mich interessieren

 

[Pechente]

wie kann ich jetzt schauen ob mein iMac unter 32bit oder 64 bit läuft auch wenn es nichts bringt, würde es mich interessieren

Weißt du, dass es unglaublich hilft zu lesen!?

Über diesen Mac -> Weitere Informationen -> Software

 

[nate]

Weißt du, dass es unglaublich hilft zu lesen!?

sorry hab erst die letzten Seiten gelesen, aber das nicht gesehen sorry!

 

[StephanG]

Ein Programm mit x86_64-Bit-Code (auch der Kernel) kann auf 64-Bit-Intel doppelt soviele Register nutzen wie ein 32-Bit-Programm und zusätzliche schnellere 64-Bit-Befehle, die seiner 32er-Version nicht zur Verfügung stehen. Darum ist der 64er Kernel schneller.

Ja, wenn die CPUs denn doppelt so viele Register hätten, dann würde das tatsächlich etwas bringen. Hat sie aber nicht, also Wunschdenken. Es ändern sich u.U. lediglich die Befehle und evtl. Anzahl der Befehle, aber auch die Laufzeiten dafür, weshalb das eine Milchmädchenrechnung ist.

Mach dir mal den Spaß und schreib den Compiler im 64-Bit Modus so um, dass die Anzahl der nutzbaren Register dem von 32-Bit entsprechen und vergleiche dann.

So schlau war Apple auch schon, wenn du da aber einen Zaubertrick gefunden hast, dann lass es mich wissen. Ich schicke das dann gerne an einen ehemaligen Studienkollegen der maßgeblich an der Entwicklung von Leopard und Snow Leopard beteiligt war. Da freut man sich bei Apple sicherlich.

Falsch. Das "System" ist das, was in 10.5 als einziges noch nicht 64-bittig war.

Manchmal hilft schon das lesen der Apple-Dokumentationen, da steht's genau drin.
Leopard: 32-Bit Kernel, 32-Bit KEXTs, 32-Bit Drivers, 64-Bit Unix, 64-Bit Cocoa, 64-Bit Apps
Snow Leopard: 64-Bit Kernel, 64-Bit KEXTs, 64-Bit Drivers, 64-Bit Cocoa, 64-Bit Apps

Mit System meine ich übrigens nicht die GUI die da läuft, sondern das System darunter.
Eine 64-Bit GUI bringt dir genauso viel wie ein 64-Bit Kernel bei SL, gar nix. In ein paar Jahren sieht die Sache anders aus, insofern macht es natürlich Sinn jetzt auf 64-Bit zu setzen. Apple limitiert sich vielmehr durch die Hardware. Ich brauche nicht nur lächerliche 32GB Hauptspeicher, bei 128GB fängt der Spaß doch erst an, da hilft mir aber der tollste MacPro kein Stück weiter.

 

[Jamsven]

Entwickeln? Es ist eine Compiler-Option, die man nutzt.

Machst du Witze?
Das ist doch schon ein riesen Aufwand für so ein Unternehmen.
Klar ist das ein Compilerflag, aber es gibt Firmen die Packen es noch nicht mal ihre eigene Firma ins Projekt einzutragen.
So bekomme ich bei der Sofware vom N24 UMTS Stick solche Logs ab:

com.yourcompany.Mobileconnect...

Ich wette in meiner Library geistern auch solche lausig benannten Plists rum.

 

[below]

In der Praxis, denn das ist eine Besonderheit von Intels x86-64-CPUs.

Benchmark?

Entwickeln? Es ist eine Compiler-Option, die man nutzt.

Offensichtlich entwickelst Du nicht professionell Software, denn mit dem Anklicken der Compileroption ist es nicht getan.

Alex

 

[Jamsven]

Offensichtlich entwickelst Du nicht professionell Software, denn mit dem Anklicken der Compileroption ist es nicht getan.

Alles klar das wäre mir auch neu. Warum?

 

[below]

Alles klar das wäre mir auch neu. Warum?

Wie Du geschrieben hast, ist das alleinige "Anfassen" eines Projekts in einer Firma mit Aufwand verbunden.

Und auch wenn sich die Software problemlos als 64 Bit Binary übersetzen lässt wäre es grob fahrlässig, sie ohne eine vollständige QA aus dem Haus zu lassen. Dazu kommt dann noch ein bischen Änderung von Text hier und da, und ein neues Deployment.

All dass klingt vielleicht trivial, ist aber eben doch Arbeit, die irgendjemand genehmigen, und irgendjemand anders machen muss.

Alex

 

[MacMark]

Wozu brauchst Du Benchmarks? Wenn doppelt soviele General Purpose Register zur Verfügung stehen im 64-bit-computing-mode der Intel-x86_64-CPUs als im 32-Mode, sollte klar sein, was das bringt.

Außerdem hat man im 64er Processing Mode auf Intel-x86_64 Befehle, die unter 32er Processing Mode nicht verfügbar sind.

Also erzählt hier nicht weiter, 64 Bit würden dem Kernel nichts bringen!

Hausaufgabe: Wir schreiben ein Programm und compilieren es in eine einzige Datei, die dann von PPC, PPC-64, Intel und Intel-64 nativ ausgeführt werden kann. Ich habe da mal etwas vorbereitet:

KeyWest:~ macmark$ cat hello.c

/* Hello World program */

#include<stdio.h>

main()
{
printf("Hello World");

}

KeyWest:~ macmark$ gcc -arch ppc -arch ppc64 -arch i386 -arch x86_64 -c hello.c
KeyWest:~ macmark$ file hello.o

hello.o: Mach-O universal binary with 4 architectures
hello.o (for architecture ppc7400): Mach-O object ppc
hello.o (for architecture ppc64): Mach-O 64-bit object ppc64
hello.o (for architecture i386): Mach-O object i386
hello.o (for architecture x86_64): Mach-O 64-bit object x86_64

KeyWest:~ macmark$ lipo -detailed_info hello.o

Fat header in: hello.o
fat_magic 0xcafebabe
nfat_arch 4
architecture ppc7400
cputype CPU_TYPE_POWERPC
cpusubtype CPU_SUBTYPE_POWERPC_7400
offset 4096
size 744
align 2^12 (4096)
architecture ppc64
cputype CPU_TYPE_POWERPC64
cpusubtype CPU_SUBTYPE_POWERPC_ALL
offset 8192
size 852
align 2^12 (4096)
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
offset 12288
size 512
align 2^12 (4096)
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
offset 16384
size 728
align 2^12 (4096)

 

[below]

Wozu brauchst Du Benchmarks? Wenn doppelt soviele General Purpose Register zur Verfügung stehen im 64-bit-computing-mode der Intel-x86_64-CPUs als im 32-Mode, sollte klar sein, was das bringt.

Außerdem hat man im 64er Processing Mode auf Intel-x86_64 Befehle, die unter 32er Processing Mode nicht verfügbar sind.

Das ist mir vollkommen klar. Aber das macht nicht jedes Stück Programmcode automatisch um einen Faktor x schneller.

Es ist nicht weiter schwer, sich Aufgaben vorzustellen die entweder enorm, oder gar nicht von diesen Erweiterungen profitieren.

Daher finde ich die Frage, wie sich das in der Praxis im Darwin Kern bemerkbar macht nicht trivial.

Hausaufgabe: Wir schreiben ein Programm und compilieren es in eine einzige Datei, die dann von PPC, PPC-64, Intel und Intel-64 nativ ausgeführt werden kann.

Öh, ja, was genau willst Du mir damit sagen?

Alex

 

[Jamsven]

Wie Du geschrieben hast, ist das alleinige "Anfassen" eines Projekts in einer Firma mit Aufwand verbunden.

Und auch wenn sich die Software problemlos als 64 Bit Binary übersetzen lässt wäre es grob fahrlässig, sie ohne eine vollständige QA aus dem Haus zu lassen. Dazu kommt dann noch ein bischen Änderung von Text hier und da, und ein neues Deployment.

All dass klingt vielleicht trivial, ist aber eben doch Arbeit, die irgendjemand genehmigen, und irgendjemand anders machen muss.

Alex

Ja gut das drumherum halt. Ich dachte schon du meintest notwendige Änderungen am Quelltext. :-D