News Spectre: Details zu Microcode-Updates für CPUs von AMD

Iscaran schrieb:
Kein Wunder dass Microsoft hier sich eher für die weiterentwicklung auf "bekanntem" Gebiet entschlossen hat und daher eher die AMD64 erweiterung für den 64bit Code support gehen wollte.

Also wenn du dich schon eingelesen hast, solltest du vielleicht auch gemerkt haben das sich Microsoft nicht für AMD64 entschlossen hat sondern IA-64 von Beginn an unterstützt hat!

Erst als nach fast 10 Jahren die Entwicklung sich noch immer nicht richtig durchsetzen konnte, hatte man beschlossen die Unterstützung dafür einzustellen.

Durch AMD gab es zu diesen Zeitpunkt eine Alternative, die zwar nur eine Erweiterung der bestehenden Architektur gewesen ist, dafür jedoch mit alter Software genauso schnell funktioniert hatte. Am Ende hat man statt einer neuen VLIW Architektur nur noch weitere SIMD Erweiterungen eingebaut, so dass moderne CPUs mittlerweile unzählige MMX, SSE und AVX Befehlserweiterungen mitschleppen, die wegen ihrer Komplexität doch wieder nur von wenigen Applikationen unterstützt werden.

Das Itanium komplexer war steht außer Frage, aber gerade die aktuelle Problematik zeigt wo es hinführen kann wenn eine CPU zum Patchwork gerät und nur noch mehr Caches, Sprungvorhersagen, Prefetcher oder andere Dinge hinzukommen.

Ob Itanium die "bessere" Lösung gewesen wäre, kann man vermutlich schlecht sagen. Mit Itanium wären aber viele Dinge anders verlaufen und wir würden uns nicht 18 Jahre später mit 32Bit Software, BIOS oder eben Spectre rumschlagen. Das bisheriger Code nur emuliert wurde, war eigentlich ein Segen und hätte alle dazu gezwungen die Software neu zu entwickeln. Stattdessen gibt es vor allem im professionellen Bereich bis heute Anwendungen die in VB6 geschrieben wurden.
 
Zuletzt bearbeitet:
xexex schrieb:
Erst als nach fast 10 Jahren die Entwicklung sich noch immer nicht richtig durchsetzen konnte, hatte man beschlossen die Unterstützung dafür einzustellen.

Ja und der Grund dafür war nicht die AMD64 erweiterung von x86.
Deswegen versteh ich ja deinen Vergleich hier auch nicht.

Es gab davor schon andere CPU ideen, die in die Richtung von Itanium gingen. z.B. Alpha:
https://de.wikipedia.org/wiki/Alpha-Prozessor

Viele der Entwickler von Alpha landeten dann ja auch bei Intels Itanium Abteilung.

Das Itanium komplexer war steht außer Frage, aber gerade die aktuelle Problematik zeigt wo es hinführen kann wenn eine CPU zum Patchwork gerät und nur noch mehr Caches, Sprungvorhersagen, Prefetcher oder andere Dinge hinzukommen.

Ja die "komplexität" als solche ist gar nicht soviel anders...
EDIT: https://de.wikipedia.org/wiki/Intel_Itanium_2
"Zum Einen zeigen sich die theoretischen Vorteile des VLIW-Designs in Sachen verminderter Chip-Komplexität nicht am tatsächlichen Prozessor."
/EDIT
es ist halt schlicht ein fast völlig anderer Ansatz wie man "Parallelisierung" in CPUs angeht. Ein Ansatz der eben erfordert dass die Programmierer die CPU-Architektur quasi "direkt" ansprechen müssen.
Etwas vergleichbares ist ja der Ansatz aktuell in der GPU-Entwicklung wieder mehr zum "Metall" hinzugehen, also Hardwarenäher zu sein. Und sie dir an wie schwierig der Prozess ist und wie sehr sich die Entwickler dagegen sträuben den Weg zu gehen.

Mit Itanium ist man hier noch um viele Größenordnung "näher" am Metall als aktuell bei den GPUs mit Vulkan/Mantle/DX12.

Und DAS ist der Grund warum sich dieser Weg auch nach 10 Jahren nur in wenigen Nischen etabliert hat.

