News Apple Silicon „M2“: Die nächsten M-SoC sollen bis zu 32+8+128 Kerne besitzen

[knoxxi]

Ja richtig und du glaubst alle 168 Kerne können gleichzeitig das Video Rendern oder nur 32 oder 8 oder nur die 128 ?

Kommt auf die Software an, nech? Aber es ist immer super etwas in Abrede zu stellen ohne auch nur einen Funken Informationen.

 

[poolk]

Wow - erinnert mich an die ersten Power-PC-Macs 1994, ich hatte die Ehre damals auf so einem mit Pagemaker zu arbeiten. Sauschnell - aber auch arschteuer (ich erinnere mich an 8000 DM, und meiner war nicht das Spitzenmodell..). Da war Intel gerade mal beim Pentium 60..

Der PPC601 der ersten PowerPC Mac hatte auch nur 50-80Mhz und dabei 30% weniger Transistoren als der erste Pentium. Worauf möchtest du hinaus?

 

[bensen]

@MasterAK
Klingt eher nach Chiplet. Alles vielfache von 8+2+32. Zudem der Name Jade 2C und 4C.

Ergänzung (19. Mai 2021)

Ja richtig und du glaubst alle 168 Kerne können gleichzeitig das Video Rendern oder nur 32 oder 8 oder nur die 128 ?

Hä? Warum vermischt du CPU und GPU. Das ist doch keine offizielle Bezeichnung. Apple wird sicher nicht mit 168 CPU Kerne werben.
Intels CPU Dies wurden auch mal mit 4+2 oder 4+3 abgekürzt.

 

[Magellan]

Früher oder später könnte es durchaus dazu kommen. Noch ist aber recht viel Arbeit im Softwarestack zu ARM zubewältigen, damit ARM wirklich über alle Bereiche hinweg eine Alternative wird.

"Alle Bereiche" ist halt sehr absolut, es wird reichen die für die Masse relevantesten Bereiche abzudecken um den Markt zu dominieren, der Rest wird dann eine immer kleiner werdende Nische.

Solange das Dekstop OS Nr. 1 nicht eine gescheite Lösung liefert, um auf entsprechenden SoCs ohne grossen Aufwand alles mitnehmen zu können, werden wir x86-64 brauchen.

MS arbeitet da ja längst dran, und Apple hat bewiesen dass diese Architektur selbst per emulation noch überaus konkurrenzfähig ist. Insofern nur eine Frage der Zeit.
Irgendwer wird x86 noch lange brauchen, viele werden es aber relativ zügig nicht mehr brauchen.

 

[B3nutzer]

War es nicht so, dass Rosetta keine Emulation ist, sondern eine Art Converter, der das x86 Programm erst übersetzt und dann quasi "nativ" ausführt?

Zumindest hab ich es so verstanden.

 

[senf.dazu]

M1: 4+4+8
M2: 8+2+16 oder 8+2+32
MPro: 32+8+64 oder 32+8+128

Lt. Wikipedia sind's bei M1 8 Graphik-Cluster a 128 AUs. Bei z.B. 1.3 GHz und FMAC könnten dann auch die bereits von Apple angegeben (8x128x2*1.3GHz=) 2.6 TFlops zustandekommen. Bei einer 1024 AU GPU.

Aber was dann bei +128 GPU für M-MacPro, 128x128= 16384 AUs rauskommen soll klingt dann schon ein wenig astronomisch für ein CPU GPU Gemisch. Selbst wenn's "erst" 2022+ kommt.

Wie der Artikel auf die 2048 EUs für den dicken M-MacPro kommt ist mir auch nicht klar.

Die Zahlen für den M2 glaub ich ja noch - das paßt auch ins Marktumfeld der typ. Apple MBP oder iMac Käufer. Und die Integration von CPU und (großer) GPU hat durchaus den Vorteil das die dann auch einen gemeinsames DRAM/HBM im Prozessorgehäuse bespaßen können. Und beide von dessen Bandbreite profitieren können. Und man sich viele zeitaufwendige Kopieraktionen und Doppelspeicherung sparen kann.

 

[puri]

Der PPC601 der ersten PowerPC Mac hatte auch nur 50-80Mhz und dabei 30% weniger Transistoren als der erste Pentium. Worauf möchtest du hinaus?

