Itanium - Licht am Ende des Tunnels?

[up¦²]

Der frage hat sich Johan de Gelas gestellt :smile:

While Itanium may not be very popular in the hardware enthusiast community, it is definitely an architecture that, from an academic and technical point of view, deserves a lot more attention.


http://anandtech.com/cpuchipsets/showdoc.aspx?i=2598

[BlackBirdSR]

wovon man vor Allem einen Blick auf diesen Vergleich werfen sollte:
http://anandtech.com/cpuchipsets/showdoc.aspx?i=2598&p=4

[Muh-sagt-die-Kuh]

Ein sehr schöner zusammenfassender Artikel über die IA-64 Architektur, der auf alle relevanten Stärken und Schwächen sowie mögliche Entwicklungen eingeht....war sehr schön zu lesen :)

[StefanV]

IA-64 halte ich für suboptimal...

Das Teil hat Monstercaches und ist dennoch den 'Standard CPUs' wie Opteron nicht so weit überlegen, wie der Aufwand es vermuten lassen würde...

[BlackBirdSR]

IA-64 halte ich für suboptimal...

Das Teil hat Monstercaches und ist dennoch den 'Standard CPUs' wie Opteron nicht so weit überlegen, wie der Aufwand es vermuten lassen würde...

Ich erinnere mich an eine CPU, die sich PentiumPro nannte.
1MB L2 Cache und für die meisten User sogar schlechtere Performance.

Am Ende hat sich dieser Ansatz aber durchgesetzt.
Ob sich das bei IA64 wiederholt ist unsicher. Aber im Gegensatz zu x86 hat IA64 noch eine menge Möglichkeiten weiter zu skalieren.

[Coda]

Die Monstercaches haben primär damit etwas mit dem Einsatzzweck zu tun, nicht mit der Architektur.

Ja man braucht mehr Instruction-Cache, aber das wird mit kleineren Fertigungsverfahren bald kein Nachteil mehr sien.

[Muh-sagt-die-Kuh]

Suboptimal in Bezug auf was? Größere Caches sind ein einfacher und effektiver Weg zur Performance-Steigerung....

[stav0815]

Ich erinnere mich an eine CPU, die sich PentiumPro nannte.
1MB L2 Cache und für die meisten User sogar schlechtere Performance.

Am Ende hat sich dieser Ansatz aber durchgesetzt.
Ob sich das bei IA64 wiederholt ist unsicher. Aber im Gegensatz zu x86 hat IA64 noch eine menge Möglichkeiten weiter zu skalieren.
Der PentiumPro hat aber keinen Architekturwechsel mit sich gebracht...

[Coda]

Oh, sogar einen sehr gewaltigen. Von Dual-Issue In-Order zu 3-way superskalar Out-of-Order.

[ilPatrino]

beim ppro hat man aber nach recht kurzer zeit einen kräftigen schnitt gemacht und ein inkompatibles redesign (den p2) gebracht.

die itanic-schiene ist für solche spielchen ungeeignet, da man sonst die komplette plattform neu definieren müßte.

[Coda]

Wieso inkompatibel? Der PPro hatte den gleichen Bus wie der PII. Oder was meinst du?

[Tigerchen]

Wieso inkompatibel? Der PPro hatte den gleichen Bus wie der PII. Oder was meinst du?

Hatte der nicht einen eigenen Sockel?

[BlackBirdSR]

beim ppro hat man aber nach recht kurzer zeit einen kräftigen schnitt gemacht und ein inkompatibles redesign (den p2) gebracht.

die itanic-schiene ist für solche spielchen ungeeignet, da man sonst die komplette plattform neu definieren müßte.

warum inkompatibles redesign?
Der P2 ist auch nichts Anderes als ein PentiumPro mit einigen minimalen Veränderungen, MMX, und dem Cache auf einem externen Träger mit weniger Takt.

[StefanV]

beim ppro hat man aber nach recht kurzer zeit einen kräftigen schnitt gemacht und ein inkompatibles redesign (den p2) gebracht.

die itanic-schiene ist für solche spielchen ungeeignet, da man sonst die komplette plattform neu definieren müßte.
Nope, gab sogar mal vor langer Zeit P2 Overdrives für den Sockel 8, ebenso wie es einen Sockel 8 Slotket gab :devil:

Und soo groß waren die Änderungen von PPro zu P2 garnicht...
Die größte Änderung war MMX und die kostengünstigere Fertigung...

Bus und sonstiger Schotter blieben weitestgehend gleich.

PS: aber durchaus erstaunlich, zu welch einer Leistung das Antike P6 Design in der letzten Fassung doch in der Lage war (Tualatin)...

[zeckensack]

Ich erinnere mich an eine CPU, die sich PentiumPro nannte.
1MB L2 Cache und für die meisten User sogar schlechtere Performance.

