Wo ist das Problem? Apple hat sein System so geschaffen (Universal Binary), dass sie ohne Probleme beliebige Architekturen einsetzen können. Es gibt für Apple also gar keinen Grund einen Intel-Prozessor zu nehmen, außer den, dass der Prozessor möglicherweise besser ist.

und vielleicht günstiger wenn sie eh alle von intel nehmen

Noch ist Mac OS UB. Aber ob das nächste, oder übernächste es noch sind?

idolum@mac
Nein, mit Sicherheit nicht. Aber die nächsten OS Versionen müssen dann auch nicht auf der "alten" Technik laufen.

Wie viel stärker wäre der INtel Prozessor denn gegenüber dem momentanen Samsung Prozessor?

ich wart schon bis bootcamp fürs iphone kommt

Nach dem, was ich gesehen habe,
sind die Programme, die mit dem iPhone SDK erzeugt werden,
Universal.

Daher laufen diese sowohl auf einem iPhone,
als auch auf dem iPhone Simulator, der auf einem Intel-Mac läuft!

philm5: Der war nicht schlecht!

Wobei, derzeit werden angeblich ja schon erste X86-Emulatoren für's iPhone geschrieben.

Nachher gibt's noch Parallels für iPhone

Gerhard Uhlhorn

Ohne Probleme? Wenn iPhone-Entwickler aus irgendeinem Grund keine neuen Kompilate zur Verfügung stellen (keine Zeit mehr fürs Hobby, keine Lust mehr $99 im Jahr dafür zu bezahlen, Forcierung eines kostenpflichtigen Updates etc.), dann steht man blöd da. Apple wäre gut beraten gewesen eine Virtuelle Maschine (z.B. LLVM-IR+JITC) zu nutzen, gerade in so einem veränderlichen Markt, wo man schon eher mal die Architektur wechseln muss.

Das würde ich ohne Probleme nennen! Universal-Binaries sind IMO nur die zweitbeste Lösung mehrere Archtitekturen zu unterstützen. Mit einem VM-basierten System könnte Apple allen Veränderungen im Prozessormarkt völlig gelassen entgegensehen, sie könnten sogar mehrere Architekturen beliebig parallel einsetzen und neue hinzunehmen, gerade wie es ihnen Spaß macht.

cmaus@mac.com

Nein, sie sind nicht Universal. Die Binaries für den iPhone-Simulator sind rein x86, einfach mal mal mit dem file-Kommando befragen.

PS: Wenn nicht das verständliche Bedürfnis bei kommerzieller Software bestünde, den Quellcode nicht offenlegen zu wollen, wären Universal-Binaries sogar nur die drittbeste Lösung.

natürlich würde intel diesen chip auch gerne an apple verkaufen - aber wozu sollte apple von arm auf x86 umsteigen? um mehr strom zu verbrauchen? alles neu compilieren zu müssen? die gerätetreiber neu schreiben zu dürfen?

unfug.

@ andreas hofmann: es geht ja wohl eher um die binaries für das iphone. aber die würde ich an apples stelle doch auch vor installation auf dem iphone von der x86-version bereinigen. ist ja nicht so, dass da unendlich viel platz drauf wäre.

idolum@mac + carboom: Warum sollte Apple eine so brilliante Technologie wegwerfen? Immerhin ermöglicht es Apple zeitnah auf Neuentwicklungen zu reagieren. Kommt plötzlich IBM mit dem Superduper-PowerPC-Prozessor, dann wechselt Apple einfach wieder. Das kann Microsoft nicht. Das ist ein unschätzbarer Vorteil, und den wird Apple nicht aufgeben wollen.

Ich denke, dass wir noch etliche Platformen erleben werden.

Andreas Hofmann: Von der Geschwindigkeit scheint mir die Universal Binary-Technik die schnellere Lösung zu sein. Und für die Programmierer bedeutet es nur das Programm einmal neu zu kompilieren.
Virtualisierung macht Apple übrigens auch: Rosetta. Die Nachteile sind hinlänglich bekannt, denke ich.

Hm, wenn Intel, dann doch Flash?

@ Gerhard Uhlhorn

Das ist natürlich auch ein interessanter Gedankengang.

Aber ich stell mir vor, dass dies einen sehr großen Aufwand bedeutet, aber "we will see".

