Apple, Samsung, ARM und Microsoft
Samsung ist der größte Flash-Speicher Hersteller der Welt (siehe Wikipedia) und Apple einer der Größten (der Größte?) Abnehmer von Flash-Speicher (siehe Wikipedia). Da haben sich Zwei gefunden die zusammen gehören. Wirklich?
Schaut man sich Samsungs beeindruckende Produktpalette an, wird klar das Samsung gerne Geräte mit Microsoft Betriebssystemen verkauft. Egal ob Notebooks, Mobiltelefone oder MP3/4-Abspielgeräte. Und so ist Samsung nicht nur Apples wichtigster Lieferant für Flash- und ARM-CPUs sondern auch Wettbewerber. Wenn vielleicht auch ein anderer Zweig von Samsung.
Samsung nutzt nicht nur Intel Prozessoren, man nutzt auch mal VIA CPUs. Zudem ist Samsung einer der wichtigsten und potentesten ARM Lizenznehmer. Samsung entwickelt Produkte mit nVidia zusammen. Oder um es kurz zu machen, Samsung ist ein Gegenspieler zu Intel. Es gab Gerüchte, das Samsung eventuell auch AMD kaufen könnte, um an eigene x86 CPUs zu kommen.
Apple gilt, meiner Meinung nach zu unrecht, als Intel-Buddy. Dennoch verschmähte Apple Intel Atom komplett, nicht nur in Netbooks (die Apple als Schrott bezeichnet) sondern auch in MIDs aka Apple iPad. Auf der anderen Seite hat Apple ein erstaunlich gutes Verhältnis zu Microsoft. Es ist ausgerechnet Apple für das Microsoft mit Office ein Produkt pflegt, das nicht auf ihrem Windows OS läuft. Balmer scheint völlig uninteressiert am iPod und iPhone Markt, anders kann man Zune und Co. nicht sehen. Hegt und pflegt Apple dafür mit BootCamp die Windows-Installation auf Mac Hardware?
Apple nutzt ARM (im iPhone GS) und angeblich hat Apple eine Lizenz ARM CPU-Komponenten und GPU-Komponenten zu nutzen (siehe bright side of news). ARM wird mit AMDs Produktionslinie Global Foundries kooperieren um ARM SoCs in modernen Produktionsverfahren herstellen zu lassen (siehe The Inquirer). Dürfte Intel nicht gefallen. Weder ARM & Global Foundries, noch Apple und ARM.
Immer noch im Dunklen verborgen: Welche Architektur liegt dem iPad A4 zu Grunde? Die Spekulationen reichen immer noch von ARM Einzelkern Cortex-A8 über Mehrkern Cortex-A9 bis hin zu einer PA-Semi PWRficient Basis. Bei Letzterem wäre geklärt, was die PA-Semi-Leute den so getrieben haben. Es gibt aber auch die Gerüchte, das der A4 letztendlich von Samsung zusammen gestellt wurde. Welchen Vorteil hätte ein Non-ARM aber ARM-kompatibler PA-Semi-A4? Wer trotzdem daran Glauben möchte, der kann sich von Mark Hibben den Rücken stärken lassen. Ein Schwachpunkt bei Mark ist, dass er an nimmt, Apple verbaue einen Cortex-A9.
Leider habe ich keinen Schimmer, welche der oben verbreiteten Gerüchte nun im Ansatz stimmt. Es sind wirre Zeiten und alles scheint Quark zu sein.
- Anmelden oder Registrieren um Kommentare zu schreiben
Kommentare
Mark Hibben
Mark Hibben nimmt durchaus nicht an, dass Apple einen Cortex A9 verbaut. Ganz im Gegenteil hält er es für unwahrscheinlich, dass Apple mit einem Team, dass keine Erfahrung mit ARM-IP hat (ausgenommen Dobberpuhls 15 Jahre alter Erfahrung mit dem StrongARM) schneller ist, als die anderen Hersteller, die seit Jahren SoCs mit ARM-IP bauen. Von denen kann noch keiner ein Cortex-A9-SoC liefern. Apples A4 ist aber seit mindestens September 2009 fertig.
Überhaupt scheint Mark Hibben der einzige zu sein (außer mir;-)), der analytisch an die Sache herangeht. Der versucht er nicht in das Zwitschern irgendwelcher Vögelchen etwas rein zu interpretieren und nimmt nicht einfach an, dass es ein ARM sein muss, denn es laufen ja iPhone-Apps. Angesichts der Tatsache, dass sogar PowerPC-Applikationen mit Rosetta unter x86 laufen, ist klar, dass ein PowerPC, der schon Prozessorseitig bessere Möglichkeiten für Emulation anderer ISAs liefert, ohne Probleme ARM-Code ausführen kann. (Unverständlich ist mir allerdings, warum er die 68k-Emulation als schlechter bezeichnet. Im Gegensatz zu Rosetta hatte diese nämlich keine Einschränkungen, was Sytemcode, Plugins etc. betrifft.)
Statt Gerüchte zu verbreiten, beweist er, anhand von bekannten Werten vom PWRficient und vom Cortex A8 (vom Cortex A9 gibt es noch keine Werte), welchen Vorteil ein "Non-ARM aber ARM-kompatibler PA-Semi-A4" hat: Bessere Performance pro Watt.
Cortex A9
Hallo,
als die anderen Hersteller, die seit Jahren SoCs mit ARM-IP bauen. Von denen kann noch keiner ein Cortex-A9-SoC liefern
IMHO gibt es breits eine ganze Reihe von Cortex A9, davon einige schon seit einiger Zeit am Markt:
- TI OMAP4 (Dual-Core Cortex A9), letztes Jahr auf der MWC vorgestellt.
- QualCooms Sbnapdragon findet sich bereits in einigen Consumerprodukten (auch wenns kein echter CortexA9 ist, so ist es doch ein DualCore ARMv7)
- Nividias Tegra 2 ist zumindest angekündigt
- Marvell's Armada 500/600 ebenfalls.
Bzgl der 68k-Emulation:
IIRC war deren effzienz (Emuliertes Instructions pro Clock) weniger gut als die von Rosetta. Zudem hatte sie auch ihre Einschränkungen, nämlich keine FPU-Unterstüzung. Das wäre heutzutage wohl ein O-Kriterium.
Bis dann
R"udiger
Jein
Qualcomm Snapdragon und Marvell Armada sind keine ARM IP, sondern eigene Implementationen der ARM v7 ISA.
TI OMAP4 wird laut Mark Hibben erst ab der zweiten Hälfte von 2010 lieferbar sein. Nur der Tegara 2 ist seit Anfang diesen Jahres in Produktion und ein Developer Kit ist verfügbar. Entwickler haben gerade erst begonnen, Tegra-2-Geräte zu entwickeln.
Das iPad ist aber schon fertig und in Produktion, dafür muss der Prozessor seit mindestens ein paar Monaten lieferbar sein. (Der Prozessor im Apple-Video stammt offenbar von September 2009.)
Zur 68k-Emulation. Mag sein, dass die weniger Effizient war. Das ist auch 10 Jahre ältere Technologie. Trotzdem hat sie insgesamt besser funktioniert, u.a. da es möglich war, erst mal nur Teile des Codes neu zu übersetzen (PowerPC-Enabler fürs System, PowerPC-Plugin bei Photoshop etc.). Hier konnten Möglichkeiten des PowerPC-Prozessors genutzt werden, die ein x86 einfach nicht hat.
die wären?
Hier konnten Möglichkeiten des PowerPC-Prozessors genutzt werden, die ein x86 einfach nicht hat.
Und die wären?
Und die wären?
Die vielen Möglichkeiten aufzuführen, die der PowerPC hat und der x86 aber nicht, in einer Form, dass jemand, wie Du es verstehen kann, würde diesen Rahmen wohl sprengen. Sollte Deine Frage implizieren, dass Du Dich ernsthaft für das Thema interessierst, was ich strak bezweifele, müsstest Du mal ein wenig Zeit investieren und Dir die entsprechende low level Dokumentation zu den Prozessorarchitekturen zu Gemüte ziehen.
Daher nur so viel. Durch Möglichkeiten des PowerPCs, die ein x86 nicht besitzt, kann nativer und emulierter Code gemischt werden, was beim x86 nicht möglich ist. Im Ergebnis konnten so beim Übergang von 68k zum PowerPC weiterhin 68k-Treiber verwendet werden, beim Übergang von PowerPC nach x86 lief aber kein einziger PowerPC-Treiber mehr. Außerdem konnten beim Übergang von 68k nach PowerPC PowerPC-Plugins in 68k-Programmen ausgeführt werden und umgekehrt 68k-Plugins in PowerPC-Programmen, was beim Übergang von PowerPC nach x86 weder in der einen, noch in der anderen Richtung möglich war.
Ebenso kann beim PowerPC 32bit-Code und 64bit-Code gemischt werden, ohne dass ein Moduswechsel nötig ist, was ebenfalls beim x86 nicht möglich ist. Diese Möglichkeit wurde allerdings von Apple nie genutzt, weil man sich beim Übergang zu 64bit an der Plattform mit den geringsten Möglichkeiten orientiert hat, den x86.
Erklärung?
Daher nur so viel. Durch Möglichkeiten des PowerPCs, die ein x86 nicht besitzt, kann nativer und emulierter Code gemischt werden, was beim x86 nicht möglich ist.
Bitte genauere Erläuterung und Quellen!
Ansonsten ist das einfach nur eine Behauptung ohne Inhalt.
Übrigens kenne ich Macuser, die seit Anfang an dabei sind und JEDER hat bisher gesagt, dass der Intel-Switch der bisher unkomplizierteste war. Und was du als Vorteil versuchst hinzustellen, sieht außer dir keiner als Vorteil. Beim 68K -> PPC-Switch sind nämlich am Anfang angeblich Teile des OS noch emuliert worden (müssen) mit Performance-Verlust bzw. nicht nativer PPC-Geschwindigkeit. Selbst wenn die Emulation ziemlich flott war, ist das dennoch nicht optimal. Du versuchst mal wieder es so zu drehen, als sei ein Teil dieser Krücke ein Vorteil, nur um irgendwo x86 sinnlos als besonders schlecht hinzustellen und dann lieferst du noch nichtmal eine Erklärung ab.
Auf einem PowerPC-Mac unter OSX würden jetzt auch keine Intel-Treiber ohne neues kompilieren laufen. Da werden zwei völlig verschiedene Dinge und Situationen von dir verglichen. Außerdem gab es damals auch schon fat binaries!!! Aber jetzt nicht darauf ausweichen ob der Switch damals besser oder schlechter war, sondern eine Erklärung für die obige Behauptung.
In einem Emulator kann man natürlich Software einer anderen Architektur laufen lassen. http://basilisk.cebix.net/ zum Beispiel gibt es auch für Intel.
Ich weiß nicht, was Du für
Ich weiß nicht, was Du für Mac-User kennst aber Deine Behauptung, dass der Übergang von PowerPC nach x86 besser gelaufen wäre, als der Übergang von 68k nach x86 ist schlichtweg falsch. Der Übergang von PowerPC nach x86 kann nur dann gut gelaufen sein, wenn derjenige die eigentlich anstehenden Hardwarekäufe solange heraus geschoben hat, bis native Intel-Versionen aller seiner Programme verfügbar waren und Intel-Treiber für jede seiner Hardware. Für Leute, die nicht ernsthaft mit ihrem Mac arbeiten mag der Übergang zum x86 recht schmerzlos gewesen sein, für Leute, die mit ihrem Mac arbeiten, war er schmerzhaft und teuer.
Beim 68K -> PPC-Switch sind nämlich am Anfang angeblich Teile des OS noch emuliert worden (müssen) mit Performance-Verlust bzw. nicht nativer PPC-Geschwindigkeit.
Das ist richtig. Nur gab es beim Übergang zu PowerPC einen so großen Geschwindigkeitsschub, dass das System und die Programme trotz teilweiser Emulation deutlich schneller liefen. Im Gegensatz zum Übergang von PowerPC zu Intel, wo der Geschwindigkeitsschub so gering war, dass viele Programme auf der neuen Hardware deutlich langsamer liefen, als auf der alten. Nur kostenpflichtige Upgrades der Programme, welche teils erst nach eineinhalb bis zwei Jahren verfügbar waren, konnte das Problem beheben.
Auf einem PowerPC-Mac unter OSX würden jetzt auch keine Intel-Treiber ohne neues kompilieren laufen.
Nein, würden sie nicht. Es wäre aber durchaus möglich, die Emulation so zu implementieren, dass es ginge. Anders herum ist es aber nicht Möglich.
x86 braucht man nicht als besonders schlecht hinzustellen, die Realität lässt sich nicht mehr toppen.
Fakten bitte
Für Leute, die nicht ernsthaft mit ihrem Mac arbeiten mag der Übergang zum x86 recht schmerzlos gewesen sein, für Leute, die mit ihrem Mac arbeiten, war er schmerzhaft und teuer.
Ich kenne Leute die mit ihrem Mac _arbeiten_.
Nur gab es beim Übergang zu PowerPC einen so großen Geschwindigkeitsschub, dass das System und die Programme trotz teilweiser Emulation deutlich schneller liefen.
Da liest man AFAIR auch anderes, was der ganz frische Anfang betrifft. Aber darum geht es nicht.
Nein, würden sie nicht. Es wäre aber durchaus möglich, die Emulation so zu implementieren, dass es ginge. Anders herum ist es aber nicht Möglich.
Erläuterung mit Fakten! ;-)
Faulheit
Hallo,
Wenn ich es richtig verstehe, biete der PPC Möglichkeiten, einen Switch auf PPC in Etappen zu machen und fördert damit die Faulheit der Entwickler, die nicht alles aus einmal machen müssen. Andererseits kann man somit einen Switch schneller beginnen (der Intelswitch wäre wohl kaum möglich gewesen ohne die jahrelange Vorbereitung "under cover"). Das dadurch ein schlechteres Gesammtprodukt heruskommt, kann man wohl kaum den besseren Möglichkeiten eines Prozessor zuschreiben.
Bzgl. Intel-Treiber unter PPC-OSX: Hier gilt wohl, dass auch der Kernel die Möglichekiten ausnutzen müsste. Das x86 diese Möglichkeiten nicht bieten, fehlen diese wohl auch im Kernel, ergo können sie nicht genutzt werden (es sei den man passt den Kernel an). Wiederum kein Fehler des Prozessors sondern der Faulheit (oder auch Ökonumität) der Entwickler.
Bis dann
R"udiger
AMOS
As Motorola stopped developing their 68000 product, Alpha Micro started to move to the x86 CPU family, used in common PCs. This was initially done with the Falcon cards, allowing standard DOS and later Windows-based PCs to run AMOS applications on the 68000-series CPU on the Falcon card. The work done on AMPC became the foundation for AMOS 8.x, which runs natively on x86, but includes a 68K emulator to run older software in a method similar to the Power Macintosh.
http://en.wikipedia.org/wiki/Alpha_Microsystems
@Rüdiger:
Du nimmst die zweifelhaften Behauptungen von ut einfach als gegeben hin und beteiligst dich an dem Spielchen... .
Das dadurch ein schlechteres Gesammtprodukt heruskommt, kann man wohl kaum den besseren Möglichkeiten eines Prozessor zuschreiben.
Jetzt mal nicht alles durcheinander werfen - ja ;)
Bzgl. Intel-Treiber unter PPC-OSX: Hier gilt wohl, dass auch der Kernel die Möglichekiten ausnutzen müsste. Das x86 diese Möglichkeiten nicht bieten, fehlen diese wohl auch im Kernel, ergo können sie nicht genutzt werden (es sei den man passt den Kernel an). Wiederum kein Fehler des Prozessors sondern der Faulheit (oder auch Ökonumität) der Entwickler.
LOL.
Mal abgesehen davon, dass das kein Sinn machen würde, denke ich nicht, dass es gehen würde.
Wie gesagt du nimmst die nicht nachgewiesenen Behauptungen von ut einfach als gegeben hin und baust darauf sogar noch auf ;-)
Emulation in Anwenungen versus Emulation uim Kernel
Hallo,
Das AMOS Beispiel wiederlegt doch gar nicht (oder hab ich den spingenden Punkt verpasst)? Der spingende Punkt ist doch, dass bei MacOS 7.5, 8.x, 9.x m68k und PPC-Code im Kernel(!) gemischt waren. Das macht uts Behauptungen zumindest plausibel.
Cross-CPU-Plattform-Emulatoren gab es gab ist doch nichts besonderes. Die gab es (gerade damals) in nahezu belibiger Richtung (z.B. auch IIRC Mac-Emulatoren und DOS/Windows udn SoftWindows unter MacOS). Der entscheidene Punkt ist die Mischung im Kernel.
Bzgl OS X: Fakt scheint doch zu sein, das der OS X-Kernel die Mischung nicht unterstützt und das es bereits ein PPC-OS gab, dass eine solche Mischung unterstützte und dass mir keine OS bekannt ist, dass eine solche Mischung auf x86er je unterstützt hätte. Der Rest ist, da hast du Recht, ein Schluss daraus.
Bis dann
R"udiger
PS: Das die m68k-Emulation im MacOS-Kernel nun das Optimum in Punkto Effizenz gewesen wäre, kann ich mich umgekehrt nun auch nicht erinnern. Eswar halt nur "state-of-the-art". Rosetta, bzw. eigentlich Transitive Technologies scheint da etwas besonderes geschaffen zu haben.
jein
Es geht nicht nur um die Mischung im Kernel, sondern auch um die Mischung in Userland-Prozessen. Photoshop wurde z.B. zuerst mithilfe eines Plugins auf die PowerPC-Architektur angepasst, bis später eine Fat-Binary fertig war.
Unter mac OS X gibt es einen standardisierte Plugin-Schnittstelle. Trotzdem kann auf einem Intel-Mac kein einziges PowerPC-Plugin in einem x86-Programm ausgeführt werden. Die Möglichkeiten des x86 lassen das nicht zu.
Ui. Dann kläre uns mal auf
Trotzdem kann auf einem Intel-Mac kein einziges PowerPC-Plugin in einem x86-Programm ausgeführt werden.
Trotzdem kann auf einem PowerPC-Mac kein einzgies Intel-Plugin in einem PowerPC-Programm ausgeführt werden. ;-)
Die Möglichkeiten des x86 lassen das nicht zu.
Ui. Dann kläre uns mal auf mit Fakten!
Genauso warum der PowerPC das können soll.
Haha...
Dass beim PowerPC kein einziges Intel-Plugin ausgeführt werden kann, hat den gleichen Grund, wie dass Mac OS X Snow Leopard nicht auf PowerPC läuft: Apple investiert nicht in Vorwärtskompatibilität. Die wollen die neue Hardware verkaufen.
Außerdem hatte ich im Bezug auf 32- und 64bit schon erwähnt, dass die Möglichkeiten, die Mac OS X bietet, bestimmt werden durch die Möglichkeiten der Hardware mit den geringsten Möglichkeiten, aka x86.
Davon abgesehen verstehe ich nicht, warum Du Dich so sehr darüber aufregst, dass ich sage, dass es unter x86 nicht möglich ist. Deshalb musst Du doch keine Komplexe haben.
Das ist kein prinzipielles Unmöglich, es ist beim x86 einfach nicht implementiert. Anders, als bei der 32-64bit-Geschichte ließe sich das durchaus in die Prozessorhardware integrieren. Nur müsste Intel dafür eine spezielle Version des x86 für Apple konstruieren, welche evtl. dann auch inkompatibel zu Windows wäre. In den PowerPC bietet spezielle Möglichkeiten, mit emuliertem Code umzugehen, der x86 bietet dafür tolle Möglichkeiten nativ mit 30 Jahre altem 16bit-x86-Code umzugehen.
Nicht aufregen.
Außerdem hatte ich im Bezug auf 32- und 64bit schon erwähnt, dass die Möglichkeiten, die Mac OS X bietet, bestimmt werden durch die Möglichkeiten der Hardware mit den geringsten Möglichkeiten, aka x86.
Ablenkung. Das ist ein anderes Thema.
Davon abgesehen verstehe ich nicht, warum Du Dich so sehr darüber aufregst, dass ich sage, dass es unter x86 nicht möglich ist. Deshalb musst Du doch keine Komplexe haben.
Ich rege mich nicht darüber auf.
Ich stelle nur fest, dass du bisher nur heiße Luft postest. Das heißt du behauptest wilde Dinge ohne Nachweis.
Das ist kein prinzipielles Unmöglich, es ist beim x86 einfach nicht implementiert.
Konkret?
In den PowerPC bietet spezielle Möglichkeiten, mit emuliertem Code umzugehen
Und die wären?
Fakten. Fakten. Fakten!
Hört sich bisher alles eher nach einem schlauen Entwickler an (vorallem Gary Davidian):
http://en.wikipedia.org/wiki/Mac_OS_nanokernel
Reg Du Dich nicht auf.
Das ist ein anderes Thema.
Aber nein. Das ist kein anderes Thema.
Wie gesagt, wenn es Dich wirklich interessiert, investiere die Zeit, die dafür nötig ist und lese die Dokumentationen zu den verschiedenen Prozessor-Architekturen, nachdem Du Dich mit Grundlagen der Prozessortechnik befasst hast und Du wirst herausfinden, wovon ich rede.
Oder beschäftige Dich nicht mit all diesen Dingen und bleibe bei Deiner Ansicht, dass der böse Ut immer nur sinnlos Deinen geliebten x86 schlecht macht.
P.S.
Rüdiger beteiligt sich an irgendwelchen Spielchen, er hat im Gegensatz zu Dir einfach genügend Grundlagenwissen, um zu erkennen, dass meine "Behauptungen" nicht irgendwie zweifelhaft sind.
??????
Rüdiger beteiligt sich an irgendwelchen Spielchen,
Muss ich das jetzt verstehen?
R"udiger
Also heiße Luft
Aber nein. Das ist kein anderes Thema.
Doch
Wie gesagt, wenn es Dich wirklich interessiert, investiere die Zeit, die dafür nötig ist und lese die Dokumentationen zu den verschiedenen Prozessor-Architekturen, nachdem Du Dich mit Grundlagen der Prozessortechnik befasst hast und Du wirst herausfinden, wovon ich rede.
Also sagst du selber, dass du keine Ahnung hast und nur Blödsinn schreibst oder was soll dieses Ablenkungsmanöver???
Ansonsten wirst du das doch darlegen können - ohne großartig nachlesen zu müssen!!!
Kannst du aber anscheinend nicht!?
Oder beschäftige Dich nicht mit all diesen Dingen und bleibe bei Deiner Ansicht, dass der böse Ut immer nur sinnlos Deinen geliebten x86 schlecht macht.
Sieht nach einem weiteren Rückschlag für dich aus.
x86 ist auch nicht meine geliebte Architektur. Ich sehe es einfach pragmatisch.
Rüdiger beteiligt sich an irgendwelchen Spielchen, er hat im Gegensatz zu Dir einfach genügend Grundlagenwissen, um zu erkennen, dass meine "Behauptungen" nicht irgendwie zweifelhaft sind.
Momentan bist du nicht in der Position, solche Äußerungen zu tätigen, nachdem außer leere Behauptungen nichts von dir kam.
Das Geheimnis liegt im CCR
Was nützt es Dir, wenn ich mit Fachwörtern um mich schmeiße, von denen Du eh nicht weißt, was sie bedeuten?
Vielleicht hilft Dir dieses Zitat von BadAndy ja weiter:
[...] the very rich and complex branch instruction population in the ISA (it is just spectacularly rich) and the CCR and ability to do boolean games on the CCR was created for PPC in part due to IBM's interest in virtual machines/operating systems at that time ... it makes the ISA fairly powerful at emulating other ISAs without too much conditional glue code [...]
P.S. Wenn Du Dich mal mit dem Thema beschäftigen würdest, dann würdest Du x86 auch wirklich pragmatisch sehen, als das, was es ist: Das schlechteste was geht.
Und Du wärest nicht jedes Mal direkt angepisst, wenn jemand erwähnt, dass PowerPC (oder welche ISA auch immer) etwas kann oder besser kann, was x86 nicht oder schlechter kann.
Link?
Da fehlt der Link? Das ist noch nichtmal eine richtige Quelle.
Und wo steht jetzt, dass die Geschichte mit Intel im Gegensatz zu PPC nicht geht?
Wo ist die konkrete Erläuterung?
Edit:
2. My belief is that...
http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/34709433...
Hier steht immer noch das:
While a similar effect could likely have been achieved for Mac OS X by running Rosetta within XNU, Apple instead chose to implement Rosetta as a userland process to avoid troublesome debugging and the potential for security holes.
http://www.absoluteastronomy.com/topics/Rosetta_(software)
Wenn Du Dich mal mit dem Thema beschäftigen würdest, dann würdest Du x86 auch wirklich pragmatisch sehen, als das, was es ist: Das schlechteste was geht.
Und Du wärest nicht jedes Mal direkt angepisst, wenn jemand erwähnt, dass PowerPC (oder welche ISA auch immer) etwas kann oder besser kann, was x86 nicht oder schlechter kann.
Ich sehe pragmatisch, dass alles was benötigt wird problemlos mit Intel geht + x86 Kompatibilität und damit riesige Soft- und Betriebsystemauswahl und Anpassungen (die für viele mehr Wert sind und einen spürbaren Nutzen bringen, gegenüber evtl. theoretischen Vorteilen auf dem Blatt Papier).
Ich sehe es einfach pragmatisch.
Indeed. I designed PowerPC processors and x86-64 processors. PowerPC wins only in a textbook.
http://forums.macrumors.com/showpost.php?p=9358969&postcount=112
;-)
Softwareimplementierung... ???
Keine Ahnung wie das im Detail bei Alpha Microsystems ausgesehen hat.
Und falls da manches anders war, bedeutet das auch nicht zwangsweise, dass man es anders machen musste. Vielleicht wollte man es auch anders machen?
Der entscheidene Punkt ist die Mischung im Kernel.
Ging das wirklich?
Außerdem wer sagt denn, dass das wirklich alles Dinge sind, die von einer bestimmten CPU-Architektur oder ISA abhängig sind? Das kann auch alles eine reine Softwaregeschichte gewesen sein (die mit PowerPC selber direkt nichts zu tun hat), die Apple sich damals geschickt ausgedacht hat und die Apple viele Möglichkeiten gegeben hat. Was damals ging muss nicht mehr heute gehen oder vorgesehen sein und umgekehrt.
So CFM-Geschichten wie bei Carbon will Apple z.B. nicht mehr. Wozu auch? Die wären auch ohne Intel-Switch verschwunden. Carbon-CFM war nur da um den Switch OS9 zu OSX auf die Beine zu stellen. Das ist schon lange abgeschlossen und von daher weg damit, wie es Apple schon häufig mit Kram gemacht hat, den man nicht mehr braucht oder für alt hält (und es jetzt auch gerade mit Flash versucht).
und dass mir keine OS bekannt ist, dass eine solche Mischung auf x86er je unterstützt hätte.
Was aber nicht zwangsweise gleich bedeutet, das manche Dinge damals (und vor allem heute) von der Architektur abhingen bzw. x86 das verhindert.
In der x86 Welt gab es keinen Anlass für solche Geschichten. Da wurde keine ISA gewechselt und von daher steht das Argument auf wackeligen Beinen. Und generell ist es auch sicherlich das Ziel alles nativ laufen zu haben, ohne solche "Krücken" (auch wenn die technisch interessant sein mögen).
Edit:
Gerade gefunden:
In the beginning (1984), there was the classic Macintosh programming model, based on the Motorola 680x0 processor and code segments. Then in 1991, the PowerPC processor was introduced. There was concern about compatibility with existing 68K applications (including the Finder), and the first step in addressing this concern was writing a 68LC040 emulator which allowed 68K code to run unmodified in the new environment. As part of this effort, a method had to be devised to switch between the native PPC and the emulated 68K modes -- thus, the Mixed Mode Manager was born.
The Mixed Mode Manager is system software that manages mode switches between code in different instruction set architectures (ISA's). An ISA is the set of instructions recognized by a particular processor or family of processors. You indicate the ISA of a particular routine by creating a routine descriptor for that routine.
http://www.mactech.com/articles/mactech/Vol.13/13.08/CallingCFMCode/inde...
http://developer.apple.com/legacy/mac/library/documentation/mac/PPCSoftw...
In dem ersten Artikel geht es auch vor allem um den "Code Fragment Manager (CFM)".
In 1994, CFM was ported back to 68K.
Hört sich eher nach einer geschickten Softwarelösung an und nicht nach irgendeinem besonderem Vorteil von PowerPC.
Kein Aussage
Hallo,
Hört sich in der Tat eher nach einer geschickten Softwarelösung aus, anstatt einem Verdienst von PowerPC.
Für mich sagt das gar nichts bzgl der aktuellen Streitfrage, eher sogar pro der besseren Einbindbarkeit von emuliertem Code beimm PPC: Angenommen, der PPC böte die Möglichkeit besser von seinem ISA in ein emuliertes ISA zu springen als and CPUs, dann ist immer noch eine Software nötig, die dies ausnutzt und verwaltet (damals eben der CFM). Das 68k-Macs ohnehin nur 68k-Code ausführten, musste die 68k Implemetation nur das Springen zwischen 68k-Code-Fragmenten beherrschen, die PPC-Impelmentation aber das Springen ziwschen PPC und 68k. Dies war offenbar auch im Kernel möglich. Der CFM wäre somit "nur" die Software, die besagte Eigenschaften des PPC ausnutzt und umsetzt.
Und generell ist es auch sicherlich das Ziel alles nativ laufen zu haben, ohne solche "Krücken" (auch wenn die technisch interessant sein mögen).
Sicherlich, aber es kann Ümstellungen erleichtern (weil man nicht alles auf einmal machen muss und gleich z.B. eine breite Treiberbasis hat). Allerdings fördert es auch die Faulheit (bei Apple und andereswo, da der Druck neue Treiber für nicht mher top-aktuelle Hardware zu bringen schwinddet). Mag sein, dass Apple sich auch deshalb bei Intel-Switch dagegen entscheiden hat. Es belibt aber die einzige positive Aussage: Bei 68k->PPC-Switch ging es.
Und ein zweites, Apple ist ja eine treibenden Kraft hinter demllvm Projekt. Dieses hat das Potenzial Apple entgültig von der Prozessorarchitektur unabhängug zu machen (auch wenn Apple sich damit wohl für HPC-Anwendungen disqualifizieren würde). Dann wäre es entgültig egal welche CPU-Plattform ein Mac hätte, solange diese LLVM-Byte-Code-Treiber im Kernel unterstützt.
Bis dann
R"udiger
It's all about Software?! ;-)
Dies war offenbar auch im Kernel möglich.
Dazu konnte ich beim Überfliegen aber bisher nichts finden...
CFM gab es jedenfalls in beide Richtungen.
The Code Fragment Manager (CFM) was originally developed for Power Macs and lets Power Mac applications use shared code libraries (trust me, they're neat). Later, Apple ported the CFM backwards to 68K machines to make it easier for developers build 68K versions of Power Mac applications. Those 68K applications are just now starting to appear, although plenty more are in development.
http://db.tidbits.com/article/802
Edit:
The PowerMacintoshes are very different from all that has gone before (you knew this, right?), as they have a different sort of chip in. However due to some extremely clever programming at Apple, software compiled for old (68K) Macs still works.
http://www.keithcom.com/matt/cw_faq.html
Edit:
The reasons for Rosetta’s lesser capabilities as compared with Apple’s earlier 68k emulator for PPCs lie within its implementation—Rosetta is merely a userland program that can only intercept and emulate userland code, while the older emulator was integrated with the system at a much lower level. The 68k emulator was given access to the very lowest levels of the OS by being at the same level as, and tightly connected to, the Mac OS nanokernel on PPC Macs (later used for multiprocessing under Mac OS 8.6 and later), which means that the nanokernel was able to intercept PowerPC interrupts, translate them to 68k interrupts (then doing a mixed mode switch, if necessary), and then executing 68k code to handle the interrupts. This even allowed lines of 68k and PPC code to be mixed within the same source file of a fat application. While a similar effect could likely have been achieved for Mac OS X by running Rosetta within XNU, Apple instead chose to implement Rosetta as a userland process to avoid troublesome debugging and the potential for security holes.
http://www.absoluteastronomy.com/topics/Rosetta_(software)
Software ist nichts ohne geeignete Hardware
Schön, dass Du Dich wenigstens mal ein kleines Bisschen mit dem Thema beschäftigt hast.
Nun solltest Du Dir die Frage stellen, warum Apple beim Übergang zum x86 die Emulation so implementiert hat, dass Code nicht gemischt werden kann. Das Know How, wie so etwas zu implementieren ist (aka "extremely clever programming"), ist ja durchaus vorhanden.
Die Antwort ist ganz einfach: Es geht beim x86 nicht. Beim x86 würde fremder Code innerhalb eines Prozesses unweigerlich zu einem Crash führen.
Hardware passt ja besser denn je! ;-)
Die Antwort ist ganz einfach: Es geht beim x86 nicht. Beim x86 würde fremder Code innerhalb eines Prozesses unweigerlich zu einem Crash führen.
Fakten!
Und zwar sowohl was PowerPC, als auch Intel angeht!
Nun solltest Du Dir die Frage stellen, warum Apple beim Übergang zum x86 die Emulation so implementiert hat, dass Code nicht gemischt werden kann. Das Know How, wie so etwas zu implementieren ist (aka "extremely clever programming"), ist ja durchaus vorhanden.
Steht doch da.
Wartung.
Sicherheit. (IT-Sicherheit)
Sind andere Zeiten "heute" als in den 90igern, wo Sicherheit häufig ein Fremdwort war.
Und was soll eine Technik im Kernel, die schon jetzt nur noch optional ist (und vielleicht schon in 10.7 verschwindet) ;-)
Zwischen den Zeilen
Das analytische Deckmäntelchen ist ja schön, allein man durch sehen. Um die Basis PWRficient zu unterstreichen, stellt er in der Vorteils- / Nachteils-Matrix den PWRficient gegen eine Cortex-A9 Basis. Und kann dann eben mit unbekannte Implementierungsproblemen argumentieren, die die Cortex-A8 Lösung nicht hat. Die hat nur Vorteile gegenüber einer Eigenentwicklung.
Bleibt die Frage, wenn der A4 auf PWRficient basiert, wieso einen ARM-kompatiblen Non-ARM Chip bauen. Wenn das überhaupt geht und nicht mit IP von ARM kollidiert, die liefern ja auch "nur" Software ab.
Was er auch nicht erklärt, was will Apple mit all der Leistung? Um 98% der Anwender und 101% der US-Anwender zufrieden zu stellen, genügt ein einziger Cortex-A8 Kern mit ein bisserl Garnierung drum herum. Wieso mehr Geld für Dinge ausgeben, die nicht benötigt werden? Das iPaddle ist kein Universal-Computer sondern eine geschlossene Anwendung.
Wir werden mehr wissen, wenn der A4 zersägt und durchleuchtet ist. Bis dahin ist alles Spekulation. Apple könnte tatsächlich alles tun. Nichts ist so richtig sinnvoll ;-)
Hmm...
Irgendwie lese ich den Artikel anderes, als Du. Es geht nicht darum, einen ARM-kompatiblen Non-ARM Chip bauen. Es geht darum, dass der A4 PWRficient-Kerne als CPU benutzt. Ein SoC mit PWRficient Kernen ist seit 2007 in Produktion, da gibt es nicht mehr Implementationsprobleme, als beim Cortex A8. ARM-Komaptibilität für iPhone-Anwendungen macht Rosetta (hier sogar ohne Geschwindigkeitsverlust gegenüber einem aktuellen iPhone).
Was das Profil des iPads betrifft, das sehe ich anderes. Das ist durchaus schon beinahe ein universeller Computer. Es sollen ja auch Anwendungen, wie iWork etc. (MS Office, Lotus Symphonie und Omni hat iPad-Apps angekündigt) darauf landen.
Außerdem ist das iPad nach dem, was man davon bisher sehen konnte, wirklich schnell.
Die Kosten bespricht Mark Hibben auch in dem Artikel. Ein eigener Prozessor bedeutet letzendlich mehr Profit für Apple.
"Wieso mehr Geld für Dinge ausgeben, die nicht benötigt werden?" ist doch mein Argument dafür, dass Apple den PWRficient-Kern, für den sie einem Menge Geld gezahlt haben, auch benutzt.
Kosten
> Ein eigener Prozessor bedeutet letzendlich mehr Profit für Apple.
Welcher Zeitraum? War das von Mark konsequent zu Ende gedacht? Es ist nicht so einfach, fürchte ich. Apples eigener Prozessor ist nur dann ein wirtschaftlicher Erfolg, wenn auch Apples Geräte ein wirtschaftlicher Erfolg sind. Und umgekehrt. Scheitert eine Komponente rutscht die andere Notgedrungen mit ins Grab. Das _war_ ja ein Grund für den Switch, das Apple von Motorola / Freescale / IBM weg wollte, hin zu jemanden der zuverlässig Entwickelt und Produziert.
Aus AMD & Freescale entnehme ich, das man bei der Chip Entwicklung ständig hohe Summen investieren muss, um marktgerechte Produkte zu haben. Man muss die Folgen einer Fehlentwicklung abfangen können, also eher zwei oder drei Optionen zur Wahl haben. Siehe nVidia, AMD, Intel ...
Der Profit stellt sich erst dann ein, wenn der Prozessor wettbewerbsfähig ist (auch wenn er nicht frei verkäuflich ist) und das Produkt darum herum gefragt ist.
Noch mal zum Non-ARM-ARM-kompatibel. Unterstellt man, dass Apple im A4 keine ARM-Cores verbaut, aber iPhone "ARM" Apps darauf laufen, also ein ARM SoC emuliert wird, dann sehe ich massive Probleme und einen Grund für gewaltige Spannungen zwischen ARM und Apple. Dann wird ARM trotzdem Lizenzzahlungen wollen. Denn ARM liefert "Software" ab die in Silizium geätzt wird, oder als Vorlage für einen Emulator dient? Ich kann mir nicht vorstellen, das ARM zu sieht, wie Apple kostenlos einen ARM SoC emuliert.
Zu den Kosten der Entwicklung kommt dann noch vorübergehend (?) die Kosten für eine ARM Lizenz, wenn es eine gibt.
Via App-Store kontrolliert Apple welche Applikationen auf dem iPaddle laufen werden. Damit ist das für mich eine geschlossenes System.
Kosten
Es war sicherlich kein Grund für den Switch, das Apple von Motorola / Freescale / IBM weg wollte, hin zu jemanden der zuverlässig Entwickelt und Produziert. Jobs hat versucht IBM und Freescale gegeneinander auszuspielen, um die Prozessoren zu Produktionskosten zu bekommen. IBM und Freescale haben dann irgendwann nicht mehr mitspielen wollen, weil Apple nur ein kleiner Abnehmer war und dazu noch unzuverlässig. (Apple hat bei Freescale gerade mal 2% des Siliziums abgenommen.) Mit einem eigenen Prozessor hätte Jobs genau das erreicht: Den Prozessor zu Produktionskosten.
Die Produktionskosten sind dazu noch verhältnismäßig gering, da das SoC nur genau die Komponenten enthält, die für das entsprechende Gerät gebraucht werden und so kein Silizium verbraucht wird für Komponenten, die gar nicht verwendet werden. Außerdem schließt ein eigener Prozessor nicht aus, dass man teilweise trotzdem woanders einkaufen kann, wenn es dort etwas geeignetes in schneller, sparsamer und billiger gibt.
Zum Non-ARM-ARM-kompatibel: Es muss kein ARM-SoC emuliert werden. Bei Rosetta würde der ARM-Code in PowerPC-Code gemorpht.
Grund für den Switch
Das _war_ ja ein Grund für den Switch, das Apple von Motorola / Freescale / IBM weg wollte, hin zu jemanden der zuverlässig Entwickelt und Produziert.
Das stimmt IMHO so nicht. Mit Intel ist bei der Firma, bei der Apple nie schlechter steht (abgesehen von selbstauferlegten Beschränkungen, siehe Single-CPU-Desktop i7 etc.) als der Markt. Wenn Intel schlecht läuft, steht auch die Konkurenz schlecht da (oder man switch ohne Aufwand zu AMD). Bei PPC war und wäre das anders, Mal liegt man deutlich vorne (z.B. seinserzeit PowerBook mit 300 MHZ 603 versus Mobile-Pentium mit < 200 MHz) oder eben hinten (z.B. 500 MHz-G4-Probleme).
Im Übrigen, wenn man sie die Entwicklungsgeschichte Intels vor dem Switch anguckt, dann sieht die alles andere als gut aus:
- Der Itanium sollte ursprünglich 1998 vorgestellt werden, es wurde dann 2001. Auch im Folgenden (eigentlich bis heute) hat Intel beim Itanium nie seine Zeitvorgaben einhalten können, selbst als es noch ein hochwichtiges projekt war.
- Der P4 wurde bereits Anfang 1999 vermisst, erschienen ist er dann Ende 2001. Und er war dann sogar zunächst langsamer als schneller PIII.
- Bei 90nm-Prescott hatte Intel so große Thermikprobleme (die allerdings bei der Konkurenz bei 90nm alle ähnlich waren), dass der Takt nicht wie versprochen gesteigert werden konnte.
- Intel hat die angekündigten 5GHz beim Pentium 4 nie erreicht.
Einzig das Pentium M-Design machte seinerzeit einen guten Eindruck, wenn auch keinen überragenden.
Vor dem Intel-Switch hatte Intel also eine alles andere als gute Bilanz, was Zuverlässigkeit in Entwicklung und Produktion angeht.
Richtig ist aber auch, dass Intel dananch einen Lauf hatte, der aber nun auch langsam ins Stocken kommt. Der 32nm Core i7 kamm eher spät 2009 und der nächste Tock, der für 2010 avisierte SandyBridge, verzögert sich wohl bis 2011.
Ergo es gibt nicht um Zuverlässigkeit, sondern um Gleichschritt mit der Windows-Konkurenz.
-----------------------------------------
Bzgl der Lizenzzahlungen und ARM. IMHO fallen für die Emulation eines ISAs keine Lizenzkosten an. Sonst wären Projekte wie Qemu etc ja kaum möglich. Letzlich tut ja nicht mal ein Compiler was anderes als ein Code in ein ISA umzusetzten.
Erst wenn man diese in Silizium implementiert, werden diese Fällig. ARM liefert ja auch eine Software im Sinne von C-Code sonst in Hardwarebeschreibungssprachen.
Bis dann
R"udiger
ja
Das stimmt IMHO so nicht. Mit Intel ist bei der Firma, bei der Apple nie schlechter steht (abgesehen von selbstauferlegten Beschränkungen, siehe Single-CPU-Desktop i7 etc.) als der Markt.
Ja, das dürfte einer der Hauptgründe sein.
Vor dem Intel-Switch hatte Intel also eine alles andere als gute Bilanz, was Zuverlässigkeit in Entwicklung und Produktion angeht.
Richtig ist aber auch, dass Intel dananch einen Lauf hatte, der aber nun auch langsam ins Stocken kommt. Der 32nm Core i7 kamm eher spät 2009 und der nächste Tock, der für 2010 avisierte SandyBridge, verzögert sich wohl bis 2011.
Sicherlich läuft auch bei Intel nicht immer alles rund. Hier wird generell immer der Fehler gemacht und von Verschiebungen prinzipiell immer darauf geschlossen, dass das böse Intel Probleme hat und nicht kann.
Auf die Idee, dass der CPU-Verkauf letztlich nur dazu da ist Geld zu verdienen (und eben kein Selbstzweck ist) und Intel manchmal bewusst die Entwicklung bremst, um scheibchenweise möglichst viel Gewinn zu generieren, kommt hier nur selten jemand. Intel ist bisher überhaupt nicht in Zugzwang gegenüber AMD.
Wenn Intel nicht unter Zugzwang ist, warum dann das ganze Feuerwerk fast auf einmal völlig unnötig abbrennen, um dann nur noch wenig nachlegen zu können.
Intel doesn’t have plans to introduce anything faster than the six-core Core i7 980X clocked 3.33GHz, at least not in 2010. This is the current plan that would only change if Intel feels challenged by AMD.
http://www.fudzilla.com/content/view/17539/1/
Intel Performance
Hier wird generell immer der Fehler gemacht und von Verschiebungen prinzipiell immer darauf geschlossen, dass das böse Intel Probleme hat und nicht kann.
Das mag für die aktuellen Verzögerungen zutreffen (und beim 32nm Nehalem magst du damit wirklich recht haben). Bei SandyBridge bin ich mir schon nicht mehr ganz so sicher.
Sicher bin ich mir aber, dass die Verzögerungen beim P4 und Itanium seinerzeit, keine taktischen Spielchen waren. Zu dieser Zeit zog AMD gerade mit den Athlon davon und schickte sich an mit dem Athlon64 entgültig die Spitz zu erobern. Das Problem von AMD war seinerzeit (und fats bis heute) Microsoft. Der K8 und der K10 sind reinrassige AMD64/x86-64/x64-CPUs und sprinten erst da richtig los. Bei Intel trifft dies erst auf die Nehalem-Serie zu, sodass unter 32bit der Vorsprung dahin schmolz. Dank Microsoft Trägheit, Beharrungsvermögen, Unvermögen oder was auch immer, beginnt sich Windows654 erst jetzt nachdem auch Intel schneller 64er hat durchzusetzen. Insofern frage ich micht, ob nicht auhc der K10 weitläufig unterschätzt wird und eigentlich Intel viel mehr zusetzen müsste, wenn er den richtig wahrgenommen würde. Aber das nur nebenbei.
Bis dann
R"udiger
Schlauberger Apple
Im Grunde muss Apple beim iPad ja nicht mit Prozessorleistung protzen. Im Gegenteil, es macht aus mehreren Gründen Sinn, so sparsam wie möglich zu entwickeln. Man erhöht die Wafer-Ausbeute, man spart Energie, es funktioniert was soll. Es ist ein eher geschlossenes System, das iPaddle.
Wenn Apple ein eigenes SoC für den Mobilbereich entwickelt, das skaliert, unterstelle ich, ist es vielleicht noch nicht fertig und der A4 nur eine perfekt angepasste Lösung. Mit einem Cortex-A8 Kern und optimierten, spezialisierten Erweiterungen. Das wäre nichts anderes als clever und wirtschaftlich. Im iPaddle einen Multikern Cortex-A9 mit viel Brimborium zu verbauen, wozu?
Vögelchen flüstert...
Mir hat ein Vögelchen um ein paar Ecken geflüstert, dass die Beziehungen zwischen ARM und Apple momentan evtl. nicht die besten sein könnten...
Weiß nur nicht, wieviel Insider dieses Vögelchen wirklich ist bzw. wie glaubhaft. Vögelchen hat auch im konjunktiv geswitchert und ist nicht wirklich konkret geworden, sondern hat nur angedeutet...
Danach könnte Apple in Zukunft eigene Prozessoren herstellen, sprich keine ARM CPU IP mehr verbauen...
... und das momentan ist evtl. noch ein Übergang mit dem a4 bzw. man wollte sich alle Optionen offen halten...
Wird man sehen, ob was dran ist.
Bin bei solchen Vögelchen normalerweise sehr skeptisch...
Leicht nachzuvollziehen...
dass die Beziehungen zwischen ARM und Apple momentan evtl. nicht die besten sein könnten, wo Apple doch im A4 PWRficient-Cores verwendet und keine ARM-IP.;-)
Hui!
> dass die Beziehungen zwischen ARM und Apple momentan evtl. nicht die besten sein könnten...
Das setzt voraus, das Apple und ARM eine Beziehung haben, also das Apple tatsächlich ARM Lizenznehmer ist. Was sich ja nicht ausmachen läßt, bisher. Muss sich ARM Sorgen machen, ob Apple ARM SoCs verbaut oder nicht? Den Massenmarkt hat Apple nicht im Visier, Apple will Premium- bzw. Luxusmarke sein. So lange man Samsung, LG, HTC, RIM, Palm ... als Kunden hat.
Würde auf der anderen Seite aber zu Jobs Paradigma passen: Es zu lieben Optionen zu haben
Da fällt mir ein, nachdem Intel nichts gegen den Power7 entgegen zu setzen hat ... ob bei Apple unter schwarzen Tüchern und schwarz gestrichenen Display auch Mac OS X auf einem Power7 testet? Mehr "Premium" geht im Augenblick nicht. Auch wenn das den üblichen Preisrahmen von Mac Hardware wohl sprengt.
switchern...
Das setzt voraus, das Apple und ARM eine Beziehung haben, also das Apple tatsächlich ARM Lizenznehmer ist. Was sich ja nicht ausmachen läßt, bisher.
Ist nur Gezwitscher, was ich gepostet habe und muss nicht stimmen.
Allerdings ist diese Vögelchen schon einige male erstaunlich gut informiert gewesen. Ansonsten hätte ich es gar nicht erwähnt, da ich auf soetwas normalerweise nichts gebe.
Da fällt mir ein, nachdem Intel nichts gegen den Power7 entgegen zu setzen hat ... ob bei Apple unter schwarzen Tüchern und schwarz gestrichenen Display auch Mac OS X auf einem Power7 testet? Mehr "Premium" geht im Augenblick nicht. Auch wenn das den üblichen Preisrahmen von Mac Hardware wohl sprengt.
Wieso?
IBM peilt ohnehin einen anderen Markt an.
Und ich habe ja schonmal dargelegt, warum Apple IMHO zu Intel gegangen ist, unabhängig von der Leistung. Meinungen können sich allerdings auch ändern, was aber IMHO nicht passieren wird, solange Hackintoshs die Verkaufszahlen nicht ernsthaft gefährden.
Zweifellos ist Power 7 eine beeindruckende CPU. Allerdings hat das Teil auch eine TDP von 200W. Würde ein Nehalem EX auch eine 200W TDP haben dürfen, wäre Intel wohl wieder nah dran oder womöglich sogar auf ähnlichem Niveau. OK, der Power 7 hat noch den großen L3-Cache und nutzt auch eDRAM. eDRAM ist schon was feines.
200W TDP?
Wie kommst Du darauf, dass der POWER7 eine TDP von 200W hätte?
Selbst, wenn IBM irgendwo von 200W spricht, hätte der Wert nicht mit TDP zu tun, sondern es wäre die maximale Leistungsaufnahme. IBM gibt keine TDPO-Werte an, sondern nur typischen und maximalen Leistungsaufnahme. Selbst die typische Leistungsaufnahme liegt höher, als eine TDP á la Intel liegen würde.