Itanium vs. AMD64: Sollten wir uns eigentlich ägern, dass es nicht Itanium geworden ist?
-
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!
-
hustbaer schrieb:
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?
SPARC ist tot, aber Power lebt im Supercomputersegment.
-
hustbaer schrieb:
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.
in verbindung mit SSE sind einige memory operationen weak. der compiler baut deswegen manchmal ein store-load ein was unnoetig aussieht.
auch schreiben an verschiedene addressen muss nicht in-order sein, du hast eine garantie nur beim schreiben auf die selbe addresse.
gibt einiges im netz dazu, z.b. http://www.nwcpp.org/Downloads/2008/Memory_Fences.pdfdu siehst, x86 programmer glauben sie haben die probleme von itanium usw. nicht, aber die meisten wissen nichtmal welche probleme sie haben koennen. meiner meinung ist das weit aus schlimmer. und bei den 64bit versionen gibt es nochmals anderes verhalten als beim x86 und was schlimmer ist, X64 und I64 unterscheiden sich wohl auch.
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?
jup, beim powerPC bin ich mir sicher.
was macht es beim itanium schwerer?
nicht schwerer als PPC/Alpha/MIPS. schwerer als x86!
ich denke, am ende nutzt jeder vernuenftige programmierer die bibliotheken der plattform die saubere implementierungen fuer diese problemfelder haben. alles andere kann selbst beim x86 zu bugs fuehren. deswegen teile ich da nicht deine meinung.
-
auch schreiben an verschiedene addressen muss nicht in-order sein, du hast eine garantie nur beim schreiben auf die selbe addresse.
also dass man es mit x86 schaffen könnte, dass zwei stores auf unterschiedliche adressen für einen anderen core/andere CPU in der verkehrten reihenfolge sichtbar werden, wäre mir neu.
ich weiss dass es in frühen "core" (ohne 2) modellen mal einen oder mehrere bugs diesbezüglich gab, aber bugs sind eben bugs - muss ich als programmierer nicht wirklich rücksicht drauf nehmen.was SSE/MMX etc. angeht: ja, da hast du recht.
ich denke, am ende nutzt jeder vernuenftige programmierer die bibliotheken der plattform die saubere implementierungen fuer diese problemfelder haben. alles andere kann selbst beim x86 zu bugs fuehren. deswegen teile ich da nicht deine meinung.
es gibt aber so wenig vernünftige programmierer.
vor allen ist multithreading leider so ein thema, wo jeder glaubt er versteht wie es geht, obwohl er in wirklichkeit keine ahnung hat.
und klar kann man mit x86 auch mist bauen. aber dass bestimmte fehler in der praxis auftreten, ist bei x86 einfach um grössenordnungen weniger wahrscheinlich, als bei anderen CPU architekturen.gäbe es eine CPU architektur, die so brutal reordert und cachet und was nicht noch, dass es fast sofort knallt, wenn man eine barrier vergessen hat, dann wäre ich vermutlich ihr grösster fan. bloss selbst bei PPC/Alpha/... knallt es so selten, dass diese architekturen auch nicht zum "besser programmieren lernen durch CPU die fehler schneller aufdeckt" taugen.
und wo ich gerade wieder dran denke: wäre cool, wenn es einen emulator gäbe, der genau das macht: also absichtlich so stark reordert/cachet/..., dass es sehr schnell kracht bei inkorrekten multi-threading anwendungen. DAS wäre wirklich praktisch.
-
Grambol schrieb:
Wäre Itanium eigentlich besser gewesen, wenn man die Kompatibilität außer acht lässt?
Nein! Itanium ist VLIW, basiert also hauptsächlich auf ILP. Wir sind aber mittlerweile am Ende dieser Ära, weil dort keine grundlegenden Verbesserungen mehr möglich sind. Die Zukunft ist TLP und GPGPU. Google mal nach so Sachen wie AMD Fusion oder Intel Tera Scale. Was x86 etwas am Bein hängt, ist die schier unendliche Geschichte an Legacy Kompatibilität. Dazu gab es erst einen schönen Artikel von Agner Fog. Auch wenn der dafür notwendige Transistoraufwand heutzutage eher vernachlässigbar ist. Der Intel Atom hat ja gezeigt, dass Chips mit gerade mal 2-3 Watt und weniger auf relativ kleiner Fläche möglich sind. Zwar noch keine Konkurrenz für ARM, aber wer weiss, was da in Zukunft noch kommt. In die gleiche Richtung wird ja auch der AMD Bobcat gehen.
So seltsam das klingt, aber CPUs, wie wir sie heute kennen, werden in Zukunft nur als eine Art Host dienen. Die eigentliche Performance wird dann über spezielle Einheiten generiert, wie eben GPUs. AMD zB nennt ein solches Gebilde aus CPU und GPU APU (Accelerated Processing Unit). Die Unterschiede, über die wir bei x86 und IA64 reden, werden irrelevant. Und darüber zu philosophieren ist eh sinnfrei, die 32-bit Kompatibilität bei x86 überwiegt einfach alles.
Einige denken zudem, wenn man Optimierungen vollkommen dem Compiler überlässt, wie bei Itanium, entfällt dieser Schritt dann im Prozessor und ist damit effizienter. Aber auch das stimmt nicht so ohne weiteres. Es gibt eine ganze Reihe von Optimierungen, die wird ein Compiler einfach niemals so effizient durchführen können wie der Prozessor selbst.
Itanium war von Beginn an eine Totgeburt und wurde mittlerweile von der effizienten Implementierung von x86 Mikroarchitekturen völlig überholt. Die schnellsten Supercomputer der Welt basieren seit geraumer Zeit, vor allem dank AMD und deren effizienten Direct Connect Architecture, auf x86 Technologie. Und das nicht grundlos. Niemand muss Itanium hinterherweinen. Würde man heute eine ISA und eine dazugehörige Mikroarchitektur von Grund auf neu entwickeln, nach aktuellen Maszstäben und zukünftigen Schwerpunkten, würde diese ziemlich sicher sowieso anders ausschauen.
-
Itanium ist kein VLIW.
-
Ok, genau genommen ist es EPIC. Läuft aber auf das gleiche hinaus.
-
http://www.heise.de/ct/artikel/Prozessorgefluester-982836.html schrieb:
Der CoreMark ist vom Embedded Benchmark Consortium (EEMBC) genau für solche kleinen Gerätchen konzipiert. Nichtsdestotrotz haben Spaßvögel ihn mal auf den Itanium Montecito (1,6 GHz) losgelassen. Mit einem Wert von 3690 konnte dieser den iPad A4 (2162) gerade so in Schranken halten, einem Atom N270 (4058) musste er sich aber geschlagen geben. Zum Vergleich: der Xeon-Quad-Core X5450 steht mit 45 665 in der CoreMark-Liste
fand ich zu interesant um es nicht zu posten
