AMD K12 -Spekulation

[MIWA]

Und das lange Zeit kein Linux drauf läuft mach die CPU noch uninteressant, aber ne CPU wie die M1 in ähnlicher Form.wie der Mac Mini und Linux/ Windows wäre sicher nice und auch Massenmarkt tauglich mehr oder weniger

 

[seTTam]

da würde mich echt mal die Performance in BOINC interessieren.

 

[Opteron]

Hätte vor einigen Jahren, als dieser Thread entstanden ist, nicht gedacht, dass sich ARM und x86 mal auf Augenhöhe begegnen würden in Sachen absoluter Performance, aber was Apple mit dem M1 veranstaltet, ist schon der Hammer

The 2020 Mac Mini Unleashed: Putting Apple Silicon M1 To The Test

www.anandtech.com

Tja .. 8fach superskalar ... da haben wir jetzt endlich das, was DEC vor 20 Jahren schon plante.

Was man aber auch nicht vergessen darf: Ein großer Teil der Mehrleistung dürfte auch aufs Konto des on-Packages DRAMs gehen. Was ein IMC bringt, wissen wir seit K7->K8, wenn das komplette RAM nun 2cm neben dem Compute-Die liegt, ist das ganz sicher auch nicht schlecht Das sind dann halt ganz andere Latenzen .. außerdem kann sich Apple beim Design dicke Puffer aufgrund 5nm Fertigung leisten. Das Design limitiert dann aber halt den Takt, was durch den aktuellen Fertigungs-Vorteil aber ebenfalls nicht auffällt.
Und dann ist noch die Frage, wie Apple eventuell die ganzen anderen SoC-Zusätze unter MacOS ausnutzt. Sind die bei den üblichen Workloads wirklich deaktiv?

Hätte ich so jetzt auch nicht erwartet bei Apples ersten ARM-Wurf für den Mac.

Na komm, die anderen Chips kennst Du doch sicher Das ist ne lineare Weiterentwicklung der bisheringen Chips. Da man mittlerweile leistungsmäßig in Desktopbereich angekommen kommen die Teile jetzt halt auch in den Desktop.

Interessant ist vielleicht noch, dass durch die kleinen Fertigungsstrukturen die Risc-Nachteile = größerer Code durch einen fetten 192 L1I-Cache pulverisiert werden kann. Dagegen ist jetzt die Frage, ob x86 seinen Nachteil - das riesige Front-End aufgrund der variablen Codelänge- ebenfalls entsprechend bekämpfen kann. Aktuell scheint man sich noch hinter dem breiter angebundenen µOp-Cache verstecken zu wollen.


Edit:

Nebenbei @topic: Samsung hat bekanntlich seiner eigene ARM-Architektur den Stecker gezogen. Eventuell setzt man jetzt auf den K12? Mittlerweile ist das Design zwar schon wieder älter, aber AMD baut einen sicherlich auch eine Version auf Zen3 Niveau oder besser

 

[Nero24]

Hätte ich so jetzt auch nicht erwartet bei Apples ersten ARM-Wurf für den Mac.

Na komm, die anderen Chips kennst Du doch sicher

Sicher, trotzdem ist das hier kein iPhone, sondern ein Mac. Ganz andere Workloads. Es ist der erste Mac mit ARM-Prozessor nach 15 Jahren Intel. Und dann so eine Performance! Nur zur Verdeutlichung: die sind mit dem ~25-W-Prozessor im Single-Thread-Workload auf Augenhöhe mit dem 105W-Zen-3! Dass sie zudem den Rosetta-2-Emulator so gut hingekriegt haben, dass x86-Code im Mittel auf 70% der Leistung des nativen Codes läuft, das ist in meinen Augen unglaublich. Ich bin wahrlich kein Apple-Jünger, aber da muss man echt mal Respekt zollen. Und das ist erst der erste Wurf. Warte mal die nächsten Jahre ab! Da dürfen sich Intel und AMD warm anziehen fürchte ich!

 

[Shearer]

Für die Endkunden ist es toll, einen dritten starken und innovativen Player im Markt zuhaben. Ich bin selbst ebenfalls sehr erstaunt, was Apple da abliefert, nach der sehr lauen Key-Note.

Apple hat seine Performance Führerschaft aus dem Mobile Handset Bereich nun in die mobilen PCs portiert und so wie es derzeit aussieht, könnte dass auch noch ein bis zwei Klassen höher (also bei Desktop PC) passieren. Dass klappt zwar nur mit der engen Verzahnung zw. Hard und Software, aber den Nutzer interessiert es am Ende nicht. Hauptsache es ist Blitzschnell, was es anscheinend ist. Zumindest in Apples Paradedisziplinen.

Hut ab, Apple!

Ich gehe davon aus, dass sie die großen Player aber das beste oder das am einfachsten umsetzbare aus den jeweilgen Konzepten "klauen" werden.

