Spekulationsthread: Was kommt 2011+

Ge0rgy schrieb:

Was mit übrigens noch bei Bobcat auffällt ist die vollständige Virtualisierungsunterstützung...
inkl. Nested Pages usw.
Die Frage ist warum? - Virtualisierung wird doch gemeinhin als Spielerei für Server betrachtet, nichts was der Endkunde bräuchte... allerhöchstens noch die Besitzer einer Win7 Professional zur Beschleunigung der XP-VM.
Höchst interessant dass man sich den Overhead trotzdem auflädt, grade bei einer "stromspar-CPU"....

Zum Vergrößern anklicken....

--> Embedded Markt!

gruffi schrieb:

Ich habe schon damals versucht, sachlich zu diskutieren. Offenbar war Opteron nicht dazu bereit, weil er sich von niemandem etwas sagen lässt, selbst wenn es diese besser wissen. Das Resultat sehen wir jetzt, meine Bedenken waren berechtigt. Oder siehst du eine Folie, die von 4 ALUs und 3 AGUs spricht?

Zum Vergrößern anklicken....

Nein und deshalb mein Vorschlag, herauszufinden, was es damit auf sich hat. Schließlich ist der Bezug zu Bulldozer immer noch gegeben. Ansonsten hat es auch mir zu einem "likely" gereicht. 100% ist nur, was in offiziellen Materialien erscheint. Alles andere an Spekulation ist eher Reverse Engineering und mit weniger Sicherheit behaftet. Das gilt genauso für Ausschlüsse.

gruffi schrieb:

Ich habe schon damals versucht, sachlich zu diskutieren. Offenbar war Opteron nicht dazu bereit, weil er sich von niemandem etwas sagen lässt, selbst wenn es diese besser wissen.

Zum Vergrößern anklicken....

Lol, soll ich Dir jetzt zugestehen, dass Du ein Besserwisser bist ? Mach ich gerne
Nochmal, wir hatten das letztens doch schon ausdiskutiert, Du meinstest der gute David Coakley spielt nur rum bzw. der Code wird noch nicht mal genutzt, ich sagte, dass das das einen tieferen Sinn haben müßte und die neue Architektur ganz sicher Bulldozer sein müßte und da sicher noch ein Codeupdate kommt. Was solls den auch sonst sein, Bobcat ?

Das Resultat sehen wir jetzt, meine Bedenken waren berechtigt. Oder siehst du eine Folie, die von 4 ALUs und 3 AGUs spricht?

Zum Vergrößern anklicken....

Ich sags Dir gerne nochmal, wie damals schon, der Kollege hat das immer noch nicht fertig codiert ... vielleicht gibts ja doch nen Sinn ...
Eine Möglichkeit hab ich bereits oben gennant (Wegen des 4way front-ends könnte es sinnvoll sein, dem Compiler auf 4 ALUs optimieren zu lassen, Dresdeboys accelerate Mode geister auch noch herum, wer weiss was das nun wieder bedeutet) .. darauf könntest Du jetzt gerne eingehen und mitdiskutieren .. aber nein, stattdessen spielst DU lieber beleidigte Leberwurst und wärmst alte Kamellen aufgewärmt. Super Stil und Diskussion.

Edit:
Dresdenboy hats kürzer formuliert


Alex

Ich hab da ne Frage.

Laut Grafiken hat der Bobcat einen Dual-x86-Decoder. Also, müsste doch 1-Way sein.
Wie kann man sich das besser vorstellen. Ist das sowas wie ein doppel-Decoder (= Doppelt durch Takt?) sein, wie wir ihn letztens besprochen haben
Na ja, vielleicht hat Bulldozer ja auch solche Dual-x86-Decoder

aylano schrieb:

Ich hab da ne Frage.

Laut Grafiken hat der Bobcat einen Dual-x86-Decoder. Also, müsste doch 1-Way sein.
Wie kann man sich das besser vorstellen. Ist das sowas wie ein doppel-Decoder (= Doppelt durch Takt?) sein, wie wir ihn letztens besprochen haben
Na ja, vielleicht hat Bulldozer ja auch solche Dual-x86-Decoder

Zum Vergrößern anklicken....

Hmm .. wie kommst Du von dual auf 1way ?