Andreas Hofmann Bin mir fast sicher, das Apple das paralell im geheimen entwickelt. "Just in case szenario" wie beim "secret life of OSX"

Gerhard Uhlhorn

Stimmt, Apple wird die Technologie nicht wegwerfen.
Ich seh da nur folgendes Szenario: Apple nimmt wieder was weg, was sie dann Jahre später als tolle Neuerung wieder einführen. Apple Intern exsistiert alles weiter.

Was hat Intel mit Flash zu tun?

Gerhard Uhlhorn
sicher kann microsoft das, die haben ihre Systeme für verschiedene Architekturen entwickelt und müssen dies nur für die neuen Prozessoren kompilieren. Gab sogar mal ein NT für PPC...

dann, das die iPhone Programme universal binaries seien... Der iPhone Simulator emuliert vermutlich einen ARM Prozessor, wäre ja absolut dämlich wenn im Simulator eine andere Prozessorgeneration läuft als auf dem Endprodukt...

Und zum Artikel: Wiedermal nur wilde, quellenlose Spekulationen zzz

emjaywap

Microsoft kann das nicht, er hat recht. Klar wäre Microsoft fähig Windows auf andere Plattformen zu portieren, aber sie könnten eine solche Umstellung den Benutzern nicht zumuten.

Es gibt viel zu viele .EXE-Programme welche nicht mehr gewartet werden, zu viele Windows-Entwickler und X-Verschiedene Entwicklungsumgebungen die alle umstellen müssten....

Gerhard Uhlhorn

Nein, es ist eben nicht schneller. Es ist ein weitverbreiteter Irrglaube, aber sobald Du Dich mit Compilerbau beschäftigst, weißt Du, dass es völliger Unsinn ist. Denn im Prinzip funktioniert LLVM + JITC wie andere Compiler auch, nur der letzte Pass wird erst zur Laufzeit ausgeführt und kann damit evtl. sogar besser optimieren, wie ein statischer Compiler. Und das ist nur nur theoretisch so, es existiert auch ein prominentes Beispiel: Apple benutzt LLVM mit einem JIT-Compiler, um OpenGL bei Software-Fallbacks zu beschleunigen.

Der Vergleich mit Rosetta ist völliger Quark. Plattformunabhängiger Zwischencode ist so entworfen, dass viele Zusammenhänge im Daten-/ und Kontrollfluss erkennbar sind und sich sehr hohes Optimierungspotential ergibt. Deshalb machen alle vernünftigen Compiler diesen Zwischenschritt, auch die von Intel mit nur einer Plattform als Target. Maschinencode dagegen ist so entworfen, dass die Hardware dazu möglichst einfach designed werden kann, die Optimierungsmöglichkeiten sind äußerst beschränkt, deshalb sind Emulationen langsam.

Casa*****

Je früher desto besser. Übrigens auch für den Mac. So gut Apple Prozessorwechsel angesichts der gegebenen Situationen immer wieder gemeistert hat, sie haben uns Benutzern immer wieder Opfer abverlangt. Wir sind jetzt schon beim dritten Wechsel x86-32 x86-64 und warten darauf, dass alle auch 64-Bit unterstützen. Für uns Benutzer geht das ja noch mit vergleichsweise geringen Geschwindigkeitseinbußen, die Prozessoren unterstützen ja diesmal beide Modi und können dazwischen wechseln. Apple hat aber trotzdem auch noch einen ganz schönen Krampf, damit es für uns nicht so wird wie mit 64-Bit-Windows.

PS: Ich meinte natürlich "es ist nicht nur theoretisch so".

PPS: Eine Editierfunktion für Beiträge wäre nicht schlecht.

emjaywap

Wie ich schon sagte, wird kein ARM emuliert. Für den iPhone-Simulator erzeugt der Compiler einfach Maschinencode für den Intel-Prozessor.

Andreas Hofmann
???
Sorry, aber das ist in meine Augen totaler Quatsch. Ein speziell für den Prozessor compiliertes Programm ist immer schneller als wenn die CPU in einer virtuellen Maschine emuliert wird oder der Code erst zur Laufzeit compiliert wird.

RA/pdx

Und wie kommst Du zu der Erkenntnis? Hast Du gelesen was ich über die Beschleunigung von OpenGL in Leopard durch LLVM und JITC geschrieben habe? Wie kann das also sein?

