it-swarm.com.de

Warum war es für den Itanium-Prozessor schwierig, einen Compiler zu schreiben?

Es wird allgemein behauptet, dass Intels Itanium 64-Bit-Prozessorarchitektur fehlgeschlagen ist, weil es sehr schwierig war, einen guten Compiler für den revolutionären EPIC-Befehlssatz zu schreiben, was einen Mangel an guten Entwicklertools für IA64 bedeutete, was einen Mangel bedeutete von Entwicklern, die Programme für die Architektur erstellen, und deshalb wollte niemand Hardware ohne viel Software dafür verwenden, und so versagte die Plattform, und das alles aus Mangel an ein Hufeisennagel gute Compiler.

Aber warum war das Compiler-Zeug so ein schwieriges technisches Problem? Es scheint mir, dass wenn die explizite Parallelität in EPIC für Compiler-Anbieter schwierig zu implementieren war ... warum sollte man sie überhaupt belasten? Es ist nicht so, als gäbe es noch keine gute, gut verstandene Lösung für dieses Problem: Belasten Sie stattdessen Intel und geben Sie den Compiler-Autoren ein einfacheres Ziel.

Itanium kam 1997 heraus. Zu diesem Zeitpunkt war das CSD P-Code Bytecode-System fast 20 Jahre alt, das Z-Maschine nur etwas jünger und die JVM war das heißer neuer aufstrebender Stern in der Welt der Programmiersprachen. Gibt es einen Grund, warum Intel keine "einfache Itanium-Bytecode" -Sprache angegeben und ein Tool bereitgestellt hat, das diesen Bytecode in optimierten EPIC-Code konvertiert und dabei sein Fachwissen als die Leute nutzt, die das System überhaupt entworfen haben?

50
Mason Wheeler

Wie ich mich damals erinnere, ging es nicht nur um die Einzelheiten von IA64, sondern auch um die Konkurrenz mit AMDs x86-64-Befehlssatz. Durch die Abwärtskompatibilität der Architektur mit dem x86-Befehlssatz konnte AMD die vorhandenen Tools und Entwicklerfähigkeiten nutzen. Der Schritt von AMD war so erfolgreich, dass Intel (und Via) im Wesentlichen gezwungen waren, die x86-64-Architektur zu übernehmen.

Die große Barriere zu dieser Zeit war 4 GB RAM auf Desktop-PCs (realistischer ~ 3,4 GB unter Windows verwendbar). X86-64 hat diese Barriere überwunden und allen Menschen eine höhere Leistungsfähigkeit eröffnet. Hatte AMD Ich bin mir sicher, Intel hätte sich gefreut, wenn alle, die auf 4 GB + RAM) für dieses Privileg jahrelang eine hohe Prämie zahlen wollten, demonstriert hätten, wie langsam die Märkte vermarkten Es hat Jahre gedauert, bis Anwendungen die 64-Bit-Multithread-Programmierung erreicht haben, und selbst jetzt sind 4 GB RAM ist Standard bei Low-End-PCs.

Kurz gesagt, Intel hat versucht, mit der IA64-Architektur einen revolutionären Sprung zu machen, und AMD hat mit x86-64 einen Evolutionsschritt gemacht. In einem etablierten Markt werden evolutionäre Schritte, die es Wissensarbeitern ermöglichen, vorhandene Fähigkeiten zu nutzen, revolutionäre Schritte gewinnen, bei denen jeder neue Fähigkeiten erlernen muss. Ungeachtet der qualitativen Unterschiede zwischen den Architekturen konnte IA64 die Dynamik seiner eigenen x86-Plattform nicht überwinden, nachdem AMD die x86-64-Erweiterungen hinzugefügt hatte.

Ich kaufe nicht die Erklärung, dass IA64 zu schwer zu programmieren war. Es war nur im Vergleich zu den Alternativen schwierig. @ delnans Punkt über Low-Level-IR ist genau richtig, ich glaube nur nicht, dass es einen Unterschied gemacht hätte.

