Bericht Arm-Kerne 2023: Cortex-X4, A720 und A520 bilden reine 64‑Bit-Plattform

[ModellbahnerTT]

Bisher gibt's ja schlicht keine Notebook CPUs dieses Kalibers abseits von Apple.

Da ist den Firmen der Pflegeaufwand zu groß da man bei ARM keine Vorgaben macht Richtung coreboot und co.

Hoffentlich folgen AMD und Intel dem, wobei dann noch Microsoft ran muss

Auch hier ist es ein riesiger Aufwand den die meisten nur merken wenn es zu Problemen kommt.

Inwieweit man SBCs wie den Raspi unter embedded sieht, ist die Frage.

Mir scheint, die fallen zurueck:

Der Raspi ist aber der einzige der von allen supportet wird.

 

[cha0shacker]

Wenn ich das richtig verstanden habe, dann geht es um den rauswurf des ganzen Legacy Käses, den wir seit Anbeginn der Zeit mit rumschleppen. Aktuell booten moderne Cpus im 16bit realmode inkl. der ganzen Beschränkungen, die man aus DOS Zeiten noch kennt (640kb ram etc pp). Der Modus wird aktiv nicht mehr genutzt, sondern man pflegt einen Haufen Code (und Silizium), nur damit man die Cpu von 16bit in 64bit schalten kann. Fliegt das alles raus, dann bootet man direkt in 64bit und fertig. Die Pflege von Interrupts und so weiter spart man sich dann.

Die Konsequenz daraus ist natürlich das sowohl 16bit als auch 32bit nicht verfügbar bzw. nur noch eingeschränkt verfügbar ist. Solange Systemapps rein 64bit sind und normale Programme auch weiterhin in 32bit laufen ist doch alles super... 16bit hat doch eh kein modernes OS mehr Support für.

Klar, aufräumen ist immer was feines, aber Performance oder Effizienz-Verbesserungen wirds dadurch nicht geben. Die paar tausend Transistoren, die benötigt werden dafür sind unter 0,01% des gesamten Prozessors.

 

[Hancock]

Wie kommst da drauf? Viele der Sachen die rausfliegen sind theoretisch bei jedem Befehl dabei (Segmentregister z.B.), da wird schon gut was rausfallen und die Logik einfacher. Das bringt sowohl Effizienz als auch Leistung.

Wenn man jetzt noch ein weak ordered mode einführt, dann geht die Kiste ab, aber ich glaub, da sind die Software-Kompatibilitätshürden zu groß.

 

[mae]

Hmm, was bringt mir die Performance, wenn ich nur Interrupts crunche? Was ist die Fläche, die die Kerne brauchen, was ist der Leckstrom? Es ist naiv, nur die Effizienz zu betrachten.

Wenn die Performance nicht gebraucht wird, warum verbaut Quallcomm dann 4 von den A55 im Snapdragon 888? 4 brauchen vier mal soviel Flaeche wie einer und verbrauchen vier mal soviel Leckstrom. Und wenn man doch die Leistung von vier braucht, waere es da nicht besser, stattdessen sowas wie einen E-Core des A15 einzubauen?

Wobei ARM etwas passendes sogar im eigenen Haus findet: Der A75 ist bei seinem effizientesten Betriebspunkt doppelt so effizient wie der A55 bei gleicher Leistung und leistet mehr als doppelt soviel wie der A55 bei gleicher Effizienz (wobei zugegebenermassen die Frage ist, wie repraesentativ SPEC CPU 2006 fuer die Lasten auf den little cores ist); und dabei ist der A75 als P-Core entwickelt worden. Von einem in Richtung E-Core entwickelter OoO-Core wuerde ich mir noch mehr erwarten.

Ergänzung (30. Mai 2023)

Wie kommst da drauf? Viele der Sachen die rausfliegen sind theoretisch bei jedem Befehl dabei (Segmentregister z.B.), da wird schon gut was rausfallen und die Logik einfacher. Das bringt sowohl Effizienz als auch Leistung.

Segmentregister gibt's in AMD64 immer noch, die werden fuer thread-local storage verwendet. Ja, beim real mode und beim protected mode werden die Segmentregister anders verwendet als bei den 64-bit Programmen (kann mich an den Mode-Namen nicht mehr erinnern), aber das scheinen Intel und AMD gut im Griff zu haben, da wuerde ich mir keine nennenswerten Leistungs- oder Effizienzsteigerungen erwarten.