Intel hat bereits Produkte angekündigt, welche RAM auf dem Packaging haben, mittels Foveros und 3D Stacking.

AMD wird vermutlich folgen.

Und Apple schaut sich für Workstations vielleicht Chiplet Designs an... mal schauen.

 

[ONH]

Nur zur Verdeutlichung: die sind mit dem ~25-W-Prozessor im Single-Thread-Workload auf Augenhöhe mit dem 105W-Zen-3!

Da bin ich erstmal erstaunt das du das so aufhängst die amd cores sind im budget auch nicht für mehr als 20 W pro Stück ausgelegt, warscheinlich sogar eher 15 W. Dh tdp ist irrelevant für st was beeindruckend sein könnte ist das apple den verbrauch der anderen bereiche und idle cores tief halten kann.

Weiter hast du missverstanden Apple emuliert gar nichts mit Rosetta 2. Die App wird übersetzt und danach als arm 64 code ausgeführt. Dh. Kein overhead durch übersetzung wärend dem ausführen.
Mit den Resourcen die Apple hat, wäre ich erstaunt gewesen falls sie das nicht hinbekommen hätten. Zumal sie ja jede relevante bisherige anwendung in ihren store haben und demetsprechen ein nahe unendlich grosses testspektrom haben zudem wussten sie auch welche befehlabfolgen häufig sind und können diese auch besser optimieren auf ihre m1 prozessoren.

 

[Pinnacle Ridge]

Wie soll auf x86/AMD64 übersetzt werden können, ohne den Quellcode zu haben?

 

[Nero24]

@ONH @Pinnacle Ridge Rosetta 2 kann beides:

Rosetta ist ein Framework von Apple zur transparenten Emulation von Programmen für eine andere, vorher von Apple in den Computern der Mac-Reihe genutzten Prozessorarchitektur.
[..]
Rosetta 2 ist ein Teil von macOS Big Sur, um bei Apples Übergang von Intel-Prozessoren auf ARM-Prozessoren (Apple Silicon) zu helfen.[7][8] Zusätzlich zur Echtzeitübersetzung, wie schon mit Rosetta, unterstützt Rosetta 2 die Übersetzung des Programmes bei der Installation.[9]

Welche Methode dabei bei den Tests genutzt wurde, kann ich nicht sagen. Ich kann mir aber nicht vorstellen, dass ein Spiel mit mehreren GB Größe vorab übersetzt wurde. Das würde ja ewig dauern und die Autoren sagten auch nichts davon, sprachen stattdessen stets davon, wie wenig die Emulation Leistung kostet, was eher dafür spricht, dass bei den Tests der JIT-Emulation am Werk war.

 

[Complicated]

Nur zur Verdeutlichung: die sind mit dem ~25-W-Prozessor im Single-Thread-Workload auf Augenhöhe mit dem 105W-Zen-3!

Da bin ich erstmal erstaunt das du das so aufhängst die amd cores sind im budget auch nicht für mehr als 20 W pro Stück ausgelegt, warscheinlich sogar eher 15 W.

Also Nero sagt ein 25W Prozessor im Singlethread und nicht mit 25W CPU-Verbrauch im Singlethread. Ein 105W-Ryzen verbraucht Single Thread auch keine 105W.

Die App wird übersetzt und danach als arm 64 code ausgeführt.

Wie soll auf x86/AMD64 übersetzt werden können, ohne den Quellcode zu haben?

Und ONH sagt nicht x86/AMD64 sondern auf ARM64

 

[tomturbo]

Ich denke die Emulation wird so etwas ein: https://en.wikipedia.org/wiki/FX!32
Also das was DEC bereits 1993 konnte. Wow voll innovativ Apple
Ich bin immer wieder erstaunt wie die Scxxxx für Gold verkaufen können.

 

[ONH]

To the user, Rosetta is mostly transparent. If an executable contains only Intel instructions, macOS automatically launches Rosetta and begins the translation process. When translation finishes, the system launches the translated executable in place of the original. However, the translation process takes time, so users might perceive that translated apps launch or run more slowly at times.

Apple sagt sie übersetzen ihr binary und nicht emulation. Quelle: Apple dev Portal

Eigentlich wäre es doch sinnvoll, wenn Apple über den Store schon die übersetzten Apps verteilen würde, die mac sind ja identifizierbar über ihre so version, dann müsste nicht jeder neue mac das einzeln tun. Klar Rosetta benötigten sie weiterhin für nicht Store App.

 

[Woerns]

Jim Keller meint, dass das Einstampfen des K12 ein Fehler war.
The Register: Former AMD chip architect says it was wrong to can Arm project
MfG

 

[pipin]

Jim Keller meint, dass das Einstampfen des K12 ein Fehler war.
The Register: Former AMD chip architect says it was wrong to can Arm project
MfG

Das kocht ja gerade hoch.

