Was kommt (nach den ersten Deneb (K10.5+)) fuer den Desktop bis zum Launch der BD(APUs)?

[Dresdenboy]

Man sollte aber bedenken, IBM geht wieder weg vom hoch taktenden In-Order Power6. Power7 ist wieder OoO, hat kürzere Pipelines und komplexere Logik. Was im Endeffekt von knapp 5 GHz in 65 nm hin zu 4 GHz in 45 nm bedeutet. Irgendwie zweifel ich daran, dass AMD hauptsächlich über den Takt gehen will. Vieles spricht bisher für signifikante IPC Verbesserungen, sowohl ILP als auch TLP. Vor allem eben die 4 Instruction Pipelines und das "mächtige" Frontend.
Es ist zwar ganz interessant, über die EUs zu philosophieren. Aber im Endeffekt stochern wir nur im Dunkeln, was uns nicht sonderlich weiterbringt. AMD wird genügend Simulationen gemacht haben, um die richtige Dimensionierung für einen typischen x86 Code-Mix zu finden. Diese Daten fehlen uns leider.

Es bleibt ein Kompromiss zwischen vielen Faktoren. Da kann in-order vs. out-of-order schonmal eine Gratwanderung sein. Aber Power ist auch viel breiter ausgelegt mit zwangsweise deutlich komplexeren Schedulern usw. Auch im Vergleich Power7 zu Bulldozer könnte man schon ableiten, dass in 32nm bei niedrigerer Komplexität des Gesamtdesigns u. dedizierter Speed-Optimierung kleiner Teile (so, dass der große Rest mit einem niedrigerem Takt laufen kann) 6+ Ghz für kleine Einheiten möglich wären.

Da K10 bisher keine stark spekulative Ausführung besitzt (es wird in Schedulern u. woanders noch viel auf das sichere Vorhandensein von Daten u.ä. gewartet), sind auch viele Prüfungen u. Bedingungen im Design. Weniger davon bei eventuellem Replay spart auch Energie und erlaubt kürzere Pipelinestufen.
.
EDIT :
.
Etwas interessantes von Andy Glew:
http://andyglew.blogspot.com/search?q=AMD

At AMD, when I started writing the K10 proposal I went out in the morning to buy a Wacom tablet at Frye's.

? Meint er BD oder hat er auch noch was für den Barcelona vorbereitet?