Und einen grossen Vorteil hat die ganze Kompatibilitaet bei den Intel- und AMD-Prozessoren: Ich kann mit dem selben USB-Stick alle PCs booten, waehrend die ganzen ARM-SBCs alle ihr eigenes Boot-Image brauchen. Den Vorteil der Intel- und AMD-Prozessoren wuerde ich nicht fuer einen kleinen Flaechen-, Effizienz- und Leistungsvorteil (wenn es ueberhaupt einen gibt) eintauschen; und als Endbenutzer haette man davon vermutlich eh nichts, da die beiden Konzerne das wohl nicht als Grund sehen, um die Preise oder die Power Limits zu senken.

 

[Piktogramm]

Wenn die Performance nicht gebraucht wird, warum verbaut Quallcomm dann 4 von den A55 im Snapdragon 888? 4 brauchen vier mal soviel Flaeche wie einer und verbrauchen vier mal soviel Leckstrom. Und wenn man doch die Leistung von vier braucht, waere es da nicht besser, stattdessen sowas wie einen E-Core des A15 einzubauen?

Mit den A5x und A5xx kann man die Anzahl an CPU-Cores erhöhen bei minimalen Kosten für Lizenzen und Chipfläche. Der Gewinn bei den Verkaufsargumenten ist jedoch groß. Da würde ich annehmen, dass die Konfiguration bei den SoCs nicht nur technisch zu begründen ist.

Aus technischer Sicht, bei den kleinen Coretex sind Kontextwechsel eine mittlere Katastrophe. Da ist es schon ganz praktisch, wenn man mehrere Kerne zu Verfügung hat, auf die sich Threads verteilen können.
Edit: Und im thermischem Budget ist wahrscheinlich oft auch kein Platz für noch mehr A7xx Xx Cores..
/Edit

Und Leistung braucht es sehr oft nicht. Die ganzen Benchmarks haben da immer das Problem, dass sie "nur" Fälle abbilden, wo extrem viel Last anliegt. Man rennt also in Fälle, wo mindestens eine kritischer Funktionsblock der Cores zum Nadelöhr wird. An der Stelle sind die kleinen Coretex wirklich nicht gut. Wo die kleinen Cores gut sind, sind kleine Aufgaben. Kurz mit einem Sensor "reden", Pakete vom Netzwerkmodem hohlen und parsen, Daten vom Festspeicher lesen/schreiben inkl. Dateisystemfoo, Daten/Pointer zu spezalisierten DSP schieben. Das sind so alles Fälle, wo ein OoO Design die Pipelines nicht gefüllt bekommt und viele Leertakte ausfüllt, nur um zu warten.

Und ja Apple, macht es anders und nutzt kleine OoO-Cores. Mein Verständnis geht bei iOS nicht all zu tief, aber tendenziell werden da Apps konsequenter angehalten und etwaige Jobs in Ticks zusammengefasst. Wenn man das sehr konsequent macht, bekommt man so einen OoO-Core auch gescheit ausgelastet.
Bei Windows, Android und den zigtausenden Linux, BSD, *nix Systemen da draußen ist das lange nicht so konsequent.

 

[Hancock]

Segmentregister gibt's in AMD64 immer noch, die werden fuer thread-local storage verwendet.

Yo, und wenn das nur noch dafür verwendet wird (fs:[rax], ...), dann kann man das statt in HW als Microcode ausführen und spart sich eine Addition pro Lookup (bzw. m.W. gibt es schon jetzt nen Performance-Penalty, wenn man ds auf != 0 setzt). Das Problem sind immer die kritischen Pfade und jeder Case ist halt ein weiterer Mux oder sogar ein Adder, der Fläche braucht und Slack klaut. Also raus damit, alles spezielle Microcoden. Wahrscheinlich sind 99 % aller ausgeführten Befehle aus < 10 % der verfügbaren Befehle. Mach ich also diese 10 % 10 % schneller (bspw. über höheren Takt), dann hab ich schon gewonnen, wenn die anderen nur noch 1/10tel so schnell sind.

Wenn ich AMD gewesen wäre hätte ich bei AMD64 schon MMX rausgeworfen, aber das Kind ist schon in den Brunnen gefallen.

 

[mae]

Yo, und wenn das nur noch dafür verwendet wird (fs:[rax], ...), dann kann man das statt in HW als Microcode ausführen und spart sich eine Addition pro Lookup (bzw. m.W. gibt es schon jetzt nen Performance-Penalty, wenn man ds auf != 0 setzt).

