Macs sind nur noch gewöhnliche PCs

[JavaEngel]

eine Binsenweisheit.
Neue Modelle sind immer besser ausgestattet.
Und schneller und billiger.
Nur der Mac mini nicht. Dank Intel-Swich.

Das ist etwas wahres dran. Nur muss ich auch entgegnen, dass ich in der Videobearbeitung nicht mehr von schneller reden kann, sondern von Quantensprüngen. Der Sprung von G3 zu G4 war dagegen lächerlich (G4 zu G5 ebenso). Wenn ich jetzt den letzten G4 im Notebook mit dem MacBookPro vergleiche, mag ich gar nicht darüber reden, sondern einfach nur noch den G4 leise belächeln. Der G5 wäre Notebookuntauglich und ich finde schon, dass der Dual Core Intel Yonah Chip gerade für Leute, die mit der Speichermenge ( die 32 Bit ermöglicht ) auskommen, einfach nur genial ist.

Mir ist relativ egal, was in diesem Gerät steckt. Für mich bedeutet der Sprung PPC auf Intel einen Quantensprung im Bereich der Audio und Videobearbeitung, den man nicht einfach nur mal "schneller" nennen kann.

Und wer 64 Bit nicht benötigt, wird wohl den deutlichen (nicht üblichen) Leistungszuwachs einfach nur lieben und die bisherige PPC-Linie müde belächeln. So geht es mir zumindest.

 

[Coda]

Ok, sachte sachte.

Because 64-bit applications will be supported using a 32-bit kernel, this 64-bit support will have no impact on most device driver or kernel extension writers. However, there are exceptions, as explained in “Device Driver Issues”."

Die Frage ist hier macht Apple es wirklich so und kompiliert den ganzen Kernel nicht einfach als 64-bit-Binary.

Myth: The kernel needs to be 64 bit in order to be fully G5-optimized.
Fact: The kernel never needs to directly address more than 4 GB of RAM at once. The kernel is able to make larger amounts of memory available to applications by simply using long long data types to keep track of mappings internally."

Das ist wohl wahr.

However, the PowerPC architecture does not have either of these limitations. It was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode. Thus, on PowerPC architectures, software does not generally become faster (and may actually slow down) when compiled as a 64-bit executable."

Das ganze funktioniert aber auch nur auf G5. G4 hat definitiv nur 32-bit Integer-Register und Instructions.

AMD hat beim Design von x86-64 festgelegt das Ring-0-Code nicht in den 32-bit Modus switchen darf. Das ist dann aber auch der einzige Punkt in dem sich die Konzepte unterscheiden.

Der Kernel muss trotzdem davon wissne, dass er auf einem 64-bit-System läuft denn sonst kann er die Register beim Task-Switch nicht sichern.

Ich verstehe Apple aber eh nicht, dass sie bei x86 nicht gleich auf 64-bit gewartet haben um nur eine Reihe von Treibern unterstützen zu müssen.

 

[abgemeldeter Benutzer]

Die Frage ist hier macht Apple es wirklich so und kompiliert den ganzen Kernel nicht einfach als 64-bit-Binary.

Bei Mac OS X gibt es keinen ganzen Kernel. Der wird erst beim Systemstart aus dem Mach und den Kexts zusammengesetzt.
Bei Tiger ist es anders, als bei Panther. Panther war definitiv 32-bit und Panther-Kexts laufen unter Tiger.

Das ganze funktioniert aber auch nur auf G5. G4 hat definitiv nur 32-bit Integer-Register und Instructions.

Binsenweisheit
Aber offensichtlich kennt er trotzdem den long long data type

AMD hat beim Design von x86-64 festgelegt das Ring-0-Code nicht in den 32-bit Modus switchen darf. Das ist dann aber auch der einzige Punkt in dem sich die Konzepte unterscheiden.

Schön, beim PPC gibt es da gar keine Modi zwischen denen geswitcht werden müsste.

Der Kernel muss trotzdem davon wissne, dass er auf einem 64-bit-System läuft denn sonst kann er die Register beim Task-Switch nicht sichern.

Beim PPC nicht.