Willamette had some good ideas. Even replay, the cause of so much instability, can be used effectively, e.g. with transitive cancellation to prevent replay tornadoes. But Willamette gave them such a bad reputation that ideas like replay may not be looked at again for 10 years. (It's already been almost five.)

AMD hat Replay-Patente.
AMD hat Transitive Suppression of Instruction Replay patentiert.
Nebenbei scheinen sie auch auf seine MCMT-Architektur zurückgegriffen zu haben.

Offenbar hört AMD nicht nur auf die Kunden.

 

[Opteron]

Einen gewissen Einfluss durch Hiroshige Goto's Artikel habe ich schon pauschal vermutet. Schau ich mir das Bild hier an:
(Quelle)

Ja, überzeugt Mit etwas Unwissen kommt da dann gleich ein 2ter Decoder dazu, ich denke mal so wars.

Das scheint ein neues Hobby von Vielen inkl. uns zu sein: Wie stellst du dir den Bulldozer vor?

Ja, scheint irgendwie rund zu gehen, eine gehörige Portion Schuld trägst sicher Du. Einfach da Patente finden, und so den üblichen Informationsfluss zw. Reportern und Marketing stören *g*

Aber aufgrund von JFs farbigem Bild mit den Pfeilen von den Int-Schedulern zum nach unten versetzten FP-Scheduler denke ich, dass es da etwas anders aussieht, als auf den japanischen Seiten suggeriert.

Welches meinst Du ? Das hier:

?
Jo das wäre dann anders, wiewohl auch das Schema etwas komisch ist (glaube kaum, dass da irgendwelche Ops die im INT Scheduler gelandet sind plötzlich in den FP versetzt werden, das könnte man dann gleich im ROB machen. Aber naja warten wirs mal ab, nach den Schedulern gibts ja µOps, vielleicht gibts doch irgendwelche Gründe dafür.

Nebenbei prüfe ich oft den Gedanken, ob 2x2 dennoch reichen würde, um die angedeutete Leistung auch zu erreichen. Wir sollten uns aber davon trennen, von IPC-Steigerungen zu reden, da mit z.B. 5 GHz keine nötig wäre, um ähnliche Effekte zu erreichen. Den Takt kennen wir nicht. Einiges spricht für ein mindestens teilweise höherfrequentes Design.

Eben ... ausserdem wollen sie ja nicht das absolute Monstrum bauen, sondern das effizienteste Design. Deswegen gibts ja jetzt auch die geteilte FPU. Zwei getrennte FPUs wären sicherlich schneller aber die Kosten / Nutzen Analyse wäre mieß. Das wäre bei 4way INT mMn ähnlich.
Die P4 waren bei INT Code nichtmal so schlecht, der schlechte Ruf stammt eigentlich nur vom hohen Stromverbrauch und der x87 Schmalspur FPU, auf der alter Code fast nur in Zeitlupe lief.
Vor kurzem kam raus das P4 topp bei Truecrypt sind, schneller als K8/K10 pro Mhz, auf Umwegen gibts den vermeintlichen Sourcecode, den hab ich dann mal kurz überflogen. Das war Assembler der nur die x86 INT Register benutzte ... tja ... da ist der Ausgang dann klar

Besonders einige Patente aus den Jahren 2005-2007 gehen in die Richtung. Das ist sozusagen die Vorarbeit, die Grundbausteine. Und da war Energieeffizienz auch schon lange ein Thema u. P4 lang genug bekannt.

Steht da eigentlich irgendwo A. Glew mit drauf ?

Mit dem "K10" wird er "seinen" K10 meinen von damals meinen, also eher das was heute Bulldozer heißt (auch wenn es da sicherlich Unterschiede geben wird). Das Projekt wurde dann bekanntermaßen abgeleht und Barcelona war dann eher ein K8+ der in K10 umbenannt wurde.

Edit:
Hab gerade noch einen alten Artikel auf realworldtech gefunden, der sich mit den kleinen 8kB L1 Caches bei den ersten P4 Chips befasst:
http://www.realworldtech.com/page.cfm?ArticleID=RWT091000000000&p=4

Kurzzusammenfassung: Ein schneller L1 Cache ist bei x86 wichtig, da es wenig Register und deshalb mehr Speicherzugriffe gibt. Da stellt sich jetzt die Frage, ob das in der heutigen Zeit mit x64 auch noch gilt.
Ich denke ich bleibe mal noch bis auf Weiteres bei der Idee, dass eher der L0 Cache 8kB groß ist
Intel hat bei Nehalem ja mittlerweile auch 4 Takte Latenz für den L1.

Aber vielleicht erhöht FMA4 ja wieder den "Druck" aufs Speichersystem. Mal schauen, was am Ende rauskommt ^^

ciao

Alex

 

[Dresdenboy]

@Opteron:

Welches meinst Du ? Das hier:
[s.o.]
?
Jo das wäre dann anders, wiewohl auch das Schema etwas komisch ist (glaube kaum, dass da irgendwelche Ops die im INT Scheduler gelandet sind plötzlich in den FP versetzt werden, das könnte man dann gleich im ROB machen. Aber naja warten wirs mal ab, nach den Schedulern gibts ja µOps, vielleicht gibts doch irgendwelche Gründe dafür.

Genau das Bild. Es gibt mir noch zu denken. Folgendes: Der Dispatcher sollte ja 2 Busse haben. Und die Threads, welche sich die FPU teilen, laufen eigentlich als Code in den Cores ab. Es ist dazu auch einige Kommunikation bzgl. der Execution nötig (neben L/S+L1D$). Da könnte die Abhängigkeit schon so aussehen.

Das mit dem P4-Design sehe ich auch so. Interessant ist die TrueCrypt-Story. Muss ich mir mal ansehen.

Bei den gemeinten AMD-Patenten steht Andy Glew nicht mit drauf. Ich habe aber schonmal seine "Multistar"-Patente gesehen.

Hab gerade noch einen alten Artikel auf realworldtech gefunden, der sich mit den kleinen 8kB L1 Caches bei den ersten P4 Chips befasst:
http://www.realworldtech.com/page.cfm?ArticleID=RWT091000000000&p=4

Kurzzusammenfassung: Ein schneller L1 Cache ist bei x86 wichtig, da es wenig Register und deshalb mehr Speicherzugriffe gibt. Da stellt sich jetzt die Frage, ob das in der heutigen Zeit mit x64 auch noch gilt.
Ich denke ich bleibe mal noch bis auf Weiteres bei der Idee, dass eher der L0 Cache 8kB groß ist
Intel hat bei Nehalem ja mittlerweile auch 4 Takte Latenz für den L1.

Aber vielleicht erhöht FMA4 ja wieder den "Druck" aufs Speichersystem. Mal schauen, was am Ende rauskommt ^^

Jepp, so mancher hat schon argumentiert, dass x64 dank mehr GPRs weniger Speicherzugriffe hat. Aber viele Throughput-orientierten Programme können da keine Rücksicht nehmen, da Code mit den zusätzlichen GPRs zwar mehr Werte in den Registern halten kann (spart auf jeden Fall paar lokale Variablen auf dem Stack) u. diese auch bei Funktionsaufrufen da bleiben können (passend abgelegt), aber viele Operationen finden auf größeren Datenmengen statt. Typisch ist dann die Schleife, optimal natürlich, wenn sie parallelisiert ist. Um ein paar Latenzen zu verstecken, können mehrere Operationen mit mehr Registern in einem Schleifendurchlauf durchgeführt werden. Schon sind die GPRs wieder weg.
Aber soviel hilft es dann doch nicht. Es ist sogar gerade ein gern genutztes Prinzip bei x86-Code mit Speicheroperanden zu arbeiten, um ein paar RISC-mäßige MOVs zu sparen u. den Befehlsdurchsatz zu erhöhen. Siehe z.B. Prime95-Code (allerdings SSE2).

Es bleibt also bei der Wichtigkeit der Caches

FMA4 verringert den Druck sogar, da pro FMA4 nur ein Speicheroperand dabei sein kann. Es sei denn, man lädt mehrere Werte vorher in die Register. Da wird noch interessant, wer die Loads/Stores ausführt. Ich denke mal, die Integer-Cores (jawohl *g*).

Da will ich mir noch überlegen, wie die FP-Scheduler u. -Register verknüpft u. belegt sein könnten bzgl. 128bit/256bit-Ausführung.

 

[Dresdenboy]

Jetzt gibt es schon AMD-Patentanmeldungen zu ein paar Techniken bzgl. Takterzeugung, -beeinflussung und -bereitstellung. Beispielhaft werden aus einem 2 GHz Referenztakt verschiedene Takte mit Teilern wie 0,5, 0,75, 1,25 usw. erzeugt. Der Teiler 0,5 (oder ein "Multiplier" von 2) führt zu einem 4 GHz Takt. Das ist zum Einen für effiziente Taktanpassungen gut (sowohl in Dauer der Anpassung als auch Granularität) und zum Anderen zur schnellen Bereitstellung auch höherer Takte (ohne einen PLL neu einzustellen).

"Techniques for integrated circuit clock management using pulse skipping":
http://www.freepatentsonline.com/y2008/0284476.html

"Techniques for integrated circuit clock management using multiple clock generators"
http://www.freepatentsonline.com/y2008/0285696.html

"Techniques for integrated circuit clock signal manipulation to facilitate functional and speed test"
http://www.freepatentsonline.com/y2008/0288804.html

"METHOD AND APPARATUS FOR CLOCK CYCLE STEALING"
http://www.freepatentsonline.com/y2009/0063888.html

 

[Dresdenboy]

Was bzgl. FMAC noch interessant ist:

Die Radeons können doch ein MUL und ein davon abhängiges ADD gleichzeitig ausführen. So etwas Ähnliches wäre mit einer bridged FMAC-Einheit auch möglich. Wobei es da aufgrund des Taktes sinnvoller sein kann, das FADD ein, zwei Takte später zu starten. Die Gesamtlatenz dieser abhängigen Befehle wäre dennoch niedriger.

 

[Opteron]

Jepp, so mancher hat schon argumentiert, dass x64 dank mehr GPRs weniger Speicherzugriffe hat. Aber viele Throughput-orientierten Programme können da keine Rücksicht nehmen, da Code mit den zusätzlichen GPRs zwar mehr Werte in den Registern halten kann (spart auf jeden Fall paar lokale Variablen auf dem Stack) u. diese auch bei Funktionsaufrufen da bleiben können (passend abgelegt), aber viele Operationen finden auf größeren Datenmengen statt. Typisch ist dann die Schleife, optimal natürlich, wenn sie parallelisiert ist. Um ein paar Latenzen zu verstecken, können mehrere Operationen mit mehr Registern in einem Schleifendurchlauf durchgeführt werden. Schon sind die GPRs wieder weg.

Hmm, bei Througputcode hat man doch sehr regelmäßige Zugriffsmuster, oder nicht ? Das sollte dann eigentlich der Prefetcher erschlagen.

Es bleibt also bei der Wichtigkeit der Caches

Zweifle ich jetzt mal wegen der Prefetcher an
Nichstdestoweniger glaube ich die 8kB L1 aber nicht. Frage ist, wieso Intel Ihre L1 Latenz auf 4 Takte angehoben haben, aber trotzdem eine gute Leistung abliefern. Kann eigentlich nur am L0 liegen.

FMA4 verringert den Druck sogar, da pro FMA4 nur ein Speicheroperand dabei sein kann. Es sei denn, man lädt mehrere Werte vorher in die Register. Da wird noch interessant, wer die Loads/Stores ausführt. Ich denke mal, die Integer-Cores (jawohl *g*).

Stimmt, da hast Du recht. Am Ende wird sich AMD vielleicht wünschen mit AMD64 mehr Register eingeführt zu haben


Zu den Taktpatenten. Wozu sind die genau gut ? (Super)schnelle Umschaltung des Taktes ohne PLL Einschwingphase ? Das wäre dann schon praktisch

Hier mal ein kleiner Ausschnitt des letzten (Taktklau) Patents:

Klingt ganz gut

Zum FMAC Unit:
Da antwortet Dir sicherlich Gipsel

ciao

Alex

 

[mibo]

Entschuldigung, dass ich hier so reinplatze, aber vielleicht kann mir hier jemand die Frage schnell beantworten...
Was für CPUs werden im ersten Halbjahr 2010 von AMD erwartet? Phenom 975 (C3-Stepping, 3,6GHz)? Hexacore für AM3?
Bulldozer ist ja wohl erst für 2011 angekündigt
http://www.hardware-infos.com/news.php?news=3352
http://www.hardware-infos.com/news.php?news=3299

 

[Dr@]

Der Thuban mit sechs Kernen soll im H1 2010 kommen. Was sonst noch an Updates kommen wird . Hier und da ein paar MHz mehr, werden aber sicher dabei sein.

Und sonst steht alles seriös bekannte auf der offiziellen Folie:

 

[mibo]

Dankeschön.

Ich hatte auch gerade noch in den P3D und Heise-News geschaut...
Thuban soll wohl auch die verbesserten Stromspartechniken (C1E) wie der C3-Phenom beherrschen. Vielleicht hat AMD noch was nettes zusätzlich eingebaut...
Anscheinend wird die LEO-Plattform ja zur Cebit erwartet.

Ich bin gespannt

 

[Dresdenboy]

Dankeschön.

Ich hatte auch gerade noch in den P3D und Heise-News geschaut...
Thuban soll wohl auch die verbesserten Stromspartechniken (C1E) wie der C3-Phenom beherrschen. Vielleicht hat AMD noch was nettes zusätzlich eingebaut...
Anscheinend wird die LEO-Plattform ja zur Cebit erwartet.

Ich bin gespannt

Thuban könnte mit einem Turbo-Boost-ähnlichem Feature ausgestattet sein. Dazu habe ich mich auch schon auf Semiaccurate geäußert. Bei einem Sixcore-Desktop-Chip lohnt sich das deutlich.

 

[mibo]

Thuban könnte mit einem Turbo-Boost-ähnlichem Feature ausgestattet sein. Dazu habe ich mich auch schon auf Semiaccurate geäußert. Bei einem Sixcore-Desktop-Chip lohnt sich das deutlich.

Hmm, dann werde ich (vielleicht doch noch bis zur Cebit mit dem CPU-Kauf warten. AMD-Turbo-Boost wäre richtig geil

 

[LoRDxRaVeN]

Wenn ein "Turbo-Boost-ähnliches" Feature tatsächlich kommt, wäre ich ziemlich positiv überrascht. Damit rechnen wohl die wenigsten bei Thuban. So würde der Sechskerner eine erste Konkurrenz und Alternative zu den (wahrscheinlich höher getakteten) Quadcores werden, da er bei "wenig-multi-threated" Applikationen (nahzu) gleichziehen könnte und über gut parallelisierbare Anwendungen brauche ich nicht reden
Das fände ich so richtig cool wenn sich das bewahrheiten würde...

Dann käme mit Sicherheit ein kleiner Kniefall vor dir Dresdenboy

LG

 

[Ragas]

Kann mir mal jemand sagen von welchem Prozessor dieser Die shot ist?!

Ich hab grad mit google nach Die shots von Bobcat und Bulldozer gesucht ....

 

[Opteron]

Das ist ein Griffin / Turion Ultra X2:

http://www.xbitlabs.com/news/mobile...ated_AMD_Turion_X2_Ultra_Mobile_Platform.html

Thuban könnte mit einem Turbo-Boost-ähnlichem Feature ausgestattet sein. Dazu habe ich mich auch schon auf Semiaccurate geäußert. Bei einem Sixcore-Desktop-Chip lohnt sich das deutlich.

Hier auch schon:
http://www.planet3dnow.de/vbulletin/showthread.php?p=4115375#post4115375

Aber da war das Posting wohl zu lange, so dass es von den Meisten übersehen wurde

Edit:
Aja ein kleiner Nachteil des Turbo Boosts, der nutzbare L3 Cache sinkt, da man pro deaktivierten Kern dessen L1&L2 Cache in den L3 auslagern muss. Wären dann unter 4 MB L3 für den TurboDual und unter 5MB für den TurboQuad. Wenn man sich an die Resultate des X4 810 erinnert, sicherlich kein Beinbruch.

Spekulation: Vielleicht auch ein Grund, wieso die ursprünglichen Quads mit je 1MB L2 gestrichen wurden ?

ciao

Alex

 

[Ragas]

Das ist ein Griffin / Turion Ultra X2:

http://www.xbitlabs.com/news/mobile...ated_AMD_Turion_X2_Ultra_Mobile_Platform.html



Hier auch schon:
http://www.planet3dnow.de/vbulletin/showthread.php?p=4115375#post4115375

Aber da war das Posting wohl zu lange, so dass es von den Meisten übersehen wurde

ciao

Alex

ah thanks

 

[LoRDxRaVeN]

Aja ein kleiner Nachteil des Turbo Boosts, der nutzbare L3 Cache sinkt, da man pro deaktivierten Kern dessen L1&L2 Cache in den L3 auslagern muss.

Im Vorhinein: Ich besitze quasi keine Vorkenntnisse in Logikschaltungen etc.

Also: Warum muss man den L1 und L2 auslagern?

Vorstellung: Z.B. 4 Kerne werden schlafen gelegt: Cache Inhalte werde in den L3 geschrieben damit die dort angesammelten Operationen von den anderen Kernen abgearbeitet werden können. Aber sobald sie abgearbeitet sind, stünde doch wieder der volle L3 für z.B. die 2 hochgetakteten Cores zur Verfügung?! Bzw. warum arbeiten die Kerne nicht selbst die in ihren Caches angesammelten Operationen ab und gehen erst dann "schlafen"?
Oder erfolgt eine Aktivierung und erneute Deaktivierung so schnell bzw. zu oft?!
Vermutlich ist nur meine Vorstellung zu primitiv Trotzdem würde mich eine Erklärung freuen.

LG

 

[mibo]

http://it.anandtech.com/IT/showdoc.aspx?i=3722&p=4

Der Cache hält Befehle und Daten. Und die Daten können von aktiven Kernen angefordert werden. Das weckt den schlafenden Kern auf und der Cachezugriff dauert sehr lange, weil der Kern erst wieder wach sein muss.
Deshalb werden L1 und L2 erst in den L3 geschrieben.
So verstehe ich das jedenfalls.

 

[Opteron]

So schaut es aus, wobei ein Kern natürlich keinen L1/L2 Zugriff auf anderer Kerne hat.

Genaugenommen können andere Kerne halt die gleichen Daten aus dem RAM laden, die schon ein anderer im L1/L2 hat. Wenn der andere Kern jetzt die Daten ändert, müssen die auch im L1/L2 Cache des schlafenden Kerns aktualisiert werden, geht natürlich schlecht, wenn der Kern schläft -> ergo die ganze Geschichte im L3 abwickeln, dann kann der Kern weiterschlafen.

ciao

Alex

 

[LoRDxRaVeN]

Das ist mir schon klar warum sie vor dem Schlafen in den L3 geschrieben werden. Ich verstehe nur nicht, warum dann dieser 1MB im L3 DAUERHAFT blockiert sein soll. Irgendwann sollten doch die Daten der schlafenden Kerne abgearbeitet sein und nicht mehr benötigt werden bzw. sie sind dann sowieso schon in einem L2 eines aktiven Kerns oder so.
Das mit den aktualisieren stelle ich mir so vor, dass man dann einfach vorraussetzt, dass diese Daten im L2 des schlafenden Kerns einfach nicht mehr aktuell sind und verworfen werden bzw. dass gar keine Daten mehr im L2/1 sind und neue "angefordert" werden.
Oder will man genau das verhinden, dass schlafende Kerne keine Daten im Cache haben, da schlafende Kerne sowieso alle paar (Milli)Sekunden aufgeweckt werden und so ein "Schlafintervall" im üblichen Fall nicht (hausnummer) 30 Sekunden dauert sondern eben nur Millisekunden?
Naja, wie gesagt, vermutlich ist meine Vorstellung einfach viel zu einfach...

LG

 

[Woerns]

Warum soll ein deaktivierter Kern noch seine Cache-Inhalte merken?

Ich finde, wenn ein Kern aus seinem Dornröschenschlaf wach geküsst wird, dann ist es ihm auch zuzumuten, dass er sich mal ein bisschen neu orientiert.8)

Ich fände es einfacher, wenn er seine Zustände "Modified" und "Owned" zurück ins RAM schreibt und alle seine Cache-Lines auf "Invalid" stellt. Dann kann er ruhig schlafen und der volle L3 kann anders verwendet werden.

Ist halt die Frage, was mehr Zeit kostet, die beiden Caches L1, L2 zu kopieren oder die betreffenden Cachelines zurückzuschreiben. Und wer das ausführt - der einschlafende Kern hat ja im Prinzip Zeit, sonst dürfte er sich nicht schlafen legen. Aber der L3 und der RAM, bzw. das Speicherinterface vielleicht nicht. MfG

 

[Opteron]

Wenn Du die Daten komplett entfernen würdest, müßte man den Kern quasi "neu booten" .. das geht schlecht, bzw. es würde viel zu lange dauern.

Deswegen sichert man halt den aktuellen, letzten, *gültige* Zustand, wenn der Kern wieder aufgeweckt wird, geht es relativ schnell wieder weiter.

ciao

Alex

 

[LoRDxRaVeN]

Wenn Du die Daten komplett entfernen würdest, müßte man den Kern quasi "neu booten" .. das geht schlecht, bzw. es würde viel zu lange dauern.

Aha, das wollte ich wissen Danke!
Ohne richtige Vorkenntnisse hat man ja kein Gefühl dafür, wie lange so ein "Neustart" inkl. Neubefüllung mit Daten eines Kerns im Verhältnis zu einer "Reaktiverung" inkl. Cacheaktualiseriung dauert...
Denn aus meinem Standpunkt gesehen, hätte dies exakt gleich lange gedauert

LG

 

[Woerns]

Ich glaube, dass ein Kern, der gerade nichts zu tun hat, auch nicht mehr sehr viele brandaktuelle Daten im Cache hat. Und wenn doch ein paar dabei sind, dann kann er sich die auch wieder besorgen. Finde ich besser, als sein Schläfchen auf Kosten der Gemeinschaft (L3) zu halten (irgendwie asozial).

Die Frage ist auch, warum der Cache mit schlafen gehen muss. Wird das Cache-Kohärenz-Protokoll denn nicht vom Cache selbst erledigt? Dann kann der Kern doch schlafen und der Cache bleibt wach. Ist halt ein bisschen statische Leakage, die man auch gerne einsparen möchte. Aber für den "leichten" Kurzschlaf (der mit hoher Rate im Submillisekundenbereich stattfinden darf) wäre das doch die bessere Variante. Und wenn daraus ein ausgedehntes Nickerchen wird (oberhalb von Millisekunden), dann spült der Cache eben die drei Lines, die inzwischen noch nicht überschrieben worden sind in den Speicher zurück. MfG

 

[Opteron]

Naja der Cache hängt an den L/S Units .. man könnte es wohl durch feines clock gating hinbekommen, dass er weiterläuft, aber das wäre vermutlich ein größerer Umbau. Der einfachere Weg ist sicherlich in den L3 zu kopieren ist ja eh groß genug

und jetzt weiter zu den aktuellen Nachrichten, die L1D Size des Bulldozers ist bekannt, zumindest wenn man den Optimierungsparametern des AMD Compilers glaubt (wird ja wohl zu 99,9999% stimmen ^^):

Zuerst der Eintrag des Barcelonas zum Vergleich:

case TARGET_barcelona:
L[0] = MHD_LEVEL(MHD_TYPE_CACHE, // Type
64*1024, // Size
64, // Line Size
11, // Clean Miss Penalty
11, // Dirty Miss Penalty
2, // Associativity
32, // TLB Entries
4*1024, // Page Size
50, // TLB Clean Miss Penalty ?
50, // TLB Dirty Miss Penalty ?
6.0, // Typical Outstanding Loads ?
0.8, // Load_OP_Overlap_1 ?
0.4, // Load_OP_Overlap_2 ?
50); // Pct_Excess_Writes_Nonhidable ?
break;

Und nun von Orochi:

case TARGET_orochi:
L[0] = MHD_LEVEL(MHD_TYPE_CACHE, // Type
16*1024, // Size
64, // Line Size
18, // Clean Miss Penalty
18, // Dirty Miss Penalty
4, // Associativity
32, // TLB Entries
4*1024, // Page Size
50, // TLB Clean Miss Penalty ?
50, // TLB Dirty Miss Penalty ?
6.0, // Typical Outstanding Loads ?
0.8, // Load_OP_Overlap_1 ?
0.4, // Load_OP_Overlap_2 ?
50); // Pct_Excess_Writes_Nonhidable ?

http://svn.open64.net/filedetails.p...osprey/common/com/x8664/config_cache_targ.cxx

Also statt 64kB 2fach assoziativ, 16kb 4fach ... interessant. Hört sich immer mehr nach P4 an

Noch zum Vergleich, der Wolfdale Eintrag (45nm DualCore mit 32kB L1):

case TARGET_wolfdale:
L[0] = MHD_LEVEL(MHD_TYPE_CACHE, // Type
32*1024, // Size
64, // Line Size ?
11, // Clean Miss Penalty ?
11, // Dirty Miss Penalty ?
2, // Associativity ?
32, // TLB Entries ?
4*1024, // Page Size ?
50, // TLB Clean Miss Penalty ?
50, // TLB Dirty Miss Penalty ?
6.0, // Typical Outstanding Loads ?
0.8, // Load_OP_Overlap_1 ?
0.4, // Load_OP_Overlap_2 ?
50); // Pct_Excess_Writes_Nonhidable ?
break;

Edit:
Ach, L2 Info gibts netterweise auch gleich noch, sind 2 MB:

case TARGET_barcelona:
// TODO: this might be too generous: in multiple processor situations,
// there is a cost to loading the shared bus/memory.
L[1] = MHD_LEVEL(MHD_TYPE_CACHE,
1*512*1024, // also 512 Kb L2
64,
150,
200, // ?
16,
512,
4*1024,
50, // ?
50, // ?
LNO_Run_Prefetch ? 1.8: 1.0, // ?
LNO_Run_Prefetch ? 0.7 : 0.1, // ?
LNO_Run_Prefetch ? 0.3 : 0.05, // ?
LNO_Run_Prefetch ? 25 : 50); // ?
break;
case TARGET_orochi:
// TODO: this might be too generous: in multiple processor situations,
// there is a cost to loading the shared bus/memory.
L[1] = MHD_LEVEL(MHD_TYPE_CACHE,
2*1024*1024, // also 2 MB L2
64,
150,
200, // ?
16,
512,
4*1024,
50, // ?
50, // ?
LNO_Run_Prefetch ? 1.8: 1.0, // ?
LNO_Run_Prefetch ? 0.7 : 0.1, // ?
LNO_Run_Prefetch ? 0.3 : 0.05, // ?
LNO_Run_Prefetch ? 25 : 50); // ?
break;

Und nochmal Wolfdale (da sieht man die 6 MB L2):

case TARGET_wolfdale:
L[1] = MHD_LEVEL(MHD_TYPE_CACHE,
6*1024*1024,
64, // ?
150, // ?
200, // ?
16, // ?
512, // ?
4*1024, // ?
50, // ?
50, // ?
LNO_Run_Prefetch ? 1.8: 1.0, // ?
LNO_Run_Prefetch ? 0.7 : 0.1, // ?
LNO_Run_Prefetch ? 0.3 : 0.05, // ?
LNO_Run_Prefetch ? 25 : 50); // ?
break;

Wäre hätte das gedacht, dass das so schnell rauskommt *g*

Also nochmal zusammengefasst, Bulldozer/ Orochi Cachegrößen:

• 16kB L1 4fach assoziativ
• 2MB L2 (vermutlich 16fach, falls die Parameter des L2 die gleichen sind wie beim L1)

ciao

Alex

 

[GHad]

So als noob... Ist das gut im Vergleich zu Deneb? Und was sagt das über mögliche Leistungsverbesserungen in welchen Bereichen aus?

Greetz,
GHad