Dass der Mac Lichtjahre schneller war als ein damaliger Pentium 60. Übrigens auch deutlich schneller wie die letzten Motorola 68K-Macs..- Obs jetzt wieder mal die bessere Adaption OS-Hardware war, oder die Rohleistung weiß ich nicht..

 

[Teralios]

Die echten Altlasten beschränken sich doch eigentlich nur auf den vorgeschalteten Decoder, der seit den PentiumPro-Zeiten die x86-Befehle in MicroOps aufteilt.

Oh, da gibt es ein paar mehr Altlasten, als nur diesen Decoder, dafür müsste man aber mal etwas tiefer in die Materie eintauchen und ein Asselembler-Erfahrungen von CISC und RISC-Prozessoren mit bringen.

Auch bei modernen ARM-Prozessoren sitzt heute ein Decoder, der die meisten Befehle noch mal in MikroOps aufsplittet. Nur geht das wesentlich schneller und einfacher, weil die meisten ARM-Befehle eine feste Breite haben und in der Regel bereits Atomar sind.

Das ist aber nur ein Teil: Die Probleme liegen auch bereits in IA32 selbst und den Zeitraum in dem die Grundzüge des x86 entstanden sind, da kommen wir aber nun in dem Bereich, in dem man sich noch mehr mit Prozessoren beschäftigen muss und auch die Gedankengänge hinter ARM und x86 mal hören musste.

Überall sonst dürfte die Entwicklung der x86-CPUs grundsätzlich ähnlich dynamisch verlaufen sein, wie bei der ursprünglich ja auch aus den 80ern stammenden ARM-Architektur.

Na, dann würde ich ja an der Stelle dir mal empfehlen in eine Universitätsbibliothek zu gehen und dir Bücher über die Entwicklung der IT in den 50er, 60er, 60er und 80er zu holen und dir anzusehen, welchen Einfluss zum Beispiel die Halbleiterfertigung in den 60er- und 70er auf das CPU-Design hatten und wie schnell sich da dann das Bild auch mal gedreht hat, nur weil plötzlich es technisch es möglich war.

x86/IA32 hat einen CISC-Befehlssatz, weil man damals Prozessoren noch primär über Assembler programmiert wurde und man dem entsprechend eher auf Lesbarkeit und Einfachheit der Befehle geachtet hat und man gewisse Aktionen hinter den Befehlen versteckt hat. Erst in den 70er, als Festplatten und ebenso wiederbeschreibbare Speichermedien relevant wurden und damit auch der Compiler beflügelt wurde, wurde RISC wirklich eine Alternative, weil RISC-Assembler für Menschen quasi schnell unverständlich und hoch komplex wid.

Dazu kommt, dass man in den Anfängen in die CPUs und damit verbunde in die ISAs nicht mehr Register als notwendig aufzunehmen und diese oft noch an gewisse Funktionen gebunden war. Denn Register benötigten Transitoren und Register, die mehre ALUs füttern können, verbrauchen noch mehr Tranistoren, als hat man sie bei x86 auf das nötigste Reduziert.

Ja, ARM ist in den 80er entsanden, nur ließ dir mal Interviews mit den Entwicklern von ARM durch und welche Erkenntnisse es damals schon gab: Je mehr man an Daten direkt in den Registern halten kann, um so schneller kann eine CPU arbeiten. Dazu kommt, dass die Daten in den Registern zu halten weniger Energie benötigt, als die Daten aus den Caches und noch schlimmer aus den RAM zu holen oder dorthin zu schieben.

Moderne x86-CPUs haben entweder - 8 oder 16 allgemeine Register im "INT"-Core und 16 Register im FPU-Teil oder - AVX512 - 32. ARMv8 sieht 31 für den eigentlichen Kern vor und 32 für Neon/SVE - bald auch SVE2. Sehr gute Compiler können alleine Anhand dieser Anzahl an Register sehr viele Daten möglichst lange auch in den Registern halten, bevor Daten aus den Caches geladen werden müssen in die Register.