Wenn's mit Microcode implementiert wird, haetten sie das gleich ganz weglassen koennen (fuer den 64-bit-Modus). Aber klar, ein Zyklus mehr Latenz ist angemessen. Gibt's das DS-Register im 64-bit-Modus noch?

Also raus damit, alles spezielle Microcoden. Wahrscheinlich sind 99 % aller ausgeführten Befehle aus < 10 % der verfügbaren Befehle. Mach ich also diese 10 % 10 % schneller (bspw. über höheren Takt), dann hab ich schon gewonnen, wenn die anderen nur noch 1/10tel so schnell sind.

Nur gewinnst Du keine 10%, schon gar nicht ueber hoeheren Takt. Andere Architekturen haben nicht diese Extra-Addition des Segmentregisters, und haben keine hoeheren Taktfrequenzen; bzw. wenn (irgendwelche Power-Varianten), dann schlechtere IPC.

Wenn ich AMD gewesen wäre hätte ich bei AMD64 schon MMX rausgeworfen, aber das Kind ist schon in den Brunnen gefallen.

Soweit ich weiss, hat Intel seine SIMD-Befehlssaetze recht geschickt aufgebaut, sodass die kleineren immer als Spezialfaelle der groesseren behandelt werden koennen, das Eliminieren vom MMX haette also wohl nicht viel gebracht, und deshalb hat's AMD auch nicht gemacht. Bei 3DNow war das wohl anders.

 

[Hancock]

Nur gewinnst Du keine 10%, schon gar nicht ueber hoeheren Takt.

Das waren Beispielzahlen, weiß Intel wohl am Besten. Und es ist natürlich der Vergleich Intel vs. Intel. Andere Archs ist halt Äpfel zu Birnen.

MMX spiegelt in die FP Register, das ist sicherlich nicht ganz einfach "richtig" und gleichzeitig schnell zu machen. Eigentlich ein gutes Bespiel für das Legacy Zeug.

Nur als Beispiel, der Intel Intrinsics Guide zählt aktuell 7231 Intrinsics auf (https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html). Das ist Wahnsinn.

 

[mae]

Das waren Beispielzahlen, weiß Intel wohl am Besten. Und es ist natürlich der Vergleich Intel vs. Intel. Andere Archs ist halt Äpfel zu Birnen.

AMD weiss es auch und schafft aehnlich hohe Taktfrequenzen. Andere Architekturen unterscheiden sich eben gerade darin, dass sie weniger Legacy-Features haben. Die muessten nach Deinem Argument schneller laufen, entweder ueber Takt oder IPC; da kommt aber nur Apple in Schlagweite (ob deren hoher IPC tatsaechlich von der Architektur profitiert, ist mir noch nicht klar). Warum Du den Vergleich nicht zulassen willst, ist mir unklar.

MMX spiegelt in die FP Register, das ist sicherlich nicht ganz einfach "richtig" und gleichzeitig schnell zu machen. Eigentlich ein gutes Bespiel für das Legacy Zeug.

Offensichtlich ein Problem, das AMD und Intel schon geloest hatten, als AMD die AMD64-Erweiterung entworfen hat. Also haben sie's auch im 64-bit-Modus von AMD64 drinnengelassen, obwohl sie mit SSE2 einen vollwertigen Ersatz dafuer hatten.

Nur als Beispiel, der Intel Intrinsics Guide zählt aktuell 7231 Intrinsics auf (https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html). Das ist Wahnsinn.

Das haben die auf der Hardware-Seite im Griff, auch wenn's bei der Doku, und in der Unterstuetzungssoftware (Assembler, Disassembler, .h-Files, etc.) ein Riesenaufwand ist.

 

[Tzk]

Und einen grossen Vorteil hat die ganze Kompatibilitaet bei den Intel- und AMD-Prozessoren: Ich kann mit dem selben USB-Stick alle PCs booten, waehrend die ganzen ARM-SBCs alle ihr eigenes Boot-Image brauchen.