Dual = 2 ->2way Dazu noch der Complex Decoder. Aber die beiden Decoder Arten arbeiten nur abwechselnd. Der max Durchsatz ist also in jedem Fall auf 2 begrenzt..

Das ist ein ähnliches Front-End wie beim K8/K10, nur 1 Fastpath Decoder weniger. Deswegen auch 2way statt 3way.

Bulldozer hat da definitiv ein total anderes Front-End.

vielleicht heißt dual auch einfach nur "2-fach" im Sinne von, kann 2 befehle zugleich dekodieren, passend zu den 2 zu befütternden ALUs.
Ob das durch "breite" realisiert wird oder durch doppelte Taktung ist unterm Strich egal.
Es soll wohl nichts anderes ausdrücken als dass Bobcat 2-fach superskalar arbeitet....

@Dr wofür braucht man im embedded Markt x86-virtualisierung? VMware für die SetTop-Box?

Edit:
Opteron war schneller

Ge0rgy schrieb:

Was mit übrigens noch bei Bobcat auffällt ist die vollständige Virtualisierungsunterstützung...
inkl. Nested Pages usw.
Die Frage ist warum? - Virtualisierung wird doch gemeinhin als Spielerei für Server betrachtet, nichts was der Endkunde bräuchte... allerhöchstens noch die Besitzer einer Win7 Professional zur Beschleunigung der XP-VM.
Höchst interessant dass man sich den Overhead trotzdem auflädt, grade bei einer "stromspar-CPU"....

Zum Vergrößern anklicken....

In den letzten Monaten werden doch verstärkt Server-Rechner (z.B. für Clouds) basierend auf kleinen CPUs (Atom oder ARM) rausgebracht oder laut angedacht. Angeblich bringt es Effizienzvorteile. Somit wäre der Bobcat auch dafür gut gerüstet.

Wäre ne Idee, AFAIK hat AMD das aber dementiert, also dass das vorgesehen sei, mit Hinweis auf die hohe Energieeffizienz Bulldozers....
Grade deswegen verwundert mich das ja so.
Versteh mich nicht falsch, ich begrüße das! - Meine Yonah-Zwillinge im Thinkpad können vanderpool, allerdigns erst seit einem Bios-Update. Anfangs ging das nicht, und obwohl sie nur 1,6Ghz haben ist das sehr praktisch mittels KVM oder Virtualbox mal eben ein Gastsystem für testzwecke etc abzufeuern.
Sogesehen begrüße ich den Schritt durchaus... evtl. wird mein x60s dann irgendwann mal durch ein Ontario-Basiertes ersetzt...
Aber ich bezweifle irgendwie dass derartige Freaks die sogar in einem 12-Zöller noch virtuelle Maschinen laufen lassen, wirklich in AMDs Blickfeld bei der Konzeptionierung Bobcats lagen...
Ich meine, ist zwar komisch, aber nimmt man gerne mit...
Vielleicht ein Hinweis auf zukünftige Betriebssysteme die VM-Technik wesentlich ausgiebiger für Sandboxing usw. nutzen?

Ge0rgy: ich nehme an, du meinst BC, nicht BD?

Ich möchte auch auf keinem Rechner mehr auf Virtualisierung verzichten, in meinem Firmenrechner mit Core2 hab ich bei Dell (760DT, die verbauen darin in preiswerter Version einen E7400 ohne VT) die Variante ohne VT bestellt und bereue es längst. Hab seit einiger Zeit eine Win7 (Hostsystem Ubuntu) im Fenster laufen, ist dank fehlendem VT in VirtualBox nur im 32-Bit-Modus lauffähig und manchmal sowas von grottig lahm, dass ich nur staunen kann. Oder reichen die 1,5GB für den Gast nicht? Nur Win7, Outlook, Messenger und hin und wieder eine Office-App.

Egal, nie wieder Intel-Billig-Scheiß ohne VT

Versteh ich vollkommen, bei mir läuft die XP VM auf Debian Host... ich kenne also die Dramatik.
Der witz ist nur, dass Bobcat, der ja auf die unteren segmente Zielt, alla Atom, nur selten in gEräten eingesetzt werden dürfte die überhaupt genug arbeitsspeicher für ernste VM-Geschichten haben...
Und die Anzahl der User die sich netbooks oder subnotebooks kauft um damit VMs auszuführen dürfte auch ziemlich gering sein...

