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

[*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

[SeppJ]

Wikinger75 schrieb:

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?

Ich beziehe mich auf das, was der Nehalem Xeon WENIGER hat. Es ist nämlich der erste X86 seit dem i486, der kein A20-Gate mehr eingebaut hat! Somit ist dieser Prozessor nicht mehr voll kompatibel zu 8086 und 186. Manche Software welche spezielle Hardwarefeatures dieser Prozessoren ausgenutzt hat (z.B. himem.sys) funktioniert auf diesem Prozessor nicht mehr.
Dafür hat man sich beim Nehalem einen umständlichen Hardwarehack gespart, den die x86-Architektur seit nunmehr 20 Jahren (ziemlich unnötigerweise) mit sich rumschleppt (beim 286 und 386 war das A20-Gate übrigens auf der Hauptplatine).

[rüdiger]

rapso schrieb:

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.

Nicht nur die 16 und 32 Bit Instruktionen, sondern auch das Format (unterschiedlich lange opcodes), A20-Gate, Protected/Real-Mode etc. Die Grundlagen des x86er stammen aus den 70ern und mittlerweile hat man halt dazu gelernt und muss den ganzen Blödsinn nicht rumschleppen.

Wenn man bei der Architektur flexibel geblieben wäre, dann würden heutige Desktops wohl deutlich weniger Energie brauchen und man könnte die Leistung deutlich besser ausnutzen.

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.

In dem Markt hatte der Itanium doch eher Probleme, weil mittlerweile Computer mit x86ern gut genug und wesentlich billiger sind.

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

Das umordnen und optimieren der Instruktionen, Branchprediction etc. Ein x86er macht ja recht viel mit den Instruktionen, daher ist recht wenig vorhersagbar.

@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?

x86(_64) macht recht wenig reordering. Auf anderen CPUs wird da viel mehr gemacht. Hustbaer hat ja auch andere CPUs als Itanium erwähnt.

[rapso]

Grohool schrieb:

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.

da hast du recht, das waere an sich die RISC idee. die funktioniert ja auch sehr konkurenzfaehig. der Itanium hat aber sehr viele teile die heute x86 auch haben, das einzige was er sich einspart ist der teil der am meisten performance bringt pro transistor, bei 08/15 code, die OutOfOrder einheiten. Er will also immer noch gefuettert werden wie ein x86, aber vom compiler, nicht vom sheduller.
das schlaegt IMHO fehl, denn die allermeisten dinge die heutzutage eine pipeline stallen (again, bei 08/15 code) sind dynamisch, im besondern speicherzugriffe. das siehst du wenn du den selben code auf nem atom oder cell ausfuehrst, ein P3-733 bzw 1.3GHz PowerPC(der in alten macbooks) kann dann mithalten und selbst wenn du ohne stalls arbeiten wuerdest, der normale code wird trotzdem einen grossen teil der pipeline wohl nicht auslasten, das was brach liegt ist nicht sonderlich weniger als dich die out of order einheiten gekostet haetten (ja, das ist meine behauptung )

[hustbaer]

ja, ich meinte das "memory-ordering", oder wie auch immer man es nennen will. x86 ist diesbezüglich watscheneinfach.

BTW: für massiv-parallele systeme macht ein entspannteres ordering ala PPC/Alpha/Itanium schon sinn (bangs-per-buck). für desktop systeme mit vielleicht insgesamt 8-16 cores auf 1-2 CPUs ist es dagegen IMO nicht notwendig.

----

ich dachte ehrlich gesagt auch lange zeit, dass die x86 architektur mit ihren "variable-grösse-befehlen" und dem ganzen CISC quargel ein grosser haufen dreck ist.

heute denke ich anders darüber. gerade diese CISC architektur ermöglicht es, CPUs zu bauen, die exakt den gleichen code schneller ausführen. ohne änderung am compiler, ohne neu übersetzen, ohne JITer. und ich meine jetzt gemessen in CPU clocks, also schneller bei gleichem takt.

zugegeben, der müll den x86 mit rumschleppt ist schon arg. andrerseits wurde beim itanium IMO wieder zu viel eingespaart.

[Grambol]

Wie sah es eigentlich mit der Patentsituation aus? Ich glaube AMD und Intel haben da irgendwie so ein Abkommen für x86? Hätte AMD überhaupt Itaniums bauen können?

[DEvent]

rüdiger schrieb:

rapso schrieb:

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.

Nicht nur die 16 und 32 Bit Instruktionen, sondern auch das Format (unterschiedlich lange opcodes), A20-Gate, Protected/Real-Mode etc. Die Grundlagen des x86er stammen aus den 70ern und mittlerweile hat man halt dazu gelernt und muss den ganzen Blödsinn nicht rumschleppen.

Wenn man bei der Architektur flexibel geblieben wäre, dann würden heutige Desktops wohl deutlich weniger Energie brauchen und man könnte die Leistung deutlich besser ausnutzen.

Wieso hat man den das gemacht? - wegen der Monokultur Windows, die sich MS unrechtmäßig ergaunert hat. Deswegen werden wir auch in 20 Jahren noch den ganzen Ballast mit schleppen. Wenn der Marktführer sein OS nun mal nur in 5 oder 3 Jahreszyklen entwickelt, kann man nicht viel Flexibilität an den Tag legen.