Letzendlich ist es ja aber eher ne finanzielle Entscheidung gewesen, weil AMD damals nicht die Mittel und Personalressourcen hatte.

Ich mein, die haben zwischendurch ihr Hauptquartier verkauft und zurück geleast.

 

[eiernacken1983]

+1 zu @pipin 's Aussage:

2016 stand der Laden ja kurz vorm Zusammenbruch. Da macht es natürlich Sinn, seine Ressourcen auf die erfolgversprechendsten Produkte zu setzen bzw. hier auch abzuwägen, bei welchen Projekten das Geld am schnellsten zurückkommt. Wenn man sich anschaut, wie sich Zen (und inzwischen ja auch ein bisschen die Grafiksparte) entwickelt hat, war das offenbar keine schlechte Idee, sich auf x86 zu konzentrieren. Insofern könnte man die Aussage abschwächen, dass es ein grober Fehler gewesen wäre, K12 einzustampfen, wenn man die Ressourcen vom blauen Mitbewerber gehabt hätte.

Ich interpretiere mal rein, dass JK hier primär aus technischer Sicht bewertet hat, was ja damals auch seine Aufgabe war.

 

[Woerns]

Sehe ich auch so.
Interessant ist Kellers Aussage, dass eigentlich alle modernen Computer RISC Maschinen sind und dass man eigentlich nur die Dekoder austauschen muss, um z.B. zwischen X86 und ARM zu wechseln.
MfG

 

[MagicEye04]

Wenn es so einfach ist, dann kann das Projekt doch im Grunde jederzeit wieder neu belebt werden - z.B. wenn die Marktlage es erfordert.

 

[pipin]

Sehe ich auch so.
Interessant ist Kellers Aussage, dass eigentlich alle modernen Computer RISC Maschinen sind und dass man eigentlich nur die Dekoder austauschen muss, um z.B. zwischen X86 und ARM zu wechseln.
MfG

Das lässt dann ja auch die Frage zu, ob es ARM sein muss oder RISC-V.

Wäre ja eh der Treppenwitz, wenn AMD zum Beispiel Trenstorrent (mit Jim Keller) übernehmen würde.

Intel hat ja auch lange an SiFive gebaggert.

Wenn es so einfach ist, dann kann das Projekt doch im Grunde jederzeit wieder neu belebt werden - z.B. wenn die Marktlage es erfordert.

Das ist ja alles schön und gut, aber ich glaube AMD will sich da einfach nicht verzetteln.
Lisa Su betont ja auch immer wieder, dass sie es unter Umständen machen, wenn die Kunden es wünschen.

Das ist für mich aber eher eigentlich ein ausgeschmücktes Nein.

 

[E555user]

Ich denke der K12 konnte nicht vermarktet werden weil AMD damals in einer zu schwachen Situation im Servermarkt war. Man musste sich einfach auf x86 konzentrieren, weil hier kurzfristig viel mehr zu gewinnen war. Eine doppelte Vermarktung von ARM-Server-CPUs hätte zu viel Aufwand in der Vermarktung der Plattform gebraucht und am Ende womöglich zu viele potentiellen Kunden verwirrt. AMD brauchte eine klare Linie für die Kunden. Das Mantra war das zu Entwicklen und anzubieten, was die Kunden zuvor auch auf dem Wunschzettel hatten

Was Mark Keller anbelangt hatte er deutlich darauf verwiesen, dass Zen bzw. eine moderne X86 CPU im Kern auch nur eine RISC Architektur ist; d.h. das CISC bzw. die x86 ISA Interface reicht bis zum Micro-Op Cue vor den ALUs. K12 hat das Frontend in ARM dazu passend designed, deshalb wäre auch eine ARM CPU identisch möglich. Nach seiner Aussage müsste also auch ein RISC-V auf der Zen-Basis möglich sein. Ist auch irgendwie logisch.

Allein die Frage ob der typische ARM-Code vs. x86-Code gleichermassen von der Aufteilung der ALUs, FPU und Load/Stores profitiert müsste man hinterfragen. Aber ein C-Compilat, das entweder auf x86 oder ARM übersetzt wird, sollte schon ähnliche Anforderungen an die CPU haben. Bei ARM IMHO einfach viel weniger Aufwand im ISA-Decoding, in der Branch-Prediction und ggf. auch Micro-Op Cache notwendig. Dafür ist ein X86 Compilat durch die komplexere ISA von vorn herein etwas komprimierter, ARM Code braucht mehr Zugriffe auf den SysRAM.
Womöglich hat sich der Vorteil heute erledigt und ARM Architekturen laden den entsprechenden Code gleich schnell nach, es verliert sich in zunehmend grösseren Caches. Vorallem da tendenziell niemand mehr effizienten C-Code schreibt und auch X86 im Cache schon zugemüllt wurde, weshalb wir überhaupt Effekte von gigantischem L3 Cache sehen können.