An welcher stelle bist du der Meinung ich hätte BC und nciht BD gemeint?
Im ersten Satz wollte ich ausdrücken dass AFAIK AMD selbst davon ausgeht dass Bulldozer schon ein derart energieeffizienter Serverprozessor wird, dass sich durch Bobcat-basierte Server nicht mehr viel einsparen lässt.

Wie gesagt, ich begrüße diesen Schritt, Vanderpool bzw. Pacifica kann man immer brauchen... und wenns nur dafür ist den browser in einer VM-sandbox laufen zu lassen und solche Spielchen...
Damit gerechnet hatte ich aber trotzdem nicht... ich hätte ins Blaue geraten eher keinen Virtualisierungssupport in Bobcat erwartet, um noch ein paar Transistoren zu sparen...

Ein Bobcat/Ontario könnte sehr gut in einem Büro-SFF mit 4G Ram (8G sollten mit 2 Riegeln auch kein Problem sein) und auch auf Bürorechnern (ich bin SysAdmin, also schon en Sonderfall) wird man wohl immer öfter auch VMs sehen, etwa um sicherheitsrelevante SW auszuführen.

Ganz ohne VT wäre das ein Genickschuss für Ontario. Dito in Thin-and-Light Notebooks.

Zu guter Letzt gibt's ja auch Fernwartungssysteme, die das eigentliche User-OS in ner VM laufen lassen, und die Fernwartung in einer Zweiten. Zumindest hab ich sowas mal gelesen. Gerade für große Unternehmen sicher interessant.

Genau das wollte ich ja damit ausdrücken... dass sich die SW-Landschaft wohl zukünftig in Richtung bessere Nutzung der Virtualisierung ändert, Sandboxing usw.
Das ist IMHO der einzige richtig einleuchtende Grund eine "Low-End" - CPU mit einem Feature auszustatten das man aktuell eher Servern und "Powerusern" zurechnet...
Im moment gibts glaubich recht wenige Anwendungsfälle wo die Normal-Tippse im Büro VM-Beschleunigung braucht....

Wenn Bobcat 2way ist, aber rund 90% der Performance heutiger Mainstream-Notebook-CPUs liefern soll, dann...

Irgendwo hab ich mal gelesen, dass der K8/K10 rund 2,3 Befehle im Durchschnitt pro Takt macht. Wenn aber Bobcat nur 2 rein theoretisch kann, dann macht er real im Durchschnitt wohl eher weit darunter, wohl eher mal so 1,7-1,8.

Aber 90% von 2,3 wären immer noch 2,07, also >2. Soll dann Ontario das Defizit mit höheren Takten ausgleichen? Mit 2Ghz im Netbook und 3Ghz im Lowend-Büro-Desktop? Und das mit dem bescheidenen 40nm-TSMC-Prozess

Macht dann der 28nm-HKMG-Bobcat 4Ghz

