Itanium vs. AMD64: Sollten wir uns eigentlich ägern, dass es nicht Itanium geworden ist?

[Grambol]

Wenn ich mich recht entsinne wollte Intel Itanium CPU quasi als ersatz für x86 nehmen als der Wechsel zu 64bit nötig wurde. Dann hat aber AMD AMD64 rausgebracht und das hat dann gewonnen weil's kompatibel war. Stimmt das?

Wäre Itanium eigentlich besser gewesen, wenn man die Kompatibilität außer acht lässt?

[Grohool]

ja

[volkard]

ja!

[zwutz]

jetzt bin ich an einer Begründung interessiert... ich dachte immer, Itanium hätte diverse Probleme gehabt.

[SeppJ]

zwutz schrieb:

jetzt bin ich an einer Begründung interessiert... ich dachte immer, Itanium hätte diverse Probleme gehabt.

Die Probleme waren meines Wissens nach:
a) Im Hochleistungsbereich war er bloß ein weiterer Prozessor unter vielen (Power, SPARC,...) ohne besondere Merkmale
b) Im Niederleistungsbereich gab es viel x86 Software die in Emulation laufen musste. Und das war rechnleistungsmäßig teuer. So teuer, dass ein neuer Itanium langsamer war als die alten x86er.

Ansonsten war/ist er natürlich dem x86 technisch überlegen. Vor allem da er nicht so viele Altlasten mit sich rumschleppt, die es dem x86er auch heute noch erlauben Anwendungen von 1982 auszuführen, die damals mit ganz tollen Tricks programmiert wurden, um wirklich alles aus einem 8086 rauszuholen.

[zwutz]

also wäre er bei nativen 64bit schneller als die AMD-Architektur?

[*rant*]

Ich habe gelesen, dass es extrem schwierig sein soll, einen guten Compiler für Itanium zu schreiben. Die tollsten Instruktionen nützen nichts, wenn sie vom Compiler nicht genutzt werden. Die explizite Parallelität auf Befehlsebene ist Segen und Fluch zugleich, da sich der Compiler dann um die Ausführungsreihenfolge auf der untersten Ebene kümmern muss (das wird bei x86-64 soweit ich informiert bin dynamisch und erst zur Laufzeit gemacht) wenn das Laufzeitverhalten optimal sein soll.

zwutz schrieb:

also wäre er bei nativen 64bit schneller als die AMD-Architektur?

Das ist sehr wahrscheinlich, wobei so eine generelle Aussage natürlich immer unter gewissen Einschränkungen zu sehen ist. Der Itanium ist eine Architektur ohne den alten x86 Schrott welcher sich seit den frühen 80er Jahren angesammelt hat und der immernoch irgendwie unterstützt werden muss. Man hat viel mehr Register (128 + 128 + 64 ), die ein Compiler nutzen darf. Zusammen mit einem durchdachten Architekturdesign denke ich schon, dass man den allgemeinen x86 / AMD64 Ansatz überholen könnte.

[SeppJ]

Vielleicht gibt es doch noch Hoffnung auf einen schlanken x86:
http://www.heise.de/ct/artikel/Prozessorgefluester-292098.html
Ganz unten, der Infokasten zu den neuen Nehalem-Xeons.

[rapso]

was vergleicht man hier eigentlich? instruction set oder hardware?

[hustbaer]

itanium is kacke, weil es schwieriger ist, funktionierende programme mit multi-threading für itanium zu schreiben. genauso wie für powerpc. und erstrecht alpha.
wären die programmierer nicht alle so doof wäre das natürlich kein problem, aber da es nunmal so ist wie es ist...

amd64 passt schon.
muss nicht immer alles kompliziert sein damit es gut ist.

[Grohool]

ist ein amd64 nicht komplizierter als ein itanium?

[Grambol]

hustbaer schrieb:

itanium is kacke, weil es schwieriger ist, funktionierende programme mit multi-threading für itanium zu schreiben. genauso wie für powerpc. und erstrecht alpha.
wären die programmierer nicht alle so doof wäre das natürlich kein problem, aber da es nunmal so ist wie es ist...

Ist das nicht nur ein Problem für den Compiler?

[rapso]

Grohool schrieb:

ist ein amd64 nicht komplizierter als ein itanium?

wie diefinierst du das objektiv? die anzahl der logikschaltungen die noetig sind auf einem die?
http://en.wikipedia.org/wiki/Transistor_count

[rapso]

Grambol schrieb:

hustbaer schrieb:

itanium is kacke, weil es schwieriger ist, funktionierende programme mit multi-threading für itanium zu schreiben. genauso wie für powerpc. und erstrecht alpha.
wären die programmierer nicht alle so doof wäre das natürlich kein problem, aber da es nunmal so ist wie es ist...

Ist das nicht nur ein Problem für den Compiler?

nein, compiler wissen meistens garnichts von multithreading.
ich wueste aber gerne was am itanium schwerer sein soll es multithreaded zu bekommen als an anderen cpus.

[Grambol]

rapso schrieb:

Grambol schrieb:

hustbaer schrieb:

itanium is kacke, weil es schwieriger ist, funktionierende programme mit multi-threading für itanium zu schreiben. genauso wie für powerpc. und erstrecht alpha.
wären die programmierer nicht alle so doof wäre das natürlich kein problem, aber da es nunmal so ist wie es ist...

Ist das nicht nur ein Problem für den Compiler?

nein, compiler wissen meistens garnichts von multithreading.
ich wueste aber gerne was am itanium schwerer sein soll es multithreaded zu bekommen als an anderen cpus.

Wikipedia schrieb:

The Itanium architecture is based on explicit instruction-level parallelism, in which the compiler makes the decisions about which instructions to execute in parallel.

So ganz weiß ich jetzt nicht was das heissen soll. Wohl nicht was hustbaer gemeint hat, ich dachte erst das es darum ging.

[rüdiger]

Itanium wäre besser gewesen. Einerseits schleppen wir mit dem x86 viel Müll rum. Aber der IA64 hätte viel gebracht, weil die einzelnen Anweisungsblöcke parallelisierbar sind. Somit profitiert der deutlich stärker von der steigenden Transistordichte, obwohl die Frequenz nicht weiter steigt. Außerdem findet keine Magie mehr in der CPU statt. x86er verarbeiten ja die Instruktionen vor, damit dieser 70er Jahre Blödsinn sinnvoll von der CPU verarbeitet werden kann. Daher passiert da viel Magie, die man von außen schlecht abschätzen kann und die stark unterschiedlich zwischen den CPU Generationen sein kann.

Beim IA64 wäre das alles in den Compiler verlagert worden. Daher waren die Compiler am Anfang auch noch ein bisschen überfordert. Aber das Problem wäre sicher gelöst.

@rapso
Ich denke hustbaer bezieht sich darauf: http://en.wikipedia.org/wiki/Memory_ordering

@hustbaer
Das liegt einfach daran, dass das übliche Threadingkonzept (shared state) zu kompliziert ist. Die meiste Zeit käme man mit deutlich einfacheren Modellen zurecht, wie dem Actormodell (ala Erlang).

[rapso]

Grambol schrieb:

Wikipedia schrieb:

The Itanium architecture is based on explicit instruction-level parallelism, in which the compiler makes the decisions about which instructions to execute in parallel.

So ganz weiß ich jetzt nicht was das heissen soll. Wohl nicht was hustbaer gemeint hat, ich dachte erst das es darum ging.

das hat nichts mit multithreading zu tun, wenn auch das wirklich ein riesen problem ist.

[Grohool]

rapso schrieb:

Grohool schrieb:

ist ein amd64 nicht komplizierter als ein itanium?

wie diefinierst du das objektiv? die anzahl der logikschaltungen die noetig sind auf einem die?
http://en.wikipedia.org/wiki/Transistor_count

Naja es macht nicht wirklich Sinn eine Architektur mit einem bestimmten Prozessor zu vergleichen. Was ich meinte ist, einiges was bei der amd64 Architektur der Prozessor Leisten muss wird bei IA64 schon vom Compiler verlangt, so dass bei einem IA64 Prozessor diese Stufe wegfällt, bzw. einfacher wird im gegensatz zu einem Multiskalaren amd64 Rechner.

[rapso]

rüdiger schrieb:

Itanium wäre besser gewesen. Einerseits schleppen wir mit dem x86 viel Müll rum.

