amd vs. intel



  • hardrocker schrieb:

    das sowas nicht von heute auf morgen geht ist wohl klar, aber langfristig ist itanium der weg, den intel gehen wird.

    Dumm nur, dass davon nichts zu sehen ist. Itanium konnte sich nicht mal gegen Netburst durchsetzen. Gegen was denn bitteschön dann?
    Langfristig wird Itanium von der Bildfläche verschwinden. Schau dir die Core Architektur an oder Atom, dann weisst du, welchen Weg Intel gehen wird. Selbst Larrabee soll auf x86 basieren. x86 mag als ISA nicht optimal sein, spielt letztendlich aber keine entscheidende Rolle. x86 Mikroarchitekturen sind hingegen so ziemlich das modernste, was du heutzutage für Desktop und Notebooks bekommen kannst. Selbst Server Bastionen wie HPC sind mehr als nur am Bröckeln.

    hardrocker schrieb:

    itanium ist ja auch richtig geil, wenn die compiler erstmal ihre neugewonnene power auszunutzen gelernt haben. 🕶

    Toll. Und wie lange soll das dauern? Bekommen Silizium Chips davon noch etwas mit? 🙄



  • groovemaster schrieb:

    x86 mag als ISA nicht optimal sein, spielt letztendlich aber keine entscheidende Rolle.

    LOL, was für ein Understatement. Ich möchte nicht wissen, wieviel chip real estate allein schon durch das komplexe dekodieren von dem alten x86 cisc schrott in mikrooperations benötigt wird. uns den rest deines statements habe ich nie bestritten!

    groovemaster schrieb:

    hardrocker schrieb:

    itanium ist ja auch richtig geil, wenn die compiler erstmal ihre neugewonnene power auszunutzen gelernt haben. 🕶

    Toll. Und wie lange soll das dauern? Bekommen Silizium Chips davon noch etwas mit? 🙄

    Das geht eben nicht von heute auf morgen, wie stellst du dir das vor? Aber es ist auf jeden Fall der richtige Weg, mehr Arbeit auf den Compiler abzuwälzen, der kann ja schließlich solange optimieren, wie er will. Das Potential von Itanium ist noch längst nicht ausgereizt! Wir werden ja sehen, wie die Zukunft in 10 Jahren aussieht!



  • groovemaster schrieb:

    rapso schrieb:

    was ich von dir halte ist irrelevant wenn ich nur deine aussage vor mir habe die falsch ist. sorry.

    Da ist nichts falsch, maximal nicht detailliert genug. Was kontextbezogen ja auch offtopic ist.

    ok, mul wird zum kontrollieren von cos/sin benutzt, verstehe, eine ungenaue definition.

    Nur als kleiner Tipp, wenn du in Zukunft etwas zu sagen hast, dann kann man das auch in der Form:

    Noch eine kleine Ergänzung meinerseits: ...

    also:

    ich glaube du verwechselst mul aund alu 😉

    machen, und nicht nach dem Motto

    Du hast doch ein Rad ab, das ist nicht bla, sondern blub.

    also nicht

    groovemaster schrieb:

    Erbsenzähler!

    verstehe.

    Übrigens, schön, du kennst Dieter Nuhr. Dann befolgst du seinen Ratschlag in Zukunft vielleicht mal. 😉

    tut mir leid, nur weil sein motto 'einmal ak immer ak' ist, muss ich nicht genau so bei manchen unsinnerzaehlern hier aufgeben 🙄



  • hardrocker schrieb:

    groovemaster schrieb:

    x86 mag als ISA nicht optimal sein, spielt letztendlich aber keine entscheidende Rolle.

    LOL, was für ein Understatement. Ich möchte nicht wissen, wieviel chip real estate allein schon durch das komplexe dekodieren von dem alten x86 cisc schrott in mikrooperations benötigt wird. uns den rest deines statements habe ich nie bestritten!

    was verwunderlich dabei ist, ist dass viele RISC architekturen anfangen Cisc-alike befehle zu implementieren und es als feature verkaufen. ARM als einer der fuehrenden low-voltage IP anbieter geht da sogar schon seit jahren hin, sogar der Gameboy hat schon den ARM und Thumb befehlssatz. frueher mag RISC ein vorteil gewesen sein, aber heute ist es nicht mehr so dramatisch mit dem dekodieren, oft eher ein vorteil.



  • rapso schrieb:

    ok, mul wird zum kontrollieren von cos/sin benutzt, verstehe, eine ungenaue definition.

    Wenn das deine Sichtweise ist, bitteschön. Etwas derartiges habe ich aber nie gesagt.
    Nochmal für dich ausführlich, ich habe gesagt, dass über die Recheneinheit, über die das zweite mul durchgeführt wird, stattdessen Sonderfunktionen wie sin oder cos durchgeführt werden. Du solltest schon das lesen, was dasteht. Und nicht irgendwas hineininterpretieren. Wenn du es nicht verstehst, kannst du auch gerne nochmal nachfragen, anstatt deine typisch kindische Besserwisserschiene zu fahren. Ist ja nicht das erste mal. 😉
    Zum Rest sag ich jetzt mal nichts, aus dem Kindergartenalter bin ich mittlerweile raus. EOD.

    hardrocker schrieb:

    LOL, was für ein Understatement. Ich möchte nicht wissen, wieviel chip real estate allein schon durch das komplexe dekodieren von dem alten x86 cisc schrott in mikrooperations benötigt wird.

    Die Logik ist teilweise recht komplex, das ist richtig. Gib dich aber keinen Illusionen hin, damit müssen auch andere CISC Architekturen leben. Intern sind x86 Mikroarchitekturen sowieso mehr RISC. Und mal abgesehen davon, Chip Logik wird durch ganz andere Sachen bestimmt und ist zudem nur ein Teil des Gesamtchips. Intels aktueller Penryn C2D besteht zB zur Hälfte aus Cache. Atom wiederum zeigt, dass auch sehr kleine und sparsame x86 Chips möglich sind. Wie ich schon sagte, dein "komplexes dekodieren von dem alten x86 cisc schrott" ist relevant für die Entwicklung, aber irrelevant für den Chip selbst. Da spielen nämlich ganz andere Faktoren eine weitaus bedeutendere Rolle, wie zB der Fertigungsprozess.

    hardrocker schrieb:

    Das geht eben nicht von heute auf morgen

    Itanium hatte aber mittlerweile genügend Zeit. Ergbenis? Nada. Und eine Besserung nicht in Sicht.

    hardrocker schrieb:

    Aber es ist auf jeden Fall der richtige Weg, mehr Arbeit auf den Compiler abzuwälzen, der kann ja schließlich solange optimieren, wie er will.

    Der richtige Weg ist, statische und dynamische Optimierungen gleichermaszen durchzuführen. Genau so wie das bei x86 gemacht wird. Bei Itanium werden praktisch nur statische Optimierungen durchgeführt. Da kann der Compiler optimieren, bis er schwarz wird. Laufzeitzustände wird er niemals kennen und dementsprechend ineffizient kann die Verarbeitung ausfallen.



  • little Star schrieb:

    SPARCle schrieb:

    Musst du ja nicht kaufen. Wenn man nicht grade dieses Windows einsetzen möchte, kann man ja auf SPARC64 VI wechseln. Das ist ein schöner Doppelkern-RISC-Prozessor, der mit bis zu 2.4 GHz auch alles andre als langsam ist.

    Hört sich gar nicht so schlecht an. Doch was kostet der? Sind die Boards kompatibel zu vorhandener PC Technologie (ATX, PCIe, DDR2, ..)? Und wo kann man CPU und Board kaufen?

    bump. würde ich auch gern' wissen.



  • groovemaster schrieb:

    rapso schrieb:

    ok, mul wird zum kontrollieren von cos/sin benutzt, verstehe, eine ungenaue definition.

    Wenn das deine Sichtweise ist, bitteschön. Etwas derartiges habe ich aber nie gesagt.

    groovemaster schrieb:

    Über das zweite MUL steuert nVidia zB Sonderfunktionen wie sin oder cos

    da du dich jetzt vernutlich weiter windest nur um fuer dich noch eine ausrede zu finden die deine eindeutige aussage umdefiniert, ist das offtopic fuer mich hier zuende.



  • Moin,

    Der Grund, warum AMD bei dem Ahtlon XP mit diesen Bezeichnungen anfing ist einfach:
    Ein Ahtlon 2,8 Ghz entspricht in etwa einem Ahtlon XP 2800+ mit 2,1Ghz (oder so).
    Der zweite Grund ist, das der Ahtlon XP damals je Mhz mehr Leistung hatte als
    ein Intel Prozessor (vergleichsweise). Da die meisten aber auf die Ghz achteten, war das ein logicher und kluger Schritt von AMD.

    So fing die Geschichte an...


Anmelden zum Antworten