Bulldozer rollt an....

[Dr@]

Jetzt bleibt nur noch die Frage zu erörtern, warum man dann vor Monaten seinen Kunden ein gutes Argument genommen hat, eine AM3-Plattform zu kaufen.

Ich bin bereits auf die Erklärung gespannt.

 

[Opteron]

Jetzt bleibt nur noch die Frage zu erörtern, warum man dann vor Monaten seinen Kunden ein gutes Argument genommen hat, eine AM3-Plattform zu kaufen.

Ich bin bereits auf die Erklärung gespannt.

Erst mal schauen, obs wirklich stimmt ^^
Aber falls ja - ja dann wirds lustig .. da müßte man AMD ja fast für den Darwin Award nominieren, so wie die ihr eigenes Geschäft gekillt haben

Tiefere Diskussionen dann hier, hab mal schnell ne Usernews getippselt.
http://www.planet3dnow.de/vbulletin/showthread.php?t=392236

Die Sache bei AsRock ist nämlich auch mysteriös .. wieso haben sie dort beim Namen das "Plus" wieder entfernt ... dabei hat das eindeutig nen AM3b Sockel ...

 

[Markus Everson]

.. da müßte man AMD ja fast für den Darwin Award nominieren, so wie die ihr eigenes Geschäft gekillt haben

Amen Bruder!

 

[Stryki]

Markus komm dieser Geniestreich des AMD-Marketings. Du hast es doch die ganze Zeit gewusst tief in deinem innersten. Wenn du glaubst es geht nicht mehr schlimmer AMD legt noch einen ordentlich Oben drauf.
Ich bin jedenfalls sollte das stimmen, mehr als nur tief beeindruckt(und vielleicht ganz froh letztes Jahr ein 870 Mobo gekauft zu haben aber ich bekomme bestimmt kein BIOS von Gigabunt).

 

[Duplex]

wenns stimmt kann ich mein Crosshair IV F. behalten, es hat sogar DDR3-2000 Support laut Asus
Die Features die ich dann nicht nutzen kann interessieren mich sowieso nicht, die CPU wird ja dadurch nicht langsamer, über den Referenztakt wird die CPU bis zum Anschlag übertaktet mein Thuban 1055T macht 300x14 @1.5v (50% mehr Takt)

 

[gruffi]

Nö, da kommen wir nicht weiter, die Wikis fußen auf wissenschaftlicher, anerkannter Basis. Unendlich viel besser als irgendwelchem Marketinggeschurbel. V.a. wenn die Argumentation wie bei den K10<>BD Pipelines nicht stringent ist, siehe unten.

Nö, mit Wikipedia kommen wir hier nicht weiter. Das ist zwar nett in einem allgemeinen Kontext. Wir reden aber ganz konkret von AMD und deren Architekturen. Also bleibe auch bitte bei der AMD Terminologie. Ansonsten blickt hier irgendwann gar keiner mehr durch.

Aktueller Stand ist jetzt "Pipe = Anbindung + X", bitte das "X" genauer spezifizieren.

Mache es doch nicht unnötig kompliziert. Alles was nach dem Scheduler kommt, bezeichnet AMD als Pipes. Das sind im Wesentlichen die "Leiterbahnen" zu den Ausführungseinheiten und die Ausführungseinheiten selbst. Wenn du noch mehr Details wissen willst, und was eventuell noch dazu gehört, dann solltest du am besten bei AMD nachfragen. Viel mehr geht aus den Docs, die ich kenne, nicht hervor.

Ok, wenn Du von der (einen)"Integer Execution Pipeline" redest, bist Du genau im Problemgebiet. Wieso solls da nur eine geben ?

Ach mann, lies dir doch bitte erstmal die AMD Docs dazu durch. Du scheinst die Terminologie überhaupt nicht zu kennen. Ich kann zB den Software Optimization Guide für 10h empfehlen. Ansonsten macht diese Diskussion überhaupt keinen Sinn, wenn du nicht mal die Begrifflichkeiten richtig zuordnen kannst. Vielleicht hilft dir für den Anfang ein kleiner Auszug:

The integer execution pipeline consists of three identical pipes (0, 1, and 2).

Mit Integer Execution Pipeline ist die gesamte Logik gemeint, also alle Pipes. Bitte setze den Begriff Pipe nicht mit Pipeline gleich. Den Fehler hast du ja nun schon mit den Ausführungseinheiten gemacht.

Ne die Pipes beinhalten keine Ausführungseinheiten

Doch.

Each integer pipe consists of an arithmetic-logic unit (ALU) and an address generation unit (AGU).

die Ausführungseinheiten sind durch Pipelines/Pipelining implementiert.

Nein. Ausführungseinheiten sind keine Pipeline(s) bzw durch diese implementiert. Begreife das doch endlich mal. Ausführungseinheiten sind Teil der Pipeline, nicht mehr und nicht weniger. Stell dir das wie ein Fliessband in der Industrie vor. Die Pipeline ist das Fliessband. Die Ausführungseinheiten sind nun eine oder mehrere Bearbeitungsstationen an bestimmten Positionen des Fliessbandes. Nur weil du ein Fliessband baust, hast du noch lange keine Bearbeitungsstationen. Die Bearbeitungsstationen müssen separat gebaut und angebunden werden.

 

[Konrad321]

Während der Cebit unterhielt sich PC Games Hardware auch mit dem Mainboard-Hersteller Asrock. Das eigenständige Tochterunternehmen von Asus dementierte die Lauffähigkeit von Bulldozer-CPUs auf dem Sockel AM3 (ohne Plus!).

Verlässliche Informationen mit gut informierten Quellen, zu denen wir Kontakt halten, sprechen derzeit davon, dass AMD an der AM3-Kompatibilität von Bulldozer arbeitet.

http://www.pcgameshardware.de/aid,8...mentiert-plus-Sockelvergleich/Mainboard/News/


Es bleibt verwirrend.

 

[Limit64]

Ganz simpel gedacht ist ja Programm Kontrollcode eher Integer lastig mit einigen FP oder SIMD Befehlen zur Berechung. Da könnte vom Gefühl her der AMD Ansatz ja durchaus funktionieren.

...Was aber z.B.: bei Software Renderern, Distributed Computing oder Matlab? Wenn die Performance eher von den erreichbaren FLOPs abhängt, könnte die gemeinsame FP Einheit schnell limitieren. Dann habe ich mit Zambezi keinen 8Core Prozessor, sondern doch wieder eher einen Quadcore mit einer relativ schnellen FP Unit.

Ich weiß nicht, ob das noch aktuell ist, aber uns wurde im Studium erzählt, dass die FPU von einem Thread selbst bei sehr FP-lastigen Programmen kaum mehr als zu ~60% ausgelastet wird. Das liegt wohl daran, dass man immer noch Kontrollfluss, Adressgenerierung usw. mit drin hat, was die Domäne der Int-Einheiten ist. Das da was dran ist, sieht man auch daran, dass MT bei FP-Code wirkungsvoller ist als bei Int-Code. Unter Berücksichtigung dieser Tatsache ist das MT nur für die FPU, wie es BD macht vielleicht gar keine so schlechte Idee. Außerdem hat man ja im Vergleich zum Vorgänger ja den gleichen max. Durchsatz (1x 128Bit / Kern). Auch Sandy Bridge bietet da nicht mehr. Nur, wenn man mit 256Bit Befehlen arbeitet, hat SB mehr theoretischen Durchsatz pro Kern, was aber wieder anders aussieht, wenn man FMA benutzt.

 

[mtb][sledgehammer]

Nein. Ausführungseinheiten sind keine Pipeline(s) bzw durch diese implementiert. Begreife das doch endlich mal. Ausführungseinheiten sind Teil der Pipeline, nicht mehr und nicht weniger. Stell dir das wie ein Fliessband in der Industrie vor. Die Pipeline ist das Fliessband. Die Ausführungseinheiten sind nun eine oder mehrere Bearbeitungsstationen an bestimmten Positionen des Fliessbandes. Nur weil du ein Fliessband baust, hast du noch lange keine Bearbeitungsstationen. Die Bearbeitungsstationen müssen separat gebaut und angebunden werden.

