News Gegen Arm und RISC-V: AMD und Intel verbünden sich für die Zukunft der x86-CPU

Ist es für Intel überhaupt sinnvoll x86S und APX in zwei separaten Schritten einzuführen, oder sollte Intel x86S u. APX besser gemeinsam bringen?

Wenn man den Leakern glauben schenken darf dann plant Intel APX mit der nächsten Generation der Xeon CPUs in zwei Jahren (Herbst 2026), Codename Diamond Rapids, auf den Markt zu bringen, welche dann APX implementiert haben sollen.

AMD wird dann bei ihrer nächsten CPU Generation ebenfalls APX implementieren (müssen).
 
@ETI1120
Naja Keller nennt schon Randbedingungen und wie du schon richtig zitierst "it doesn't matter much"

Und überschaubar ist auch relativ, was Keller ja auch beschreibt. Der Aufwand ist da und wird im Verhältnis bei großen Kernen klein genug.

Für mich bleiben Probleme auch Probleme, wenn es eine Lösung gibt. Es ist mir schon zu häufig passiert, dass bei anstehenden Änderungen vergessen wurde, dass die bestehende Lösung viele Probleme mit div. Lösungen/Hacks kompensierte, die bei der Planung der Änderung vergessen wurden.

@WinnieW2
Wieso sollten sie das zusammenziehen? Die Erweiterungen bzw. Modifikation überschneiden sich nicht.
 
Piktogramm schrieb:
Wieso sollten sie das zusammenziehen? Die Erweiterungen bzw. Modifikation überschneiden sich nicht.
Soweit Intel das mitgeteilt hat soll APX nur im 64 Bit Modus aktiv sein.
Sowohl x86S als auch APX sind recht umfangreiche Änderungen an der CPU Architektur. Weshalb sollte Intel zwei solch umfangreiche Änderungen in zwei Schritten vornehmen anstatt diese zusammen zu legen?
Zumindest APX zuerst und x86S als nächsten Schritt würde bedeuten, zuerst die CPU-Architektur verkomplizieren und dann wieder vereinfachen.
Die Frage ist ob es die Testprozedur vereinfacht wenn beide Änderungen zusammen durchgeführt werden.

Ob in 2026 wirklich nochmal jemand ein 32 Bit OS auf einen neuen Rechner installieren möchte halte ich für ziemlich fragwürdig, und gerade bei Server-CPUs dürfte 32 Bit Software praktisch keine Rolle mehr spielen.
 
@WinnieW2
APX kann man einführen und hat kein Problem mit historischem Altlasten. Bei x86S würde ich davon ausgehen, dass da bei einigen Partnern doch Dinge kaputtgehen. Dabei sehe ich für die Performance und Effizienz eh den (viel) größeren Sprung bei APX und das im Zweifelsfall zu verzögern bis x86s produktiv gehen kann wäre ein Fehler.
 
Piktogramm schrieb:
APX kann man einführen und hat kein Problem mit historischem Altlasten.
Ja, kann man, aber APX bringt ohne neu compilierten Programmcode keine Vorteile und keine höhere Performance; und wenn ohnehin für APX neu compilierter Programmcode notwendig ist um diese Erweiterung zu nutzen, weshalb dann nicht auch gleich auf x86S gehen?

Oder wie funktioniert APX-enabled Programmcode auf nicht-APX-fähigen x86 CPUs?
 
Zuletzt bearbeitet:
@WinnieW2
Software die man einfach mal durch den Compiler zieht um neue Erweiterungen mitzunehmen sind typischerweise Programme aus dem Userspace, die betrifft die Änderung von x86S eher nicht.
Auf Ebene von Firmware, Betriebssystemen ist x86S jedoch relevant, da ist die Gefahr das etwas kaputt geht und da hilft kein Compiler der Welt.
 
Zurück
Oben