Wer weiß, warum Intel nicht versucht hat, diese Last selbst zu tragen? Sie waren zu dieser Zeit die Marktmacht. AMD war eine Bedrohung, aber Intel war der König des Hügels. Vielleicht dachten sie, dass IA64 so viel besser sein würde als alles andere, dass sie den gesamten Markt bewegen könnten. Vielleicht haben sie versucht, eine Premium-Stufe zu erreichen und AMD, VIA usw. in der zweiten Stufe zu verlassen, um um margenschwache Rohstoffhardware zu kämpfen - eine Strategie, die sowohl Intel als auch Apple] recht erfolgreich angewendet haben.

War Itanium ein bewusster Versuch, eine Premium-Plattform zu schaffen und den Teppich unter AMD, VIA usw. herauszuziehen? So funktioniert das Geschäft natürlich.

33
Robert Munn

Der Wikipedia-Artikel über EPIC hat bereits die vielen Gefahren umrissen, die VLIW und EPIC gemeinsam haben.

Wenn jemand das Gefühl des Fatalismus in diesem Artikel nicht versteht, möchte ich Folgendes hervorheben:

Ladeantworten aus einer Speicherhierarchie, die CPU-Caches und DRAM enthält, haben keine deterministische Verzögerung.

Mit anderen Worten, jedes Hardware-Design, das (*) die nicht deterministische Latenz beim Speicherzugriff nicht bewältigt, wird zu einem spektakulären Fehler.

(*) Durch "Bewältigen" ist es notwendig, eine einigermaßen gute Ausführungsleistung zu erzielen (mit anderen Worten "kostengünstig"), was erfordert, dass die CPU nicht so oft für zehn bis Hunderte von Zyklen im Leerlauf bleibt.

Beachten Sie, dass die von EPIC verwendete Bewältigungsstrategie (im oben verlinkten Wikipedia-Artikel erwähnt) das Problem nicht wirklich löst. Es heißt lediglich, dass die Verantwortung für die Angabe der Datenabhängigkeit jetzt beim Compiler liegt. Das ist gut; Der Compiler verfügt bereits über diese Informationen, sodass der Compiler diese problemlos einhalten kann. Das Problem ist, dass die CPU über einen Speicherzugriff immer noch für zehn bis Hunderte von Zyklen im Leerlauf ist. Mit anderen Worten, es wird eine sekundäre Verantwortung externalisiert, während die primäre Verantwortung immer noch nicht bewältigt wird.

Die Frage kann wie folgt umformuliert werden: "Angesichts einer Hardwareplattform, die zum Scheitern verurteilt ist, warum (1) konnten (2) die Compiler-Autoren keine heldenhaften Anstrengungen unternehmen, um sie einzulösen?"

Ich hoffe, dass meine Umformulierung die Antwort auf diese Frage offensichtlich macht.


Es gibt einen zweiten Aspekt des Fehlers, der ebenfalls tödlich ist.

Bei den Bewältigungsstrategien (im selben Artikel erwähnt) wird davon ausgegangen, dass das softwarebasierte Prefetching verwendet werden kann, um zumindest einen Teil des Leistungsverlusts aufgrund einer nicht deterministischen Latenz beim Speicherzugriff wiederherzustellen.

In der Realität ist das Vorabrufen nur dann rentabel, wenn Sie Streaming-Vorgänge ausführen (Speicher sequentiell oder in hohem Maße vorhersehbar lesen).

(Das heißt, wenn Ihr Code häufig auf einige lokalisierte Speicherbereiche zugreift, hilft das Caching.)

Die meisten Allzweck-Programme müssen jedoch viele zufällige Speicherzugriffe durchführen. Wenn wir die folgenden Schritte berücksichtigen:

  • Berechnen Sie die Adresse und dann
  • Lesen Sie den Wert und dann
  • Verwenden Sie es in einigen Berechnungen