Am Ende hat sich dieser Ansatz aber durchgesetzt.
Ob sich das bei IA64 wiederholt ist unsicher. Aber im Gegensatz zu x86 hat IA64 noch eine menge Möglichkeiten weiter zu skalieren.Der Vergleich ist mal sowas von daneben.
Der PPro hat Probleme mit bestimmten Dingen in alter Software mit denen der Pentium und seine Vorgänger keine Probleme hatten, namentlich Zugriffe auf Teilregister, was damals als "16 Bit-Schwäche" zusammengefasst wurde. Kompiliert man seine Software für den PPro nochmal neu, läuft sie schnell.

Wenn du mir jetzt verraten könntest, unter welchen Code-Altlasten genau der Itanium gleichermaßen leidet, und wie diese überhaupt existieren können, wo IA64 doch eine neue ISA ist, für die jede Software bereits speziell kompiliert sein muss, dann könnte ich den Vergleich vielleicht ernst nehmen. Ich glaube allerdings nicht dass du das schaffen wirst.

Der P2 ist auch nichts Anderes als ein PentiumPro mit einigen minimalen Veränderungen, MMX, und dem Cache auf einem externen Träger mit weniger Takt.Diese sogenannten minimalen Veränderungen betrafen vor allem die partial register stalls. Auf die Performance hatte das seinerzeit große Auswirkungen.

[zeckensack]

http://anandtech.com/cpuchipsets/showdoc.aspx?i=2598Gut getroffen:
"The main philosophy behind Itanium is, of course, that a compiler can statically schedule instructions much better than a hardware scheduler, which has to decide this dynamically in a few clock cycles."

Allerdings zweifle ich daran, dass diese Idee richtig ist. Ein Compiler kann nichts über laufzeitdynamische Daten wissen.

bool fertich=false;
float t=0.0f;
while (!fertich)
{
if (t<25.0f) vorwäsche(t);
else
if (t<75.0f) hauptwäsche(t);
else
if (t<85.0f) spülen(t);
else
if (t<100.0f) schleudern(t);
else fertich=true;
t+=0.1f;
}Dh schon bei so simplen Dingen wie einer Waschmaschinensteuerung ist die Grundidee falsch. Statisches Scheduling durch den Compiler kann gegen eine vernünftige dynamische Sprungvorhersage nicht bestehen.

[RLZ]

Allerdings zweifle ich daran, dass diese Idee richtig ist. Ein Compiler kann nichts über laufzeitdynamische Daten wissen.
Das ist sicher richtig. Wobei dein Beispiel nicht gerade optimal gewählt ist. :)

while (t<25.f) {
vorwäsche(t);
t += 0.1f;
}
while (t<75.f) {
....
}
...

Würde das Problem entschärfen.
Meistens lässt sich ein Konstrukt bauen um diese Fälle zu verhindern.
Der Allerweltsprogrammierer wird dies aber nicht tun und dass Compiler dies wirklich erledigen können bezweifel ich.

[stav0815]

Oh, sogar einen sehr gewaltigen. Von Dual-Issue In-Order zu 3-way superskalar Out-of-Order.
aber der PPro war ein x86 Prozessor.
Itanium bricht mit x86 und bringt eine Leistung für diese Architektur, die eines Pentium 133 gleichzusetzen ist.

[BlackBirdSR]

Der Vergleich ist mal sowas von daneben.

Vielleicht siehst du es auch nur daneben, und wir reden aneinander vorbei?
Es ging nicht darum, die Probleme des PPro mit denen des Itanium zu vergleichen. Warum auch?
Vielmehr ging es darum, Ähnlichkeiten im Image und seiner Geschichte aufzuzeigen.
Der PentiumPro hatte bei normalen Usern, Zeitschriften und kaum sonstwo so gut wie keine positive Kritik bekommen. Das lag natürlich am User und an der verwendeten Software.
So geht es dem Itanium ja auch. Ganz egal jetzt, woran genau diese Probleme sind, weswegen sie auftreten und ob Itanium nun scheisse ist oder nicht.

Daneben ist also aus meiner Sicht höchstens dein Ansatz.


Wenn du mir jetzt verraten könntest, unter welchen Code-Altlasten genau der Itanium gleichermaßen leidet, und wie diese überhaupt existieren können, wo IA64 doch eine neue ISA ist, für die jede Software bereits speziell kompiliert sein muss, dann könnte ich den Vergleich vielleicht ernst nehmen. Ich glaube allerdings nicht dass du das schaffen wirst.

Wie gesagt, hast du dich in die ganz falsche Richtung verlaufen.