Ich verstehe Apple aber insofern dann nicht, dass sie bei x86 nicht gleich auf 64-bit gewartet haben um nur eine Reihe von Treibern unterstützen zu müssen.

Der ganze Switch sieht irgendwie nach einem Schnellschuss aus.

 

[Coda]

Aber offensichtlich kennt er trotzdem den long long data type

Der Compiler kennt ihn um es dann auf 2 32-bit-Register zu verteilen. Das hilft dir im Kernel aber nichts. Da must du die kompletten 64-bit-Register sehen. Das geht bei PowerPC offenbar auch im 32-bit-Modus auf einem 64-bit-PowerPC.

Schön, beim PPC gibt es da gar keine Modi zwischen denen geswitcht werden müsste.

Nein, dann nicht. Das ist die Schlussfolgerung daraus.

Allerdings sehe ich trotzdem nicht ein warum das einen großen Nachteil darstellen soll. Die Libs müssen auch auf PowerPC für 64-bit-Apps trotzdem 64-bit-aware sein, sowie der Kernel auch (dann können sie das allerdings auch im 32-bit-Modus tun).

Die Treiber können 32-bit bleiben. Das ist der einzige Vorteil.

 

[pallo]

Haben wir mal wieder ein "ich bi der größte schaut zu mir auf und knie"-Mitglied .

._ut hat schon sehr viel Ahnung von den Sachen über die er redet, mach dir da mal keine Sorgen.

LOL! Nicht immer alles glauben, was ut & co schreiben

 

[abgemeldeter Benutzer]

Allerdings sehe ich trotzdem nicht ein warum das einen großen Nachteil darstellen soll. Die Libs müssen auch auf PowerPC für 64-bit-Apps trotzdem 64-bit-aware sein, sowie der Kernel auch (dann können sie das allerdings auch im 32-bit-Modus tun).

"Myth #3:
Myth: All of the system calls have to change (or new ones have to be added) for 64-bit compatibility.
Fact: Most of the system call arguments changed to 64 bit many years ago.[...]"

Die Treiber können 32-bit bleiben. Das ist der einzige Vorteil.

Bzw. umgekehrt, für 64bit-x86 müssen wieder alle Treiber neu geschrieben/besorgt werden.

D.h. das ganze Spiel geht wieder von vorne los:
Montelang Meldungen bei Mactechnews: "XXX jetzt IntelMac64-kompatibel."

 

[Coda]

"Myth #3:
Myth: All of the system calls have to change (or new ones have to be added) for 64-bit compatibility.

Jo, nur haben sie die GUI dabei vergessen. Ups, das betrifft ja fast nur 99% aller Apps. Wie brauchbar.

Und komm mir nicht mit dem Hintergrundprozess. Das ist übler Scheiß zum programmieren und sicher keine brauchbare Lösung

 

[abgemeldeter Benutzer]

Jo, nur haben sie die GUI dabei vergessen. Ups, das betrifft ja fast nur 99% aller Apps. Wie brauchbar.

Weil eine 64-bit GUI derzeit das System nur bremsen würde (höherer Speicherverbrauch und Umsatz).

Und komm mir nicht mit dem Hintergrundprozess. Das ist übler Scheiß zum programmieren und sicher keine brauchbare Lösung

Das Thema hat sich mit dem Switch doch eh erledigt.

 

[Coda]

Weil eine 64-bit GUI derzeit das System nur bremsen würde (höherer Speicherverbrauch und Umsatz).

Dann brauchen sie auch nicht damit werben dass sie "den ersten 64-bit-Desktop" haben. So ist es einfach nur lächerlich.

Das Thema hat sich mit dem Switch doch eh erledigt.

Ist es sicher, dass die x86-64-Version von Mac OS X endlich eine 64-bit-GUI haben wird?

 

[-Nuke-]

Weil eine 64-bit GUI derzeit das System nur bremsen würde (höherer Speicherverbrauch und Umsatz).

Ja, aber das was man an Rechenzeit und Speicher einspart, geht in die Zeit und Kosten der Programm-Entwicklung rein.