Ob Itanium die "bessere" Lösung gewesen wäre, kann man vermutlich schlecht sagen. Mit Itanium wären aber viele Dinge anders verlaufen ...

Ja das kann man wohl schlecht sagen - bzw. eigentlich schon. Itanium IST die schlechtere Lösung für 99% der Anwender. Denn in Nischen insbesondere wo man sowieso eigene Software für ein Problem entwickeln muss kann und IST Itanium auch die bessere Lösung.
EDIT: Nach Messungen („Benchmarks“) aus dem Jahre 2010 mit Itanium 9350 liegt die CPU im SPEC-Vergleich CINT-2006-Rate und CFP-2006-Rate sehr deutlich hinter der aktuellen Power7-Familie von IBM und ebenfalls hinter den aktuellen Xeon-CPUs von Intel (zur besseren Vergleichbarkeit wurden die Power7-Testergebnisse auf 8 Rechenkerne normiert.
https://de.wikipedia.org/wiki/Intel_Itanium_2

Genau DAS ist das Problem an Itanium....selbst ein Power7 schlägt das Ding in der reinen Performance..../EDIT

ABER Itanium ist natürlich nicht anfällig für Spekulative Ausführungsattacken (Spectre) - aber WER WEISS wofür sonst....ist also ein bisschen schwierig diesen Vergleich zu führen.

EDIT: Deswegen ist er ja auch für "mission critical" sehr gut geeigenet (siehe Wiki) /EDIT
 
Zuletzt bearbeitet:
xexex schrieb:
Also wenn du dich schon eingelesen hast, solltest du vielleicht auch gemerkt haben das sich Microsoft nicht für AMD64 entschlossen hat sondern IA-64 von Beginn an unterstützt hat!
Das bedeutet was genau? Dass MS diesen Marktanteil nicht komplett den Unix/Linux-System überlassen wollte um damit Geld zu verdienen?
xexex schrieb:
Erst als nach fast 10 Jahren die Entwicklung sich noch immer nicht richtig durchsetzen konnte, hatte man beschlossen die Unterstützung dafür einzustellen.
Eine Konsequenz daraus, dass selbst am Server-/High-Perfromance-Markt kein nennenswertes Interesse an der Architektur bestand. Im Desktop-Bereich hat der Itanium eh nie eine Rolle gespielt.
xexex schrieb:
Durch AMD gab es zu diesen Zeitpunkt eine Alternative, die zwar nur eine Erweiterung der bestehenden Architektur gewesen ist, dafür jedoch mit alter Software genauso schnell funktioniert hatte. Am Ende hat man statt einer neuen VLIW Architektur nur noch weitere SIMD Erweiterungen eingebaut, so dass moderne CPUs mittlerweile unzählige MMX, SSE und AVX Befehlserweiterungen mitschleppen, die wegen ihrer Komplexität doch wieder nur von wenigen Applikationen unterstützt werden.
Weder MMX, SSE noch AVX wurde von AMD entwickelt oder ist an x86-64 gekoppelt. Übrigens verwenden moderne Compiler diese Erweiterungen auch ohne manueller Optimierung, wenn auch der Performancevorteil größer wird wenn bei rechenintensiven Operationen direkt vom Programmierer Anpassungen vorgenommen werden.
xexex schrieb:
Das Itanium komplexer war steht außer Frage, aber gerade die aktuelle Problematik zeigt wo es hinführen kann wenn eine CPU zum Patchwork gerät und nur noch mehr Caches, Sprungvorhersagen, Prefetcher oder andere Dinge hinzukommen.
Schuld ist eine schlampige Implementierung, könnte also (da vom selben Hersteller) auch beim Itanium was schlummern, hat nur keiner Interesse daran was zu suchen, da obsolet.
xexex schrieb:
Ob Itanium die "bessere" Lösung gewesen wäre, kann man vermutlich schlecht sagen. Mit Itanium wären aber viele Dinge anders verlaufen und wir würden uns nicht 18 Jahre später mit 32Bit Software, BIOS oder eben Spectre rumschlagen. Das bisheriger Code nur emuliert wurde, war eigentlich ein Segen und hätte alle dazu gezwungen die Software neu zu entwickeln. Stattdessen gibt es vor allem im professionellen Bereich bis heute Anwendungen die in VB6 geschrieben wurden.
Super, bei neu geschriebener SW sind dann neue statt alte Fehler enthalten :). Wäre auch gar nicht nötig, solange da ein Windows drunter läuft hätte der nicht HW-Abhängige Teil mehr oder weniger nur neu durch einen Itanium-Compiler gejagt werden müssen. Und schon läuft die 32 Bit VB6-Anwendung wieder, da der Itanium auch 32 Bit konnte...

