MacBook 32 bit oder 64 bit

[MacMark]

>> Alex

Jedes Programm wird schneller, wenn der Compiler mehr Register zur Verfügung hat. Und "doppelt soviele Register" ist enorm. Zugriffe auf Register sind um Größenordnungen schneller als auf den Hauptspeicher.

Was ich mit dem Codebeispiel sagen will? Daß es kinderleicht ist, ein 32er Programm auch als 64er zu compilieren.

 

[Rastafari]

Hausaufgabe ...

Du hast ganz offensichtlich in deinem Leben noch nie einen Heisenbug ausmerzen müssen.

Jedes Programm wird schneller, wenn der Compiler mehr Register zur Verfügung hat.

Totaler Unsinn.

 

[below]

Jedes Programm wird schneller, wenn der Compiler mehr Register zur Verfügung hat.

Ja, und wie viel schneller ist jetzt der Darwin Kern? 10% ? 200% ?

Was ich mit dem Codebeispiel sagen will? Das es kinderleicht ist, ein 32er Programm als 64er zu compilieren.

Hast Du schon mal ein größeres, existierendes (Treiber-)Projekt auf 64 Bit gebracht?

Es ist meistens nicht damit getan, das 64 Bit Flag zu setzen -- und eventuelle Code-Änderungen sind, wie oben beschrieben, der kleineste Teil des Aufwands.

Jamsven und ich sprechen nicht davon, "Hello World!" als 64 Bit zu bauen, sondern kommerzielle Software marktfertig zu machen.

Alex

 

[MacMark]

Du hast ganz offensichtlich in deinem Leben noch nie einen Heisenbug ausmerzen müssen.


Totaler Unsinn.

Ersteres ist ein Extremfall.

Und das mit dem "Unsinn" darfst Du erklären.

… sprechen nicht davon, "Hello World!" als 64 Bit zu bauen, sondern kommerzielle Software marktfertig zu machen.…

Der Punkt ist, daß sie nicht komplett neu als 64er entwickelt werden muß, wenn sie schon als 32-Code vorliegt. Der Extra-Aufwand für eine 64er Version ist gering.

 

[Rastafari]

Und das mit dem "Unsinn" darfst Du erklären.

Erst wenn du mir erklärst, warum mehr Register einen Code beschleunigen sollten, der sie gar nicht braucht.

 

[StephanG]

Wie soll denn ein Programm doppelt so schnell werden, wenn die doppelte Anzahl an Registern zur Verfügung steht? Das ist doch schon ein Schuss ins Knie, da nur ein Bruchteil der Register überhaupt statisch sind und der Großteil dynamische Register sind. Da hast du als Programmierer gar keinen Einfluss darauf, wie es gehandhabt wird. Das zieht einen riesigen Rattenschwanz hinter sich her. Da musst du das System schon komplett selbst geschrieben haben und für jede mögliche Anwendung ein eigenes System und eigenen Compiler verwenden.

Der PPC hatte 128 Bit Register für Vectoroperationen, also zurück zum PPC weil wir mehr Daten mit einem Ruck ansprechen können? Wohl kaum.

Das Beispiel was ich vorher gegeben habe, den 64-Bit Compiler auf die Register zu beschränken die auch im 32-Bit Modus zur Verfügung stehen zeigt das recht gut. Das geht nicht via Compiler-Flag, dazu muss der Compiler umgeschrieben werden. Letztenendes macht man das nur bei der Compiler Entwicklung oder aber bei Forschungsprojekten bei denen sowieso zig Millionen pro Jahr verbraten werden. Alles andere ist eine Milchmädchenrechnung nach dem Motto ein System mit 2GHz ist doppelt so schnell wie eines mit 1GHz. Das kennt man ja aus der Aldi Werbung, wenn da mal wieder ein Rechner verscheuert wird. Leider funktioniert es aber bei vielen Konsumenten.

 

[MacMark]

Erst wenn du mir erklärst, warum mehr Register einen Code beschleunigen sollten, der sie gar nicht braucht.

Der Kernel benutzt die General Purpose Register nicht?

… Wie soll denn ein Programm doppelt so schnell werden, wenn die doppelte Anzahl an Registern zur Verfügung steht? …

Das habe ich auch nicht geschrieben. Es ist jedoch eine der gängigsten Methoden, den Rechner zu beschleunigen: "Anzahl der General Purpose Register erhöhen." Und wenn dieses Mehr an Registern nur im 64er-Processing-Mode genutzt werden kann, ist klar, was das bedeutet.

Laßt doch bitte Eure Nebendiskussionen. Mir ging es darum zu zeigen, daß der Kernel sehr wohl in x86_64 Bit schneller ist als in i386.

 

[Rastafari]

Der Kernel benutzt die General Purpose Register nicht?

Ein mal in zwei Stunden ganz bestimmt.

 

[below]

Der Extra-Aufwand für eine 64er Version ist gering.

Sprichst Du da aus Erfahrung? Ich schon.

Und da Du mit den Hausaufgaben angefangen hast:

Dein altes Cocoa Program lies sich unter 10.5 wunderbar mit

gcc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -arch ppc -arch i386 -arch x86_64 -framework Cocoa main.m