Halten wir erst mal fest, dass LLVM z.B. wie jeder andere Compiler auch erst mal in Zwischencode übersetzt, weil sehr viele Optimierungen darin einfach besser möglich sind als im Quellcode einer Hochsprache oder Maschinencode. Wird die Übersetzung in Maschinencode danach sofort durchgeführt, arbeitet er also genau so wie andere Compiler und kann genau so effizienten Code erzeugen. Wird der letzte Pass jedoch auf die Laufzeit verschoben, ergeben sich Nachteile, aber auch Vorteile.

Nachteil ist, dass zusätzlich Rechenzeit für die Übersetzung des Codes aufgewendet werden muss. Die wird aber bei längerer Laufzeit schnell unbedeutend, da sie nur einmal für jeden Programmteil aufgewendet werden muss - aber für Optimierungen durchaus öfter kann.

Vorteil ist, dass der Just-in-Time-Compiler Informationen zur Optimierung nutzen kann, die ein statischer Compiler überhaupt nicht hat, z.B. wo die Hot-Spots in der Praxis liegen (Stellen im Code, die besonders oft durchlaufen werden), oder ob bestimmte Branches auf dem gegebenen System statisch werden und wegoptimiert werden können.

Dass ein Just-In-Time-Kompilierung langsamer sein muss oder sogar immer langsamer ist, wie Du meinst, ist also nichts weiter als eine Urban Legend. Sie kann schneller sein, mal langsamer, aber je länger Programme laufen, desto wahrscheinlicher ist es, dass sie schneller ist. Und sollte sie im konkreten Fall des iPhones im Schnitt langsamer sein, könnte Apple auch einen letzten Pass schon bei der Installation durchführen, statt zur Laufzeit. Das würde selbst so ein schwachbrüstiger Prozessor wie im iPhone wahrscheinlich noch parallel zum Download erledigen. In jedem Fall wäre diese Distributionsform also ein Gewinn.

Andreas HofmannJa, das habe ich gelesen - konnte aber keine Bestätigung deiner Aussage im Internet finden, dass es dadurch schneller wurde. Wo hast du diese Info denn her?

Ich wil ja auch gar nicht sagen, dass Just-In-Time-Compiler grundsätzlich was schlechtes sind, aber aus meiner Erfahrung heraus ist es im Normallfall deutlich langsamer als ein Vorcompiliertes Programm und braucht dazu noch deutlich mehr Hauptspeicher.

Und das Just-In-Time-Compiler schneller sein sollen ist bisher nur graue Theorie aus Informatiklehrbüchern, denn in der Praxis bestätigt sich dies nicht.

RA/pdx

Lass mich raten welche Erfahrungen Du in der Praxis gemacht hast, es war JVM (Java) und/oder CLR (.NET)? Wäre es nicht auch möglich, dass die Performance-Defizite mit anderen Eigenschaften zusammenhängen? Beide VMs erzwingen eine Garbage Collection, obwohl die auch nicht die Performance so dramatisch drückt, wie oft übertrieben dargestellt. Beide setzen AFAIK auf ein stackbasiertes Modell der Operandenübergabe (bei Java weiß ich es, habe mich mal intensiv mit Java-Bytecode auseinandergesetzt). Das ist leider sehr unterschiedlich zu dem wie heutige CPUs in der Regel arbeiten und macht die Übersetzung in Maschinencode jedenfalls nicht leichter. Nur um mal zwei Möglichkeiten zu nennen, für weiteres müsste ich zu sehr ausholen.

Darüber was Apple damit macht:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-August/006492.html

Und es kommt nicht von irgendwem:
http://www.nondot.org/sabre/

Wenns langsamer wäre hätte sich Apple a wohl auch kaum die Mühe gemacht.

Wenn Du mal vergleichen willst:
http://llvm.org/nightlytest/index.php

Ich kann da keine eindeutig Tendenz sehen, dass nativer Code noch nennenswert schneller sein sollte. Wie ich gesagt habe, mal gewinnt der JIT, mal verliert er, je nach Test und CPU-Architektur meistens so im Rahmen von +/-10%, von ein paar Ausreißern abgesehen. Von im Normalfall langsamer kann da beileibe keine Rede sein und von grauer Theorie auch nicht.