Irgendwie beschleicht mich das Gefühl dir ist nicht ganz Bewusst was du schreibst ;).
 
Zuletzt bearbeitet: (Groß-/Kleinschreibung :D)
iamunknown schrieb:
Das bedeutet was genau? Dass MS diesen Marktanteil nicht komplett den Unix/Linux-System überlassen wollte um damit Geld zu verdienen?

Eine Konsequenz daraus, dass selbst am Server-/High-Perfromance-Markt kein nennenswertes Interesse an der Architektur bestand. Im Desktop-Bereich hat der Itanium eh nie eine Rolle gespielt.

Bevor AMD mit AMD64 kam war Itanium der einzige Ansatz für eine x64 Architektur. Logischerweise hat Microsoft da von Anfang an passende Serversoftware bereitgestellt. Zu diesem Zeitpunkt fehlte jedoch noch der Reiz überhaupt auf x64 umzusteigen.

Itanium wurde im Jahr 2000 präsentiert. Selbst bei (Windows) Servern kam man mit der 32Bit Architektur zurecht und die Unterstützung von x64 war zu diesem Zeitpunkt ähnlich gut wie die Unterstützung von DX12 derzeit. Die Situation ist übrigens vergleichbar auch wenn derzeit zum Nachteil von AMD. GCN würde wesentlich besser mit DX12 funktionieren, aber weil NVidia sehr gut mit "bewährten" DX11 funktioniert passiert selbst nach Jahren gar nichts.

iamunknown schrieb:
Weder MMX, SSE noch AVX wurde von AMD entwickelt oder ist an x86-64 gekoppelt. Übrigens verwenden moderne Compiler diese Erweiterungen auch ohne manueller optimierung, wenn auch der Performancevorteil größer wird wenn bei Rechenintensiven Operationen direkt vom Programmierer Anpassungen vorgenommen werden.

Die genannten SIMD Erweiterungen sind allesamt ein Patchwork, der nach und nach an die bestehende Architektur "angeklebt" wurde. Bevor du mich der Unwissenheit beschuldigst, solltest du dich vielleicht besser selbst informieren.
https://www.bernd-leitenberger.de/simd-vliw.shtml


iamunknown schrieb:
Wäre auch gar nicht nötig, solange da ein Windows drunter läuft hätte der nicht HW-Abhängige Teil mehr oder weniger nur neu durch einen Itanium-Compiler gejagt werden müssen. Und schon läuft die 32 Bit VB6-Anwendung wieder, da der Itanium auch 32 Bit konnte....

Ich glaube du hast die Technik hinter Itanium nicht begriffen. Eine VB6 Anwendung wäre unter Itanium immer im Emulator gelaufen und wäre schnarchlangsam. Die Entwickler hätten seinerzeit das machen müssen, was erst heutzutage Schritt für Schritt geschieht: Die Applikationen neu entwickeln und alte Zöpfe, Bibliotheken und Komponenten entsorgen.
http://www.hardwaresecrets.com/intel-64-bit-architecture-ia-64/2/

Apple hatte das "Glück" mit der Umstellung von System 7 auf macOS X und dann nochmal mit der Umstellung auf Intel Hardware. Eine Zeit lang gab es eine Emulation, heute ist alles neu entwickelt und man schleppt keine alte Grütze mehr mit.
 
