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. Beitrag
  1. Thema

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


Neues Thema Ansicht wechseln


Thema
 

Intels Fehleinschätzung

/mecki78 | 02.08.21 - 13:07
 

Re: Intels Fehleinschätzung

486dx4-160 | 02.08.21 - 14:51
 

Re: Intels Fehleinschätzung

nate | 02.08.21 - 15:15
 

Re: Intels Fehleinschätzung

Johannes321 | 02.08.21 - 15:59
 

Re: Intels Fehleinschätzung

NilsP | 02.08.21 - 17:00
 

Re: Intels Fehleinschätzung

MarkusXXX | 02.08.21 - 19:45

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. Business Analyst (m/w/d) Fachinformationen
    Deutsche Leasing AG, Bad Homburg v. d. Höhe
  2. Global Senior Data Manager (m/f/d) - Consumer Data
    Dr. August Oetker Nahrungsmittel KG, Bielefeld
  3. Requirements Engineer (w/m/d) Softwareentwicklung
    SSI SCHÄFER IT Solutions GmbH, Giebelstadt, Dortmund
  4. JavaScript-Entwickler (m/w/d)
    tangro software components GmbH, Heidelberg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Monster Hunter World - Iceborne (Master Edition) für 24,99€, Xbox Live Card 20 Euro für...
  2. heute: Microsoft Surface Pro 7+ 12,3 Zoll Convertible 8GB 128GB SSD + Microsoft 365 Family für...
  3. u. a. Geschenke für Gamer


Haben wir etwas übersehen?

E-Mail an news@golem.de


Merck: Von der Apotheke zum zweitbesten IT-Arbeitgeber
Merck
Von der Apotheke zum zweitbesten IT-Arbeitgeber

Das Pharmaunternehmen Merck ist auf Platz 2 der Top-IT-Arbeitgeber Deutschlands gelandet - wir wollten von den Mitarbeitern wissen, wieso.
Von Tobias Költzsch


    Resident Evil - Welcome to Raccoon City: Ein holpriger Neuanfang
    Resident Evil - Welcome to Raccoon City
    Ein holpriger Neuanfang

    Nach sechs Filmen mit Milla Jovovich wagt Constantin einen Neuanfang von Resident Evil: Er führt zurück ins Jahr 1998.
    Von Peter Osteried

    1. Capcom Update korrigiert Kopierschutz von Resident Evil Village
    2. Resident Evil: Infinite Darkness Mehr ein Film als eine Serie
    3. Resident Evil 8 Village Mod manipuliert den Hut des Horrors

    Ohne Google, Android oder Amazon: Der Open-Source-Großangriff
    Ohne Google, Android oder Amazon
    Der Open-Source-Großangriff

    Smarte Geräte sollen auch ohne die Cloud von Google oder Amazon funktionieren. Huawei hat mit Oniro dafür ein ausgefeiltes Open-Source-Projekt gestartet.
    Ein Bericht von Sebastian Grüner

    1. Internet der Dinge Asistenten wie Alexa und Siri droht EU-Regulierung