Habe das ein bischen mitverfolgt: Es geht doch darum, ob ein BD Kern am Ende mehr oder weniger ALUs hat als der Phenom?

Zum Phenom: Ich würde mich was AMDs vokabular angeht an dem orientieren, was man im
"Software Optimization Guide for AMD Family 10h and 12h Processors (40546 Rev. 3.13 February 2011)" steht:

Three-way integer execution; Three-way address generation

Und natürlich das Bild (siehe Anhang, Quelle AMD.com, "Software Optimization Guide for AMD Family 10h and 12h Processors (40546 Rev. 3.13 February 2011)") Demnach ist Phenom laut AMD's aktuellem Sprachgebrauch ein 3 ALU Design.

Zum Bulldozer gibts sowiet ich das verfolgt habe nur die Marketingslides? Oder noch mehr? Ich glaube Dresdenboy's Artikel enthält keine verlässlichen Aussagen dazu?

 

[Dresdenboy]

Zum Bulldozer gibts sowiet ich das verfolgt habe nur die Marketingslides? Oder noch mehr? Ich glaube Dresdenboy's Artikel enthält keine verlässlichen Aussagen dazu?

Stimmt, verlässlich war da noch nicht möglich. Wird wohl Zeit für ein Update
Jetzt steht im Manual übrigens two-way integer execution, two-way address generation.
.
EDIT :
.
Hiroshige Goto hat seinen ISSCC Bulldozer-Artikel online: http://pc.watch.impress.co.jp/docs/column/kaigai/20110301_430044.html

 

[gruffi]

Habe das ein bischen mitverfolgt: Es geht doch darum, ob ein BD Kern am Ende mehr oder weniger ALUs hat als der Phenom?

Nein, es ging eigentlich um die Begrifflichkeiten. Die Anzahl der Ausführungseinheiten dürfte ja mittlerweile bekannt sein. Bisher waren es ALU/AGU Pärchen, jeweils eines an insgesamt 3 Pipes. Bei Bulldozer sind es 2 ALUs und 2 AGUs, jeweils eine Einheit an insgesamt 4 Pipes.

 

[Ge0rgy]

Anders ausgedrückt, die Gesamt-Anzahl mag weniger werden, dafür sind sie flexibler verwendbar.
Wenn mir jetzt aber hier noch einer mit dem bereits bis zum erbrechen durchgekauten Argument kommt BD müsse bei INT-Code langsamer sein als K10 (taktbereinigt) nur weil er 1/3 weniger ALUs hat, der soll sich bitte als Schreiberling bei der Computer-Bild bewerben. Die brauchen solche Leute um ihr "Niveau" zu halten...

 

[Opteron]

Nö, mit Wikipedia kommen wir hier nicht weiter. Das ist zwar nett in einem allgemeinen Kontext. Wir reden aber ganz konkret von AMD und deren Architekturen. Also bleibe auch bitte bei der AMD Terminologie. Ansonsten blickt hier irgendwann gar keiner mehr durch.

Wie besagt, der Wiki Artikel ist 100% i.O. selbiges kann man vom Marketingschmierereien ganz sicher nicht behaupten.

Mache es doch nicht unnötig kompliziert. Alles was nach dem Scheduler kommt, bezeichnet AMD als Pipes. Das sind im Wesentlichen die "Leiterbahnen" zu den Ausführungseinheiten und die Ausführungseinheiten selbst. Wenn du noch mehr Details wissen willst, und was eventuell noch dazu gehört, dann solltest du am besten bei AMD nachfragen.

AMD ist mir egal, ich rede mit Dir, und ich will wissen, was Du darunter verstehst. Du wirst ja wohl wissen, worüber Du redest, oder nicht ?