bauen, und lief dann auch auf 10.4. Reicht hier auch ein einfaches Anfügen von -arch x86_64 ?

Alex

 

[StephanG]

Der Punkt ist, daß sie nicht komplett neu als 64er entwickelt werden muß, wenn sie schon als 32-Code vorliegt. Der Extra-Aufwand für eine 64er Version ist gering.

Wie bitte? Das stimmt sicherlich für Code der Marke "int x = 25;". Für mehr aber auch nicht. Mach dir mal den Spaß und ruf bei der Firma Aycan an und frag nach warum die über 2 Jahre gebraucht haben um von 32-Bit auf 64-Bit umzustellen. Kannst den Jungs auch einen schönen Gruß von mir ausrichten.

Auch hier http://tech.groups.yahoo.com/group/osirix-dev/ darfst du gerne mal vorbeischauen und allen erklären wie einfach es doch ist auf 64-Bit zu porten, wenn 32-Bit schon existiert. Der Aufwand kann gigantisch sein.

 

[below]

Ein Zitat von Ars Technika:

"Apple makes the following claims about (the 64 Bit Kernel's) performance:

250% faster system call entry point
70% faster user/kernel memory copy
Focused benchmarking would bear these out, I'm sure. But in daily use, you're unlikely to be able to attribute any particular performance boost to the kernel. Think of K64 as removing bottlenecks from the few (usually server-based) applications that actually do exercise these aspects of the kernel heavily." (Hervorhebung von mir)
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/5

Alex

 

[Jamsven]

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:

Wie sieht es denn aus, wenn du Bitoperationen durchführst und du ursprünglich nur von einem DWORD ausgehst?
Hier hat doch beispielsweise ein bit-shift mit einem 64bit Word ein anderes Verhalten als bei einem 32bit word...
Das könnte doch zu einer Programmlogik führen, welche im 64bit Build fehlerhaft ist.

 

[MacMark]

-> Rastafari
Nur ein Beispiel: Bei x86_64 werden (die ersten sechs) Argumente für Funktionen typischerweise nicht mehr wie bei x86 auf dem Stack übergeben, sondern über Register. Und der Kernel hat sehr viele Funktionen.

--> below, StephanG
Es gibt diverse OS X-Software von der Kext bis zur Anwendung, die schneller und problemloser auf 64 Bit gebracht wurde. Eure individuellen Negativ-Beispiele sind daher nicht allgemein.

--> Jamsven
Ein DWord ist in beiden Fällen ein DWord. Warum mutwillig ein QWord daraus machen?

Edit:

--> below
Der Artikel von arstechnica beachtet nicht, daß die zusätzlich genutzten Register der 64-Bit-Version des Kernels diesen selbst insgesamt beschleunigen.

 

[below]

--> below, StephanG
Es gibt diverse OS X-Software von der Kext bis zur Anwendung, die schneller und problemloser auf 64 Bit gebracht wurde. Eure individuellen Negativ-Beispiele sind daher nicht allgemein.

Ich habe keine grossartigen Negativbeispiele gebracht, aber das kürzste (nicht triviale) Projekt war bei uns eine Woche, inkl. QA, neuem Read Me, etc. etc.

Jetzt möchte ich Dich aber noch mal fragen: Dein Wissen in diesen Dingen hast Du wo her?

Alex

 

[iPain 3G]

Mmmh, worum gings hier nochmal?








Achja, darum was beim Macbook besser ist,64 oder 32bit, und nicht darum wie schwer oder einfach es ist in 64bit zu schreiben.

 

[MacMark]

--> iPain 3G
Auf Intel CPUs 64, weil die Vorteile die Kosten für den Overhead überwiegen, denn die 32er Programme können die 64er Intel-CPU nicht voll nutzen.
Auf PPC haben 64er Programme nicht so viele Vorteile gegenüber 32er Programmen, weil in beiden Computing Modes die CPU voll genutzt werden kann, wodurch auf PPC der Overhead größer ist als die Vorteile.

 

[iPain 3G]

Wenn ich ehrlich bin ist mir das egal.
Ich wollte nur darauf hinweisen das der ganze Kram den ihr geschrieben habt VOELLIG OT wahr.

 

[Jamsven]

--> below, StephanG
Es gibt diverse OS X-Software von der Kext bis zur Anwendung, die schneller und problemloser auf 64 Bit gebracht wurde. Eure individuellen Negativ-Beispiele sind daher nicht allgemein.

--> Jamsven
Ein DWord ist in beiden Fällen ein DWord. Warum mutwillig ein QWord daraus machen?

Ok blödes Beispiel, aber unter Windows muss man schon ein paar Sachen beachten. Bei denen reicht ein Flag nicht aus.

 

[GunBound]

Wenn ich ehrlich bin ist mir das egal.
Ich wollte nur darauf hinweisen das der ganze Kram den ihr geschrieben habt VOELLIG OT wahr.

Aber er war interessant. Schliesslich gibt's hier auch noch weitere Mitleser…

 

[Jamsven]

Hier:
http://msdn.microsoft.com/de-de/library/cc438589(VS.71).aspx