Itanium vs. AMD64: Sollten wir uns eigentlich ägern, dass es nicht Itanium geworden ist?
-
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?
-
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
-
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.
-
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.
-
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).
-
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.
-
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_countNaja 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.
-
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 jahrenBeim 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_orderingdiese probleme gibt es auf jeder cpu, wieso sollte das das threading auf dem itanium problematischer machen?
-
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
-
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).
-
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 jahrenDas 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_orderingdiese 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.
-
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_countNaja 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 )
-
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.
-
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?
-
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.
-
DEvent schrieb:
Wieso hat man den das gemacht?
Weil Kompatibilität wichtiger ist.
DEvent schrieb:
wegen der Monokultur Windows, die sich MS unrechtmäßig ergaunert hat.
Du kannst es echt nicht lassen, oder?
DEvent schrieb:
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.
Windows läuft ganz prima auf IA-64.
-
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.
zum einen ist das bei einigen x86 raus afaik (im genauen sollen einige xeons fuer server kein a20 gate mehr haben :D, hauptsaechlich wegen EFI), zum anderen sollte das eigentlich komplett egal sein. niemand von uns hier benutzt das und chipmaessig ist es doch auch weniger transistoren als man fuer die division verbaut afaik.
mehr als das sich die leute darueber auslassen koennen macht A20 usw. nicht mehr aus.
wie gesagt, kompletter 286 war ca 100k transistoren. NahalemEx hat etwas um 2Mrd, fuer den oldy mode sicher nur paar k, das sollte doch niemanden stoeren?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 architektur ist sehr flexibel, so sehr dass komplett neu erstellte chips gemacht werden die alte dinge nur emulieren oder hardware fehler per flash beheben koennen. ich finde das ist extrem flexibel. das was sich nicht aendert ist das instruction set um softwarekompatibilitaet zu gewaehrleisten, aber das auch nur bei minimalen kosten.
Wenn man sich andere architekturen ansieht die komplett die kompatibilitaet geschmissen haben, sehe ich keinen riesen vorteil.
Und gerade wenn man ueber verschwendung spricht, muesste eine VLIW architektur wie die des Itaniums einem total die zaehnaegel aufklappen lassen. Schau dir die geplanten Itaniums mal gegen einen Power7 an, rein datentechnisch ist der Power7 ewigkeiten voraus und wenn man dann sieht wieviel effizienter der code fuer Power7 die einheiten auslastet, wundert es einen wieso irgendjemand einen Itanium kaufen sollte (ausser aus spass am VLIW optimieren ).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 meinte den server markt, dafuer war der itanium gedacht, und er hatte auch dort probleme weil er 32bit code nicht schnell genug ausfuehrte.Das hat auch intel gesehen, deswegen gab es immer mehr hardware im itanium die 32bit schneller machen sollte (dagegen sind die 70er jahre altlasten der heutigen cpus sogar ein witz
).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 jahrenDas umordnen und optimieren der Instruktionen, Branchprediction etc. Ein x86er macht ja recht viel mit den Instruktionen, daher ist recht wenig vorhersagbar.
naja, du hast die wahl, entweder stallen oder instruktionen ausfuehren die unabhaengig sind. natuerlich hast du recht, sowas ist dann nicht vorhersagbar und ja, mit steigender transistorzahl nimmt die effektivitaet von den eingesetzten transistoren ab.
Aber das ziel ist auch ein anderes. Intel und amd zielen auf software ab die 08/15 ist, die weder neu compiliert wird, nur weil es ne neue cpu gibt, noch macht sich die programmierergemeinde die arbeit die 5verschiedenen existierenden cpu architekturen bei x86 auszunutzen. Trotzdem kauft jemand eine neue cpu und erwartet dass alles schneller wird.
Neue features zu supporten wie z.b. neue instruktionen, mehr register, etc. bringt in den allermeisten faellen jahrelang nichts und dann auch nur in ausgesuchten benchmarks was. alles was du dir bisher gekauft hast bringt dir nichts and mehrleistung nur weil ein neues hardwarefeature vorhanden ist.
Du musst dir nur anschauen wie bescheiden der support von multicore bis heute ist, obwohl intel massig dafuer wirbt, software anbietet die einem dabei viel arbeit abnimmt und single-core cpus fast ausgestorben sind in desktop PCs.
Da koennte man auch sagen dass es bescheuert ist von intel, dass sie 3cores auf minimum runtertakten und dann einen uebertakten.
aber am ende bringt es den meisten anwendern den performancevorteil den sie wollen, wenn sie ihre eine single-thread-anwendung laufen lassen, um die cpu zu kaufen.@rapso
Ich denke hustbaer bezieht sich darauf: http://en.wikipedia.org/wiki/Memory_orderingdiese 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.
deswegen wundert es mich was der itanium mehr an reordering macht als z.b. ein powerPC. Ich zaehle vermutlich auch zu dem teil ueber den er flucht ;), ich weiss ehrlich nicht was man beim itanium ueber das von anderen cpus hinaus beachten muss.
-
hustbaer schrieb:
ja, ich meinte das "memory-ordering", oder wie auch immer man es nennen will. x86 ist diesbezüglich watscheneinfach.
vermutlich weil die meisten nichtmal mitbekommen wenn der compiler nen pipeflush auf x86 macht
aber dein poste am anfang schimpfte doch dass der itanium nicht ueberlebt weil die programmierer das threading darauf nicht hinbekommen. powerpc, sparc ueberleben doch auch, was macht es beim itanium schwerer?
-
DEvent schrieb:
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.
ach komm, es gibt fuer die allerwenigste software ein update wegen neuen cpu features, wieso schiebst du die schuld auf MS allein? schau dir mal den ganzen open source code an, du wirst in den allerwenigsten faellen irgendwo support fuer neue cpu features finden. das ist ein problem das ueberall vorhanden ist, nicht nur bei MS.
-
rapso schrieb:
hustbaer schrieb:
ja, ich meinte das "memory-ordering", oder wie auch immer man es nennen will. x86 ist diesbezüglich watscheneinfach.
vermutlich weil die meisten nichtmal mitbekommen wenn der compiler nen pipeflush auf x86 macht
was für ein "pipeflush" bei x86? der compiler muss da garnix machen, und er macht auch nix. store ist immer store_release, und load ist immer load_acquire.
aber dein poste am anfang schimpfte doch dass der itanium nicht ueberlebt weil die programmierer das threading darauf nicht hinbekommen. powerpc, sparc ueberleben doch auch
wo haben die überlebt?
was macht es beim itanium schwerer?
nicht schwerer als PPC/Alpha/MIPS. schwerer als x86!