Es geht mir hier nicht darum Itanium schön oder schlecht zu reden. Vielleicht willst du auf das hinaus.
Ich würde mich aber freuen, wenn ich noch etwas darstellen dürfte, ohne in diesen kalten Krieg hineingezogen zu werden. Den könnt ihr gerne wo anders austragen.
Es ist völlig egal ob Itanium nun scheisse oder nicht ist. Denn das hatte noch nie sonderliche Auswirkungen auf die Akzeptanz am Markt.
Für x86 gibt es ebenso Codebeispiele die wirklich scheisse laufen. Für x86 findet man ebenfalls mehr als genug Beispiele wo Alles einfach suboptimal ist. Man muss es sich nur raussuchen.

Mein Punkt ist ganz allein der, dass man nicht sagen kann ob und wann Itanium mal erfolgreich wird. Der PentiumPro war auch Vater einer Erfolgsgeneration.
Nein.. und damit will ich nicht spezifische Punkte zwischen PPro und Itanium vergleichen.

@stav0815
Die ersten Merceds hatten diese Performance.
Mit McKinley wurde das etwas besser, wenn auch immernoch total sinnlos um performancekritische Anwendungen damit laufen zu lassen. Man fragt sich, warum Intel dafür knapp 5 Milionen Transistoren verschwendet.
Intel setzt jetzt sowieo auf einen Softwarelayer, der um Einiges mehr Performance möglich macht.

[Coda]

Itanium bricht mit x86 und bringt eine Leistung für diese Architektur, die eines Pentium 133 gleichzusetzen ist.So schlecht ist sie sicher nicht.

[DavChrFen]

Hm, wenn auf dem Itanuium 4 Millionen Transistoren für IA32-Kompatibilität (was ja 32-bit x86 ist, oder?)sind, wieso ist dann Itanuim mit x86-Code so langsam? Ich dachte bis jetzt immer, x86-Code wird auf Itanium per Software-Emulator emuliert.

[Muh-sagt-die-Kuh]

Gut getroffen:
"The main philosophy behind Itanium is, of course, that a compiler can statically schedule instructions much better than a hardware scheduler, which has to decide this dynamically in a few clock cycles."

Allerdings zweifle ich daran, dass diese Idee richtig ist. Ein Compiler kann nichts über laufzeitdynamische Daten wissen.

bool fertich=false;
float t=0.0f;
while (!fertich)
{
if (t<25.0f) vorwäsche(t);
else
if (t<75.0f) hauptwäsche(t);
else
if (t<85.0f) spülen(t);
else
if (t<100.0f) schleudern(t);
else fertich=true;
t+=0.1f;
}Dh schon bei so simplen Dingen wie einer Waschmaschinensteuerung ist die Grundidee falsch. Statisches Scheduling durch den Compiler kann gegen eine vernünftige dynamische Sprungvorhersage nicht bestehen.Das geht doch sehr schön mit Predication....du jagst einfach alle Befehle von Vorwäsche, Hauptwäsche, Spülen und Schleudern als konditionale Instruktionen durch die Pipeline. Am Ende noch ein Sprung unter der Bedingung T >= 100 um die Schleife zu beenden.....genau dies ist der einzige konditionale Sprung den du brauchst.

[Muh-sagt-die-Kuh]

Hm, wenn auf dem Itanuium 4 Millionen Transistoren für IA32-Kompatibilität (was ja 32-bit x86 ist, oder?)sind, wieso ist dann Itanuim mit x86-Code so langsam? Ich dachte bis jetzt immer, x86-Code wird auf Itanium per Software-Emulator emuliert.Weil x86 Code und die Ausführungslogik einer IA-64 CPU sich ungefähr so gut vertragen wie George W. Bush und Kim Jong-Il ;)

Die Transistoren dafür kann man eigentlich rauswerfen, die Software-Emulation namen IA-32 Execution Layer ist deutlich performanter, ein Madison 1,5 Ghz kommt damit bei IA-32 Code ungefähr auf die Geschwindigkeit eines Xeon 1,5 Ghz.

[Coda]

Hm, wenn auf dem Itanuium 4 Millionen Transistoren für IA32-Kompatibilität (was ja 32-bit x86 ist, oder?)sind, wieso ist dann Itanuim mit x86-Code so langsam? Ich dachte bis jetzt immer, x86-Code wird auf Itanium per Software-Emulator emuliert.Ja und das ist sogar schneller.

[Benedikt]

Ja und das ist sogar schneller.
Erinnert mich irgendwie an DECs gutes altes FX!32. 32bit x86 auf Alpha. Mann, das waren noch Zeiten... ;)

[zeckensack]

Das geht doch sehr schön mit Predication....du jagst einfach alle Befehle von Vorwäsche, Hauptwäsche, Spülen und Schleudern als konditionale Instruktionen durch die Pipeline. Am Ende noch ein Sprung unter der Bedingung T >= 100 um die Schleife zu beenden.....genau dies ist der einzige konditionale Sprung den du brauchst.Ob sich das lohnt hängt davon ab wieviele Instruktionen das jeweils sind. Das können auch richtig große Funktionen sein. Das war auch eher als humoristisches Beispiel gedacht ;)

