Fotos eines angeblichen Bulldozer "Version 2" enthüllt - Zwischenstufe zu Piledriver?
Der Nachfolger des Orochi-Kerns wird für Ende diesen bzw. Anfang nächsten Jahres erwartet. Wie nun erschienene Fotos eines Engineering-Samples erahnen lassen, scheint AMD seinem Bullldozer noch einmal ein zweites Leben gönnen zu wollen. Die "zweite Version" soll zwar noch die alte Architektur nutzen, aber schon Funktionen von Piledriver anwenden.
Auf OBR-Hardware sind ein CPU-Z-Screenshot sowie ein Foto eines mutmaßlichen Bulldozer-Nachfolgers erschienen. Es handle sich bei dem gezeigten Modell um einen AMD FX-8300 mit 3,3 Ghz Basistakt und 3,9 GHz Turbo-Takt bei alleiniger Auslastung eines Kerns. Das Erscheinungsdatum sei laut OBR für Oktober festgelegt. Die auf dem Foto erkennbare OPN verrät mehr über das vorliegende CPU-Modell (ZD338251W8K54), wie schon das von Toppc. OBR vermutete, dass dem Bulldozer einige Piledriver-Funktionen eingepflanzt wurden (F16C, FMA, BMI1, TBM, TCE) sowie einige Fehler-Verbesserungen vorgenommen wurden. Zum Schluss orakelt OBR noch, dass es sich hier um den Desktop-Piledriver handeln könnte, nur eben mit C0-Bulldozer-Technik - durchaus korrekt.
Denn Fakt ist, dass AMD den nächsten FX, Codename Vishera und mit Piledriver-Basis, als Orochi C0 bezeichnet - die aktuellen FX basieren ebenfalls auf Orochi-Silicium, aber im B2-Stepping. Somit sind weiterhin ES im Umlauf, ab Oktober dürften diese in den Handel gelangen.
Quelle: OBR-Hardware
Bei 10-15% mehr Takt dürfte das realistisch sein
Mit Ausnahme des eigentlichen x86-64 Kernbefehlssatzes, hat Bulldozer entweder weniger Durchsatz oder Phenom schlichtweg gar keinen. Die genannten Befehlssatzerweiterungen beziehen sich durch die Bank auf die SIMD-Einheiten und von denen hat Bulldozer spürbar weniger - die aber eben einige Befehle beherrschen, die der Phenom gar nicht konnte.
"Möglicherweise" ist gut. Mal so zum Vergleich: Intel hat seit dem Core2 einen vierfachen Decoder (der afaik in einigen Fällen sogar 6 Befehle ausspucken kann) für drei Ausführungseinheiten und kombiniert den mit stetig weiterentwickelten Zwischenspeichern, die es erlauben, erneut genutzte Befehle zusätzlich und ohne Decodierung wieder in die Pipeline zu schmeißen. Es ist nunmal so, dass auch primitive Load/Store&Co-Befehle umgesetzt werden müssen (für die Intel drei weitere Einheiten pro Kern und AMD 4 weitere pro Modul vorsieht) und iirc auch so, dass komplexe Befehle mal mehr als einen Takt benötigen, bis sie bearbeitet sind. Dummerweise sind Decoder halt nicht so ganz die einfachste Einheit - weswegen AMD ja mit den Modulen soviel Platz einspart.
1. C0 ist Vishera.
2. AMD FX - Top oder Flop? (Teil 1) - Prozessoren - Planet 3DNow! Forum
Hilf mir mal auf Sprünge, ist der Test nicht für das ganze Design?
3. AMD betont aber gerne, dass es zu keinen Engpässen kommt
Ersteres würde suggerieren, dass Vishera prozesstechnisch als minimale Weiterentwicklung von Zambezi umgesetzt wird (sehr ähnlicher Grundaufbau, die leicht veränderten Masken gehen ohne Respin zwecks Fehlerkorrektur/Optimierung in Serie), letzteres dass Vishera als eigenständig konzipiertes Layout sorgfältig durchgestestet wurde und erst in der min. dritten Optimierungsstufe auf den Markt kommt.
Und Beta Bulldozer hat noch viele weitere Krankheiten.
Das Problem ist wohl, wenn das ganze nicht genau abgestimmt ist, die Latenzen zu hoch sind, dass sich das ganze eher behindert, als reibungslos zu funktionieren und man möglicherweise die Integer-Kerne nicht mit genug Befehlen füttern kann.
"Möglicherweise" ist gut. Mal so zum Vergleich: Intel hat seit dem Core2 einen vierfachen Decoder (der afaik in einigen Fällen sogar 6 Befehle ausspucken kann) für drei Ausführungseinheiten und kombiniert den mit stetig weiterentwickelten Zwischenspeichern, die es erlauben, erneut genutzte Befehle zusätzlich und ohne Decodierung wieder in die Pipeline zu schmeißen. Es ist nunmal so, dass auch primitive Load/Store&Co-Befehle umgesetzt werden müssen (für die Intel drei weitere Einheiten pro Kern und AMD 4 weitere pro Modul vorsieht) und iirc auch so, dass komplexe Befehle mal mehr als einen Takt benötigen, bis sie bearbeitet sind. Dummerweise sind Decoder halt nicht so ganz die einfachste Einheit - weswegen AMD ja mit den Modulen soviel Platz einspart.
Du hast eine Firma und musst Aufträge fertig stellen. Jetzt brauchst du eine Struktur, um einen effizienten Arbeitsablauf zu haben.
Du brauchst einen Manager der Aufgaben vergibt und darauf achtet das jeder sein Zeug bekommt, du brauchst genug Arbeiter, welche die Aufgaben bearbeiten usw.
Was bringen dir 20 Manager, wenn du nur 5 Arbeiter hast? Die Arbeiter kommen mit der Arbeit nicht hinterher und somit musst du warten. Was bringen dir 100 Arbeiter, wenn du nur 1 Manager hast? Der ist gnadenlos überfordert und somit musst du wieder warten.
Ziel einer Architektur ist es eine Balance zu finden, die am besten abgestimmt ist.
Ein Decoder übersetzt die X86-Instruktionen in kleine Micro-Befehle, die von den Integer-Kernen dann abgearbeitet werden.
Ein Integer-Kern von einem Phenom hat z.B. 3 Ausführungseinheiten und einen Decoder der 3 Befehle decodieren kann.
Beim Bulldozer ist ein Integer-Kern leicht abgespeckt, er hat nur 2 Ausführungseinheiten und wie wir wissen hat ein Bulldozer Modul 2 Integer-Kerne. Beim Bulldozer teilen sich beide Kerne einen Decoder, der allerdings 4 Befehle auf einmal decodieren kann.
Waren es damals 3 Befehle für 3 Ausführungseinheiten sind es jetzt 4 Befehle für 2x2 Ausführungseinheiten.
Das Problem ist wohl, wenn das ganze nicht genau abgestimmt ist, die Latenzen zu hoch sind, dass sich das ganze eher behindert, als reibungslos zu funktionieren und man möglicherweise die Integer-Kerne nicht mit genug Befehlen füttern kann.
Deswegen wird wohl ab Steamroller jeder Integer-Kern seinen eigenen Decoder spendiert bekommen.
Damit sollte die Versorgung reibungsloser funktionieren.
Jop das ist mir bewusst.