1. Foren
  2. Kommentare
  3. Sonstiges-Forum
  4. Alle Kommentare zum Artikel
  5. › Itanium-CPUs: Intels "Itanic…

Intels Fehleinschätzung

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Intels Fehleinschätzung

    Autor: /mecki78 02.08.21 - 13:07

    Die ersten CPUs waren dumm. Sie taten genau das, was man ihnen gesagt hat, wie man es ihnen gesagt hat.

    Dann wurden die CPUs schlauer. Sie taten immer noch, was man ihnen gesagt hat, aber sie selber bestimmten jetzt intern den genauen Ablauf. Dadurch konnten sie bestehenden Code besser und schneller ausführen als bisher, ohne dass man diesen Code anpassen musste. z.B. da die CPU Code in anderer Reihenfolge ausgeführt als übermittelt oder Code parallel ausgeführt hat, wenn dieses problemlos möglich war. Der Nachteil war aber, dass dadurch die CPU komplexer zu bauen ist und man Chipfläche verliert bzw. sich der Stromverbrauch erhöht.

    Mit immer schlauer werden Compilern kam jetzt Intel auf die Idee, die CPU wieder dumm zu machen, was sie einfacher zu produzieren und damit leichter auf Performance hin zu trimmen macht, und die Intelligenz in den Compiler zu verlagern, denn Software ist einfacher zu verändern als Hardware. Das ist der Grund warum Software existiert.

    Das Problem mit diesem Ansatz: Wenn nur der Compiler schlau ist, dann kann eine neue CPU bestehenden Code nur dann besser ausführen, wenn man ihn für diese CPU neu baut. Lasse sich sie Code ausführen, der für die Vorgängerversion gebaut wurde, wird der nicht besser laufen, außer der Takt ist höher. Auch muss der Code dann für jede unterstützte CPU einmal getrennt optimiert gebaut werden, wenn er auf jeder CPU ein Optimum an Leistung bringen soll. Erschwerend kam hier noch hinzu, dass auch parallele Ausführung (nicht über mehrere Cores sondern pro Core) bei Itanium durch den Compiler und nicht durch die CPU gesteuert wurde. Wenn also eine neue Generation hier mehr Parallelität erlaubt hätte, konnte Code nur dann davon profitieren, wenn man ihn neu baut und dann wird er aber zu Vorgängerversionen inkompatibel.

    Daher konnte sich dieses Design nicht durchsetzen, weil es einfach nicht gut funktioniert hat in der Praxis. Kunden erwarten, dass alter Code schneller läuft, wenn sie eine neue CPU kaufen und das ohne, dass sie jedes mal den gesamten Code neu bauen müssen.

    Aber Moment mal: Wie konnte Intel denn so dumm sein? War denen das nicht vorher schon klar? Natürlich war es das. Aber wo ist dann der Denkfehler gewesen? Der Denkfehler war, dass Intel gedacht hat, dass statisch kompilierter Code ein Relikt des letzten Jahrtausend ist. Mit Java und C# schien die Ära der JIT Sprachen geboren. Intel dachte, dass in Zukunft, Code nicht mehr direkt in CPU Code übersetzt wird, sondern nur noch in irgendwelche VM Zwischensprachen und erst ein JIT Compiler daraus dann CPU Code macht und der kann diesen Code dann immer perfekt auf die jeweilige CPU optimieren, die im System steckt. Wenn nicht JIT, dann zumindest AOT, was ja die gleiche Optimierung erlaubt.

    Und das war aber eine gravierende Fehleinschätzung. Die meiste Software wird nach wie vor statisch kompiliert. C und C++ mag zwar an Bedeutung verlieren, aber auch ganz neue Sprachen wie Rust oder Swift setzen auf statisches Bauen. Java verliert zunehmend an Bedeutung für komplett neue Entwicklungen und C# ist nach wie vor nur unter Windows von Bedeutung und zum einen ist es selbst dort oft nicht die Sprache der Wahl und zum anderen hat Windows auch massiv an Bedeutung eingebüßt. So liegt der Marktanteil von Windows derzeit bei 73%. Der lag aber schon mal bei 98%.

    Was dem Itanium aber wohl den größten Todesstoß verpasst haben dürfte, waren Mulitcore CPUs. Denn einer der größten Features des Itanium war, dass er Anweisungen parallel ausführen konnte. Nun, das kann so gut wie jede aktuell CPU, nur kann dort der Compiler die Ausführung nicht steuern, sondern die CPU selber steuert die Ausführung und diese ist daher nicht immer optimal. Aber mit Dual- und Quad-Core CPUs hatte man jetzt auf einmal vergleichbare Features auch für x86_64 und ARM, echte, steuerbare Parallelität und zwar nicht nur durch den Compiler, sondern sogar durch den Programmierer, es war also nicht länger nötig die Architektur dafür zu wechseln. Und das sogar für alten Code, der zwar direkt nicht von den Cores profitiert hat, aber dafür konnte ich jetzt z.B. zwei Apps zeitgleich laufen lassen, von denen jede einen Core belegt hat und beide daher so schnell waren wie bisher, ohne sich wie bisher aber zeitweise auszubremsen (also die einzelnen Apps wurden nicht automatisch schneller, aber das Gesamtsystem wurde es).

    Es gab also kein Verkaufsargument mehr für Itanium CPUs, deren einfaches Design jetzt auf einmal komplex erschien, denn ohne einen super optimierten Compiler war es nicht möglich brauchbaren Code für diese CPUs zu erstellen. ARM oder x86_64 CPU Code kann man zur Not noch von Hand schreiben, Itanium Code will niemand von Hand schreiben und das Ergebnis wird auch niemanden überzeugen. Und ja, Itanium sind leistungsstark, aber das kann man durch einfach mehr Cores kompensieren. Dann mach ich halt eine ARM CPU mit 128 Cores, na, wer ist jetzt leistungsstärker? Denn entweder ich kann etwas parallelisieren, dann kann ich es aber auch über Cores hinweg parallelisieren oder ich kann es nicht parallelisieren, dann aber bringt mit die Arbeitsweise des Itanium auch nicht viel in der Praxis.

    /Mecki

  2. Re: Intels Fehleinschätzung

    Autor: 486dx4-160 02.08.21 - 14:51

    Compiler und Bytecode hin oder her:
    Diese Itanium-CPUs waren schlicht langsamer und teurer als so ziemlich alle anderen Server-CPUs (PA-RISC, Sparc, POWER). Auch bei nativem, gut compiliertem Code. SGI hat damals erfolgreich schnelle MIPS64-Workstations verkauft und war so eingeschüchtert von Intels Marketing-Tammtamm, dass die ihre eigene Architektur eingestellt haben und voll auf Itanium setzten und anschließend die Firma beerdigen konnten.
    Der einzige Vorteil von Itanium: Die Marke Intel - von der kauft jeder Entscheider nach wie vor gerne, weil Tradition. Ganz gleich was für einen Müll (WLAN-Chips, Ethernet-Chips, Itanium...) der Konzern liefert.
    Als Intel dann noch ankam und meinte, dass als Ausgleich für die magere Performance und die hohen Preise dafür x86-Binaries drauf laufen würden, ohne zu sagen wie arschlangsam das war, war der Ofen komplett aus.

  3. Re: Intels Fehleinschätzung

    Autor: nate 02.08.21 - 15:15

    > was für einen Müll (WLAN-Chips, Ethernet-Chips, Itanium...) der Konzern liefert

    Oh, was ist denn an den Netzwerkchips von Intel auszusetzen? Ich hatte die immer unter "gute Mittelklasse" verbucht ...

  4. Re: Intels Fehleinschätzung

    Autor: Johannes321 02.08.21 - 15:59

    Ich denke auch, dass das alleinige Abwälzen der Schuld auf EPIC der Sache nicht gerecht wird. Bei vielen HPC Anwendungen wäre das Neukompilieren vom Code z.B. gar kein Problem gewesen.

    Auch die schlechte x86 Performance ist sicher nicht alleinig Schuld am Itanium-Tod. Die vielen Hersteller auf der RISC-Schiene bis zum Erscheinen des Itaniums zeigen ja, dass man so gut leben konnte.

    Imho ist ein Wichtiger weiterer Aspekt das der Enterprise Markt stirbt. Großkotzig per Top-Down Engineering entworfene Architekturen funktionieren an vielen Detailstellen eben nicht so gut wie über Erfahrungswerte von unten nach oben aufgebaute und optimierte Designs.
    Was gab es z.B. bei x86 alles für Irrungen und Wirrungen bis man zum heutigen Design gekommen ist. (CISC, Efficeon, RISC Backends in allen Geschmacksrichtungen, SIMD Extensions und heute häufig JIT Assemblierung von Java/.net Bytecode)

    In den 80ern war das noch einfach. Da konnte man einfach mal eine CPU hinstellen und dank der geringen Komplexität war man nicht soo ewig vom leistbaren Maximum entfernt. In der Zeit hatten die vielen RISC Designs auch Zeit zu wachsen und besser zu werden da die Komplexität nur langsam anstieg.

    Itanium als Newcomer hätte aber gleich alles richtig machen müssen um mithalten zu können. Bei einem derart komplexen Design wie einer CPU aus dem Jahre 2000 ist das halt nicht mehr einfach möglich.
    Und Intel hat Erfahrung damit so was zu verbocken.



    1 mal bearbeitet, zuletzt am 02.08.21 16:02 durch Johannes321.

  5. Re: Intels Fehleinschätzung

    Autor: NilsP 02.08.21 - 17:00

    So schlecht war die Idee mit VLIW und EPIC nicht unbedingt. Allerdings haben die sich natürlich massiv bei der Entwicklung zu dynamischen Compilaten vertan.

    Sinnvoll wäre gewesen, erst einen Zwischen-/Bytecode zu generieren, der dann bei der Installation oder direkt vor der Ausführung auf die Zielplattform übersetzt und optimiert wird. Dafür wäre eine sehr enge Zusammenarbeit mit Microsoft notwendig gewesen - und für Linux wohl auch Open Source - und dafür ist Intel ja grundsätzlich wenig zu haben. Außerdem hätte man mit dem Zwischencode natürlich auch ganz schnell einen Wechsel auf eine andere Architektur ermöglichen können...

  6. Re: Intels Fehleinschätzung

    Autor: MarkusXXX 02.08.21 - 19:45

    Ich dachte immer, das Problem bei diesen CPUs sind die Speicherzugriffe. Wenn der Compiler die Verteilung der Arbeit auf die einzelnen Execution Units macht, dann muss er dazu wissen, wie lange die einzelnen Befehle dauern. Bei Speicherzugriffen kann man das aber nicht so richtig vorhersagen, insbesondere bei dynamischen Daten oder wenn noch andere CPU-Kerne vorhanden sind.

    Wenn die Verteilung der Aufgaben aber innerhalb der CPU passiert, dann kann man die Arbeit einfach so verteilen, wie gerade freie Einheiten verfügbar sind.

    Ich kann mir auch nicht vorstellen, dass man es einerseits nicht schafft, solche Compiler zu schreiben, aber anderseits sehr wohl CPUs bauen kann, die diese Optimierung in Echtzeit nebenher machen. Deswegen glaube ich, dass es wegen der Speicherproblematik solche Compiler einfach nicht geben kann.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Product Owner S / 4HANA (m/w/d)
    Haufe Group, Freiburg im Breisgau
  2. Referent (m/w/d) IT-Servicemanagement
    Amt für Statistik Berlin-Brandenburg, Berlin
  3. Spezialist*in für Monitoring, Evaluierung und Informationssysteme
    GIZ Deutsche Gesellschaft für Internationale Zusammenarbeit GmbH, Eschborn
  4. (Senior) IT-Product Manager / Product Owner (m/w/d)
    NOVENTI Health SE, München

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Apacer AS340X 960GB SATA-SSD für 82,90€, Patriot Viper VPN100 2TB PCIe-SSD für 216...
  2. (u. a. Samsung U28R552UQU 28 Zoll für 249€)
  3. (u. a. mit Free M 20GB für 34,99€ monatlich (36 Monate Laufzeit) + 57,98€ Euro einmalig)
  4. (u. a. Expansion Desktop 14TB externe HDD für 290,99€, FireCuda 530 500GB PCIe 4.0 für 113...


Haben wir etwas übersehen?

E-Mail an news@golem.de