Gute OoO-Algorithmen mit passender Fluss-Analyse und dazu Registerrenames minimieren den Zugriff auf die Caches und erst recht den RAM. Nur braucht man dafür auch eine entsprechende Anzahl an Register: Ein Grund warum Intel quasi seit MMX die Register Anzahl der FPU erst von 8 auf 16 und nun 32 Erweiterte oder warum AMD mit x64 zumindest 8 allgemeine Register eingeführt hat.

Intern hat eine aktuelle x86-CPU nur noch herzlich wenig mit einem 8086/8088 aus den 70ern gemein.

Auf Hardware ebene mag das zwar durchaus hinkommen, nur die ISA stammt immer noch aus den 70er mit all den damaligen Überlegungen um Kosten zu sparen und die Limitierungen der ISA kann man nicht einfach eliminieren. Diese sind immer noch vorhanden und diese Limitierungen bestimmen bis Heute auch das Design der Kerne.

Sieht man sich sich den Firestorm-Kern an, dann kommt da ein Decoder, der 8 Befehle pro Takt decodieren kann, dahinter ist ein Backend mit 6 ALUs + DIV-ALU, macht also 7 ALUs, 2 Load-Einheiten, 1 Sore-Einheit und eine Load/Store-Kombi. Dazu 4 * 128Bit Neon.

Zen 3 kommt auf 4 ALUs, 3 AGUs und damit auf 3 Load + 2 Store pro Takt, Apple kann entweder 3 Load + 1 Store oder 2 Load + 2 Store machen und versorgt damit ein deutlich breiteres Backend. Warum? Weil man dank der "Masse" an Register wesentlich seltener in den Cache und in RAM muss.

Und da sind wir wirder bei den 70er und den 80er: In den 70er waren Transitoren "Teuer" und jedes unnötige Register war nicht gerne gesehen. In den 80er hat sich das geändert, denn man wusste, dass Zugriffe auf Caches und Speicher und damit das verbundene Warte nicht nur Energie kostet, sondern auch Zeit.

 

[Xes]

Ich bin gespannt ob sich bei größerer Verbreitung von ARM im Notebook, Desktop und Workstationsegment durch Apple, nicht auch Google dazu entschließt mit einem "Chromebook Pro" auf ARM Basis diese Märkte stärker anzugreifen. Qualcomm und co. warten mit Sicherheit schon gierig darauf dieses Feld zu beliefern.

Intel und AMD müssen hier zukünftig richtig Gaß geben um x86 in diesem Bereich als wichtigste Plattform zu halten. Nochmal 7 Jahre am Stück bei fast gleicher Leistung zu pennen (2010-2017 mit den Quadcores bei Intel und den lahmen FX bei AMD) wird man sich vermutlich nicht mehr leisten können...

 

[nagus]

WOW wie toll. 32+8 Threads in 2022 für eine PRO Workstation. AMD hat seit 2020 schon 128 Threads. IN 2022 hat AMD wahrscheinlich sogar schon 192 ... ZEN4 Threads

 

[Teralios]

Obs jetzt wieder mal die bessere Adaption OS-Hardware war, oder die Rohleistung weiß ich nicht..

Von der theoretischen Rohleistung, dürften beide sogar recht ähnlich sein, was ich da so an Blockdiagrammen finde und was beim PowePC an ALUs da war und beim Pentium, nur dass der Aufbau beim PowerPC deutlich einfacher war und das man - erneut wegen der Anzahl der Register - wesentlich seltener auf Daten warten musste und man auch vieles länger in den Registern halten konnte, was dazu führte, dass man schneller war.

Und auch heute - sieht man sich die Schaltpläne usw. an - fällt auf, dass man bei x86 ein riesen Aufwand betreiben muss um das Backend nur irgendwie möglich ausgelastet zu halten, während ARM-Desigsn da doch um ein gutes Stück einfacher aufgebaut sind.

Womit wir halt bei dem Punkt sind: Auch wenn auf Hardware-Ebene die heutigen x86 nichts mehr mit dem Ur-86 oder gar dem P5 zutun haben, die ISA merkt man dennoch.

 

[dero.O]

Dass der Mac Lichtjahre schneller

Hinweis: Mit Lichtjahren gibt man Entfernungen an, keine Geschwindigkeiten

Starke Antwort.
CB lässt definitv keine Gelegenheit aus Apple Zucker in den Hintern zu blasen.