Wenn man Bobcat wirklich als Cloud-Server einsetzen will, sollte der doch auch ECC bekommen. Hat man darüber schon was gehört? (Ich denke, dass Intels Atom z.B. wegen fehlendem ECC nicht weit im Servermarkt kommen wird.

Was den "accelerate Mode" angeht: ist es nicht möglich, dass wenn nur (max) 4 Threads auf einem 4-Modul-BD aktiv sind, BD jeweils alle Module aktiv halten, aber jeweils nur einen Kern mit allen 4 dem Modul zur Verfügung stehenden Decodern befüttern könnte? Gleichzeitig könnte der 2. Int-Kern (und e nach Code FP) quasi stillgelegt werden, zwar nicht mit Power-, aber mit Clock-Gating und der erste so deutlich schneller laufen. Den Grafiken nach steht dem jedenfalls nichts entgegen und ich meine auch nichts gelesen zu haben, dass bestimmte Decoder bestimmten Kernen fest zugewiesen seien. Denkbar wäre Derartiges auch bei (zeitweise) reinem FP-Code mit Matzratzenhorchdienst für beide Int-Cores - No? Sind die einzelnen Execution-Einheiten überhaupt schnell genug, um diese Menge decodierter Instruktionen entgegenzunehmen?

Der Gedanke geht mir schon länger im Kopf rum und ich meine dies hier noch nirgends gelesen zu haben. Ist das denkbar/möglich oder nur ein Hirngespinst?

@nazgul99:
Die Idee geisterte hier und da schon rum. Hab das auch schonmal erwähnt. Es wurde auch schon von Greg Hoeppner (AMD) als Möglichkeit dargestellt. Es ist auch nichtmal wichtig, dass ein Core die Decoder voll auslastet. In Leerlaufzyklen kann man dann mit Clock Gating Energie sparen.

Jedenfalls gewinnt so ein einzelner Core min. ~11% Performance, da er von den 90% im 2-thread-Betrieb wieder auf 100% gehen kann. Darüber hinaus könnte durch Ausnutzung des freigewordenen Energiebudgets die Leistung noch steigen. Und es würden auch nur halb soviele Threads um L3, I/O und vor allem Speicherzugriffe konkurrieren.
.
EDIT :
.
Grad keine Zeit für den Blog:

A quick and raw estimation of single threaded performance for Zambezi based on the 50% number given for Interlagos (just to show, what has to be counted in at the least):

Relative_perf_1_thread_to_AMD_fam_10h = (Perf_Magny_Cours*1.5 * 12 / 16) * Freq_ratio_of_half_#_of_Cores * Perf_boost_single_core_in_Module * Perf_boost_single_module_on_chip

Freq_ratio_of_half_#_of_Cores = 3.2/2.3 = 1.39
Perf_Magny_Cours = 1
Perf_boost_single_core_in_Module = 1.11 (while going from 90% back to 100%)
Perf_boost_single_module_on_chip = 1.3 (some cheap turbo)

Relative_perf_1_thread_to_AMD_fam_10h = (1 * 1.5 * 12/16) * 1.39 * 1.11 * 1.3 = 2.26

So with some frequency scaling a Zambezi core will be about 126% faster than a core running in a 2.3GHz MC without turbo. This would equal a 5.2GHz PhII core.

Sind da noch Denkfehler?

Dresdenboy: Das wären Hammer-Werte! 8)
(Ähm, wil sagen Bulldozer-Werte )

"half_#_of_Cores" - wie ist das zu verstehen? Ah, ich sehe: Der Desktop (Zambezi) hat nur halb so viele Cores wie der dickste Server-BD (Interlagos).

Ich sehe keine eindeutigen Fehler, die Performance skaliert allerdings nicht 1:1 mit dem Takt, die 1,39 wäre somit also zu hoch gegriffen. Allerdings ist Magny-Cours ein MCM mit entsprechenden Verlusten (kein gemeinsamer L3 für alle Cores, HT- statt SRQ-Verbindung zwischen je der Häfte Cores), in abgeschwächter Form vermutlich auch Interlagos (?), so könnte der Frequenzskalierungsmangel wieder aufgefangen werden.

Wie sieht die Skalierung Thuban(6) : Zambezi(4/8 ) bei voller Auslastung aller Kerne aus? Das wären doch wieder die guten alten 1 : 1,5 bzw 50% Zuwachs oder?

laut JF-AMD arbeitet AMD wahrscheinlich bereits an einem neuem Design, evtl. 2 BD Generation ? @amdzone

Ge0rgy schrieb:

Was mit übrigens noch bei Bobcat auffällt ist die vollständige Virtualisierungsunterstützung...
inkl. Nested Pages usw.
Die Frage ist warum? - Virtualisierung wird doch gemeinhin als Spielerei für Server betrachtet, nichts was der Endkunde bräuchte

Zum Vergrößern anklicken....

Bei Server denkst Du nicht an Firewall, NFS, P2P - richtig?

Opteron schrieb:

Lol, soll ich Dir jetzt zugestehen, dass Du ein Besserwisser bist ?

Zum Vergrößern anklicken....

Nein, aber dass ich von Quellcode womöglich mehr Ahnung habe als du?

Opteron schrieb:

Nochmal, wir hatten das letztens doch schon ausdiskutiert, Du meinstest der gute David Coakley spielt nur rum bzw. der Code wird noch nicht mal genutzt, ich sagte, dass das das einen tieferen Sinn haben müßte und die neue Architektur ganz sicher Bulldozer sein müßte und da sicher noch ein Codeupdate kommt.