Ach mann, lies dir doch bitte erstmal die AMD Docs dazu durch. Du scheinst die Terminologie überhaupt nicht zu kennen. Ich kann zB den Software Optimization Guide für 10h empfehlen. Ansonsten macht diese Diskussion überhaupt keinen Sinn, wenn du nicht mal die Begrifflichkeiten richtig zuordnen kannst. Vielleicht hilft dir für den Anfang ein kleiner Auszug:

Ok, AMD DOCs, sind etwas besser als Marketing, würde ich unter Umständen auch akzeptieren, wenn alles eindeutig und genau definiert ist.

Nein. Ausführungseinheiten sind keine Pipeline(s) bzw durch diese implementiert. Begreife das doch endlich mal. Ausführungseinheiten sind Teil der Pipeline, nicht mehr und nicht weniger. Stell dir das wie ein Fliessband in der Industrie vor. Die Pipeline ist das Fliessband. Die Ausführungseinheiten sind nun eine oder mehrere Bearbeitungsstationen an bestimmten Positionen des Fliessbandes. Nur weil du ein Fliessband baust, hast du noch lange keine Bearbeitungsstationen. Die Bearbeitungsstationen müssen separat gebaut und angebunden werden.

Jo, aber wer sagt denn, dass die Bearbeitungsstation eine Pipe sein muss ? Bzw. wieso überhaupt ein Fließband bauen ?
Die Sichtweise ist sehr eingeschränkt. Wenn Du eine CPU mittels Pipelining implementierst, dann ist sind die FU=Ausführungseinheiten ganz selbstverständlich Teil der Pipeline, das ist ne Binsenweißheit. Wenn Du oben genannte Licht& Wärmequelle mittels Kernfusion implementierst, dann fusioniert da natürlich Wasserstoff, was denn auch sonst ?

Aber Functional Units gibts schon viel länger als es Pipelining oder Pipeline gibt. Grab mal ein paar Schaltpläne aus den 70/80ern heraus, da findest Du massenhaft Functional Units, ALUs, FPUs, ICUs, etc. pp. aber kein Wort von Pipe oder Pipeline.
Selbst der K10 ist nicht fully pipelined:

For AMD Family 12h it is recommended to use the division instructions DIV or IDIV (refer to Appendix C to review the latency of DIV/ IDIV instructions). DIV and IDIV instructions are now fastpath instructions. The divider is not pipelined and can only execute one div instruction at any given point of time. The latency of unit to produce the quotient is 8+ ceil(num quotient bits/2). The remainder is available 2 cycles later.

Wie willst Du nun die Div Einheit benennen ? Ist das noch ne "Div-pipe" ? Falls ja wieso ? Was macht eine Pipe aus ? Muss sie nun pipelined sein, oder nicht ? Reichts es, wenn das Fließbandkonzept außenherum benützt wird ?

The integer execution pipeline consists of three identical pipes (0, 1, and 2).

Mit Integer Execution Pipeline ist die gesamte Logik gemeint, also alle Pipes. Bitte setze den Begriff Pipe nicht mit Pipeline gleich.

Achso ? Aber welche Pipes denn nun ? Was sind alle ? Jetzt mit oder ohne AGUs ?

Das ist jetzt die Frage ... schauen wir mal, was das AMD PDF dazu sagt und komplettieren wir mal Deine Definition um den nachfolgenden Satz:

The integer execution pipeline consists of three identical pipes (0, 1, and 2). Each integer pipe consists of an arithmetic-logic unit (ALU) and an address generation unit (AGU).

Ok, also jede Pipe besteht aus ner ALU und ner AGU. Soweit so gut. Unterstreicht Deinen Punkt, dass die Darstellung der MC FUs richtig wäre.

Aber wenn man etwas weiter herumblättern dann kommt man auch auf diese Textstelle:

The processors move integer instructions through the integer execution pipeline, which consists of the integer scheduler and the ALUs, as shown in Figure 8.

Toll .. also diesmal ohne AGUs ? Einmal eine Textstelle mit einmal ohne AGU Pipe ? Prima Definition, und auf sowas auf dieser tollen "AMD Terminologie" willst Du Deine Argumentation aufbauen ? Ja, wenn wir die benützen blickt wirklich keiner mehr durch.