Extra für den Kommentar angemeldet oder beglückst du weiterhin das Forum?


@nagus: nicht alles was hinkt ist ein Vergleich



Zum Thema: Liest sich spannend. Mal abwarten, wie gut das ganze skaliert

 

[Herdware]

Oh, da gibt es ein paar mehr Altlasten, als nur diesen Decoder, dafür müsste man aber mal etwas tiefer in die Materie eintauchen und ein Asselembler-Erfahrungen von CISC und RISC-Prozessoren mit bringen.

Ich gebe zu, ich habe wenig Ahnung, sowohl vom inneren Aufbau von CPUs als auch von (hardwarenaher) Programmierung. Aber wenn ich das nicht falsch verstehe, arbeiten moderne x86-CPUs intern doch sowieso unabhängig vom alten CISC-Befehlssatz. Es sind quasi RISC-CPUs, die (per Decoder) nur nach außen hin so tun, als wären sie noch CISC.

Es dürfte Intel und AMD also wenig daran hindern, die CPUs intern nach Herzenslust zu optimieren. Deshalb meine Annahme, dass es eigentlich nur der der Decoder ist, der die modernen x86er von alternatvien Architekturen unterscheidet.

Mir ist dazu auch ein alter Artikel über Intels damals neue Atom-CPUs auf Anandtech in Erinnerung, in dem auf ein nochmal älteres Interview mit dem damaligen Chefentwickler bei AMD Bezug genommen wurde.
Darin ging es um die Vor- und Nachteile von x86 z.B. gegenüber ARM und anderen RISC-CPUs.
Schon als AMD seine ersten 64Bit-K8-CPUs vorstellte, wurden sie gefragt, warum sie nicht, wie Intel mit dem Itanium geplant hatte, bei der Gelegenheit die x86-Kompatibilität ganz aufgegeben haben. Die Antwort war, dass der "Preis" für die x86-Kompatibilität nur sehr gering war. Den Decoder wegzulassen hätte nur einen kleinen Prozentsatz an Transistoren eingespart. Andere Vorzüge sah der AMD-Entwickler damals wohl nicht und auf der anderen Seite bedeutete die Kompatibilität zur bestehenden x86-Software einen riesigen Vorteil.

Ich hab den Artikel wider Erwarten tatsächlich wiedergefunden. Anandtechs Suchfunktion scheint inzwischen besser geworden zu sein. 😁
https://www.anandtech.com/show/2493/3

 

[NJay]

Ja richtig und du glaubst alle 168 Kerne können gleichzeitig das Video Rendern oder nur 32 oder 8 oder nur die 128 ?

Die 128 Kerne sind die "Kerne" der Grafikkarte, natuerlich koennen die nicht bei allen Lasten helfen, da es eben GPU-Kerne sind. Du beschwerst dich doch auch nicht, dass deine X GPu Kerne der Grafikkarte beim nutzen von Firefox gar nicht ausgelastet sind?

Im klassischen Desktopmarkt werden die Anzahl der GPU Kerne nicht so prominent erwaehnt, da der Chipname bereits zur Unterscheidung reicht.

In einem SOC muss man aber irgendwie ausdrucken, wie viele CPU und GPU Einheiten er hat. Man koennte jetzt den 128 Kernend er GPU einen namen geben und sagen, dass ist der M2 Chip mit der Peter-GPU oder Apple super mega RTX GPU 3001, oder man laesst solchen Marketing Bullshit und nennt einfach die Fakten, naemlich die Anzahld er GPU Kerne.

 

[Teralios]

Schon als AMD seine ersten 64Bit-K8-CPUs vorstellte, wurden sie gefragt, warum sie nicht, wie Intel mit dem Itanium geplant hatte, bei der Gelegenheit die x86-Kompatibilität ganz aufgegeben haben. Die Antwort war, dass der "Preis" für die x86-Kompatibilität nur sehr gering war. Den Decoder wegzulassen hätte nur einen kleinen Prozentsatz an Transistoren eingespart.

Vor weg: Ich will dich jetzt nicht angreifen, mit nichten, deswegen auch nicht in den falschen Hals bekommen, nur passt das jetzt an der Stelle wunderbar:

Und so, meine lieben Mitforisten, entstehen Fakenews in dem Aussagen nur zum Teil wiedergeben werden, der Kontext fehlt oder weil wichtige zusätzliche Informationen fehlen.

An der Stelle gibt es nämlich einen entscheidenden Punkt: AMD64/x64 oder x86_64 baute von den Befehlen her auf der ISA vom x86 auf und hat diesen Erweitert. Es handelt sich aber immer noch um eine CISC-CPU, die ohnehin einen komplexen Decoder gebraucht hat. Natürlich hätte man damals die Unterstützung für x86_32 auch fallen lassen können, nur - und darauf bezieht sich auch die Antwort des AMD-Entwicklers: Die Unterstützung hat an der Stelle den Kohl nicht mehr Fett gemacht.

 

[Tzunamik]

Die großen Chips sind garantiert nicht monolithisch.
Das wäre Apple untypisch. Die sehen ja bei AMD wie viel es bringt in Modulen zu arbeiten.
Das gleiche wird garantiert auch beim großen Jade 4C sein. Wieso sollte er den sonst 4C heißen? Na weil er vermutlich 4 Module beinhaltet.

 

[cruse]

Welche Anwendung, [..] soll von so vielen Kernen profitieren?

Benchmarks!

 

[Herdware]

An der Stelle gibt es nämlich einen entscheidenden Punkt: AMD64/x64 oder x86_64 baute von den Befehlen her auf der ISA vom x86 auf und hat diesen Erweitert. Es handelt sich aber immer noch um eine CISC-CPU, die ohnehin einen komplexen Decoder gebraucht hat. Natürlich hätte man damals die Unterstützung für x86_32 auch fallen lassen können, nur - und darauf bezieht sich auch die Antwort des AMD-Entwicklers: Die Unterstützung hat an der Stelle den Kohl nicht mehr Fett gemacht.

Vorweg, ich fühle mich natürlich nicht angegriffen und lerne gern dazu. 😁

Trotzdem bin ich nicht sicher, ob zutrifft was du schreibst, auch wenn ich sicher bin, dass du sehr viel mehr Ahnung über CPU-Architektur hast, als ich.

Intel hatte sich damals, bei Schritt auf 64Bit entschieden, auf eine ganz neue, modernere RISC-Archtektur zu wechseln (Itanium). AMD entschied sich bei erweitertem x86 und CISC zu bleiben, was aber, wenn ich die Aussage von Anand und Weber nicht ganz missverstehe, halt doch nur den Decoder betrifft und der Rest der CPU davon unabhängig ist.

Intern waren doch auch die x86-CPUs schon längst (seit dem Pentium Pro und AMD K6?) "RISC". Da unterscheiden sich AMD64, x86, IA64 und ARM letztlich nicht oder nur sehr wenig. Es war und ist nur der vorgeschaltete Decoder, der bei x86 und AMD64 noch vorgaukelt, es handle sich um eine klassische CISC-CPU.

Es mag durchaus so sein, dass sich "echte" RISC-CPUs trotzdem eleganter programmieren lassen, als die x86er, die nach außen noch wie CISC angesprochen werden. Aber was die "Rechenwerke" in der CPU selbst angeht, operieren doch alle mit den selben oder ähnlichen MicroOps.

Echtes CISC gibt es also aus Hardware/CPUs-Sicht schon seit den 90ern nicht mehr.

 

[Magellan]

Es dürfte Intel und AMD also wenig daran hindern, die CPUs intern nach Herzenslust zu optimieren.

Die Frage stellt sich dann was sie denn die letzten Jahre daran gehindert hat - es wird ja nicht daran liegen dass Apple als einzige auf die Idee kamen eine CPU zu bauen die gleichermaßen stark und effizient ist.

Aktuell sehe ich einen größer werdenden Vorsprung von Apples ARM SoCs kommen und kein Aufholen von x86.

Es ist ja sicher auch kein Zufall dass Amazon bereits Rechenzentren auf ARM umstellt, dass Google und MS eigene ARM SoC entwickeln usw...

 

[cruse]

Wir haben einige große Projekte zu compilen und da sind mehr kerne immer mehr besser.

Und die werden alle auf einem Laptop kompiliert?