Zum Vergrößern anklicken....

Schau mal, ich programmiere seit über 15 Jahren und habe schon genug Quellcode zu Gesicht bekommen, um zu wissen, dass man keinen "tieferen Sinn" suchen sollte. So viel, wie in diesem Bereich rumgewurschtelt wird, da sollte man sehr vorsichtig mit Schlussfolgerungen sein. Gerade, wenn im Laufe der Zeit immer wieder andere Leute am Projekt mitarbeiten. Da ist es auch egal, ob du ein kleines Tool für ein Kleinunternehmen programmierst oder David Coakley heisst und am Open64 Compiler werkelst. Ein Programmierer ist da nicht besser als der andere.
Da bleiben schon mal Kommentare bestehen, die mit dem Code gar nichts mehr zu tun haben. Da werden Variablen nicht umbenannt, obwohl sie einen anderen Verwendungszweck erhalten. Wer dann noch die UN oder ähnlichen Murks nutzt und sich Typen ändern, wird es noch wilder. Da werden schon mal Hacks eingebaut, um schnell Funktionalität zu gewährleisten (was ich mit "rumgespielen" meinte), ohne sauberes Design. Usw.
Kurzum, das ganze kann für Laien äusserst undurchsichtig und verwirrend sein. Besonders, wenn sie nicht verstehen, wie Datenstrukturen eigentlich funktionieren bzw wie sie letztendlich verwendet werden. Deshalb sollte man sich auch mal von den Leuten etwas sagen lassen, die diese Materie wesentlich besser kennen und nicht stur auf die eigenen Ansichten beharren.

Opteron schrieb:

Ich sags Dir gerne nochmal, wie damals schon, der Kollege hat das immer noch nicht fertig codiert ...

Zum Vergrößern anklicken....

Und ich sage dir gerne nochmal, was ich dir damals schon gesagt habe. Bis es soweit ist, sollte man sich mit Schlussfolgerungen zurückhalten. Und selbst dann muss man erstmal verstehen, wie der Code funktioniert bzw was er genau macht.

Opteron schrieb:

Eine Möglichkeit hab ich bereits oben gennant (Wegen des 4way front-ends könnte es sinnvoll sein, dem Compiler auf 4 ALUs optimieren zu lassen, Dresdeboys accelerate Mode geister auch noch herum, wer weiss was das nun wieder bedeutet) .. darauf könntest Du jetzt gerne eingehen und mitdiskutieren .. aber nein, stattdessen spielst DU lieber beleidigte Leberwurst und wärmst alte Kamellen aufgewärmt.

Zum Vergrößern anklicken....

Es geht mir nicht darum, alte Kamellen wieder aufzuwärmen, sondern es explizit nochmal anzusprechen, um daraus zu lernen. Ansonsten gibt es beim nächsten Mal das gleiche Theater.

Dein Gedanke, den Compiler auf 4 ALUs optimieren zu lassen, würde ich übrigens sogar teilen. Gut möglich, dass der Compiler die 3 ALU/AGU Pärchen des K10 simpel als 3 ALUs behandelt. Die 2 ALUs + 2 AGUs scheinen in Bulldozer komplett unabhängig arbeiten zu können, sind also flexibler, weshalb der Compiler dies als 4 ALUs behandelt.
Ein weiterer Gedanke wäre, dass der Compiler nicht für einen Kern, sondern für ein Modul optimieren soll. Das wären dann insgesamt auch 4 ALUs.

Dresdenboy schrieb:

So with some frequency scaling a Zambezi core will be about 126% faster than a core running in a 2.3GHz MC without turbo. This would equal a 5.2GHz PhII core.

Zum Vergrößern anklicken....

"Some frequency scaling" ist gut. Er taktet praktisch den 2,3 GHz K10 auf 3,2 GHz und rechnet da noch 30% Turbo (0,96 GHz) drauf. Im Endeffekt nichts anderes als 4,16 GHz vs 5,2 GHz. Blieben für Bulldozer 25% mehr IPC pro Thread. Was immer noch recht gut wäre. Da der schnellste Phenom II allerdings bereits mit 3,6 GHz taktet, sind es pro Thread "nur" noch ~44%.