Zuletzt bearbeitet:
xexex schrieb:
Bevor AMD mit AMD64 kam war Itanium der einzige Ansatz für eine x64 Architektur. Logischerweise hat Microsoft da von Anfang an passende Serversoftware bereitgestellt. Zu diesem Zeitpunkt fehlte jedoch noch der Reiz überhaupt auf x64 umzusteigen.
Erster Fehler: Itanium != x64. Zweiter Fehler: Die erste 64-Bit-Umstellung erfolgte bei MS (intern) auf die von Alpha, wenn auch nie erschienen: https://technet.microsoft.com/en-us/library/2008.08.windowsconfidential.aspx
xexex schrieb:
Itanium wurde im Jahr 2000 präsentiert.
Und ca. 40 Jahre früher waren Prozessoren mit 64 Bit Wortbreite verfügbar. Und?
xexex schrieb:
Selbst bei (Windows) Servern kam man mit der 32Bit Architektur zurecht und die Unterstützung von x64 war zu diesem Zeitpunkt ähnlich gut wie die Unterstützung von DX12 derzeit.
Nochmal: 64 Bit != x64. Und lass den Vergleich mit DirectX, das ist nur eine API. Sehr gut ist übertrieben, nicht umsonst gab es mit PAE einen Weg auch mit 32 Bit Betriebssystemen HW-Unterstützt mehr als 4GB RAM anzusprechen. Bei Hochleistungsrechnern war die späte Umstellung von Windows auf 64 Bit kein Problem, dort war Windows früher überhaupt nicht vertreten und auch heute hat es einen schweren Stand.
xexex schrieb:
Die genannten SIMD Erweiterungen sind allesamt ein Patchwork, der nach und nach an die bestehende Architektur "angeklebt" wurde. Bevor du mich der Unwissenheit beschuldigst, solltest du dich vielleicht besser selbst informieren.
https://www.bernd-leitenberger.de/simd-vliw.shtml
Wo habe ich behauptet es wären keine Erweiterungen? Steht doch sogar im Zitat...
Was sind denn die Nachteile der nachträglichen Befehlserweiterungen gegenüber einer neuen Architektur?
xexex schrieb:
Ich glaube du hast die Technik hinter Itanium nicht begriffen. Eine VB6 Anwendung wäre unter Itanium immer im Emulator gelaufen und wäre schnarchlangsam. Die Entwickler hätten seinerzeit das machen müssen, was erst heutzutage Schritt für Schritt geschieht: Die Applikationen neu entwickeln und alte Zöpfe, Bibliotheken und Komponenten entsorgen.
Ok, jetzt wird es mir langsam zu blöd. Welchen Kenntnisstand hast du den von der Funktionsweise von Rechnersystemen? Ich frage deshalb, weil dir der Unterschied einer Programmiersprache zu Maschinencode nicht bekannt ist - das wären dann die absoluten Basics...
xexex schrieb:
Apple hatte das "Glück" mit der Umstellung von System 7 auf macOS X und dann nochmal mit der Umstellung auf Intel Hardware. Eine Zeit lang gab es eine Emulation, heute ist alles neu entwickelt und man schleppt keine alte Grütze mehr mit.
"Glück" war nicht der Grund auf die Umstellung zu OS X (Basis von nexT gekauft), eher die veraltete Architektur von mac OS Classic. Die Umstellung auf x86 war mangels energieeffizienter Power-PC-CPUs für die Notebooks auch keine freiwillige Entscheidung - der Itanium ist es allerdings bewusst nicht geworden ;).
Abgesehen vom BIOS (das könnte auch für einen Itanium implementiert werden) zieht Apple übrigens HW-Seitig die selben "Patchworks" mit, auch wenn sie Softwareseitig schnell mal ältere Dinge abschneiden - wenn MS das machen würde hätten sie im Business-Bereich ein winziges Problem: Wenn schon eine sehr teure und kritische Umstellung ansteht könnte man als Kunde auch weg von MS...
 
Zuletzt bearbeitet:
iamunknown schrieb:
Was sind denn die Nachteile der nachträglichen Befehlserweiterungen gegenüber einer neuen Architektur?...

Das wir nun nach 18 Jahren bei AVX512 angelangt sind..... Sprich es werden immer mehr und mehr Flicken eingebaut um letztlich Sachen zu realisieren, die man mit VLIW machen wollte und aus Gründen der Kompatibilität nutzt nur ein Teil der Software solche Erweiterungen.