Bei den meisten Allzweck-Programmen müssen diese drei Funktionen schnell hintereinander ausgeführt werden. Mit anderen Worten, es ist nicht immer möglich (innerhalb der Grenzen der Softwarelogik), die Adresse im Voraus zu berechnen oder genügend Arbeit zu finden, um die Stände zwischen diesen drei Schritten zu füllen.

Um zu erklären, warum es nicht immer möglich ist, genügend Arbeit zu finden, um die Stände zu füllen, können Sie dies folgendermaßen visualisieren.

  • Nehmen wir an, um die Stalls effektiv zu verbergen, müssen wir 100 Anweisungen ausfüllen, die nicht vom Speicher abhängen (daher wird es keine zusätzliche Latenz geben).
  • Laden Sie jetzt als Programmierer jede Software Ihrer Wahl in einen Disassembler. Wählen Sie eine Zufallsfunktion für die Analyse.
  • Können Sie irgendwo eine Folge von 100 Anweisungen (*) identifizieren, die ausschließlich frei von Speicherzugriffen sind?

(*) Wenn wir jemals NOP dazu bringen könnten, nützliche Arbeit zu leisten ...


Moderne CPUs versuchen, mit dynamischen Informationen damit umzugehen - indem sie gleichzeitig den Fortschritt jedes Befehls verfolgen, während sie durch die Pipelines zirkulieren. Wie oben erwähnt, ist ein Teil dieser dynamischen Informationen auf eine nicht deterministische Speicherlatenz zurückzuführen, daher kann sie von Compilern nicht mit einem gewissen Grad an Genauigkeit vorhergesagt werden. Im Allgemeinen sind zum Zeitpunkt der Kompilierung einfach nicht genügend Informationen verfügbar, um Entscheidungen zu treffen, die möglicherweise diese Stände füllen könnten.


Als Antwort auf die Antwort von AProgrammer

Es ist nicht so, dass "Compiler ... Parallelität zu extrahieren schwierig ist".

Die Neuordnung von Speicher- und Rechenanweisungen durch moderne Compiler ist der Beweis dafür, dass es kein Problem gibt, Operationen zu identifizieren, die unabhängig und somit gleichzeitig ausführbar sind.

Das Hauptproblem besteht darin, dass eine nicht deterministische Speicherlatenz bedeutet, dass jede für den VLIW/EPIC-Prozessor codierte "Befehlspaarung" durch Speicherzugriff blockiert wird.

Das Optimieren von Anweisungen, die nicht blockiert werden (nur Register, Arithmetik), hilft nicht bei Leistungsproblemen, die durch Anweisungen verursacht werden, die sehr wahrscheinlich blockieren (Speicherzugriff).

Dies ist ein Beispiel für die Nichtanwendung der 80-20-Optimierungsregel: Durch die Optimierung bereits schneller Dinge wird die Gesamtleistung nicht wesentlich verbessert, es sei denn, die langsameren Dinge werden ebenfalls optimiert.


Als Antwort auf die Antwort von Basile Starynkevitch

Es ist nicht "... (was auch immer) schwer ist", es ist so, dass EPIC für jede Plattform ungeeignet ist, die mit einer hohen Dynamik in der Latenz fertig werden muss.

Zum Beispiel, wenn ein Prozessor alle folgenden Eigenschaften hat:

  • Kein direkter Speicherzugriff;
    • Jeder Speicherzugriff (Lesen oder Schreiben) muss mit DMA transfer;
  • Jeder Befehl hat die gleiche Ausführungslatenz;
  • In-Order-Ausführung;
  • Breite/vektorisierte Ausführungseinheiten;

Dann passt VLIW/EPIC gut.

Wo findet man solche Prozessoren? DSP. Und hier hat VLIW floriert.


Im Nachhinein ist das Scheitern von Itanium (und das fortgesetzte Einbringen von F & E-Anstrengungen in ein Scheitern trotz offensichtlicher Beweise) ein Beispiel für ein organisatorisches Versagen und verdient eine eingehende Untersuchung.