Ich habe IPC pro Thread selbst mal durchgerechnet. Basis dafür war die Aussage mit 50% mehr Performance bei 33% mehr Kernen und die Skalierung von Westemere gegenüber Nehalem bei gleichem Takt (3:2 Kerne, 4:3 Performance Spec Rate (+24% Int, +42% FP)).


80% Speedup für das Modul (180% insgesamt, 90% pro Kern)

2,2 GHz Magny-Cours vs 2,2 GHz Interlagos = +41% IPC
2,2 GHz Magny-Cours vs 2,6 GHz Interlagos = +19% IPC
2,2 GHz Magny-Cours vs 3,0 GHz Interlagos = +3% IPC


60% Speedup für das Modul (160% insgesamt, 80% pro Kern)

2,2 GHz Magny-Cours vs 2,2 GHz Interlagos = +58% IPC
2,2 GHz Magny-Cours vs 2,6 GHz Interlagos = +34% IPC
2,2 GHz Magny-Cours vs 3,0 GHz Interlagos = +16% IPC


Von 0-60% mehr IPC scheint also vieles möglich. Nimmt man den Durchschnitt, 30%, plus mehr Takt bzw Turbo, dürften 50% oder gar mehr gegenüber dem aktuell schnellsten Phenom II (X6 1090T, 3,2 GHz, 3,6 GHz mit Turbo) pro Thread möglich sein.

Duplex schrieb:

laut JF-AMD arbeitet AMD wahrscheinlich bereits an einem neuem Design, evtl. 2 BD Generation ? @amdzone

Zum Vergrößern anklicken....

Wo genau?

gruffi schrieb:

"Some frequency scaling" ist gut. Er taktet praktisch den 2,3 GHz K10 auf 3,2 GHz und rechnet da noch 30% Turbo (0,96 GHz) drauf. Im Endeffekt nichts anderes als 4,16 GHz vs 5,2 GHz. Blieben für Bulldozer 25% mehr IPC pro Thread. Was immer noch recht gut wäre. Da der schnellste Phenom II allerdings bereits mit 3,6 GHz taktet, sind es pro Thread "nur" noch ~44%.


Ich habe IPC pro Thread selbst mal durchgerechnet. Basis dafür war die Aussage mit 50% mehr Performance bei 33% mehr Kernen und die Skalierung von Westemere gegenüber Nehalem bei gleichem Takt (3:2 Kerne, 4:3 Performance Spec Rate (+24% Int, +42% FP)).


80% Speedup für das Modul (180% insgesamt, 90% pro Kern)

2,2 GHz Magny-Cours vs 2,2 GHz Interlagos = +41% IPC
2,2 GHz Magny-Cours vs 2,6 GHz Interlagos = +19% IPC
2,2 GHz Magny-Cours vs 3,0 GHz Interlagos = +3% IPC


60% Speedup für das Modul (160% insgesamt, 80% pro Kern)

2,2 GHz Magny-Cours vs 2,2 GHz Interlagos = +58% IPC
2,2 GHz Magny-Cours vs 2,6 GHz Interlagos = +34% IPC
2,2 GHz Magny-Cours vs 3,0 GHz Interlagos = +16% IPC


Von 0-60% mehr IPC scheint also vieles möglich. Nimmt man den Durchschnitt, 30%, plus mehr Takt bzw Turbo, dürften 50% oder gar mehr gegenüber dem aktuell schnellsten Phenom II (X6 1090T, 3,2 GHz, 3,6 GHz mit Turbo) pro Thread möglich sein.

Zum Vergrößern anklicken....

Der "er" war ich Das Scaling von 2,3 auf 3,2 ist einfach mal ein 12C MC mit low-k vs. 6C Thuban ebenfalls mit low-k. Das soll als Faktor für die Skalierung vom Interlagos zum Zambezi wirken.
.
EDIT :
.
So, da hätten wir Hiroshige's Artikel:
http://pc.watch.impress.co.jp/docs/column/kaigai/20100827_389491.html

Dresdenboy schrieb:

Der "er" war ich

Zum Vergrößern anklicken....

Ah, ok. Ich dachte, du hättest das von irgendwo übernommen.

AMDs Bulldozer-Modul soll durch den 2.Integer-Kern nur um 12,5% gewachsen sein.