"Nur für OS X" wird keiner sein Programm-Design ändern. Das ist das Problem. Selbst das FinalCut-Team von Apple gefällt diese Methode absolut nicht und es ist auch nur schwer möglich, weil die GUI einen erheblichen Teil ausmacht. Zu lesen in einem Kommentar auf Slashdot.

 

[-Nuke-]

Ist es sicher, dass die x86-64-Version von Mac OS X endlich eine 64-bit-GUI haben wird?

Muss sie ja, ansonsten bringt's nix. *gg*

Mal sehen wie Apple das anstellt. Bisher scheint es wohl Probleme mit Cocoa zu geben, wegen der massiven Anzahl an Pointer. Soll wohl extrem langsam sein, weil der Cache auf dem G5 ausging. Fragt sich ob es bei Intel noch der Fall ist mit 4MB L2-Cache.

Apple entschlackt wohl gerade Cocoa ein bisschen.

 

[Coda]

Muss sie ja. *gg*

Warum muss sie das? Das ist auch nur ein Userspace-Programm und kann auch unter x86-64 durchaus als 32-bit ausgeführt werden.

Mal sehen wie Apple das anstellt. Bisher scheint es wohl Probleme mit Cocoa zu geben, wegen der massiven Anzahl an Pointer.

Objective-C-Geschwür halt.

 

[-Nuke-]

Objective-C Geschwür halt.

Hat halt alles Vor und Nachteile. ObjC ist halt dynamisch ohne Ende.

Apple braucht Cocoa nur entschlacken. Alle Cocoa-Objekte sind kompatibel zu ihren CoreFoundation-Derivaten (C-Typen).

 

[Coda]

Hat halt alles Vor und Nachteile. ObjC ist halt dynamisch ohne Ende.

Aha, was bedeutet "dynamisch" in diesem Zusammenhang denn deiner Meinung nach?

 

[-Nuke-]

Hier steht was dazu:
http://sit.iwr.uni-heidelberg.de/~reichenb/documents/objc.html

Würde ich auch "nur" abtippen. Es ist halt so, das vieles zur Laufzeit "rausgesucht" wird.

[obj dieMethodegibtsnicht: mystring];

kompiliert in jedem Fall, sofern obj und mystring definiert sind. Wenn du dann ggf. irgendwann die Klasse erweiterst, dann wird es ohne Probleme aufgerufen, ohne diesen Teil neu zu kompilieren.

 

[Peacekeeper]

LOL! Nicht immer alles glauben, was ut & co schreiben

Es ging mir jetzt mehr um den Ton als um den Inhalt.

 

[Coda]

Hier steht was dazu:
http://sit.iwr.uni-heidelberg.de/~reichenb/documents/objc.html

Würde ich auch "nur" abtippen. Es ist halt so, das vieles zur Laufzeit "rausgesucht" wird.

[obj dieMethodegibtsnicht: mystring];

kompiliert in jedem Fall, sofern obj und mystring definiert sind. Wenn du dann ggf. irgendwann die Klasse erweiterst, dann wird es ohne Probleme aufgerufen, ohne diesen Teil neu zu kompilieren.

Das ganze erinnert etwas an C++ mit Qt-Metacompiler.

 

[vava]

Objective-C-Geschwür halt.

Machen wir jetzt einen nahtlosen Übergang von Prozessor-Architektur Shootout zur Hochsprachendebatte?

(Mein Popcorn ist nämlich alle)

 

[Coda]

Machen wir jetzt einen nahtlosen Übergang von Prozessor-Architektur Shootout zur Hochsprachendebatte?

Wenns sein muss

 

[-Nuke-]

Das ganze erinnert etwas an C++ mit Qt-Metacompiler.

Klar. C++ kann man um alles erweitern. Nur bei ObjC sind es Sprach-Features schon von Beginn an.

Ich will mich jetzt auch nicht darum streiten was besser ist. Da kommen wir als Programmierer eh nicht auf den Punkt.

Für Anwendungen ist Objective-C halt sehr gut geeignet. Einfach zu verstehen, leicht verdauliche Syntax, man erreicht sehr schnell sehr viel.

Nicht umsonst gucken sich sehr viele Sprachen einiges von ObjC ab.

>Die< Sprache für alles ist es trotzdem nicht.