Zugegeben, die anderen Unternehmungen des Anbieters wie Hyperthreading, SIMD usw. scheinen sehr erfolgreich zu sein. Es ist möglich, dass die Investition in Itanium eine bereichernde Wirkung auf die Fähigkeiten seiner Ingenieure hatte, die es ihnen ermöglicht haben, die nächste Generation erfolgreicher Technologie zu schaffen.

33
rwong

TL; DR: 1/Es gibt andere Aspekte beim Versagen von Itanium als die Compiler-Probleme, und sie können durchaus ausreichen, um dies zu erklären. 2/ein Bytecode hätte die Compilerprobleme nicht gelöst.

Es wird allgemein behauptet, dass Intels Itanium 64-Bit-Prozessorarchitektur fehlgeschlagen ist, weil es sehr schwierig war, einen guten Compiler für den revolutionären EPIC-Befehlssatz zu schreiben

Nun, sie waren auch zu spät (geplant für 98, erste Lieferung im Jahr 2001) und als sie schließlich die Hardware lieferten, bin ich mir nicht einmal sicher, ob sie das lieferte, was für den früheren Termin versprochen wurde (IIRC, sie ließen zumindest einen Teil der x86-Emulation, die ursprünglich geplant war), daher bin ich mir nicht sicher, ob sie erfolgreich gewesen wären, selbst wenn die Kompilierungsprobleme gelöst worden wären (und AFAIK noch nicht). Der Compiler-Aspekt war nicht der einzige Aspekt, der zu ehrgeizig war.

Gibt es einen Grund, warum Intel keine "einfache Itanium-Bytecode" -Sprache angegeben und ein Tool bereitgestellt hat, das diesen Bytecode in optimierten EPIC-Code konvertiert und dabei sein Fachwissen als die Leute nutzt, die das System überhaupt entworfen haben?

Ich bin nicht sicher, wo Sie das Werkzeug platzieren.

Wenn es sich im Prozessor befindet, haben Sie nur eine andere Mikroarchitektur und es gibt keinen Grund, x86 nicht als public zu verwenden ISA (zumindest für Intel hat die Inkompatibilität höhere Kosten als alles andere) eine sauberere öffentliche ISA mitbringen).

Wenn es extern ist, macht es das Starten von einem Bytecode noch schwieriger als das Starten von einer höheren Sprache. Das Problem mit EPIC ist, dass es nur die Parallelität verwenden kann, die ein Compiler finden kann, und dass es schwierig ist, diese Parallelität zu extrahieren. Wenn Sie die Sprachregeln kennen, haben Sie mehr Möglichkeiten, als wenn Sie durch etwas bereits Geplantes eingeschränkt sind. Meine (zugegebenermaßen unzuverlässige und von jemandem, der dem von weitem gefolgt ist) Erinnerung ist, dass HP (*) und Intel auf der Compiler-Front die Extraktion der Parallelität auf Sprachebene nicht erreicht haben, nicht die niedrige Ebene, die in einem Byte vorhanden gewesen wäre Code.

Sie unterschätzen möglicherweise die Kosten, zu denen der aktuelle Prozessor seine Leistung erzielt. OOO ist effektiver als die anderen Möglichkeiten, aber sicherlich nicht effizient. EPIC wollte das von der Implementierung von OOO verwendete Flächenbudget nutzen, um mehr Rohdaten bereitzustellen, in der Hoffnung, dass Compiler es nutzen können. Wie oben geschrieben, sind wir nicht nur - wie AFAIK, auch theoretisch - immer noch nicht in der Lage, Compiler zu schreiben, die diese Fähigkeit besitzen, sondern das Itanium hat auch genug andere schwer zu implementierende Funktionen, so dass es spät war und seine rohe Leistung nicht sogar wettbewerbsfähig (außer vielleicht in einigen Nischenmärkten mit vielen FP Berechnungen)) mit dem anderen High-End-Prozessor, wenn er aus der Fassung geraten ist.


(*) Sie scheinen auch die HP-Rolle in EPIC zu unterschätzen.