Also, wenn der 2. Int-Core das Modul um 12,5% zum wachsen bringt, dann muss der 1. Integer-Core auch "relativ" 12,5% groß sein, weil beide Integer gleich sind.

Wenn ich es richtig verstanden habe und wenn die AMD-Folien es richtig zeigten, besteht ein Integer-Core aus.
- Integer-Shedule
- Execution-Units (ALUs)
- L1 Data Cache
- Load / Store Unit

Wenn der K10 so 9,50 mm² groß sind und die Sektoren richtig eingezeichnet sind, dann ergebe das vollgende Aufteilung. (siehe auch Dresdenboy-Bulldozer-Puzzle-Artikel-#21)
- Integer-Sheduler................ schon in ALU-Sektor?
- Execution-Units (3 ALUs) .. 0,9 mm²
- L1 Data Cache ..................1,6 mm²
- Load / Store Unit ...............0,8 mm²
Gesamt ..............................3,3 mm²

Dann ist der Integer-Core des K10 mit 3 ALUs ganze 35% groß, was dann mit einem 2. K10-Integer im 15 mm² dann +22% wäre und nicht 12,5%
Ich frage mich, wie AMD auf 12,5% gekommen ist. AMD musste einiges eingespart haben, aber wie?

Angenommen das Bulldozer-Modul ist 15 mm² groß
- Integer-Sheduler................ schon in ALU-Sektor?
- Execution-Units (2 ALUs)... 0,6 mm² ..... 2 ALU statt 3 ALU ......... 0,9 * 2/3 = 0,6
- L1 Data Cache ..................0,4 mm² ...... 16 kb statt 64 kb L1D ....1,6 * 16/64 = 0,4
- Load / Store Unit ...............0,8 mm²
Gesamt ..............................1,8 mm²

Also, dann wären bei einem 15 mm² Modul die vom 2. Integer-Core zusätzlichen 1,8 mm² wirklich die berühmten +12,5% ..... 1,5/1,32 = 1,136 = 13,6 %
Na ja fast, es ist um 1% zuviel.

Also, passt doch oder nicht ??

(Aber es sind einige Unsicherheiten wie: Wo ist der Integer-Sheduler oder ob die Load & Store Unit nicht noch größer wird, da sie statt 2mal-Load oder 1mal schreiben dann 2-mal-Load und 1-mal-schreiben gleichzeitig und unabhängig kann.
Die Frage ist halt, ob 32 kb L1D mit 4 fach Assoziativität wirklich nur 1/4 ist von 64 kb L1D mit 2 fach Assoziativität?)

@aylano:
Alles verschiebt sich stark, sobald der L2 mitzählt. Ich schau mir das morgen nochmal mit höherer Aufmerksamkeit an.

Erstmal noch was zu den Ausführungseinheiten. Ashutosh Dhodapkar (hat auch mit bekannten BD-Leuten zusammengearbeitet, gehört wahrscheinlich zum Team) hat mal etwas zum Scheduler patentiert. Und darin steht etwas Interessantes:

Execution resources may generally refer to any hardware circuitry the performs all or part of the execution of an instruction operation. For example, the EXU 20 , the AGU 22 , and the data cache 24 may comprise execution resources. An execution resource may be designed to accept one or more instruction operations per clock cycle. There may be any number of various types of execution resources in various embodiments. Thus, the source buffer 30 may be configured to receive and resolve multiple tag broadcasts per clock cycle and the ATV buffer 32 may be configured to receive multiple broadcast and/or status ATVs per clock cycle.

Zum Vergrößern anklicken....

Double pumping?
Patent: http://www.freepatentsonline.com/y2008/0028193.html
Ah, hier stehts nochmal in einem anderen Patent mit Mike Butler (der vom Bulldozer-Vortrag) und Gene Shen als weiteren Erfindern:
http://www.freepatentsonline.com/y2009/0024838.html

aylano schrieb:

- Integer-Sheduler................ schon in ALU-Sektor?

Zum Vergrößern anklicken....

Ja.
Die eigentlichen ALUs sind recht klein. Ich klaue mal eine Abbildung von Hans de Vries, die den Teil mal in guter Auflösung mit detaillierten Bezeichnungen zeigt. Ist zwar noch K8, aber das sieht beim K10 auch nicht viel anders aus.