Der Punkt war der der zeitlichen Kohärenz bei der Sprungauswahl, aus welcher der Compiler allerdings nichts machen kann, selbst wenn er sie erkennt. Davon ist die gesamte Klasse der "finite state machines" betroffen, und die ist IMO nicht unwichtig.

Ich prügle mich seit einer Weile mit 'nem ARMv4T, und der hat das Problem auch (neben einigen anderen). Im Moment lasse ich das Maschinchen dauernd irgendwelche Funktionszeiger austauschen, um bloss keine dynamischen Sprünge mehr machen zu müssen. Sowas zu schreiben und zu warten, allem voran erstmal deterministisch zu bekommen, ist wirklich der absolute Horror.

Ich weiß auch dass HW-BP nicht billig ist, aber sie macht das Leben wirklich wesentlich leichter.

[aths]

Ich weiß auch dass HW-BP nicht billig ist, aber sie macht das Leben wirklich wesentlich leichter.Wie funktioniert das eigentlich, vom Grundprinzip her? Wird die Sprungadresse nur geschätzt oder wird der Sprung schon ausgewertet, wenn nach Möglichkeit noch andere Mikroinstruktionen in der Pipe sind?

[BlackBirdSR]

Hm, wenn auf dem Itanuium 4 Millionen Transistoren für IA32-Kompatibilität (was ja 32-bit x86 ist, oder?)sind, wieso ist dann Itanuim mit x86-Code so langsam? Ich dachte bis jetzt immer, x86-Code wird auf Itanium per Software-Emulator emuliert.

Emuliert wurde zu Beginn gar nichts.
Die ankommenden x86 Befehle wurden von Hardwareinheiten in IA64 Anweisungen übersetzt. Das hat am Anfang auch ziemlich beschissen geklappt.
Eine interessante Frage ist nun, wie viel Abwärme diese Transistoren verursachen, und wieviel Takt dadurch eventuell verloren geht.
5 Millionen mag jetzt nicht nach viel klingen. Aber vergleichen mit dem eigentlich IA64 Kern ist das schon ein großer Brocken.

[Muh-sagt-die-Kuh]

Wie funktioniert das eigentlich, vom Grundprinzip her? Wird die Sprungadresse nur geschätzt oder wird der Sprung schon ausgewertet, wenn nach Möglichkeit noch andere Mikroinstruktionen in der Pipe sind?Auch hier ist Wikipedia eine ganz brauchbare Quelle:

http://en.wikipedia.org/wiki/Branch_predictor

[Muh-sagt-die-Kuh]

Ob sich das lohnt hängt davon ab wieviele Instruktionen das jeweils sind. Das können auch richtig große Funktionen sein. Das war auch eher als humoristisches Beispiel gedacht ;)Korrekt, in diesem Fall würde ein echter konditionaler Sprung im Funktions-Selektor aber kaum ins Gewicht fallen.Der Punkt war der der zeitlichen Kohärenz bei der Sprungauswahl, aus welcher der Compiler allerdings nichts machen kann, selbst wenn er sie erkennt. Davon ist die gesamte Klasse der "finite state machines" betroffen, und die ist IMO nicht unwichtig.

Ich prügle mich seit einer Weile mit 'nem ARMv4T, und der hat das Problem auch (neben einigen anderen). Im Moment lasse ich das Maschinchen dauernd irgendwelche Funktionszeiger austauschen, um bloss keine dynamischen Sprünge mehr machen zu müssen. Sowas zu schreiben und zu warten, allem voran erstmal deterministisch zu bekommen, ist wirklich der absolute Horror.

Ich weiß auch dass HW-BP nicht billig ist, aber sie macht das Leben wirklich wesentlich leichter.Wenn man das per Hand machen muss ist das definitiv ein Krampf ;) IA-64 ist aus diesem Grund auch sehr von leistungsfähigen Compilern abhängig, die eben aus Code mit dynamischen Sprüngen möglichst statischen machen. Dies ist kein leichtes Unterfangen und erfordert auch eine ganze Menge Forschung. Allerdings kann man hier eben durch Software-Verbesserungen die Leistung gehörig steigern.

P.S.: Hat irgendwer Ahnung, wieviele Transistoren der HW-Branch Predictor in einem P4 Prescott frisst?

[Coda]

Gerade bei den Compilern mangelt es aber noch extrem. Was GCC für nen Scheißcode produziert für IA64 ist echt brutal ;)

[Muh-sagt-die-Kuh]

Gerade bei den Compilern mangelt es aber noch extrem. Was GCC für nen Scheißcode produziert für IA64 ist echt brutal ;)Sowas in der Richtung Bundle = (Befehl | NOP | NOP) und keine Abhängigkeitsinformationen? ;)