eastcoast_pete schrieb:
Eher enttäuschend! Bei allen tatsächlichen und vermutlichen Verbesserungen bei den großen Kernen (X4 und A720) ist es doch schade und auch verwunderlich daß ARM nach wie vor ihre kleinen Kerne als in-order Designs ausführt.
OoO erzwingt ein deutlich größeres Budget bei Transistoren und schlussendlich Energie.
Siehe auch die Analyse von Chips and Cheese zu ARMs A53:
https://chipsandcheese.com/2023/05/28/arms-cortex-a53-tiny-but-important/
Solang es nur darum geht simpelste Aufgaben zu lösen, wären größere Designs schlicht Verschwendung. Ein bisschen Protokoll für Netzwerkprotokolle, für Anwendungen Datenhäppchen via Push/Pull besorgen, Sound abspielen reicht die A5x und A5xx Familie ja locker.
eastcoast_pete schrieb:
Die bei Apples Bionic SoCs als "efficiency cores" geführten kleineren Kerne sind ja schon seit mehreren Generationen out-of-order Designs, und das ist wohl auch einer der Gründe warum diese Kerne gut die doppelte IPC haben wie die kleinen in-order Stock ARM Kerne; bei übrigens fast gleicher Leistungsaufnahme. Dazu kommt, daß mit mehr Leistung der kleinen Kerne es auch seltener notwendig ist, die großen (und mehr Strom verbrauchenden) Kerne zu benutzen, was Batterie spart.
In jedem Apple SoC (und jedem anderem SoC auch) sitzen meist noch ein gutes weiteres Dutzend ARM-Cores as Controller und Co-Prozessoren. Die sieht das Betriebssystem nicht, diese Controller können aber recht viel. Ich wäre mir da gar nicht so sicher, dass bei Apple keine noch kleineren inOrder Designs verbaut sind.
Wenn man dem Asahi Linux Projekt folgt, bekommt man immer wieder mit, wie die Entwickler neue Controller[1] "finden" und was die Firmware bei Apple alles im Hintergrund erledigen kann.
[1] Ohne genauere Analyse, was für Cores das sind. Das würde dem Ziel Linux auf Apple Si zu verbessern schlicht nicht helfen.
eastcoast_pete schrieb:
Wenn einer von Euch (CB) hier Mal die Gelegenheit hat, fragt ARM doch bitte, warum sie bei den kleinen Kernen immer noch auf in-order setzen.
Für moderne, mobile Geräte ist das eine gute Lösung. Moderne Geräte haben quasi ständig irgend eine aktive Verbindung, irgendwelche Sensoren die zu verwalten sind. Entweder packt man da zig Controller mit eigener Firmware in den SoC, oder man lässt den Spaß vom Betriebssystem/dessen Userspace bearbeiten und da reichen 1..4 kleine Kerne und sind effizienter als alle OoO Designs.
7H0M45 schrieb:
Generell bin ich mal gespannt auf den X4. Vor allem wie der im Vergleich zu den Apple Cores abschneidet
Wenn die X4 am Markt sind, wird der M3 bei Apple auch spruchreif sein. Ich würde davon ausgehen, dass Apple da weiterhin besser dasteht. Die meisten Lizenznehmer von ARM eskalieren die Möglichkeiten der IP-Blöcke nicht. Wo Apple einfach mal 192kB L1i Cache vorsieht, sind die realen Coretex X3 meist auf 64kB beschränkt, obwohl das Design mehr könnte. Beim ReorderBuffer ist es ähnlich, da eskaliert Apple, das X3 Design bleib da konservativer.
Leider fanden die Diskussionen und Analysen fast nur auf Twitter statt und das wieder auffinden ist entsprechend schwer (bis unmöglich, weil die Leute ihre Accounts gelöscht haben..). Aber Apple hat wirklich viel daran gesetzt ihre 8 Pipelines möglichst immer zu füllen. Da kann das X4 Design breiter sein, es deutet aber nichts daraufhin, dass auf eine optimale Füllung derart optimiert wurde und noch weniger deutet darauf hin, dass die kleinste Konfig des X4 (die halte ich für am wahrscheinlichsten, dass sie real implementiert wird), eine Chance hat die Pipelines wirklich gut zu füllen.
0x8100 schrieb:
32 bit apps sollen in ring 3 noch weiter funktionieren:
Anhang anzeigen 1362027
sie werden schon erkannt haben, dass ein komplett fehlender 32bit support wohl nicht so gut ankommt.
Bei Ring3 kann man aber auch ne Emulationsschicht drunter werfen. Entsprechend könnte Intel da wirklich großzügig alle 16bit und 32bit Befehle rauswerfen.
