Apple ARM-Mac: Hybriddesign und Fertigung in 5 nm

[HWL News Bot]

Bereits mehrfach wurde darüber berichtet, dass Apple in absehbarer Zeit zumindest einen Teil seiner Mac-Produkte auf eigene Prozessoren umstellt, die auf eine ARM-Design basieren. Von Bloomberg stammen nun konkretere Details zum technischen Umfang der Umstellung.
... weiterlesen

 

[L0rd_Helmchen]

Darauf warte ich schon sehnsüchtig, Apples CPU Team leistet seit Jahren fantastische Arbeit. Ich prophezeie mal, dass sich da in Sachen Perf./Watt einige ganz schön umschauen werden.

High-End geht wohl erstmal noch nicht, aber wie viele brauchen das schon. Desktop Replacement ist eine Nische, Akkulaufzeit ist Trumpf.

 

[DeckStein]

Darauf warte ich schon sehnsüchtig, Apples CPU Team leistet seit Jahren fantastische Arbeit. Ich prophezeie mal, dass sich da in Sachen Perf./Watt einige ganz schön umschauen werden.

High-End geht wohl erstmal noch nicht, aber wie viele brauchen das schon. Desktop Replacement ist eine Nische, Akkulaufzeit ist Trumpf.

Im ARM feld, sicher.

 

[Hyrasch]

Ist ARM nicht die Zukunft, auch im Desktop?
Erwartet man im hpc-Bereich ständing Softwareportierungen von arm nach x86?

 

[DeckStein]

Ist ARM nicht die Zukunft, auch im Desktop?
Erwartet man im hpc-Bereich ständing Softwareportierungen von arm nach x86?

Wer weis das schon.

 

[L0rd_Helmchen]

Ist ARM nicht die Zukunft, auch im Desktop?

Ob nun ARM, RISC-V oder etwas anderes, x86 ist jedenfalls nicht die Zukunft.

Die x86 Hersteller werden das Verkleinerungsspiel noch so lange weiter betreiben, bis die Fertigung in die Mauer rennt. Dann wird man sich unweigerlich mal von dem uralten Kram lösen und bessere Designs suchen müssen.

 

[Infi88]

Warum sollte eine Stagnierung im Fertigungsprozess für x86 schlecht sein und für ARM nicht, eher umgekehrt.

 

[freekymachine]

Soll Apple machen ; die sehen nur noch Geld, wollen noch billigere CPUs um sie weiter teuer zu verkaufen ;

Einst hieß es ind er Werbung, wer sich noch erinnert ; "Its an apple, not a pc" - der Anti-PC, die Nische, der nicht Krüppel X86er, die Gegenbewegung, für die Ahnung haben, echte 32 Bit und später 64 Bit und nicht 16+16+32 Bit oder 8x8 bit.

..dann ham sie X86er verbaut und jetzt soll es ARM werden ?! - Für Creative, Nerds, Grafik und Videobearbeitung, wofür einst Apple stand, wars das dann wohl endgültig - das sind nur noch Handys mit großem Display - klar funzen tut das und wird/ist auch ausreichend für jeden der ne Runde im Netz surft - aber wehe man verlang dann mal Leistung - naja man wird sehen, wenn die Teile gebaut sind und frei verfügbar, dann kann man die unabhängig gegen aktuelle Hardware stellen.

Erinnert aber an an wechsel von IBM zu Intel, da waren auch lauter geschönte Folien, benchmarks unterwegs um das natürlich zu rechtfertigen. Fazit war dann am Ende ; Was man vorher mit einem IBM Apple konnte, konnte man danach mit einem x86er Apple nicht mehr. War auch ein Schock innerhalb Apple, lauter Ingenieure die von Anfang an bei Apple waren, teils 25 Jahre sollten aufeinmal ihr makelloses 64 Bit IBM OS auf x86er umschreiben - und ham dann geschmissen "könnt ihr selber machen"..

Und jetzt weg von Intel auf noch billigere ARMs..gut Intel hat ja auch grad seine Sorgen... 60k Dollar 28 Xeon vs 5k € 64 Core AMD.. da fehlen einem die Worte

jarjar, Geld regiert die Welt und Apple ist süchtig^^

 

[Brokk]

Mal gucken ob apple das schafft .... von Power PC zu x86 war der richtige Schritt, aber ob das für ARM auch der gild? :/
Ich bin mal vorsichtig und erwarte einen Rohrkrepierer ....

 

[PussyCat]

Würde effizienter sein wie ein Intel, und würde die Akku Laufzeit verdoppeln.
immer noch besser als Microsoft SQ1 crap lasst sich Qualcomm Teuer bezahlen.

 

[Rollo3647]

Ob nun ARM, RISC-V oder etwas anderes, x86 ist jedenfalls nicht die Zukunft.

Die x86 Hersteller werden das Verkleinerungsspiel noch so lange weiter betreiben, bis die Fertigung in die Mauer rennt. Dann wird man sich unweigerlich mal von dem uralten Kram lösen und bessere Designs suchen müssen.