Müssen sich da nicht eher die ganzen ARM Entwickler an die Nase fassen, dass sie den Bootvorgang der ARM Cpus nicht standarisiert haben anstatt jeder ein eigenes Süppchen zu kochen? Mag natürlich auch daran liegen wo ARM anfangs eingesetzt wurde. Nutzt jeder OEM einfach ein proprietäres Image bzw. Firmware für sein Smartphone/Industrieplatinchen/Gerät dann ist es vermutlich Wurst... weil es eh keine Firmware wie Linux gibt, die so breit eingesetzt wird/werden kann um diese Geräte zu bereiten. Geschlossene und verrammelte Bootloader machen die Nummer nicht besser...

Ich würde mich jedenfalls freuen wenn die ARM IP zugänglicher für den Enduser wird, sprich man einfach regulär ein Win11 oder Linux installieren kann welches dann nativ auf ARM läuft und maximal via "Microsoft Rosetta" x86 Software ausführt.

 

[mae]

Müssen sich da nicht eher die ganzen ARM Entwickler an die Nase fassen, dass sie den Bootvorgang der ARM Cpus nicht standarisiert haben anstatt jeder ein eigenes Süppchen zu kochen?

Es muessen viele Akteure alles richtig machen, damit sowas funktioniert. Dazu braucht es ueblicherweise eine Instanz, die dafuer sorgt, dass sich die Akteure daran halten und das auch ueberpruefen koennen. Sowas wie die weite Verbreitung von Boot-Disketten in den Anfangszeiten des PCs. Bei den Uebergaengen zu CDs, zu USB-Sticks, zu UEFI gab's da immer wieder Schwierigkeiten, aber letztlich hat es funktioniert, weil die Kunden eben einen kompatiblen PC kaufen wollten. Und die selben Marktkraefte sorgen dafuer, dass das Legacy-Zeug nicht aus dem PC rausfliegt (zumindest laengere Zeit nicht, bis sich etwas neues etabliert hat; UEFIs haben noch immer das CSM, damit man von USB-Sticks (und vielleicht sogar Disketten) fuer BIOS booten kann. Und bevor sich da irgendwer das antut, die ganze Industrie auf einen 64-bit-Bootvorgang umzustellen, nur um in ferner Zukunft einmal den Real Mode entfernen zu koennen, laesst man den Real Mode lieber drin.

Bei den ARM-Sachen gibt's diese Kundenerwartung nicht, weil der Hauptmarkt sind die Mobiltelephone, und die werden schon als Gefaengnis verkauft, und die Kunden holen sich nur die Upgrades der Hersteller. Die SBCs nutzen nur SoCs, die eigentlich fuer Mobiltelephone entwickelt wurden, und auch wenn die Hersteller der SBC gerne eine vernuenftige Kompatibilitaet bieten wuerden, klappt das nicht besonders gut. Und wenn man schon einen SoC-spezifischen Linux-Kernel braucht, dann hilft ein gemeinsamer Boot-Standard halt auch nicht viel.

 

[KurzGedacht]

Da ist den Firmen der Pflegeaufwand zu groß da man bei ARM keine Vorgaben macht Richtung coreboot und co.

Naja auch AMD und Intel bauen bisher keine großen Notebook Chips, obwohl die Fähigkeiten dafür vorhanden sind.
Scheint also zumindest kein Arm spezifisches Problem zu sein.

Von einem Chip Monster wie bei Apple mit viel Cache, breiter Speicheranbindung und großzügiger GPU die man am Sweet Spot betreibt sind die Angebote von AMD/Intel weit entfernt.

 

[ModellbahnerTT]

Müssen sich da nicht eher die ganzen ARM Entwickler an die Nase fassen, dass sie den Bootvorgang der ARM Cpus nicht standarisiert haben anstatt jeder ein eigenes Süppchen zu kochen?

Nein ARM selber müsste die Vorgaben machen bei der Lizenzvergabe damit daran alle gebunden sind und es brauchbar funktioniert.

 

[Haldi]

warum verbaut Quallcomm dann 4 von den A55 im Snapdragon 888? 4 brauchen vier mal soviel Flaeche wie einer und verbrauchen vier mal soviel Leckstrom.

Uff ich glaub die ersten generationen big.LITTLE hatten noch ziemlich mühe mit der Threadübergabe und dem gemeinsamen Cache.
Somit mussten für 4 Grosse auch 4 Kleine kerne vorhanden sein, damit alles reibungslos lief.
Nicht sicher wann Aber ich glaub Mediathek hat die ersten 2 Core geräte mit 2 grossen und 4 kleinen gebracht.
Gibt es aber sehr sehr selten das mehr grosse als kleine Cores verbaut sind.