Kein Wunder, dass dann die Argumentatino so gut klappt, die erste Textstelle paßt zum K10, die zweite zum BD. Da die AGUs in der 2. Def. nicht unter INT Pipeline zusammengefaßt werden, "darf" mans in dem Fall anscheinend extra zählen.

Deine Argumentation ist im Moment somit Folgende:
AMD definiert Pipes einmal so und einmal so, aber das macht ja nichts, denn in beiden Fällen sind es "Pipes".

Selbstreden ein irrer Standpunkt
Da bin dann selbst ich mit meiner Geduld am Ende.

Auf die ganze Pipeline und Pipe Definition kann man mMn pfeiffen. Wichtig ist zu wissen, ob ein Prozessor nun die Fließbandtechnik / Pipelining anwendet, oder nicht, dann die Anzahl/Typ der FUs und zum Schluß deren Superskalarität.

Alles andere ist dann doch nur wieder Wortklauberei und Marketinggedöns, selbst im Optimization Handbuch mit der "AMD Terminologie".

mtb][sledgehammers Beitrag bringt das ganze dann auch auf dem Punkt, dort wird die Superskalarität mittels der "x-way" Bezeichnung benannt, einmal 3way einmal 2way. Mehr muss man nicht wissen.

Wenn Du Dir jetzt von AMD ein X für ein U vormachen lassen willst, da sie mal schnell die "Pipe" Definition auswechseln, dann bitteschön. Das wäre dann der Diskussionsendpunkt.

Ich verlass mich lieber auf technischen Details und felsenfeste, anerkannte Definitionen.

 

[gruffi]

Anders ausgedrückt, die Gesamt-Anzahl mag weniger werden, dafür sind sie flexibler verwendbar.

Ja, kann man so sagen.

Wenn mir jetzt aber hier noch einer mit dem bereits bis zum erbrechen durchgekauten Argument kommt BD müsse bei INT-Code langsamer sein als K10 (taktbereinigt) nur weil er 1/3 weniger ALUs hat, der soll sich bitte als Schreiberling bei der Computer-Bild bewerben. Die brauchen solche Leute um ihr "Niveau" zu halten...

Um das mal noch etwas genauer zu erläutern, eine amerikanische Universität hatte vor einiger Zeit eine Analyse der IPC eines Core 2 Duo Prozessors anhand von SPEC CPU2006 gemacht (PERFORMANCE ANALYSIS OF INTEL CORE 2 DUO PROCESSOR). Die Core Architektur liegt ja, was IPC betrifft, nicht so weit entfernt vom K10. Dabei herausgekommen ist, dass die durchschnittliche IPC irgendwo bei 1 liegt.





Der verwendete Microsoft C/C++ Compiler ist sicherlich nicht für besonders gute Optimierung bekannt. Dennoch, selbst mit 2 ALUs und 2 AGUs hat man noch ausreichend Spielraum für Verbesserung der IPC. Die Frage wird einfach sein, wie effizient arbeitet die Bulldozer Pipeline bis dahin und um wie viel besser kann sie die Ausführungseinheiten auslasten.

 

[Dresdenboy]

Hiroshige Goto hat noch einen Artikel veröffentlicht:
http://pc.watch.impress.co.jp/docs/column/kaigai/20110302_430341.html
bzw.
http://translate.google.com/transla...co.jp/docs/column/kaigai/20110302_430341.html

 

[gruffi]

Wie besagt, der Wiki Artikel ist 100% i.O. selbiges kann man vom Marketingschmierereien ganz sicher nicht behaupten.

Es geht nicht darum, ob der Wikipedia Artikel iO ist oder nicht. Er ist schlichtweg nicht von Belang bei der Diskussion.

AMD ist mir egal

Dein Problem. Ich spreche von dem, was AMD an technischer Dokumentation rausgibt. Wenn dich das nicht interessiert, sprichst du auch nicht mit mir. Der Rest deines Beitrages ist damit obsolet. Offenbar hast du bisher noch nicht wirklich viel mit technischen Dokumentationen zu tun gehabt. Du steigerst dich wieder mal in etwas hinein, was völlig nebensächlich ist. Fakt ist, eine Pipe ist kein Synonym für eine Ausführungseinheit, wie von dir behauptet. Darum ging es doch. EOD.

 

[Markus Everson]

"Bulldozer Orochi-basierte 300 mm ² Die-Größe geschätzt geschnitten werden. AMD Istanbul(Thuban) 45nm 346mm AMDs aktuelle Six-Core "Istanbul (Istanbul) / Thuban (Tuban)" ist ein 45-nm-Die-Größe von 346 mm ² in den Prozess, so dass die Produktionskosten niedriger ist als die 6-Kern-Prinzip."

-> 8core Bulldozer 10% weniger Fläche als Thuban, vermutlich etwas geringere Herstellungskosten (höhere Kosten pro Wafer-Rohling, Yieldrate)

Nix aufregendes, aber für mich ein Indiz das AMD die Preise nicht zu hoch treiben muß um finanziell wieder etwas Luft zu bekommen

 

[denjo]

wie gross wäre Thuban in 32 nm ?!

 

[Onkel_Dithmeyer]

wie gross wäre Thuban in 32 nm ?!

Wenn mein Dreisatz stimmt:
346*32/45=246mm²

 

[denjo]

Wenn mein Dreisatz stimmt:
346*32/45=246mm²

Ja so hätte ich auch gerechnet aber irgendwie denke ich das es noch faktoren gibt die eine eins zu eins umrechnung nicht so ohne weiteres ermöglichen.

 

[gruffi]

Da Flächen immer noch zweidimensional sind, müsste es schon 346*32²/45² heissen. Da die Verkleinerung aber sowieso nicht linear ist, ist das recht theoretisch. Ausgehend von Shanghai und Llano Kern käme man auf folgendes:

346 / 15,3 * 9,7 = ~220 mm²

 

[Onkel_Dithmeyer]

Ja so hätte ich auch gerechnet. Allerdings bezweifel ich irgendwie das sich das einfach 1 zu 1 umrechnen lässt

War auch nicht gaaaanz ernst gemein

Da Flächen immer noch zweidimensional sind, müsste es schon 346*32²/45² heissen. Da die Verkleinerung aber sowieso nicht linear ist, ist das recht theoretisch. Ausgehend von Shanghai und Llano Kern käme man auf folgendes:

346 / 15,3 * 9,7 = ~220 mm²

Klingt logischer, aber ich hab mir mal andere Shrinkgrößen angeguckt, die Wahrheit dürfte irgendwo zwischen unseren Ergebnissen liegen ^^

 

[nazgul99]

Flächen rechnet man exponetiell fester Exponent, also quadratisch:
346mm² * 32² 45² = 174mm²,

Ein Full-Node ist immer 1/Wurzel-2 der alten Strukturgröße, in der Fläche macht das (theoretisch) genau 1/2 [ 1 / (Wurzel-2)² ].

Das wäre (obiges Beispiel knapp über) die Hälfte. Besonders wegen der Bump-Areas, die von der Bump-Technik abhängen und nur bei Verbesserungen in dem Bereich schrumpfen, ist dort schonmal deutlich weniger zu erwarten, die Transistoren schrumpfen aber ebenfalls erfahrungsgemäß nicht 1:2 zum Prozess. Ich werf mal nen Pfeil und der landet bei 200mm²

 

[Onkel_Dithmeyer]

Stimmt, das sind ja mm² -.-
Manchmal wunder ich mich, wie ich durch meinen Physik-LK gekommen bin

 

[denjo]

Stimmt, das sind ja mm² -.-
Manchmal wunder ich mich, wie ich durch meinen Physik-LK gekommen bin

Ich erinnere mich da böse an plagiierte Formeln auf der Rückseite eines Taschenrechners

Dann wäre BD ca. 1/3 größer als ein thuban@32nm.