Wenn keiner Programme für AVX2/AVX512 etc optimiert, warum sollte das jemand für ARM/RISC tun ?
Soweit ich weiß emulieren ARM systeme noch x86 code, Bitte korrigieren wenn das völlig Falsch ist !

 

[smalM]

Was Arm-Systeme unter Windows machen ist für Apple völlig irrelevant!

Wenn Apple umsteigt, werden zum Zeitpunkt der Verfügbarkeit der Maschinen alle APIs, MacOS und die Applikationen von Apple inklusive Xcode nativ ARMv8-A sein, eventuell gleich ARMv8.5-A. Und anders als bei der Transition von PPC zu x86 wird das dieses Mal von (sehr) langer Hand vorbereitet sein.

Apple hat gerade erst alle x86-32-Programme hinter sich gelassen, d.h. jeder Programmanbieter, der weiterhin was verkaufen wollte, hat seine Programme auf einen neueren Stand bringen müssen, und bis auf die Ausnahmen, die wirklich x86-spezifisches enthalten, werden sich diese relativ leicht portieren lassen. Zumal in MacOS die Applikationen eher selten eigene APIs mitbringen, meist werden die von Apple genutzt.
Auch kann man erwarten, daß MS in kürzester Zeit ein natives Office anbieten wird und Adobe portiert sowieso gerade seinen Kram auf's iPad, da wird ein Arm-Mac keinen große Mühe machen.
Einen wie großen Anteil der Mac-User hat man damit bereits abgedeckt? 70%, 80%, gar 90%?
Die Verkaufszahlen von Mac Pro und iMac Pro sind vergleichsweise winzig, alles andere kann man bereits mit dem kolportierten 8+4-SoC locker abdecken und nur die beiden i9-99xx-8-Kerner in MacBook Pro und iMac 27" werden sich dagegen behaupten können.

WENN es so kommt wie ( ausgerechnet ) von Bloomberg gemeldet...

 

[fl0]

echte 32 Bit und später 64 Bit und nicht 16+16+32 Bit oder 8x8 bit.

magst du mir mal erklären was du damit meinst?

 

[mr.dude]

Big.LITTLE halte ich für Notebooks/Desktops nach wie vor für kontraproduktiv. Zudem wird man wohl keine günstigen Geräte mit den Apple big Kernen sehen. Genau das würde mich aber interessieren, gerne auch mit abgespeckten Varianten. Also für Apple sicherlich ganz nett, sich von der Intel Abhängigkeit zu lösen. Wirklich Bewegung am Markt erwarte ich dadurch aber nicht.

 

[smalM]

@mr.dude
Begründe das doch mal, was da kontraproduktiv sein soll. Das würde mich jetzt echt interessieren.

 

[fdsonne]

Ich würde eher Vorteile allein durch das Prinzip sehen... Weil gerade im Notebook/Desktop Bereich meist eh genug Leistung vorhanden ist um die normalen Aufgaben spielend abgefedert zu bekommen (das machen dann die Stromspar Cores) - und erst wenn die Last-Tasks drauf kommen, werden die dicken Kerne ausgepackt. Man spart den ganzen Spaß abseits komplett Abschaltung in Sachen Stromsparttechniken im niedrig Lastbereich. Je anch Modell scheint sich der Mehrflächenbedarf auch eher in Grenzen zu halten ggü. dem Rest (ich denke da bspw. an Lakefield bei Intel - die winzigen Atom Kerne vs. den riesigen Sunny Cove Kern) usw.

Einziger Nachteil den ich (potentiell) sehe - der Task/Threadscheduler könnte der ganzen Theorie viel Wind aus den Segeln nehmen... Funktioniert das rumgeschubse nicht sauber, gibts alle Nase lang Probleme. Keine Ahnung wie gut/schlecht das generell bei MacOS oder iOS Funktioniert.
Ein Windows hat damit ja generell so seine Problemchen - Linux bekommt es klar besser hin, aber auch lange nicht wirklich perfekt, weil die Anwendungen immer noch recht klar mitspielen müssen (und die Hardware kennen müssen) - wobei das gerade bei Apple wieder funktionieren könnte -> wenn sie die Entwickler zwingen, wäre auch nicht das erste mal.

 

[mr.dude]

Begründe das doch mal, was da kontraproduktiv sein soll. Das würde mich jetzt echt interessieren.

Ob man ein paar Milliwatt oder selbst Watt in Niedriglastszenarien spart, spielt in den Segmenten absolut keine Rolle. Die bessere Reaktionsfähigkeit des Systems mit Big Cores spielt für mich aber sehr wohl eine Rolle. Jeder der schon mal produktiv was mit einem 2-Kern Atom Notebook machen musste, weiss wie zäh das teilweise ist. Selbst 4 Kerne helfen nicht wirklich weiter. Dem ziehe ich jedes Ryzen oder Core iX Book vor. Hinzu kommt der Aufwand des Betriebssystems, dass der Scheduler mit big.LITTLE auch umgehen kann. Einheitliche Kerne sind da wesentlich einfacher zu handhaben. Wir haben ja schon bei SMT gesehen, wie problematisch die Threadaufteilung sein kann.