Den Rest meine Aussage willst du anscheinend nicht verstehen. Weil man seinerzeit den "leichten Weg" genommen hat, leben wir bis heute mit Altlasten. Es hat gut 15 Jahre gedauert bis BIOS endlich zu Grabe getragen wird, mit all den damit verbundenen Problemen. Es wird vermutlich nochmal so lange dauern bis Windows Applikationen auf eine komplett neue Basis (UWP) umziehen. Viele Probleme der vergangener Jahre und eben auch das aktuelle Spectre Problem, hätten wir nie zu Gesicht bekommen wenn Itanium Erfolg gehabt hätte.

Letztendlich ist es egal, Itanium ist tot und wenn ARM nicht irgendwann die x86 Architektur ersetzt werden wir auch noch in 20 Jahren mit dem Flickenteppich leben müssen.
 
Zuletzt bearbeitet:
iamunknown schrieb:
Was sind denn die Nachteile der nachträglichen Befehlserweiterungen gegenüber einer neuen Architektur?

Es werden zuviele Altlasten aus Kompatibilitätsgründen mitgeschleppt.
Warum müssen aktuelle CPUs noch nativen x87-FPU-Code ausführen können?
Aktuelle Compiler erzeugen standardmässig gar keinen x87-Code mehr, die generieren gleich SSE-Code.
Warum schmeisst man also das instruction set nicht gleich raus.
 
xexex schrieb:
Das wir nun nach 18 Jahren bei AVX512 angelangt sind.....
Was ist daran ein Nachteil? Es werden *neue* Befehle eingeführt...
xexex schrieb:
Sprich es werden immer mehr und mehr Flicken eingebaut um letztlich Sachen zu realisieren, die man mit VLIW machen wollte und aus Gründen der Kompatibilität nutzt nur ein Teil der Software solche Erweiterungen.
Was von z.B. dem dir genannten AVX(512) hätte durch die Itanium VLIW-Implementierung denn abgedeckt werden können, ohne die bestehende Itanium-VLIW-Implementierung zu ändern (womit alle SW mindestens neu compiliert werden darf)? Und wie viel mehr Software würde mehr von der CPU nutzen, wenn sie nicht wirklich auf die Architektur angepasst wird?
xexex schrieb:
Den Rest meine Aussage willst du anscheinend nicht verstehen. Weil man seinerzeit den "leichten Weg" genommen hat, leben wir bis heute mit Altlasten.
Du meinst bei der effizienteren und erheblich verbreiteteren x86-Architektur geblieben ist?
xexex schrieb:
Es hat gut 15 Jahre gedauert bis BIOS endlich zu Grabe getragen wird, mit all den damit verbundenen Problemen.
Kannst du die damit verbundenen Probleme benennen? Mir fällt erstmal keines ein.
xexex schrieb:
Es wird vermutlich nochmal so lange dauern bis Windows Applikationen auf eine komplett neue Basis (UWP) umziehen.
Wenn das durch ist (gerade mit der Windows-Store-Vergängelung) wirst auch du dich auf die guten alten Zeiten zurück besinnen, zumindest in der Windows-Welt.
xexex schrieb:
Viele Probleme der vergangener Jahre und eben auch das aktuelle Spectre Problem, hätten wir nie zu Gesicht bekommen wenn Itanium Erfolg gehabt hätte.
Welche Probleme abgesehen von Spectre (was auch ARM betrifft, also kein x86-Exklusives Problem darstellt) wären denn nicht aufgetreten? Auch hier fällt mir erstmal nichts ein!
xexex schrieb:
Letztendlich ist es egal, Itanium ist tot und wenn ARM nicht irgendwann die x86 Architektur ersetzt werden wir auch noch in 20 Jahren mit dem Flickenteppich leben müssen.
Stimmt, bei ARM wird alles immer komplett neu entwickelt und Spectre gibt es dort auch nicht. Halt, warte ;).

kisser schrieb:
Warum müssen aktuelle CPUs noch nativen x87-FPU-Code ausführen können?
Aktuelle Compiler erzeugen standardmässig gar keinen x87-Code mehr, die generieren gleich SSE-Code.
Warum schmeisst man also das instruction set nicht gleich raus.
Weil das bis auf ein paar weniger Befehle (sowie nicht mehr ausführbarer SW) am CPU-Aufbau kaum bis gar nichts ändern würde. Beim CPU-Design wird versucht so viel wie möglich wieder zu verwenden, sprich die FPU kann auch durch die SSE-Einheiten nach außen simuliert werden.
 
Zurück
Oben