7
AProgrammer

Ein paar Dinge.

Zum einen war IPF in Ordnung. Dies bedeutete, dass Sie sich nicht auf eine Neuordnung verlassen konnten, um Sie im Falle eines Cache-Fehlers oder eines anderen Ereignisses mit langer Laufzeit zu retten. Infolgedessen mussten Sie sich auf spekulative Funktionen verlassen - nämlich spekulative Lasten (Lasten, die ausfallen durften - nützlich, wenn Sie nicht wussten, ob Sie ein Lastergebnis benötigen) und erweiterte Lasten (Lasten, die es sein könnten) Führen Sie es erneut aus, indem Sie den Wiederherstellungscode verwenden, wenn eine Gefahr aufgetreten ist. Es gab auch Prefetch-Hinweise für Verzweigungen und Caches, die wirklich nur von einem Assembly-Programmierer oder mithilfe einer profilgesteuerten Optimierung intelligent verwendet werden konnten, im Allgemeinen nicht mit einem herkömmlichen Compiler.

Andere Maschinen zu dieser Zeit - nämlich UltraSPARC - waren in Ordnung, aber IPF hatte auch andere Überlegungen. Einer verschlüsselte den Raum. Itanium-Anweisungen waren von Natur aus nicht besonders dicht - ein 128-Bit-Bundle enthielt drei Operationen und ein 5-Bit-Vorlagenfeld, in dem die Operationen im Bundle beschrieben wurden und ob sie alle zusammen ausgegeben werden konnten. Dies führte zu einer effektiven Operationsgröße von 42,6 Bit - im Vergleich zu 32 Bit für die meisten kommerziellen RISC-Operationen zu dieser Zeit. (Dies war vor Thumb2 et al. - RISC bedeutete immer noch eine Steifigkeit mit fester Länge.) Schlimmer noch, Sie hatten nicht immer genug ILP, um auf die von Ihnen verwendete Vorlage zu passen - also müssten Sie das NOP-Pad ausfüllen Vorlage oder das Bundle. In Kombination mit der vorhandenen relativ geringen Dichte bedeutete dies, dass eine anständige i-Cache-Trefferquote a) sehr wichtig und b) schwierig war - zumal I2 nur einen 16 KB L1I hatte (obwohl dies ziemlich schnell war).

Obwohl ich immer das Gefühl hatte, dass das Argument "Der Compiler war das einzige Problem" übertrieben wurde - es gab legitime mikroarchitektonische Probleme, die I2 wirklich keinen Gefallen für Allzweckcode taten -, machte es keinen besonderen Spaß, Code für den Vergleich zu generieren zu den schmaleren, höher getakteten OoO-Maschinen des Tages. Wenn man es wirklich richtig ausfüllen konnte, was oft entweder PGO oder Handcodierung beinhaltete, war es großartig - aber die Leistung von Compilern war oft nur wenig inspirierend. IPF machte es nicht einfach, großartigen Code zu generieren, und es war unversöhnlich, wenn Code nicht großartig war.

6
Lexi

Aber warum war das Compiler-Zeug so ein schwieriges technisches Problem? Es scheint mir, dass wenn die explizite Parallelität in EPIC für Compiler-Anbieter schwierig zu implementieren war ... warum sollte man sie überhaupt belasten? Es ist nicht so, als gäbe es noch keine gute, gut verstandene Lösung für dieses Problem: Belasten Sie stattdessen Intel und geben Sie den Compiler-Autoren ein einfacheres Ziel.

Was Sie beschreiben, ist ein bisschen was Transmeta versucht hat, mit ihrer Code-Morphing-Software (die x86 "Bytecode" dynamisch in Transmeta internen Maschinencode übersetzt) ​​zu tun.

