Barton im Zentrum der Spekulationen

Auf unserer Lieblings-Gerüchteküche <a href="" TARGET="b">The Inquirer</a> ist man gerade wieder dabei, die verwegensten Spekulationen um den <i>Thoroughbred</i>-Nachfolger <i>Barton</i> voranzutreiben.

Der verdutzte Leser erblickt dort, AMD werde den Core des <i>Barton</i> mit "Hammer optimisations" ausstatten und damit die Pro-Taktleistung (IPC) deutlich steigern können. Dies erkläre, so The Inquirer weiter, die angeblich dramatisch höheren Model-Ratings, die der <i>Barton</i> laut einem weiteren Gerücht bekommen soll (wir <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1025391801">berichteten</a>).

Hammer Optimierungen für den <i>Barton</i>? Klingt gut, denkt sich der AMD-Kunde. Allerdings schweigt sich The Inquirer aus, welche Art Optimierungen das sein sollen. Der <i>Barton</i> wird ja 512 KB L2-Cache bekommen. Dies ist seit langem bekannt und hat erst einmal nichts mit dem Hammer zu tun. Die weiteren Features, die der Hammer dem aktuellen K7-Core voraus hat, sind schnell aufgezählt:

<li><u>64-Bit Adress-Register:</u> ein K7-Core Rechner mit 64-Bit Extensions wird der <i>Barton</i> sicherlich nicht werden! Zum einen ist das nicht so einfach zu realisieren, wie mal eben ein paar KB mehr Cache in den Core zu hängen und zum zweiten sind die 64-Bit Register keine zusätzliche, separate Unit, wie etwa 3DNow! oder SSE. Der Core müßte dann den neuen Long-Mode beherrschen, um auch den Compatibility-Mode bereitzustellen und zwischen Long-Mode und Legacy-Mode unterscheiden können (siehe <a href="http://www.planet3dnow.de/artikel/diverses/64bitpreview/index.shtml">64-Bit CPUs für's Wohnzimmer : Innovation oder Marketinggeblubber?</A>).
Ergo => völlig abwegig</li>
<li><u>SSE2:</u></li> technisch am einfachsten realisieren ließe sich für AMD wohl die Implementierung von SSE2 in den <i>Barton</i>. Dem <i>Palomino</i> wurde gegenüber dem <i>Thunderbird</i> auch die SSE-Einheit spendiert, ohne daß dafür tiefgreifende Veränderungen notwendig gewesen wären. Allerdings bliebe zu bedenken, was SSE2 mit "Hammer Optimierungen" zu tun hat, schließlich ist SSE2 ein Intel Pentium 4 Feature.
Ergo => technisch machbar, aber unwahrscheinlich.
<li><u>On-Chip Memory-Controller:</u></li> Entgegen allen Markting-Beteuerungen, die wir nach dem Launch zu hören bekommen werden, wird der Hammer sein Plus an Leistung nicht aus den 64-Bit Adress-Registern holen, sondern aus seinem On-Chip Memory-Controller. Die Verlagerung des Memory-Controllers direkt auf die CPU verkürzt die Latenzzeiten beim Zugriff auf das RAM dramatisch. Allerdings ist ein Einbau dieser Einheit in den <i>Barton</i> vollkommen unmöglich, da der <i>Barton</i> ein Sockel A Prozessor sein wird und sämtliche Sockel A Mainboards den Memory-Controller in der Northbridge tragen.
Ergo => technisch unmöglich

Bleibt also nicht mehr viel übrig an "Hammer Optimierungen", die der Barton eventuell bekommen soll. Vielleicht die minimal verlängerte Pipeline (wir <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1025151815">berichteten</A>)? Oder eine andere Predictor-Unit? Der größere TLB vielleicht? Wie auch immer: wir halten diese Meldung von The Inquirer für eine Sommerloch Nachricht, lassen uns aber gerne eines besseren belehren...
THX @munich & mtb][sledgehammer für den Hinweis

guten morgen,

ist ein bisschen reisserisch, der artikel, ja....aber grad von dir haett ich fundiertere und vollstaendige antithesen erwartet!
so wird der hammer doch sowohl eine verbesserte sprungvorhersage besitzen, wie auch einen groesseren TLB.
nicht falsch verstehen: ich glaub definitiv auch nicht an das gebrabbel da von [µ], jedoch macht das spekulieren doch uns allen spass.
es darf nur nicht allzu sehr ausarten, sonst ist das enttaeuschte geschrei wieder gross, siehe thoroughbred.
der inquirer ist vor allem nett wegen der wechselnden mottos on top of the page:
"resistance is futile when electrons are excited"
herrlich...*ggg*

@x

Original geschrieben von /-\'I'/-\&gt;&lt;
guten morgen,

ist ein bisschen reisserisch, der artikel, ja....aber grad von dir haett ich fundiertere und vollstaendige antithesen erwartet!
so wird der hammer doch sowohl eine verbesserte sprungvorhersage besitzen, wie auch einen groesseren TLB.
nicht falsch verstehen: ich glaub definitiv auch nicht an das gebrabbel da von [µ], jedoch macht das spekulieren doch uns allen spass.
es darf nur nicht allzu sehr ausarten, sonst ist das enttaeuschte geschrei wieder gross, siehe thoroughbred.
der inquirer ist vor allem nett wegen der wechselnden mottos on top of the page:
"resistance is futile when electrons are excited"
herrlich...*ggg*

@x

Zum Vergrößern anklicken....

bist du wissenschaftler oder warum brauchst du "vollständige antithesen"
als ich diese meldung las dachte ich: "mein gott, für so ´n blödsinn soviel analyse". na, so verschieden sind die ansprüche.

Original geschrieben von /-\'I'/-\&gt;&lt;
guten morgen,

ist ein bisschen reisserisch, der artikel, ja....aber grad von dir haett ich fundiertere und vollstaendige antithesen erwartet!
so wird der hammer doch sowohl eine verbesserte sprungvorhersage besitzen, wie auch einen groesseren TLB.
nicht falsch verstehen: ich glaub definitiv auch nicht an das gebrabbel da von [µ], jedoch macht das spekulieren doch uns allen spass.
es darf nur nicht allzu sehr ausarten, sonst ist das enttaeuschte geschrei wieder gross, siehe thoroughbred.
der inquirer ist vor allem nett wegen der wechselnden mottos on top of the page:
"resistance is futile when electrons are excited"
herrlich...*ggg*
@x

Zum Vergrößern anklicken....

Find ich nicht wirklich reisserisch, eher "aufklärend".
Da im Moment irgendwie sehr viele PRO-AMD-Gerüchte kursieren nach dem 0.13-Flop, finde ich sehr gut, dass hier vehement dagegengesteuert wird
Sonst setzt sich so ein "Schwachsinn"(?) noch als Halbwahrheit durch...

P.S.: ich glaube nicht wirklich dass der Barton noch etwas neues bekommt, da sich AMD ja voll auf den Hammer konzentriert.
Wenn Nero hier anfängt, von einem größeren TLB zu labern, kommt keiner mehr mit...
Ich übrigens auch nicht

Original geschrieben von /-\'I'/-\&gt;&lt;
guten morgen,

ist ein bisschen reisserisch, der artikel, ja....aber grad von dir haett ich fundiertere und vollstaendige antithesen erwartet!
so wird der hammer doch sowohl eine verbesserte sprungvorhersage besitzen, wie auch einen groesseren TLB.
[...]

Zum Vergrößern anklicken....

Eben, der Hammer wird ja noch ettliche kleinere Verbesserungen seiner 32-Bit-Einheit erfahren, also allzu hoffnungslos muß man sich auch nicht anstellen

also gemeint war natuerlich der artikel aus mike magee schmiede!

und ich finde, wenn nero anfaengt, von tlb stc. zu "labern", dann hat das wenigstens hand und fuss und langweilt nicht und ist fuer jedermann(der sich aufnahmefaehig gibt und nicht "auf durchzug schaltet")aufschlussreich!

schliesslich fuehrte er mich zu p3dnow, als alten leser seiner eigenen hp...

@x

Ich fand die Meldung sehr interessant, vor allem würde sie die hohen Ratings des Barton (600 über TBred) erklären. Als ich gelesen habe, dass er "hammer optimizations" bekommen soll, dachte ich zuerst nur an SSE2 und besonders x86-64, um eine breitere 64 Bit "Plattform" bei den Kunden zu schaffen.
BlackBirds Gedanke, dass die komplette Hammer Pipe drin ist würde aber ehrlich gesagt auch meiner Meinung nach am meisten Sinn machen, da man dabei schon den Hammer antesten kann und außerdem wohl ziemlich einfache Designarbeit hat: man nehme den Hammer, mache alles ab der Crossbar weg und füge den alten EV6 Bus an.
An ähnliches habe ich auch beim guten alten Sockel 7 gehofft: K7 mit P5 Bus ohne internen L2 --> perfekte Aufrüster CPU. Vielleicht bereut AMD gerade, dass sie damals diesen Schritt nicht machten, und somit vollkommen auf die neue Infrastruktur angewiesen waren. Und jetzt geht man lieber auf Nr. sicher. Wäre der komplette K8 Kern im Barton enthalten, hätte das den Vorteil, dass AMD viel schneller x86-64 in die PC Welt bringt, da schon die komplette Infrastruktur (Mainboards, Lüfter, Chipsätze) vorhanden sind.

Eine Sache spricht für mich allerdings ein wenig gegen diese Theorie: warum wurde beim TBred der L2 an eine andere Stelle verlegt als beim Palomino? Wobei ich nicht glaube, dass dieser Schritt sehr aufwändig war, eher die nun fehlenden 300.000 Transis, die auch schon für ein aufwändigeres Redesign beim TBred sprechen.

Hallo "/-\'I'/-\><"

erst mal herzlich Willkommen auf Planet 3DNow!

Ich denke, die Antithesen sind ausführlich genug. Ein größerer Translation Lookaside Buffer ist ja keine Hammer Optimierung - und die Predictor Unit wurde genannt, obwohl das im Grunde auch keine Hammer Optimierung ist

Original geschrieben von /-\'I'/-\&gt;&lt;
also gemeint war natuerlich der artikel aus mike magee schmiede!

und ich finde, wenn nero anfaengt, von tlb stc. zu "labern", dann hat das wenigstens hand und fuss und langweilt nicht und ist fuer jedermann(der sich aufnahmefaehig gibt und nicht "auf durchzug schaltet")aufschlussreich!

schliesslich fuehrte er mich zu p3dnow, als alten leser seiner eigenen hp...

@x

Zum Vergrößern anklicken....

ah so
btw: das mit dem labern meinte ich nicht abwertend, war unglückliche Wortwahl meinerseits.

MfG

Eine kleine Berichtigung:

SSE basiert zu 90% auf 128 Bit-Registern und nicht auf den 64Bit-Registern der FPU wie bei 3DNow.

Die restlichen 10% basieren noch auf den FPU-Registern, deshalb werden einige
3DNow-Befehle auch von SSE unterstützt.

Der Athlon XP besitzt diese 128 Bit-Register (jeder Informatiker wird das bestätigen).


Es wäre also ein leichtes SSE2 in den Barton zu integrieren...

@jeansmixer:

vielleicht reden wir nur aneinander vorbei - aber 3DNow! nutzt nicht die Standard FPU-Register, sondern die acht MMX-Register MM0 bis MM7. Das kann ich mit Bestimmtheit sagen, da ich in der Vergangenheit 3DNow! selbst programmiert habe

In Sachen SSE hast Du Recht. Wie ich mich eben überzeugen konnte nutzt auch bereits SSE die 128-Bit breiten XMM-Register von SSE2 Mein Fehler Werde das gleich fixen...

Wenn Du jetzt noch etwas weiterliest, dann wirst du feststellen, das die MMX-Register auf die FPU-Register abgebildet werden...

Auf Deutsch: Es sind die selben!!! Nur das sie in einem anderem Modus betrieben werden.

Wenn man also nun MMX/3DNow-Befehle benutzt, sollte man in dieser Zeit nicht die FPU benutzen...

Die FPU besitzt einen Register-Stapel mit jeweils 80Bit-Registern.
MMX und 3DNow benutzen genau diese Register, da man dadurch das Betriebsystem nicht ändern muss.
(Im Falle eines Taskwechsels muessten alle neuen Register gesichert werden).

Das ist auch der Grund warum einem SSE auf Win95 oder WinNT 4.0 nicht viel bringt,
da Windows diese neuen Register nicht sichert.

@ sledgehammer

das wäre schon geil, ein hammer ohne speichercontroller der in mein sockel A mainboard passt, aber wirklich glauben will ich das nicht. obwohl ich zugeben muss dass sich das so unrealistisch gar nicht anhört.

ich zweifel jedoch daran aus folgendem grund: sse2 darf amd erst ab 2003 einsetzen also müsste sich der barton wie auch der hammer auf anfang 2003 verschieben. und der barton ist doch im gegensatz zum hammer noch für dieses jahr geplant.
außerdem hätte amd das in der roadmap irgendwie deutlich gemacht dass der barton hammerähnlich ist...

@jeansmixer:

Die Geschichte mit den Registern ist immer eine Frage, von welcher Ebene aus man die Sache betrachtet (wie so vieles bei einem superskalaren Prozessor )

Aus der Sicht eines 3DNow! oder MMX Programms (ich kann nur für 3DNow!/MMX sprechen, da ich SSE noch nicht programmiert habe - aber im Endeffekt ist es ja eh alles das selbe) gibt es keine FPU-Register, nur die logischen MM-Register.

Auf CISC-Level betrachtet dagegen hast Du natürlich Recht. Die MMX-Register werden auf die auf Floatpoint-Register abgebildet. Real existieren demnach gar keine MMX-Register, sie werden nur von der CPU emuliert. Anmerken sollte man jedoch, daß der Penalty beim Umschalten von MMX auf FPU Mode beim K6-2 oder beim Athlon bei weitem nicht mehr so lange dauert, wie beim Pentium MMX, auch ohne FEMMS, sodaß das alte Argument, die Verwendung von MMX-Registern würde das System eher verlangsamen, als beschleunigen, so nicht mehr ganz stimmt. Gut, wenn natürlich jemand umschaltet, um gerade mal eine SIMD-Operator auszuführen, dann vielleicht schon, aber dem Programmierer ist dann eh nicht mehr zu helfen

Aus der superskalaren, vom Programmierer nicht beeinflußbaren, RISC-Ebene heraus ergibt sich wieder eine ganz andere Sicht. Eine CPU wie der Athlon hat drei Fließkomma/MMX/3DNow! Units, eine für FSTORE, eine für FADD und eine für FMUL, sowie eine ganze Palette von Registern im Überfluß für das Register-Renaming. Im Gegensatz zum K6-2 etwa ist es dem Athlon nun weitestgehend egal, ob ein Task MMX-Register verwendet und ein anderer die FPU-Register, da er die Register eh so verwendet, wie er sie gerade benötigt.

Wie man sieht - wie was wo auf wem abgebildet wird, ist nur eine Frage des Blickwinkels

Original geschrieben von Nero24
@jeansmixer:


Wie man sieht - wie was wo auf wem abgebildet wird, ist nur eine Frage des Blickwinkels

Zum Vergrößern anklicken....

AAAAAAAAAAHHHHHHHHHHHH
brauche ein neues superskalares Konversationslexikon!

Aber exht nette tiefgründige Sache, macht (auch wenn ich kaum was verstehe) Spass da zuzuhören

@ ice-cool
AFAIK ist es nur ein Gerücht, dass AMD SSE2 ert ab 2003 nutzen darf. Da der Hammer aber offiziell auch schon für 2002 angekündigt ist, denke ich, dass es auch nicht mehr als ein Gerücht ist.

Zu den Registern: In der C't habe ich mal gelesen, dass SSE2 getrennt von x87 FPU/MMX/3Dnow! arbeitet: Ist es dann so, dass die XMM Register 100% getrennt von den FP Registern sind, während die alten MMX/3Dnow! (SSE ?) Register immer von den FPRs abhängig sind?

Natürlich ist das eine Frage des Blickwinkels, aber genau hier meine ich sollten wir es genau nehmen, da hier teilweise viel Mist geschrieben wird.

Ich wollte auch gar nicht darauf hinaus, das MMX/3DNow langsam wäre (in welcher Hinsicht auch immer), wollte nur erklären warum damals MMX u. 3DNow in den FPU-Registern gelandet sind und nicht gleich was neues bekommen haben.

Desweiteren kann ich nur empfehlen mit SSE zu arbeiten und 3DNow zu vernachlässigen, da es nicht nur mehr Möglichkeiten besitzt (mehr Operationen), größerer Verarbeitungsbreite bietet (4*float) und eben mittlerweile auf Intel und AMD-Systemen zum Standard gehört.


P.S.: Den Tasks war es schon immer egal ob nun mal mit FPU oder MMX-Registern gearbeitet wurde, da dieser Zustand der Register nicht vom Betriebssystem verwaltet werden muss.

(Jetzt glaube ich, das wir an uns vorbeireden).

Original geschrieben von jeansmixer
P.S.: Den Tasks war es schon immer egal ob nun mal mit FPU oder MMX-Registern gearbeitet wurde, da dieser Zustand der Register nicht vom Betriebssystem verwaltet werden muss.

Zum Vergrößern anklicken....

Den Tasks schon, logisch. Den Tasks ist es auch wurscht, ob eine CPU superskalar ist, den Tasks ist es auch egal, wie viele Pipelines eine CPU besitzt, welche Predictor-Features sie hat, wieviel Cache etc. All das geht den Tasks sonst wo vorbei. Aber von Tasks war auch keine Rede.

Der CPU ist es nicht egal! Ein Pentium MMX der 586er Generation etwa beherrscht noch kein Register Renaming. Laß dort mal ein MMX Programm und ein FPU Programm mit einem OS, das preemptives Multitasking beherrscht, parallel laufen und messe sie Operationen pro Zeit. Anschließend mach das gleiche auf einem 686er Prozessor wie dem Pentium II und Du wirst sehen, worauf ich hinaus will...

(Jetzt glaube ich, das wir an uns vorbeireden).

Zum Vergrößern anklicken....

Den Eindruck habe ich bereits von Anfang an Nix für ungut

Desweiteren kann ich nur empfehlen mit SSE zu arbeiten und 3DNow zu vernachlässigen, da es nicht nur mehr Möglichkeiten besitzt (mehr Operationen), größerer Verarbeitungsbreite bietet (4*float) und eben mittlerweile auf Intel und AMD-Systemen zum Standard gehört.

Zum Vergrößern anklicken....

Volle Zustimmung meinerseits. Mittlerweile wäre es ein Unding, noch 3DNow! zu programmieren. Allerdings komme ich ohnehin nicht mehr zum Programmieren und meine Brötchen muß ich damit auch nicht verdienen, also schwelge ich in der guten alten Zeit, wo man als einer der wenigen 3DNow! geübten Programmierer noch der Gott war und tue so, als gäbe es nichts neueres und besseres auf dieser Welt

Lassen wir die Tasks und deine Prozessoren ohne Register-Renaming raus, da ich darauf nicht hinaus wollte.
(Im Gesatz zum Ur-Pentium gab es das beim K6 schon -> war wohl der erste).


Du hast mal programmiert
Beruflich oder Freizeit (oder Student)

Ich verfolge die Themen hier von Anfang an, obwohl ich mich noch nie zu Wort gemeldet habe. Aber heute wollte ich das ändern (oh hilfe nein!!!)

Kann das hier mal einer übersetzen was hier geredet wird??

Original geschrieben von jeansmixer
(Im Gesatz zum Ur-Pentium gab es das beim K6 schon -> war wohl der erste).

Zum Vergrößern anklicken....

Mit Register Renaming war AMD relativ fix. Das beherrschte sogar der K5 schon während Intel erst mit dem Pentium Pro erwachsen wurde

Du hast mal programmiert
Beruflich oder Freizeit (oder Student)

Zum Vergrößern anklicken....

Sowohl, als auch. Im Studium habe ich nebenbei als Admin gearbeitet, wo es genügend zu programmieren gab. 3DNow! natürlich nur in der Freizeit, welche Firma programmiert schon 3DNow!

Ich verfolge die Themen hier von Anfang an, obwohl ich mich noch nie zu Wort gemeldet habe. Aber heute wollte ich das ändern (oh hilfe nein!!!)

Zum Vergrößern anklicken....

HIIIIIIIIIIIILFE

Ne Quatsch. Herzlich Willkommen auf Planet 3DNow! - und das gleich mit einem wortreichen Einstand

K5 -> Stimmt (mein Fehler)...

Wenn keiner mehr 3DNow nutzt, solltet ihr dann nicht die SSE/SSE2-Ecke einrichten

Den Namen Planet3DNow könnt ihr ja behalten.

Original geschrieben von jeansmixer
Wenn keiner mehr 3DNow nutzt, solltet ihr dann nicht die SSE/SSE2-Ecke einrichten

Zum Vergrößern anklicken....

Hehe, sowas in der Art haben wir schon hinter uns - pünktlich zum ersten April
http://www.planet3dnow.de/misc/1april02.htm

Mit dem Namen haben wir auch kein Problem - AMD nennt die SSE-Befehle ja 3DNow! Professional

Original geschrieben von [SKY]Dax
Kann das hier mal einer übersetzen was hier geredet wird??

Zum Vergrößern anklicken....

nö.
Aber als kleiner Trost: du bist nicht allein ! Ich kapier auch nix mehr

[Schnitzl]
Wovon wir hier reden:

Über Prozessoren!!! Genauer gesagt, habe ich erklärt, daß 3DNow-Register nicht gleich SSE-Register (wurde kommentarlos angenommen) sind.
Dann haben wir uns etwas verstrickt, in dem versucht wurde, daß jeder sein bestes zum internen Aufbau und zur Programmierung beibringt und sind schließlich beim Namen dieser Seite angekommen.


[Nero24]
Den 1.April habe ich nicht verpasst. Ich war sofort eurer Meinung, bis ich den Text gelesen hatte und gemerkt habe, daß hier jemand mächtig gegen die Prinzipien der Planet3DNow-Site verstoßen hatte...

3DNow-Professional:
Wenn man nun die Features unserer Prozessoren zusammenfast, dann
wird man gar nicht mehr fertig.

Man nehme einen meiner Athlon MPs:
MMX, 3DNow!, 3DNow Enhanced!, 3DNow Professional...
Quanti-Speed-Tech, SmartMP-Tech...
und man vergesse nicht: Designed for Windows 98/Me/...


Man sollte mal bei AMD nachfragen, welchen Namen 3DNow erhält, wenn SSE2 noch implementiert wird!

- 3DNow Ultra
- 3DNow Supra
- 3DNow Color
- 3DNow Flüssig =>ganz im Sinne der Tradition eines Waschmittelherstellers?