mae schrieb:
Vorhersage von 1997-06: >$35G Serververkaeufe mit Itanium im Jahr 2002
Gut, wenn man sich so etwas quasi zu „Projektstart“ ansieht, gibt es immer Übertreibungen.
AMD hat glaub ich den eigenen potenziellen AI Markt auch auf 50.000.000.000 geschätzt, oder waren es gar 500.000.000.000, muss ich mal raussuchen.
mae schrieb:
aber wenn man "nicht RISC" zu begruenden wollte, waere das wohl das, auf das man zeigen wuerde.
Die Sache ist die: auch ARM kämpft heute mit Altlasten und es ist „kompliziert“ einen neuen Kern zu entwickeln.
Jim Keller hat dazu ja auch schon in Interviews geschrieben und das aktuell quasi der beste Befehlssatz RISC-V ist, weil er clean ist und genau das kann, was benötigt wird.
Die Diskussion RISC oder CISC und dem Decoder ist heute eigentlich vollkommen irrelevant. Egal ob jetzt CISC-Ähnlich oder RISC-Ähnlich, in beiden Welten werden die Befehle in Micro-OPs zerlegt und dann ausgeführt. Beide Varianten benötigen heute sowohl einfache Decoder für die meisten Befehle und komplexe Decoder für eben kompliziertere Befehle. Das Decoding macht heute allerdings nur noch einen kleinen Teil des Energiebudgets aus und ebenso auf die Fläche sowie Transistorzahl bezogen ist es quasi "irrelevant".
Die Diskussion RISC/CISC und was da besser ist, ist ein Nebenschauplatz, den man in der Regel aufmacht, wenn man zwar genug von der Technik versteht und interessiert ist, gleichzeitig jedoch nicht nicht so tief in der Materie drin steckt und tiefer gehendes Wissen noch fehlt.
adfsrg schrieb:
"Entpuppt" klingt so, als ob das überraschend kam.
Überraschend kam zu dem Zeit Punkt eher, dass die Superskalarität zusammen mit OoO weit aus besser funktioniert hat, als es die gängigen VLIW-Konzepte und gleichzeitig eine Hoheflexibilität beim Kern-Design ermöglichten, die ein VLIW-Konzept eben nicht bietet.
adfsrg schrieb:
Aber gerade dass die Parallelisierung Aufgabe des Compilers war und nicht erst zur Laufzeit gemacht wurde, war doch der größte Vorteil.
Nur war es das nicht, wie auch ATi, bzw. AMD bei TeraScale lernen musste und warum man sich bei eigentlich etwas so so vorhersehbaren wie einer GPU vom VLIW Konzept verabschiedet hat. Und der Itanium hat eine Springvorhersage, denn das VLIW-Konzept verhindert kein Sprünge, womit viele der Probleme, die du benennest eben doch existieren.
Dazu kommt, dass man bei IA64 für jede größere Kernänderungen einen neuen Compiler benötigt hätte, weil der Compiler über die „Belegung“ der Ports entscheidet und welche Befehle parallel ausgeführt werden. Es gibt nämlich noch einen Punkt, der moderne Prozessoren schnell macht und die so mit EPIC nicht möglich waren: Die Spekulative Ausführung von Befehlen.
Bei EPIC hat man sich sehr viel Kontrolllogik gespart damals und diese in Rechenwerke und Register gesteckt. Gleichzeitig hat man sich beim Kerndesign jegliche Flexibilität genommen, die für eine CPU jedoch wichtig ist. Intel und AMD haben in den letzten 25 Jahren ihre Designs von 2 ALU, eine FP ALU auf heute 6 ALUs und 4 FP-ALUs verbreitert und es funktioniert, ohne „Größere“ Anpassungen bei einem Compiler. Bei Itanium hätte jede Erweiterung der Executionports umfassende Änderungen am Compiler erfordert und es wäre immer schwerer geworden den Kern auch effektiv auszulasten.
IA64 ist so wie IA32 und ARM und ebenso x86_64 sind zu bestimmten Zeiten entstanden und Spiegeln in der Form auch wieder, was damals die Grundparadigmen der jeweiligen Generation waren. IA32 ist mit 8 Registern entworfen worden. Transistoren waren damals unglaublich teuer, während RAM-Bausteine vergleichsweise "billig" waren. Dazu wurde primär damals noch per Assembler programmiert, wodurch CPU-Hersteller mächtige Befehle in ihre CPUs einbauten, damit man "komfortabel" programmieren konnte.
Mit dem Erfolg von Programmiersprachen und besser werdenden Compilern, die Code auf die Hardware besser optimieren können als Menschen - waren komplexe Befehlssätze nicht mehr notwendig, also hat man sich auf atomare Operationen beschränkt, der Compiler zerlegt eh alles in die Richtung. Den frei werdenden Platz hat man in Register gesteckt, denn je weniger die CPU auf den Speicher warten, um so schneller wird sie.
VLIW und damit auch EPIC entstanden genau in dieser Zeit, die Compiler sind immer besser geworden, gleichzeitig waren Transistoren immer noch teuer - einer der Gründe, warum man beim Pentium Pro den L2-Cache als eigenen Die integrierte und bei den ersten Athlons und beim Pentium 2 und den ersten 3ern den Cache wieder auslagerte. Die nun aufkommende Kontrolllogik für Out-of-Order-Ausführung, die Buffer für das Neusortieren, die entsprechende Caches kosten Platz und damit wertvolle Fläche. EPIC soll diese "wertvolle" Fläche einsparen, in dem die Kontrolllogik weitgehend auf den Compiler verlagert wird. Für sich gesehen damals keine schlechte Idee, jedoch gleichzeitig auch sehr unflexibel. Am besten sieht man das heute an GPUs, weil hier ein Großteil im SIMD/SIMT-Konzept an Kontrolllogik in den Treiber verlagert wurde. Rein auf Softwareebene fällt es AMD und Nvidia immer schwerer ihre großen GPUs effizient auszulasten, weswegen hier auch zum Teil immer mehr Kontrolllogik auch wieder ihren Weg in die GPUs finden.
Damals hat AMD und Intel - TSMC war ja noch nicht so das Thema wie heute - quasi alle 6 Monate einen neuen Fertigungsprozess auf den Weg gebracht (Ja ich übertreibe, ich weiß, dass das nicht so schnell ging). Pentium 2 und Pentium 3 hat man noch die die Caches ausgelagert, dann plötzlich "Bumm" neuer Fertigungsprozess, Transistoren viel "billiger" als vorher, also Cache wieder rein. Oh, die Kontrollogik, die wir ausgelagert habe in den Compiler, die können wir doch wieder implementieren, weil es ist jetzt viel billiger.
Jeder, der sich Abseits der Wikipediaartikel mit dem Thema IA64, Itanium und ebenso x86_64 von AMD befasst, merkt schnell, dass IA64 und EPIC als gesamtes Konzept so einige Probleme hatte und das AMDs 64-Bit-Erweiterung der x86-Architektur eher so etwas wie der finale Todesstoß für IA64 war.
adfsrg schrieb:
aber dann hätten wir die Probleme mit der Multithreading-Performance in Games wohl nicht oder nur sehr schwach gehabt.
Ich gehe jetzt an der Stelle nur noch auf die beiden Aussagen ein, weil die doch relativ prägnant sind und gleichzeitig allerdings auch zeigen, dass dir tiefgreifenderes Wissen scheinbar weitgehend fehlt und du hier verschiedene Ebenen mit einander vermischt und daher auch wirklich jetzt groben Unfug hier geschrieben hast.
EPIC/IA64 kann und hätte niemals die Probleme von Multi-Threading - Parallelisierung auf Softwareebene - lösen können, weil diese auf einer ganz anderen Ebenen statt finden. Spiele stehen bei der Parallelisierung vor einem ganz anderen Problem und selbst wenn man gewisse Probleme wunderbar parallelisieren kann auf Softwareebene, gibt es hier Bereiche, bei denen das nur bis zu einem gewissen Grad funktioniert, weil die Aufgaben zu einem bestimmten Zeitpunkt "synchron" sein müssen. KI, Sound, Animation, Spielemechanik, all das kann man auf der einen Seite wunderbar in eigene Threads auslagern, gleichzeitig kommt der Zeitpunkt X, bei dem die Daten vorliegen müssen und synchronisiert für die Bild und Tonausgabe an die dafür zuständige Hardware übermittel werden müssen.
Dieses Problem hätte EPIC nie lösen können und das war auch nie die Intention dahinter. EPIC/IA64 hat auf die Mikro-Parallelisierung innerhalb eines Threads abgezogen:
Code:
A = B + C
D = E + F
B = A + D
DAS ist ein Problem, wenn man das programmiert, dass EPIC "lösen" sollte, weil zu der Zeit, als EPIC entstand, die Kontrolllogik für Hardware OoO relativ teuer war als Fläche für eine CPU. IA64 hätte dann auf Compiler-Ebene diesen Code analysiert, und hätte erkannt, das A = B + C und D = E + F "unabhängig" sind und hätte als Binärcode verpackt, dass eine der Operation auf ALU 0 und die andere auf ALU 1 ablaufen, der zweite Binärcode wäre dann gewesen, dass auf ALU 0 noch das B = A + D läuft.
Parallelisierung über diese Ebene hinaus war KEIN Bestandteil von Itanium und das hätte man auch nicht lösen können.
adfsrg schrieb:
Stell dir eine Welt vor, in der Sprungvorhersagefehler keine große Rolle spielen und ohne Pipeline-Stalls.
An welcher Stelle hätte denn IA64 mit der Auslegung keine Sprungvorhersagefehler mehr gehabt? An welcher Stelle wäre es nicht mehr zu Pipeline-Stalls gekommen?
Neben den ganzen Mikrosprüngen, die auf der Binärebene vollkommen normal sind und quasi keine CPU heute vor einer Herausforderung stellen, du weißt schon, dass wie die meisten Sprünge in einer Software entstehen und warum lange Zeit Nvidia, ATi und später AMD in ihren Leitfäden zur Optimierung von Shadern angeben haben, dass man auf Kontrollkonstrukte weitgehend verzichten sollte und nur, wenn es gar nicht anders geht und dann bitte ja nur ein
IF-ELSE am besten NUR ein
IF.
Sowas wie
FOR, WHILE, FOREACH in vielen Sprachen ist dagegen sogar noch harmlos. Die häufigsten Sprünge heute auf Software-Ebene kommen durch Modul-, Methoden- und Funtkionsaufrufe, womit Software heute strukturiert wird.
All das löst Sprünge aus, die eine CPU ausführen muss und all das führt zu Pipelines-Stalls, dazu das Register ggf. weggesichert werden müssen und mit anderen Werten geladen. Und genau all das - und wir lassen die Killerebene noch heraus - macht deine Fantasterei zu IA64 bereits unmöglich, da der Compiler jedes Abzweigung, jede Schleife und jeden Funktionsaufruf erfassen muss. Wenn wir dann noch die Ebene der Benutzereingaben hinzuziehen, dann wird aus dem unmöglichen ein Problem, dass man nicht mal mehr erfassen kann.
Es gibt - Stand heute - nur einen einzigen Betriebssystem-Kernel, der nachweisbar als funktional korrekt gilt - in dem Fall ist gemeint, dass es keinen unerwarteten Zustand gibt und das ist der L4-Mikrokernel. Du kannst dir ja mal ansehen, was da für ein Aufwand betrieben wurde und was ca. 7500 Zeilen Code bereits an Aufwand benötigen.
Für ALL das, was du IA64 hier zu schreibst, ist jedoch genau das notwendig, der Compiler muss das Programm als funktional korrekt "kompilieren" und damit JEDEN ZUSTAND im voraus erkennen und als Binärcode abspeichern. Wie groß sollen denn die Binaries werden? Wie lange soll der Compiler dafür benötigen?
Es hat einen Grund, warum man bei Intel relativ schnell wieder Abstand von EPIC genommen hat und warum man dann doch lieber mit AMD ein Patentabkommen geschlossen hat. Moderne CPUs können On-the-Fly den Binärcode, denn sie bekommen, optimieren und so für sich anpassen, dass er möglichst effektiv und schnell ausgeführt wird. Das ist nicht perfekt, das benötigt entsprechende Schaltungen und Caches/Buffer, jedoch deutlich flexibler, als eine "Softwarelösung" auf Compiler-Ebene, die für jede Prozessorgeneration angepasst werden muss, wenn man Änderungen am Kern vornimmt.
Ich habe lediglich benannt, dass du diesen verdeckten Themenwechsel abgezogen hast. Dass du das vermeintlich nicht gemerkt hast und dir dann dachtest "Äh, warum gebraucht der jetzt plötzlich das Wort "Grammatik"?" ist nun wirklich nicht mein Problem 