Warum hat Intel keinen ausreichend guten Compiler für IA64 entwickelt? Ich denke, sie hatten nicht genug Compiler-Know-how im Haus (sogar) wenn sie natürlich einige sehr gute Compiler-Experten hatten, aber wahrscheinlich nicht genug, um eine kritische Masse zu bilden). Ich denke, dass ihr Management die Anstrengungen zur Erstellung eines Compilers unterschätzt hat.

AFAIK, Intel EPIC ist fehlgeschlagen, weil die Kompilierung für EPIC sehr schwierig ist und weil andere Wettbewerber, wenn sich die Compilertechnologie langsam und schrittweise verbesserte, ebenfalls in der Lage waren, ihren Compiler (z. B. für AMD64) zu verbessern und etwas Compiler-Know-how zu teilen.

Übrigens wünschte ich mir, AMD64 wäre ein weiterer RISCy-Befehlssatz gewesen. Es könnte einiges gewesen sein POWERPC64 (aber es war wahrscheinlich nicht wegen Patentproblemen, wegen Microsoft-Anforderungen zu dieser Zeit usw.). Die x86-64-Befehlssatzarchitektur ist wirklich keine "sehr gute" Architektur für Compiler-Writer (aber irgendwie "gut genug").

Auch die IA64-Architektur hat einige starke Einschränkungen eingebaut, z. Die 3 Befehle/Word waren gut, solange der Prozessor 3 Funktionseinheiten hatte, um sie zu verarbeiten, aber als Intel zu neueren IA64-Chips überging, fügten sie weitere Funktionseinheiten hinzu, und die Parallelität auf Befehlsebene war erneut schwer zu erreichen.

Vielleicht wird RISC-V (eine Open-Source-ISA) allmählich erfolgreich genug sein, um sie gegenüber anderen Prozessoren wettbewerbsfähig zu machen.

Wie Robert Munn betonte, war es die mangelnde Abwärtskompatibilität, die das Itanium (und viele andere "neue" Technologien) tötete.

Während das Schreiben eines neuen Compilers möglicherweise schwierig war, benötigen Sie nur einige davon. Ein C-Compiler, der optimierten Code erzeugt, ist ein Muss - sonst haben Sie kein brauchbares Betriebssystem. Sie benötigen einen C++ - Compiler, Java und vorausgesetzt, die Hauptbenutzerbasis wäre Windows, eine Art Visual Basic. Dies war also kein wirkliches Problem. Es gab ein anständiges Betriebssystem (NT) und ein guter C-Compiler verfügbar.

Was für ein Unternehmen, das ein Softwareprodukt anbietet, als triviale Anstrengung erscheint - kompilieren und testen Sie Ihre C-Code-Basis neu (und zu diesem Zeitpunkt wären die meisten in reinem C geschrieben worden!), War nicht so einfach. Das Konvertieren eines großen Satzes von C-Programmen, die eine 32-Bit-Ganzzahl und eine 32-Bit-Adressierung annahmen, in eine native 64-Bit-Architektur war voller Fallstricke. Wäre IA64 zu einem dominanten Chip geworden (oder sogar zu einem beliebten!), Hätten die meisten Softwareunternehmen die Kugel gebissen und sich die Mühe gemacht.

So schneller Chip mit einem vernünftigen Betriebssystem, aber einem sehr begrenzten Satz verfügbarer Software, daher haben nicht viele Leute ihn gekauft, daher haben nicht viele Softwareunternehmen Produkte dafür bereitgestellt.

3
James Anderson

Was Itanium tötete, waren Versandverzögerungen, die AMD64 die Tür zum Eingreifen öffneten, bevor sich Softwareanbieter zur Migration auf IA64 für 64-Bit-Apps verpflichteten.

Es war eine gute Idee, die Optimierung dem Compiler zu überlassen. Eine Menge Dinge können statisch gemacht werden, die sonst in der Hardware ineffizient sind. Die Compiler waren ziemlich gut darin, besonders wenn sie PGO-Profiling verwendeten (ich arbeitete bei HP und der HP Compiler übertraf tendenziell den von Intel). PGO war ein harter Verkauf, es ist jedoch ein schwieriger Prozess für den Produktionscode.

