Spekulationsthread: Was kommt 2011+
- Ersteller Ge0rgy
- Erstellt am
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Naja ... das Naheliegenste wäre, dass der Store die gleiche Adresse wie einer der Loads haben muss ...Das erklärt aber immernoch nicht wie man 2 Loads & 1 store pro cycle mit 2 AGUs abhandeln will!?
Also entweder muss das mit Einschränkungen verbunden sein oder irgendwo haben wir nen Bruch in der Logik bzw. zuwenig Infos.
Die Berechnungen ansich laufen ja eh auf den Registern ab, selbst die neuen FMA4 Befehle haben nur 1 Mem Parameter.
Aber naja, vermutlich übersehen wir nur noch was, da es ne komplexe Angelegeheit ist.
.
EDIT :
.
So wenigstens sind die 2 MB L2 jetzt in trockenen Tüchern:
Zitat von JF:
http://bit.ly/a0ykVq
Bin ja mal gespannt, ob er sich da verplappert hat, oder nicht ... ^^
.
EDIT :
.
as von der c't hat jetzt auch das Proz. Geflüster online, gabs die Performance Zahlen schon ?
http://www.heise.de/ct/artikel/Prozessorgefluester-1064662.html
ciao
Alex
Zuletzt bearbeitet:
Dr@
Grand Admiral Special
Woher nimmt der das? Auf der Folie sieht das anders aus:
Ich sehe da einen direkten Pfeil vom L1D zur FPU
Und erneut wird dieser Quatsch verbreitet:
Da JF immer betont, es würde bis zum ´Start keine weiteren Angaben zur Performance geben als die bekannte, wird das wohl reine Spekulation sein.
gruffi
Grand Admiral Special
Du darfst gerne weiterspekulieren. Hat ja niemand etwas dagegen. Dann behaupte aber nicht, dass ich Sachen gesagt hätte, was gar nicht stimmt.Ja, das Thema hatten wir doch auch schon 3x, was solls den sonst sein ... wir spekulieren da jetzt weiter, da wir das so annehmen, dass das BD ist und aktuell wird jetzt diskutiert, wie da jetzt was gemeint sein könnte, ob bei den "4" ALUs nun die "MMX" Pipes dabei sind, oder ob das "4" wg. der 2 IMAC Pipes sein könnten, die dann 2 Befehle pro Takt und Pipe verarbeiten können, oder oder oder. Wie besagt, da bist Du herzlich willkommen, aber die ollen Kammellen interessieren keinen mehr. Wir spekulieren da munter weiter, ob mit oder ohne Dir
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
LOL:
@Dr@:
Ja, die Story mit dem K8 wollt ich schon gar nicht mehr kommentieren ...
Zum Bypass .. keine Ahnung, ich geh aber mal davon aus, dass er interne Dokus hat, die 2MB L2 Info hat er auch, und die hat JF gerade erst wieder geschärzt.
Könnte also schon was dran und die Marketingfolie nur falsch sein.
ciao
Alex
nazgul99
Grand Admiral Special
Andreas Stiller ist wohl nicht gut drauf, gibt auch noch ausgerechnet den Spät-Nachplapperer Fudo als Quelle für die TDP-Werte an. Ich dachte er liest hier mit? Oder zumindest bei Citavia?
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Hier liest er garantiert nicht mit, sonst wäre er auch nicht auf die Idee gekommen, dass die AMD 4 Operand Befehle von SSE5 übrig geblieben wären.
Auf alle Fälle ne schlechte Stiller News, Interlagos und ein gemeinsamer 8 MB L3 glaub ich auch erst, wenn ichs sehe ...
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
http://blogs.amd.com/work/2010/08/30/bulldozer-20-questions-–-part-2/
Intel will bei den dicken Sandy Bridge Eisen nativ zum Quick Path parallel auch PCI-Express 3.0 Interfaces hineinbacken. Also Bandbreite satt bei Intel.
MFG Bobo(2010)
Wundert mich etwas, aber hängt wohl davon ab, wann PCI-Express 3.0 bei AMDs Chipsätzen startet.
Intel will bei den dicken Sandy Bridge Eisen nativ zum Quick Path parallel auch PCI-Express 3.0 Interfaces hineinbacken. Also Bandbreite satt bei Intel.
MFG Bobo(2010)
Zuletzt bearbeitet:
ich kann leider den Post von JF-AMD nicht mehr finden, bestimmt wurde der Post entfernt, es stand aber was von AMD arbeitet bereits an einem neuem BD Design evtl. bezog sich das auf BD 2. (wie wärs wenn jemand JF fragen würde?)
Nun, in dem Zitat sagt er eigentlich, daß die ALUs auch AGU-Instruktionen abarbeiten können, wohl sogar gleichzeitg zu einer ALU-Instruktion (dual issue), wenn er da nicht Blödsinn(*) erzählt hat. Daß würde aber zu potentiell vier AGUs führen, was in meinen Augen ein wenig nach Overkill aussieht.
Eine AGU ist ja im Prinzip ein 3fach Addierer mit Bitshift eines Summanden. Den Shift kann man mit ein wenig gutem Willen auch als Multiplikation verkaufen, so daß die Bezeichnung Integer Multiply ACumulate dafür nicht völlig abwegig erscheint.
(*) Oder er hat die Frage nach den vier Pipelines nicht ganz verstanden und redet in der K7..K10-Terminologie mit paarigen ALUs/AGUs, wo jede Reservation Station auch "Dual Issue" ist. Dann hat er wohl gemeint, daß es 2 ALUs und 2 AGUs gibt, ohne weiter ins Detail zu gehen.
AVX.Das erklärt aber immernoch nicht wie man 2 Loads & 1 store pro cycle mit 2 AGUs abhandeln will!?
Also entweder muss das mit Einschränkungen verbunden sein oder irgendwo haben wir nen Bruch in der Logik bzw. zuwenig Infos.
Angenommen alle 256Bit Loads/Stores generieren zwei 128Bit L/S-Requests, dann können die zwei AGUs im Prinzip zu maximal vier L/S-Requests pro Takt führen. Das Gleiche macht ein K10 übrigens bei 128Bit Stores (wird in zwei 64Bit-Zugriffe zerlegt, Loads werden direkt in 128Bit abgearbeitet). Das ist übrigens wegen BDs Möglichkeit auch mit 128Bit-Anweisungen die FPU auszulasten eventuell recht sinnvoll.
Markus Everson
Grand Admiral Special
Ich gehe inzwischen davon aus das AS einen Praktikanten als Ghostwriter für AMD-Prozessornews beschäftigt. Aber auf mich hört ja eh keiner
.
EDIT :
.
Ist denn PCIe 2.0 schon bei den Steckkarten im Server angekommen? Ich hätte vermutet das selbst 1.0 x 16 noch ne Weile reicht, also die Anzahl der Lanes mehr zählt als die Geschwindigkeit pro Lane.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Das war ursprünglich vermutlich für ne Menge Larrabees gedacht
.
EDIT :
.
Ahh, also auf Deutsch, die AGUs berechnen jeweils eine 256bit Adresse ?
Crashtest
Redaktion
☆☆☆☆☆☆
Ja nur dass ein PCIe 2.0 x16 Slot manchmal auch nicht mehr ausreichend ist - 100Gigabit-Netzwerkadapter sprengen PCIe 2.0 x16 und sprengen sogar fast PCIe 3.0 x16; ok sind noch sehr selten aber kommen - ggf per HTX 3.1 @ 3.2GHz oder im sehr seltenes PCIe 2.0 x32 Slot
Das ist aber schon ein ziemliches Extrembeispiel. 100GBit NICs werden wohl sehr wenige Leute in ihren Servern einsetzen. Schon bei 2x10GBit wird es schwer einen entsprechenden Unterbau drunter zu setzen um die Bandbreite aus zu lasten, wenn der Server auch noch was sinnvolles machen soll und nicht nur Netzwerkpakete durch die Gegend schaukeln soll.
Markus Everson
Grand Admiral Special
Na ja, deshalb die Frage. Das man auch 2.0 sättigen kann ist klar, aber wie weit ist das innerhalb der Lebensdauer der CPU (vier/sechs Jahre?) schon relevant? Ist PCIe 2.0 in den gegenwärtig ausgelieferten Servern schon die Regel?
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Allgemein würde ich jetzt vorschlagen nochmal die Dekoderpatente abzugrasen (lesen), das ist der letzte dunkle Punkt bei BD. Vor ein paar Seiten hatten wir schon die 8fach Diskussion, die dadurch entsteht, dass die Pack Unit wegfällt und das Dispatch Unit verdoppelt wird. Eventuell ist da sogar irgendwo auch der mysteriöse accelerate Mode vergraben.
(...)
P.S:
Wg. Pack Unit, Hans De Vries schrieb da im K8 Artikel:
Wenn das jetzt wirklich 6 pro Takt wären, wären das jetzt bei BD im Maximalfall dann 8 und der 8fach Dispatch würde Sinn machen. Aber im Patent steht ja, dass es 6 pro 2 Takte waren ... die Info sollte damit falsch sein.
Quelle mit "Richtungsangaben"
http://www.planet3dnow.de/vbulletin/showthread.php?p=4255797#post4255797
So wies ausschaut sollte das jetzt auch gelöst sein, zumindest klingt es recht plausibel. Bisher war mir nicht klar, was der 8fach Dispatch soll, wenn nur 4 Instr. aus den Dekodern kommen. Na .. da muss der Rest dann einfach aus dem Trace Cache / RRC kommen.
Das hatten wir ja eigentlich schon mal fürs 2x4 Design Pipeline angedacht, aber das macht jetzt auch schon Sinn. Dispatch ist ja direkt nach den Dekodern, vor den Schedulern, optimal für eine µOp Injektion aus dem RRC. Wenn der schon alle Daten liefern kann, gehen dann pro Takt halt idealerweise 8 Ops anstatt 4 durch die INT+FP Pipes.
Mehr oder weniger hatte das mmarq auf AMDzone geschrieben:
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&p=187176
Macht so eigentlich am meisten Sinn, und läßt für mich keine Fragen offen, auch die Doubles stören dann nicht (dachte zuerst ja, die wären für den 8fach Dispatch verantwortlich).
Mal schauen ob es stimmt, oder sieht jemand schon jetzt *das* große Problem ?
ciao
Alex
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Nö, der 4fach Double Decoder kann laut Patenten nur immer 4 µOps weiterleiten, die 4 Doppelblöcke haben nur je 1 Ausgang.Ich verlor irgnedwie ziemlich den Überblick.
Was willst du im Grunde sagen?
Dass es wegen den 8 fach Dispatch dann 4-fach-double-Decoder gibt, die die 2x2-ALU im Hochtakt (= Doppeltakt) mit 8 Ops versorgen??
Am Dispatch gehts aber 8fach weiter - wozu ?
Lösung: Da können auch noch parallel zu den Decodern µOps aus dem Tracecache/RRC einsickern.
Mal die ganzen Bildchen nochmal im Paket:
Wobei ... im 2ten Bildchen geht der Pfeil nicht in den Dispatch, sondern in die Map Unit .. naja die fehlt wohl noch im ersten, da wird in den Patenten ja immer gerne vereinfacht.
Frage die offen bleibt, kann man den Compiler auf sowas optimieren lassen ? Vielleicht ist der accelerate mode doch was anderes ...
ciao
Alex
Zuletzt bearbeitet:
Also ohne es vollständig zu verstehen, sehe ich das so, als ob der Compiler je nach Aufteilung der Instruktionen in diese "Instruction windows" und Platzierung der loads/stores der OoO-Engine helfen kann diesen "lookahead" - status zu erreichen und die 8 Operationen im Batch durch die ALUs zu jagen...
Aber vielleicht stell ich mir das auch zu einfach vor.
Jedenfalls wäre ein Tracecache wohl wirklich eine Plausible Erklärung dafür dass 4 fach reinkommt (über die Decoder) und der Dispatch plötzlich 8 ausliefern will.
Derartiger Übereifer ist zwar lobenswert, hängt aber ohne so ein Konstrukt wie RRC/TC etwas in der Luft...
Aber vielleicht stell ich mir das auch zu einfach vor.
Jedenfalls wäre ein Tracecache wohl wirklich eine Plausible Erklärung dafür dass 4 fach reinkommt (über die Decoder) und der Dispatch plötzlich 8 ausliefern will.
Derartiger Übereifer ist zwar lobenswert, hängt aber ohne so ein Konstrukt wie RRC/TC etwas in der Luft...
@Opteron
Was bedeutet das jetzt genau?
Das man ein Design, was 8 Instruktrionen (= 8 µOps) pro Takt abarbeiten muss/kann, nur ein Decoder braucht der 4 µOps pro Takt abarbeiten kann?
Was bedeutet das jetzt genau?
Das man ein Design, was 8 Instruktrionen (= 8 µOps) pro Takt abarbeiten muss/kann, nur ein Decoder braucht der 4 µOps pro Takt abarbeiten kann?
Was ist dann der Vorteil eines Einfachdecoder der 1 Ausgang hat und einem Double Decoder mit einem Ausagang? Wo ist dann der vorteil vom Double-Decoder mit nur einem Ausgang?
Triskaine
Lt. Commander
- Mitglied seit
- 19.01.2009
- Beiträge
- 105
- Renomée
- 12
, ansonsten ein großartiges Werk.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Lol .. mann .. wieso haben wir das bisher übersehen, David Kanter von realworldtech hat auch nen Bulldozer Artikel online. Da gehts ans Eingemachte.
Den RRC hat er zwar nicht mit in der Grafik, aber sonst gibts viele Details und er erwähnt zumindest nen "loop detector" in nem Satz, damit sollte er den RRC meinen, da es beim Branch Predictor dabeisteht:
Aber egal, weiter:
Zur vorherigen Diskussion, ob die 2 AGUs reichen schreibt er:
Edit:
Triskaine war schneller, hab solange gebraucht, da ich beschlossen hab das zusammenzufassen. Mitten beim Lesen bekam ich nen Datenbankfehler von rwt und nicht war deshaalb nicht sicher, ob er den Artikel gerade wieder offline nimmt ^^
Deswegen ist die Reihenfolge der Stichpunkte auch umgekehrt, war schon auf der zweitletzten Seite ^^
ciao
Alex
Den RRC hat er zwar nicht mit in der Grafik, aber sonst gibts viele Details und er erwähnt zumindest nen "loop detector" in nem Satz, damit sollte er den RRC meinen, da es beim Branch Predictor dabeisteht:
Klingt aber trotzdem etwas konfus .. für die Prediction bzw. der Behebung falscher Vorhersagen bracht man dann schon nen vollen RRC / Trace Cache, da hilft kein Loop Detektor und den gabs auch erst im Core2, nicht im Pentium M.
Aber egal, weiter:
Zur vorherigen Diskussion, ob die 2 AGUs reichen schreibt er:
Zu den Dispatch Windows:
Zum "enhanced mode", ist das vielleicht das ?:
Der Rest in Stichpunkten:
- 4cycle Latency für den L1D$ (stand das schon im Open64 Compiler ?) ziemlich viel für nur 16kB -> das gibt nen hohen Takt ...
- 18-20 cycles Latency für den L2D$ (aus dem Open64 Comp).
- The FP cluster can execute two 128-bit loads per cycle
- Die "MMX" Teile sind u.a. LD/Str Durchgangsstationen
- FMAC Unit 1 macht auch noch XOP,
- FMAC Unit 2 macht auch noch XBAR (hääää):
- Shared 60 entry FPU scheduler. This is roughly 50% larger than the reservation stations for Istanbul (42 entries) and almost double Barcelona's (36 entries). The heart of the cluster is a pair of 128-bit wide floating point multiply-accumulate (FMAC) units on P0 and P1. Each FMAC unit also handles division and square root operations with variable latency.
- Unified 40 entry ALU/AGU scheduler
- ALU0: Üblicher INT Krams plus POPCNT, LZCOUNT + unpipelined integer divider.
- ALU1: Üblicher INT Krams plus fused branches + pipelined integer multiplier
- 128 entry retirement queue,
- 96 Entry INT Pysical Rregister File
- 160 Entry FP PRF
- Fetching is "effectively multi-threaded with single cycle switching between threads"
- Bulldozer has mechanisms to repair the return stack, avoiding this (Anmerung:Istanbul's) corruption issue and decreasing return mispredictions; a feature first seen in Nehalem.
- Loop Detektor
- Interlagos mit Valencia verwechselt
- XBAR ??
Edit:
Triskaine war schneller, hab solange gebraucht, da ich beschlossen hab das zusammenzufassen. Mitten beim Lesen bekam ich nen Datenbankfehler von rwt und nicht war deshaalb nicht sicher, ob er den Artikel gerade wieder offline nimmt ^^
Deswegen ist die Reihenfolge der Stichpunkte auch umgekehrt, war schon auf der zweitletzten Seite ^^
ciao
Alex
Zuletzt bearbeitet:
Triskaine
Lt. Commander
- Mitglied seit
- 19.01.2009
- Beiträge
- 105
- Renomée
- 12
Hier noch meine zusammengefasste Meinung zu der IPC-Diskussion, zuerst hier gepostet:
This IPC discussion is grating on my nerves, it's time for some factual analysis, instead of conjecture:
Datapoint 1: Yorkfield has an average 7 % IPC advantage over Deneb
proofed here by comparing the Q9650 and the PhII X4 945, both at 3 GHz
Datapoint 2: Nehalem has an average 7 % IPC advantage over Yorkfield (without Turbo or HT)
proofed here by comparing i7-965 and the QX9770
Datapoint 3: Sandy Bridge has an average 12 % IPC advantage over Nehalem
calculated from the leaked benches and the Anandtech preview
(not as exact as the other two Datapoints, because the existing comparisons are suboptimal)
Ergo, to match Sandy Bridge's IPC Bulldozer would need an approximate IPC boost of 30 % over Deneb (1.07 * 1.08 * 1.12 ~ 1.30) and that is indeed an unrealistically high jump.
However, with Barcelona AMD achieved an IPC boost of 15-18 % with relatively few major enhancements to the architecture and considering that the core/module architecture gets a huge overhaul in Bulldozer (as can be seen in this article by David Kanter), an IPC boost of 15-20 % is not an unrealistic proposition for Bulldozer.
A boost of at least 12,8 % is already confirmed by the "50 % over Magny-Cours" statement, however, because of the shared architecure the behavior in single thread situations will be different, with a greater boost to be expected.
So while it is very probable that BD won't match Sandy on IPC, an IPC for BD on the level of Nehalem and maybe a bit above is not a totally unreasonable expectation.
Statement: Should the actual IPC of BD "completely suck" [sic], I give you alle every right to knock AMD for it, for a duration of 5 years after this Statement evaluetes to TRUE.
Zuletzt bearbeitet:
nazgul99
Grand Admiral Special
Triskaine: Meinst du IPC oder Performance bei gegebener Verlustleistung? Da Bulldozer dem Vernehmen nach ein Hochfrequenz-Design wird, kann IPC auch gleich bleiben (oder nur leicht steigen oder sinken), wenn der Takt (bei gleicher Verlustleistung) entsprechend steigt.
Triskaine
Lt. Commander
- Mitglied seit
- 19.01.2009
- Beiträge
- 105
- Renomée
- 12
Ich meine damit tendenziell die Single-Thread performance, wobei IPC natürlich mehr als nur das ist.
Um AMD's Willen hoffe ich doch stark auf einen annehmbaren Sprung, so ca. 15 %, ansonsten müsste AMD schon mit 5,0+ GHz anrücken um mit Sandy Bridge konkurrieren zu können.
Ähnliche Themen
