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

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

  • G

    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.

    0
  • R

    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?

    0
  • W

    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 😃

    0
  • Mod

    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).

    0
  • R

    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.

    0
  • R

    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 😉 )

    0

  • 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.

    0
  • ?

    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?

    0
  • D

    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.

    0
  • A

    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.

    0
  • R

    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 jahren 😕

    Das 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_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.

    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.

    0
  • R

    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?

    0
  • R

    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.

    0

  • 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!

    0
  • Mod

    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.

    0
  • ?

    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.pdf

    du 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.

    0

  • 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.

    0
  • G

    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.

    0
  • G

    Itanium ist kein VLIW.

    0
  • G

    Ok, genau genommen ist es EPIC. Läuft aber auf das gleiche hinaus.

    0
Anmelden zum Antworten