IPF sollte abwärtskompatibel sein, aber als AMD64 gestartet wurde, wurde es strittig, der Kampf war verloren und ich glaube, die X86-Hardware in der CPU wurde nur entfernt, um als Server-CPU neu auszurichten. Itanium als Architektur war nicht schlecht, die 3 Anweisungen pro Wort waren kein Problem. Was ein Problem war, ist die Hyper-Threading-Implementierung durch Austauschen von Stapeln während des Speichers IO war zu langsam (um die Pipeline zu leeren und neu zu laden) bis Montecito usw., was sie daran hinderte, gegen Out-of-Out zu konkurrieren PowerPC-CPUs bestellen. Die Compiler mussten spät reparieren, um Fehler bei der CPU-Implementierung zu erkennen, und ein Teil der Leistung von Edge ging zu schwer verloren, um Fehler vorherzusagen.

Die Architektur ermöglichte es Itanium, relativ einfach zu sein und gleichzeitig Tools bereitzustellen, mit denen der Compiler die Leistung steigern kann. Wenn die Plattform gelebt hätte, wären die CPUs komplexer geworden und hätten schließlich Threads, außer Betrieb usw. wie x86. Die ersten gens-fokussierten Transistoren zählen jedoch auf andere Leistungsschemata, da der Compiler einen Großteil der harten Dinge handhabte.

Die IPF-Plattform setzte auf den Compiler und die Tools und war das erste Mal, dass ein äußerst vollständiges und leistungsstarkes PMU-Design (Performance Monitoring Unit) veröffentlicht wurde, das später auf Intel x86 zurückportiert wurde. Daher nutzen leistungsstarke Tool-Entwickler es immer noch nicht in vollem Umfang, um Code zu profilieren.

Wenn Sie sich ISA Erfolge) ansehen, ist es oft nicht die technische Seite, die die Würfel wirft. Es ist ihr Platz in der Zeit und den Marktkräften. Schauen Sie sich SGI Mips, DEC Alpha ... Itanium wurde gerade unterstützt Von den Verlierern, SGI- und HP-Servern, Unternehmen mit Managements, die sich auf strategische Geschäftsfehler stützten. Microsoft war nie voll dabei und befürwortete AMD64, nicht nur mit Intel als Player zu arbeiten, und Intel spielte nicht richtig mit AMD um ihnen eine Möglichkeit zu geben, im Ökosystem zu leben, wie sie AMD schnupfen wollten.

Wenn Sie sich ansehen, wo wir uns heute befinden, hat die komplexe Hardware von X86 bisher zu einer Sackgasse in der Evolution geführt. Wir stecken bei 3 + GHz fest und entleeren Kerne, die nicht genug Verwendung dafür haben. Das einfachere Design von Itanium hätte mehr Material auf den Compiler gebracht (Raum für Wachstum) und es ermöglicht, dünnere, schnellere Pipelines zu bauen. Bei der gleichen Generation und fabelhaften Technologie wäre es schneller gelaufen und hätte sich trotzdem, aber etwas höher, mit anderen Türen geöffnet, die sich dem Gesetz von Push Moore öffnen könnten.

Nun, zumindest ist das oben genannte meine Überzeugung :)

3
Dan T.

Der Speicher wird vage ... Itanium hatte einige großartige Ideen, die großartige Compiler-Unterstützung benötigen würden. Das Problem war, dass es nicht eine Funktion war, sondern viele. Jeder war keine große Sache, alle zusammen waren es.

Zum Beispiel gab es eine Schleifenfunktion, bei der eine Iteration der Schleife Register aus verschiedenen Iterationen bearbeiten würde. x86 löst das gleiche Problem durch massive Funktionen außerhalb der Reihenfolge.

Zu dieser Zeit Java und JVMs waren in Mode. IBM sagte, dass man mit PowerPC schnell Bytecode kompilieren könne und die CPU ihn schnell machen würde. Nicht auf Itanium.

1
gnasher729