ETI1120 schrieb:
Aber er hat eben keinen Arm-Kern gewählt.
Er hat das gewählt was seine Arbeitgeber ihm vorgeben.
Er sagt aber auch, dass heute, wenn er denn dürfte, auch eher RISC-V nimmt als x86 oder ARM und das auch wegen den ganzen Extensions, die es aufblähen.
ETI1120 schrieb:
Und er hat viel Zeit darauf verwendet zu erklären dass X86 kein grundsätzliches Problem hat.
Jaein, weil er hier auf die Fragen des Redakteures genatwortet hat und es - auch in seinen Aussagen - um primär zwei Punkte ging: Die Befehle und damit verbunden die Decoder und auf die Weiterentwicklung der ISA die heute zu einigen Problemen führen und die Designs auch komplex machen.
Über die anderen Vor- und Nachteile der jeweiligen ISAs hat Jim Keller überhaupt nicht gesprochen und sie ware auch nicht Thema des Interviews.
RISC vs CISC (ARM vs. x86) wird heute oft immer noch auf den Decoder reduziert und entsprechend wir da auch sehr viel Bullshit verbreitet - ich bin da auch ein paar Fehlern erlegen, weil ich noch die "alten" RISC-Werte Intus hatte bis vor einige Zeit.
Aber es gibt auch andere Unterschiede zwischen ARM und x86, die ebenso Teilweise die Logik der einzelnen Bestandteile eines Kernes betreffen und entscheidend sind, wie Komplex eine Lösung ausfallen muss und welche Hilfsmittel man wann schon braucht.
ETI1120 schrieb:
Und ich fand seine Aussagen zur Arm-ISA nicht gerade wohlwollend.
Seine Aussagen ware weder zu ARM noch x86 wirklich wohlwollend, wenn man es genau nimmt und er hat beide - stark vereinfacht - als Bloatware bezeichnet, weil sie über die Jahre verfettet und vermüllt wurden.
ETI1120 schrieb:
Dass die Firestorm-Kerne so schnell sind liegt an den ganzen Hardwareeinheiten und Caches die Apple eingebaut hat. Wenn wir schon
anandtech zitieren:
... das schreibe ich aber in fast jedem Thema zum M1 wobei das mit dem Cache nicht ganz stimmt, auch dazu habe ich die passende Rechnungen mal hinzu gefügt.
Die Leistung der Firestorm-Kerne beruht auf einem richtig breiten fetten Design: Decoder der 8-Befehle pro Takt schafft. Ein Backend, dass mit 6 INT-ALUs und 4 * 128 Bit-VEC-ALU (Neon) daherkommt. Dazu ein riesiges Register-File - was auch zum Teil notwendig ist, müssen 31/32-Register pro ALU vorgehalten werden. Dazu kommt ein riesiger Out-of-Order-Buffer zur Sortierung und die Buffer für die Branchprediction sind auch nicht ohne!
Ein so großes Front- und Backend wollen auch mit Daten gefüttert werden, gerade die Befehle müssen quasi in riesiger Geschwindigkeit vorliegen und in den Decoder geschaufelt werden. So ein breites Design bedingt sehr breite Caches und würde an kleinen Caches quasi verhungern und würde die Leistung nicht auf die Straße bringen.
Die Caches haben natürlich einen Anteil daran, aber große Caches alleine helfen am Ende wenig - SunnyCove zu WillowCove - wenn man nicht an anderen Stellen auch entsprechende Anpassungen vornimmt.
ETI1120 schrieb:
Intel ist mit Alderlake von einem 4-wide auf ein 5-wide decode gewechselt. Ob der Autor recht damit hat, dass die X86 nicht breiter werden können, weil die variable Instruktionsbreite ähnlich breite Decodedesigns bei X86 verhindert, kann ich nicht beurteilen.
Nö, bei AlderLake ging es von einem 4-wide Decode sogar auf einen 6-wide Decode. Im INT-Bereich des Kernes ging es von 4-wide auf 5-wide.
ETI1120 schrieb:
Ich finde es übrigens witzig, dass Apple mit den M1-SoCs APUs bereitstellt, wie wir seit Jahren von AMD erwarten. Dabei hat Apple auch die erforderliche Softwareunterstützung bereitgestellt.
Ja, dass muss man Apple an der Stelle auch lassen. Ich werde kurz flapsig: "Metal is for everyone!". Im Endeffekt zeigt sich hier auch Apples Bemühung saubere APIs, Frameworks und Co für ihr Betriebssystem umgesetzt zu haben, die man nutzen soll. Es gibt für alles irgendwas, was man nutzen soll, statt "nativen" ISA-Code.
Da kann sich Microsoft mal eine Scheibe von abschneiden. Mal sehen, wie es mit der neune "Win32" wird.
Nixdorf schrieb:
Schon ist das ein eher knappes Rennen, und der Ryzen ist noch nicht einmal aus der aktuellsten Generation und auf einem älteren Fertigungsverfahren (TSMC N7 zu N5). Bei den absoluten Werten ist der M1 Max dennoch vorne, auch weil hier 10 gegen 8 Kerne antreten.
Die Rechnung hab ich schon angestellt und es kommt halt drauf an, was man wählt als Ausgangsbasis:
https://www.computerbase.de/forum/threads/apple-silicon-m1-ultra-2-x-m1-max.2075111/post-26692669
Wählt man die 45 W, stimmt es, geht man auf den M1 dreht sich es wieder, da ist Apple haushoch überlegen. Der M1 ist dabei nähet an 6900 und Core i7/9 was die Leistung angeht.
Im Endeffekt kann man hier alles Errechnen und jede Aussage stützen.