was genau bezeichnest du als muell, 16bit oder auch die 32 bit?
die 16bit passten damals in 100k transistoren und sind heutzutage weit aus weniger da sie nur ein paar macros sind die auf normale (unverzichtbare) instruktionen mappen.
die 32bit sind hingegen das was noch 90% der leute nutzt, ohne die kannst du keine mainstream-cpu rausbringen, das war ein grund weshalb der itanium probleme hatte und das obwohl er eigentlich fuer einen markt gedacht war wo das wenig relevant sein sollte.

Aber der IA64 hätte viel gebracht, weil die einzelnen Anweisungsblöcke parallelisierbar sind. Somit profitiert der deutlich stärker von der steigenden Transistordichte, obwohl die Frequenz nicht weiter steigt.

das ist irgendwie ne milchmaenchenrechnung (das soll kein angriff gegen dich sein ), eine prozessor architektur aendert wenig daran wie code der schon geschrieben ist parallelisiert werden kann. es ist schon aufwendig code zu schreiben/generieren der 2 unabhaengige pipelines auslastet (so ist es z.b. bei den cell-SPUs und einigen powerPC kernen). sehr viel vom code wie ihn normale menschen schreiben baut auf vorherigen schritten auf, es ist eher selten dass unabhaengige (verschiedene) befehle ausgefuerht werden, besonders nicht auf 6pipes wie itanium es hat, afaik.
da ich shader schreibe und zugriff auf ein paar untere ebenen habe, sehe ich VLIW opcode und ohne das man sich da wirklich reinkniet, benutzt der code meist nur ca 30% der einheiten. mit viel arbeit bekommt man es dann hin ca 75% zu nutzen, das aber auch nur wenn man schon per hand assembler schreibt,
und das obwohl der compiler fuer <500 instructions sich 5Min goennt.

Die stellen an denen VLIW vorteile hat, gegenueber simplem abarbeiten von opcodes, sind stellen die meistens mit SIMD ebenfalls angegangen werden koennen.
Es stimmt dass compiler auch SIMD code nicht vernuenftig generieren koennen, aber an den stellen an denen du fuer VLIW optimieren willst, kannst du auch fuer SIMD optimieren und an den stellen wo du nicht per hand fuer VLIW optimierst, da laeuft es besser auf normalen cpus.

Außerdem findet keine Magie mehr in der CPU statt. x86er verarbeiten ja die Instruktionen vor, damit dieser 70er Jahre Blödsinn sinnvoll von der CPU verarbeitet werden kann. Daher passiert da viel Magie, die man von außen schlecht abschätzen kann und die stark unterschiedlich zwischen den CPU Generationen sein kann.

ich verstehe ehrlich nicht was du mit magie meinst in bezug auf 70er jahre.
meinst du die 16bit? da seh ich irgendwie keine magie
oder out of order execution (magie)? da seh ich irgendwie keinen zusammenhang zu den 70er jahren

Beim IA64 wäre das alles in den Compiler verlagert worden. Daher waren die Compiler am Anfang auch noch ein bisschen überfordert. Aber das Problem wäre sicher gelöst.

seitdem ich wirklich smarte leute scheitern sah beim versuch algorithmen zu finden die deterministisch den besten code generieren, seh ich VLIW als ein schoenes theorie konstrukt was in der realitaet scheitert.

@rapso
Ich denke hustbaer bezieht sich darauf: http://en.wikipedia.org/wiki/Memory_ordering

diese probleme gibt es auf jeder cpu, wieso sollte das das threading auf dem itanium problematischer machen?

[Wikinger75]

Vielleicht gibt es doch noch Hoffnung auf einen schlanken x86:
http://www.heise.de/ct/artikel/Prozessorgefluester-292098.html
Ganz unten, der Infokasten zu den neuen Nehalem-Xeons.

http://de.wikipedia.org/wiki/Intel_Xeon_(Nehalem)
Also ich weiß nciht was bei deinem Link für probleme gibt.
Die CPU Architekture unterstüzt doch noch x86 und AMD64, naja eigentlich unterstüzt sie nur diese und wenn ich da was falsch verstanden habe, was sollte bei dme neues mitkommen?

Mfg Wikinger75