TRINITY & Co: alles um Bulldozer-based APUs von AMD und deren Plattform

Status
Für weitere Antworten geschlossen.
Schonmal gedanken darüber gemacht das ein K10 mit 8 Kerne in 32nm kleiner als Bulldozer ausgefallen wäre und dabei hätte jeder Kern deutlich mehr Ressourcen als ein BD Thread...
Wofür willste Ressourcen sparen wenn die Leistung nicht höher ausfallen kann? Das SSE/AVX Zeug ist jetzt komplett im Design neu, erkläre mir wie AMD die Integer-Leistung bis 2013 um 30% ohne Taktupdates steigern kann? Im Desktop Markt wird sich der Abstand in 1 Jahr mit Haswell dann noch weiter vergrößern, Bulldozer ist im Desktop nicht besser als Thuban, das was in Winrar oder encodieren passiert interessiert fast niemanden.
Schonmal drüber Gedanken gemacht dass das keine Rolle gespielt hätte, weil man mit dem 10 jahre alten Design trotzdem nicht gegen SB angekommen wäre und immernoch Architektonisch genau keinen Schritt voran gekommen wäre?
Man hätte für den Serverbereich noch immer kein AVX bieten können, erst Recht kein FMA und der Rückstand in der featureliste wäre immer größer geworden.
Schonmal Gedankend arüber gemacht dass Ressourcen nicht alles sind und einen Dreck wert wenn man sie nicht ausgelastet bekommt? - Oder warum schmeißt man nicht den ganzen Verwaltungskram aus den kernen raus udn verbaut 5MB L1-Cache? *noahnung*
Ressourcen spart man nicht nur für mehr Leistung, sondern auch um weniger Strom aufzunehmen etc. 8 K10 sind nicht so viel kleiner als 4BD Module. Hätten womöglich ein Kleinbisschen mehr Leistung ja... aber man hätte den selben Zombie der die Firma schon seit vielen Jahren trägt zum wiederholten mal aufgekocht ohne technologisch auch nur 1 Schritt voran zu kommen. -> eine Sackgasse.
Zudem sehen wir ja an Llano wie die Taktbarkeit der 32nm K10er ausschaut. Ob das beim Octacore so prickelnd wäre?
Du verallgemeinerst und polemisierst, vergleichst eine durchoptimierten, über jahrzehnte gereifte Architektur im 100. aufguss und mit Himbeergeschmack verziert, mit einem neuen Ansatz ohne jegliches Wissen über die Hintergründe.
Klar, AMD ist total verblödet in der Birne und fahren koplett grundlos gegen die Wand... die haben sicher nicht darüber diskuttiert das zu machen und dann abgewogen sondern sich im Meeting besoffen und mit Drogen weggeballert und einer hat "Bulldozer" ans Flipchart geschrieben... :]
Alles hat eine einfache Lösung und die Welt ist eine Scheibe, und wer das nicht sehn will ist selber schuld... schon klar 8-(
In der Evolution wäre das lustig gekommen... die ersten Säugetiere tauchen auf, chancenlos gegen die Raptoren, also stampfe wir das Konzept ein und bauen weiter Reptilien *lol*
 
Schonmal drüber Gedanken gemacht dass das keine Rolle gespielt hätte, weil man mit dem 10 jahre alten Design trotzdem nicht gegen SB angekommen wäre und immernoch Architektonisch genau keinen Schritt voran gekommen wäre?

In Multithreading wäre der X8 aber mind. gleichwertig mit einem i7-2700k. (Weil der K10 pro Thread 15-20% mehr Integer Leistung als BD hat)
Man hätte für den Serverbereich noch immer kein AVX bieten können, erst Recht kein FMA und der Rückstand in der featureliste wäre immer größer geworden.
AMD bietet FMA4, das wird Intel nicht unterstützen, deshalb wird das 4 Operanden Systen auch nicht mehr Standard, also erkläre uns doch bitte wofür man langfristig FMA4 braucht *noahnung*
Schonmal Gedankend arüber gemacht dass Ressourcen nicht alles sind und einen Dreck wert wenn man sie nicht ausgelastet bekommt? - Oder warum schmeißt man nicht den ganzen Verwaltungskram aus den kernen raus udn verbaut 5MB L1-Cache? *noahnung*
Ressourcen spart man nicht nur für mehr Leistung, sondern auch um weniger Strom aufzunehmen etc. 8 K10 sind nicht so viel kleiner als 4BD Module. Hätten womöglich ein Kleinbisschen mehr Leistung ja... aber man hätte den selben Zombie der die Firma schon seit vielen Jahren trägt zum wiederholten mal aufgekocht ohne technologisch auch nur 1 Schritt voran zu kommen. -> eine Sackgasse.
Das K10 Design wurde seit Barcelona nicht mehr weiterentwickelt...Die Husky Kerne haben nur kleine überarbeitungen erhalten, wenn man das K10 Design damals mit allen Ressourcen die man hatte, weiterentwickelt hätte, dann wäre er heute auch deutlich stärker als Bulldozer geworden, ich denke das der sogar für SB gefährlich geworden wäre, aber AMD war zu stolz ein neue Architektur zu entwickeln...
Zudem sehen wir ja an Llano wie die Taktbarkeit der 32nm K10er ausschaut. Ob das beim Octacore so prickelnd wäre?
1. hat Llano eine GPU, 2. hat Llano das B0 Stepping, 3. war Llano unabhängig von der GPU ursprünglich mit mehr als 3Ghz+ geplant....
Du verallgemeinerst und polemisierst, vergleichst eine durchoptimierten, über jahrzehnte gereifte Architektur im 100. aufguss und mit Himbeergeschmack verziert, mit einem neuen Ansatz ohne jegliches Wissen über die Hintergründe.
Ich kann nichts von einem 100. Aufguss sehen, was meinst du? Die letzte Architektur Änderung vor BD war Barcelona dessen Entwicklung zwischen 5-8 Jahre zurückliegt und davor K8 & K7.

1. Gen. > K7
2. Gen. > K8
3. Gen > K10

Das sind doch nur 3 große Entwicklungen gewesen, Bulldozer ist Entwicklung Nr.4 aber neue Architektur ohne den Vorgänger zu verbessern, also was für einen 100. Aufguss meinst du den?

Sandy Bridge ist auch nicht der 100. Aufguss, gab es jemals sowas?

Pentium3 (P6)
Pentium4 (Netburst)
Core2 (P6)
Nehalem (P6)
Sandy (P6)
 
Zuletzt bearbeitet:
@Duplex
Ich sehe die Problematik eher anders herum ... aber das Denke ich, wissen auch Einige.
Hätte AMD die Kryptonit-Serie unlängst eingestampft, so könnte man Bereits eine CPU haben, die einen i7-2700k hinter sich lies.
Aber man pumpte immer wieder Geld und Know-How in die alte K7/8 Architektur um sie ein klein wenig schneller zu machen. Anstatt mal komplett auf eine neue Architektur zu Bauen.
Die Konkurrenz hatte in der Zeit eine neue bzw.alte Architektur gestartet und erfolgreich weiter entwickelt.
Und der Stand ist heute mal der, dass man selbst mit einem K10, der mit 4GHz OC läuft, keinen I7-Besitzer mehr ärgert.
Wenn man jetzt noch an die Fertigungs-Probleme in 32nm denkt, dann wäre bei einem 8x 32nm K10 hinten nichts raus gekommen.

Gruß Lehmann

Wir jetzt aber langsam hier ganz schon OT.
Sorry dafür
 
Zuletzt bearbeitet:
Duplex schrieb:
Bulldozer ist im Desktop nicht besser als Thuban, das was in Winrar oder encodieren passiert interessiert fast niemanden.
Das Problem ist eben, dass man mit einem Prozessor nur für den Desktop nichts mehr gewinnt. Das ist ein Marktsegment, das schrumpft.
Im Serverbereich ist Bulldozer top und da braucht AMD wieder mehr Marktanteile.
Und für Notebooks ist die Architektur mit niedrigen Verbrauchswerten wahrscheinlich auch nicht schlecht und hat dazu noch deutliches Potential was die weitere Verschmelzung von CPU und GPU angeht. (soweit zum Thema)
AMD hätte sich auch bei der 32nm-Fertigung schlicht kein weiteres Design leisten können. Hätten sie einen 8Kern-k10 entwickelt, dann wäre entweder Llano oder Orochi auf der Strecke geblieben. Und die sind beide mehr wert als jeder 8Kern-K10.
Bulldozer bringt ja mehr mit, als einfach nur ein neues Kerndesign und Erweiterungen. Da ist auch viel an Stromsparmodi und Turbo etc. gearbeitet worden. Diese Entwicklung hätte man parallel dann auch in den K10 einfließen lassen müssen. Und daran fehlt es eben bei AMD: Geld und damit an Ressourcen, um sich solche Dinge leisten zu können. Intel kann sowas machen. Die basteln mal nebenbei SCC mit 48 Kernen und bauen drei Generationen Larrabee, ohne eine davon kommerziell zu veröffentlichen. Erst mit der vierten Generation aka Knights Corner macht man das jetzt. Und warum: Weil man das Geld hat. AMD hat das nicht. Also warum sollte man ein verlorenes Design wie einen 8-Kern K10 bringen? Nur weil Du gerne einen hättest? AMD kann das nicht leisten, aus fertig.

Meine bisherigen Erfahrungen mit meinem 8120 unter Linux zeigen übrigens, das das Ding deutlich mehr Bums hat als ein Thuban mit höherem Takt. Derzeit noch mit optimierter Software, demnächst vielleicht schon @stock.
 
Zuletzt bearbeitet:
Ok, ich versuch mich deutlicher auszudrücken:
1. Powergating bei ALUs etc. ist mit den Aufwachzeiten eine _ganz_ andere Baustelle als einen Kern aufzuwecken. Wenn du am ende um die 4. schlafende ALU wieder wach zu bekommen mehr Takte brauchst als den entsprechenden, anstehenden Befehl in die Warteschlange der anderen 3 ALUs zu packen, gewinnst du nichts.
2. Das mit den 100% ist eine Definitionsfrage. Ein HW-Tester beurteilt die Performance einer CPU nach dem SingleThread-Fall und rechnet dann den skalierungsfaktor bei Multithreaded aus. Er hat keine andere Basis. das bedeutet in dem fall wäre 1x8 ALUs das Referenz-Ergebnis, und jede mehr threads, je weniger ALUs also einem Thread zur verfügung stehen, desto schlechter das Ergebnis, also eine unterirdische Skalierung.
3. Beim ILP des x86-Assemblercodes hat sich in den letzten 10 Jahren eher wenig getan. Es ist nunmal fakt dass in einer Architektur die relativ wenige REgister hat (verglichen mit RISC-Architekturen anderen fabrikats) und derart komplexe befehle quasi zwangsweise Abhängigkeiten entstehen, du findest einfach keien 8 Befehle in Folge die nichts miteinander zu tun haben, um sie parallel abzuarbeiten. Das Ganze geht soweit dass man zu erkennen versucht welche Loads und stores sich gegenseitig nicht behindern um dort noch abseits der Register OoO - Ausführung zu ermöglichen, Stichwort "Memory Disambiguation".
Es hat also nichts mit dem alter der Kernarchitektur zu tun sondern mit der Struktur des Codes.
Dass Multithreading zuwenig zum Einsatz kommt ist ein ganz anderes Problem.
1. Du gewinnst nicht nur nichts, du kannst sogar jede Menge verlieren, da Power-Gating schon mal Takte im dreistelligen Bereich benötigen kann. Anders als zB Clock-Gating, welches nur wenige Takte braucht. Es sollte klar sein, dass vor allem eine statische Power-Gating Implementierung Sinn macht. Also für bestimmte Workloads oder für eine bestimmte Zeit konstant greift und nicht in jedem Takt neu entschieden wird. Wobei man das wahrscheinlich auch neu überdenken müsste. Power-Gating braucht momentan, auf Kernebene, deshalb so viele Zyklen, da zB Register und/oder Cache Inhalte gesichert werden müssen. Das würde auf Pipelineebene natürlich wegfallen.
2. Wenn du nach dieser Rechenweise Intel Prozessoren mit SMT beurteilst, ist deren Skalierung auch unterirdisch. Wie gesagt, das war nicht mein Thema. Es ging erstmal nur um eine theoretische Analyse. Und dafür brauchst du halt eine Basis. Wie es dann in der Praxis ausschaut, steht auf einem anderen Blatt. Aus technischer Sicht ist die Skalierung von 1x8-fach auf 4x2-fach auch weniger von Bedeutung. Hier interessiert viel mehr von 1x2-fach auf 4x2-fach. Mit einer flexiblen Pipeline kann man das im Labor sicherlich problemlos simulieren. Hier zeigt sich, wie gut die Architektur skaliert. Wenn diese dann 4-fach oder 8-fach bei singlethreaded Workloads fährt, geht es nur noch um Performancemaximierung. Skalierung ist dann belanglos.
3. Codeabhängigkeiten liegen nicht an der ISA, sondern am Code selbst, also an der Struktur der einzelnen Instruktionen. Aber wie gesagt, auch hier muss man neu überdenken. Seit den 90ern sind doch jede Menge Befehlssatzerweiterungen hinzugekommen. Auch Konzepte wie SpMT erfordern neue Denkansätze und mehr Ressourcen für ILP. Damit liesse sich sogar einige komplexe und Transistor fressende Logik aktueller Architekturen eliminieren, wie im Branch Predictor. Und nochmal, versteife dich nicht auf 8-fach. Wenn Simulationen hier keine Mehrperformance ergeben, kannst du auch 4- oder 6-fach fahren.

Der jux ist, um das mal salopp gegenüberzustellen:
man nehme 4 Bobcat-Kerne, die haben zusammen 8 ALUs, diese können paarweise, inkl. caches, dekoder etc. schlafengelegt werden, indem man die kerne clock- und powergated. Das geht relativ simpel, da sie logische und physikalische Einheiten sind, und damit keine großen Synchronisierungsprobleme bestehen, entweder der Kern ist stromlos oder eben nicht.
Dem Gegenüber steht dein 8-Fach OoO megacore.
Theoretisch die selbe Rechenleistung bei 4 Threads... jetzt kommt das aber...
+ Verwaltungsaufwand für das "splitting" in Einzelkerne, jeder befehl in den caches, im scheduler,retirenement etc. muss extra tagged werden zu welchem thread er gehört., evtl. Trashingprobleme in Caches, unsagbar kompliziertes Abhängigkeits-Tracking bei 8-Fach OoO
+ Probleme mit aufwachzeiten, Hotspots und komplizierter Verdrahtung um einzelne Einheiten schlafen zu legen, ersparnisse fraglich, da die Recheneinheiten sowieso am wenigsten vom Transistorbudget ausmachen.
+ Herstellung schwieriger, da bei einem defekt in diesem Kern unter Umständen der ganze Kern ad acta gelegt werden muss, und somit wesentlich mehr Ausschuss-transistoren, als wenn ein Bobkätzchen defekt ist.
+ Debugging eines sehr großen, sehr komplexen gebildes, fehleranfällig etc.
Ich denke eben nicht, dass du hier mehr Verwaltungsaufwand hast. Das Tagging von Instruktionen, zu welchem Thread sie gehören, hast du momentan ja auch schon. Registersätze müsste man natürlich entsprechend viele implementieren. Bei 8-fach OoO sehe ich auch kein Problem. Immerhin hat man es beim Alpha EV8 schon mal hinbekommen. Cache müsste man eventuell neu überdenken. Aber hier ist ja nicht gesagt, dass man nicht neue Ansätze findet. Haswell soll angeblich auch einen neuartigen Cache besitzen. Ich sehe bei 4 Bobcat Kernen eher, dass man hier redundante Einheiten hat, die eliminiert werden können. Und du hast eben das Problem mit der geringeren Performance bei ein oder zwei Threads.
Aufwachzeiten, Hotspots, etc sind mMn nicht problematischer als bei Bulldozer.
Die Herstellung sehe ich auch nicht als schwieriger, eventuell maximal das Deaktivieren von Funktionseinheiten. Wenn man das von vornherein aber berücksichtigt, ist das eigentlich recht unproblematisch. Bei aktuellen Prozessoren kannst du ja auch nicht nur einzelne Kerne deaktivieren, sondern auch CMT oder SMT. Und wie schon erwähnt, versteife dich nicht zu sehr auf eine Möglichkeit der Umsetzung des Konzeptes. Ich schrieb zuvor schon mal, du kannst es flexibel auslegen. Mit einem 2x2-fach Kern muss es natürlich nicht beim Single-Core bleiben. Davon kannst du dann auch 2 oder 4 ins Design integrieren und kannst wie bisher ganze Kerne deaktivieren.
Debugging ist jetzt schon ziemlich komplex. Das darf keine Ausrede sein. Entsprechendes Equipment und Personal sollte natürlich vorhanden sein.

-> Und das Ganze nur dafür dass man einen auf "wer hat den längsten" machen kann?
Nein, sicherlich nicht. Das ganze, um den Kunden ein möglichst ausgewogenes Design zu bieten, was auf alle denkbaren Workloads optimal reagieren kann. Wobei ich hier vor allem vom Desktop- und Notebookmarkt spreche. Für Server ist es nicht wirklich notwendig, da singlethreaded Performance nebensächlich ist. Ebenso, was den Markt für Kleinstgeräte betrifft. Hier ist Performance grundsätzlich nebensächlich, da es vor allem um Sparsamkeit und Energie-/Flächeneffizienz geht.
Natürlich ist die Umsetzung eines solchen "Mega-Kerns" anspruchsvoller. Nur, ist das ein Grund, es nicht zu versuchen? Wenn man immer nur den Weg des geringsten Widerstandes geht, wird sich Technologie nicht weiterentwickeln.

Und dazu sei noch gesagt, dass die "breite" der OoO-Architektur garnicht das tragende Problem darstellt, sondern die Recheneinheiten durchgängig zu füttern! Eine gute Cache-Architektur, Prefetching, Sprungvorhersage usw. zur minimierung von Leerlaufzeiten in der Pipeline, ist 100 mal wichtiger als die Frage nach 2-fach oder 3-fach OoO.
Deshalb sehe ich ja auch als Grundeinheit eine 2-fach superskalare Teilpipeline pro Thread. ;) Irgendwie habe ich das Gefühl, du versteifst dich zu sehr auf 8-fach. Darum geht es aber gar nicht bei dem Konzept. Die maximale Breite der Pipeline ist nach oben hin flexibel. Das kann 4-fach, 6-fach, 8-fach oder sogar noch mehr sein. Hier müssen eben Simulationen zeigen, was am sinnvollsten ist. Und natürlich sind auch oberhalb von 2-fach oder 3-fach mit einem Thread noch Gewinne möglich. Wenn ich mich richtig erinnere, kam der Alpha EV8 zumindest in theoretischen Tests auf eine IPC von etwa 6. Davon können aktuelle x86 Prozessoren nur träumen. Wie der Alpha EV8 in der Praxis ausgesehen hätte, konnte er ja leider nicht mehr zeigen.

Ergo ist alles > 3 völliger nonsens.
Sehe ich nicht so. Dafür gibt's auch keine Belege. Eher das Gegenteil ist der Fall. Aktuelle Intel Prozessoren und SMT sagen uns da nicht wirklich viel.

BDs schwache Singlethread-IPC kommt nicht von den 2-Fach Int-Cores
Das sagt auch niemand. Ich sehe das Konzept ja unabhängig von aktuellen x86 Prozessoren. Wobei man bei Bulldozer auch nicht wirklich von schwacher IPC sprechen kann. Das ist im Moment noch sehr abhängig vom Code.


Schonmal gedanken darüber gemacht das ein K10 mit 8 Kerne in 32nm kleiner als Bulldozer ausgefallen wäre und dabei hätte jeder Kern deutlich mehr Ressourcen als ein BD Thread...
So wie es ausschaut, wird Trinity mit 2 CUs ähnlich gross wie Llano mit 4 Kernen. Bei vergleichbarer Ausstattung (L3, Clock-Grid, Power-Gating, FMA, AVX, etc.pp) wäre ein K10 mit 8 Kernen sehr wahrscheinlich nicht kleiner ausgefallen als Orochi. Eventuell hätte man das Design etwas kompakter gestalten können, da man genügend Erfahrung mit K10 hat. Garantiert ist das aber auch nicht. Barcelona mit 6 Kernen war hier schon nicht ganz optimal. Und was die Performance betrifft, nun ja, wenn ich mir die Ergebnisse von HT4U anschaue, dann liegt der FX4 im Schnitt in Anwendungen bei voller Auslastung etwa 5% vorne und braucht zudem weniger Energie (zumindest bezüglich Linpack). Mittlerweile ist schon zu sehen, dass ein erneutes Aufwärmen der alten Architektur nicht sonderlich viel Sinn gemacht hätte. Weder kurzfristig, noch mittel- oder langfristig.
 
Zuletzt bearbeitet:
Zitat von Ge0rgy
3. Beim ILP des x86-Assemblercodes hat sich in den letzten 10 Jahren eher wenig getan. Es ist nunmal fakt dass in einer Architektur die relativ wenige REgister hat (verglichen mit RISC-Architekturen anderen fabrikats) und derart komplexe befehle quasi zwangsweise Abhängigkeiten entstehen, du findest einfach keien 8 Befehle in Folge die nichts miteinander zu tun haben, um sie parallel abzuarbeiten. Das Ganze geht soweit dass man zu erkennen versucht welche Loads und stores sich gegenseitig nicht behindern um dort noch abseits der Register OoO - Ausführung zu ermöglichen, Stichwort "Memory Disambiguation".
Es hat also nichts mit dem alter der Kernarchitektur zu tun sondern mit der Struktur des Codes.
Dass Multithreading zuwenig zum Einsatz kommt ist ein ganz anderes Problem.

Das ist so nicht richtig. Heutige x86-Microprozessoren sind Zwitter. Sie verarbeiten einen CISC-Befehlssatz. Dieser wird durch die Dekodiereinheiten in RISC-Befehle übersetzt. Durch die Registerrenaming-Technik stehen dem Prozessor auch über 100 Register zur Verfügung. Die Ausführung der Befehle erfolgt wie bei einem RISC-Prozessor. Natürlich versucht man Abhängigkeiten zwischen den Befehlen zu erkennen und zu umgehen, da echte Abhängikeiten zwischen 2 Befehlen zu langen Wartezeiten führen. Die Ausführung des zweiten Befehls muss solange warten bis Befehl 1 die Pipeline durchlaufen hat.
 
Danke für die Erklärung aber das war mir ohnehin schon klar,
Die Frage die sich mir stellt ist:
Wenn x86-Code im Mittel einen ILP größer 5 ergeben würde, warum baut Intel seit wie vielen Generationen 3-Fach OoO - Kerne?
Register Renaming hilft dir nur bedingt.
Der meiste assembler-code da draußen bzw. maschinencode ist so geschrieben dass er mindestens noch auf einem Pentium 3 läuft (i686), in 64bit-Geschmacksrichtung noch gewürzt durch SSE2-Befehlssatz. Das bedeutet aber dennoch dass sich Assembler-Schreibeling, genau wie Compiler nur auf das Vorhandensein einer Handvoll Register verlassen kann, x86 galt seit jeher als eine Architektur mit vergleichsweise wenig GP-Registern. Im Vergleich z.B. zum uralten Motorola 68000 und auch gegenüber PowerPC.
Das ist ein Erbe, das sich in Kompatibilität zu uralten Architekturen äußert, das x86 schon eine Weile mit sich herumschleppt, das sagt nichts über Alpha aus oder über befehlssatzerweiterungen. Die müssen zuerst mal verwendet werden. Wenn man sich dann anschaut wie wenig die Compiler mit auto-parallelisierung etc. anfangen können... nunja.
Wenn mir irgendjemand eine Publikation zeigen kann die bei modernem x86-Code eine ILP größer als 5 ausweist, nehm ich alles zurück. Solange das nicht der Fall ist, bleibe ich dabei dass alles größer 3 nonsens ist.
@Gruffi
Ich habe dich schon verstanden, ich sehe nur den Sinn darin nicht. Wenn 2-fach OoO nicht der Flaschenhals ist der die Performance deutlich einschränkt, bringt es auch nichts irgendwie breiter zu sein. Egal bei wie vielen Threads parallel. Gleichzeitig kann ich aber 4 kleine 2-fach Kerne viel einfacher debuggen als 1 großen. Die schwächere Performance bei teillast versucht man ja durch Turbomodi entsprechend zu kaschieren, das ist immernoch einfacher als dieser megacore.
Versteh mich incht falsch, toller Gedanke den du da hast...
Aber es ist bestimmt nciht so dass noch kein CPU-Ingineur je auf so eine idee gekommen wäre. Und es hat bestimmt einen Grund warum man sie nicht weiter verfolgt hat.
 
ILP grösser 5? Was soll das bedeuten? Meinst du IPC grösser 5?

Und wie kommst du auf 3-fach OoO? Intels Pipeline ist doch 4-fach OoO. Manche bezeichnen es aufgrund von MacroOp Fusion auch als 4+1.

Die Frage ist eher, warum baut überhaupt jemand 3- oder 4-fach superskalare Pipelines, wenn die IPC im Schnitt irgendwo bei 1 liegt. Die Antwort ist, weil IPC keine Konstante ist. Je nach Workload kann IPC komplett anders ausfallen. Und je breiter die Pipeline, umso besser kann man Spitzen nach oben abfangen. Daher kann man auch nicht einfach sagen, mehr als x-fach OoO ist Quatsch. Das hängt wie gesagt vom Code selbst ab und natürlich der ISA.


@Ge0rgy
2-fach OoO ist aber ein Flaschenhals, zumindest bei Teillast. Und nur, damit es keine Missverständnisse gibt, ich rede nicht speziell von Bulldozer. Der ist auch nicht 2-fach OoO. Debugging hin oder her, das darf keine Ausrede sein oder ein Hindernis für andere Ansätze. Softwareentwickler müssen sich schliesslich auch Lösungen einfallen lassen, um Anwendungen mit mehreren Threads debuggen zu können. Und wie gesagt, Turbo kommt auch bei diesem Konzept noch hinzu. Das ist also kein Ausgleich.
 
Naja, SandyBridge hat auch nur 3 Alus ;)
vielleicht meint er deswegen 3fach OoO - aber das verstehe ich auch nicht so recht, ist OoO wirklich nur auf die Dekoderanzahl bezogen?
 
Intel hat aber auch noch 3 Ports für Load/Store. Also ist es 6-fach OoO. *lol*

Die Superskalarität wird dadurch bestimmt, wie viele Instruktionen die gesamte Pipeline durchgängig theoretisch verarbeiten kann. Und das sind bei Intel, genauso wie bei Bulldozer, 4 für einen Thread.
 
Also bei Bulldozer hätte man dann die 2 ALUs, die 2 AGUs und die FPU (2x?).
Da der Dekoder aber nur 4 Instruktionen durchlassen kann, ist BD 4fach OoO. Habe ich das so richtig verstanden?
 
Zitat aus Onkels link.
...You can simply plug-and-play these home entertainment centers with its pre-installed Windows® 7 Home Premium (Windows® 8 ready) and numerous USB 2.0 and 3.0 ports to connect you wirelessly.

*kopfkratz Seit wann braucht USB Ports zum kabellos verbinden. Klar stick brauchen kein Kabel . Jedoch würde ich so auf die schnelle Wlan unter Wirelessly verstehen. ...

Zumindest mal mit mSATA vorhanden womit man dan auch schon wieder 2 Kabel spart.
 
@VlaDeZ

Genau genommen sind es AGLUs. Und die FPU besitzt 4 Ports, 2x FMAC (FP) und 2x MMX (Int). Es sind also Ressourcen für mehr als 4 Instruktionen vorhanden. Ansonsten ja, aufgrund der gesamten Breite der Pipeline ist es trotzdem 4-fach OoO.
 
In den Ultrabooks ist fast nie eine GPU (Anm. dedizierte)

So gesehen muss das fast eine echte Chance für Trinity sein. Wenn Intel nicht per extra Grafikchip nachbessern kann - weil einfach kein Platz dafür (egal in welcher Hinsicht, klassisch, thermisch, Akku-technisch), dann kann AMD Ultrabooks mit Eigenschaften (eben verhältnismäßig hohe Grafikleistung; "spielefähig") anbieten, die Intel nicht bieten kann.
Die Entwicklung wird interessant zu beobachten. Dabei kann man nur hoffen, dass AMD(/Gf) einerseits genug Volumen liefern kann, es vom Markt angenommen wird und die Piledriverkerne bei dementsprechender Leistungsaufnahme"ausreichend" CPU-Leistung liefern können.

LG
 
. Dabei kann man nur hoffen, dass AMD(/Gf) einerseits genug Volumen liefern kann
LG
Die Frage wäre für mich, will das GF überhaupt? Schliesslich hat sie Llano schon einiges gekostet. AMD konnte seine Marktanteile nicht steigern, also wozu noch mehr herstellen??
Da denke ich mal hat GF bessere Kunden, wie AMD.

Gibt es eigentlich schon Infos wieviel Kerne der Trinity haben soll?? Habe was von "nur" 2x gehört.
 
Aus dem "Appendix A" (=Slide 34) der Folien von Lisa Su:

"5. Battery life calculations using the “Pumori” reference design based on average power draw based on multiple benchmarks and usage scenarios. For Windows Idle calculations indicate 732 minutes (12:12 hours) as a resting metric; 421 minutes (7:01 hours) of DVD playback on Hollywood movie, 236 minutes (3:56 hours) of Blu-ray playback on Hollywood movie, and 205 minutes (3:25 hours) using 3D Mark ‘06 as an active metric.
Projections for the 2012 AMD Mainstream Platform Codename “Comal" assume a configuration of “Pumori” reference board, Trinity A8 35W 4C – highest
performance GPU, AMD A70M FCH, 2 x 2G DDR3 1600, 1366 x 768 eDP Panel / LED Backlight, HDD (SATA) – 250GB 5400rpm, 62Whr Battery Pack and
Windows 7 Home Premium


6. Testing done by AMD Performance Labs based on a 2012 Comal Reference Design Pumori. Results show 3D Mark Vantage for the A6 ULV 17W "Trinity“ to score
2355 3D marks. Testing on a Core i5 ULV 2537M (17W) measured 1158 3D marks. With an assumed 30% increase for the Ivy Bridge architecture, the projected
competitive score would be 1505 3D Marks. This provides the A6 ULV a 56% performance advantage over the projected Intel Ivory Bridge score. The 3D Mark
Vantage score for the A10 LV 25W APU is 3600
. This is 139% better than the projected Ivy Bridge score."


Meine Frage: taugen diese angeblichen 3D-Mark-Werte für Trintiy?

12h Battery für Mainstream-15"-Notebook mit 62Wh wäre auch nicht übel. BD mag für High-Performance schwach sein, aber im LowPower scheint AMD mit diesen neuen Cores fett auf zu drehen. Und da sehe ich die Zukunft. :)
 
Trinity Mobile: 17-35 Watt, die 45W-Version entfällt dieser Grafik zufolge. Dafür gibt's 2 LV-TDPs: 17 und 25 Watt. Letztere für Quads?
 
Zuletzt bearbeitet:
was soll der link der auf sich selber verlinkt?
 
Boah, müsst ihr immer schneller antworten, als ich meine verwursteten Posts korrigieren kann? ;D
Nu stimmt der Link.
 
Kleine Frage : ist es realistisch mit Trinity Notebooks Anfangs Juni zu rechnen?
Oder wie sieht das aktuell aus, weiss man da schon was konkretes?
 
Kleine Frage : ist es realistisch mit Trinity Notebooks Anfangs Juni zu rechnen?
Oder wie sieht das aktuell aus, weiss man da schon was konkretes?

Na ich hoffe doch, dass die Trinity-Systeme auf der Computex gezeigt werden und dann auch hoffentlich schnell verfügbar sind.
.
EDIT :
.

Was mir an dem 17-W-Trintiy gefällt: das Ding soll ja Quadcore sein und die gleiche Performance mit 17 Watt liefern, was vorher ein 35Watt-Llano geliefert hat. Für solche Ultrathins wäre das dann recht ordentlich. Zudem meint ja AMD, dass Trinity auch noch höhere Laufzeiten ermöglichen würde. Wenn Trinity das alles können sollte, dann gefällt mir das Ding doch wieder so richtig. Und dann kann man auch verschmerzen, wenn Trinity im Performance-Desktop nicht viel reißen kann. Macht aber meines Erachtens nix, weil diese Performance-PCs brauchen sowieso nur noch Gamer und Renderer. Und die kaufen sowieso nur noch Intel. Gut dass AMD das eingesehen hat.
 
Ja , so sieht's aus, jetzt sollten die Notebook Hersteller nur noch checken dass matte Displays gefragt sind und nicht der Spiegel Crap.
Wird endlich mal Zeit dass ich mein ca. 8 Jähriges Travelmate ablösen kann. :)

OT : naja, auch für die meisten Gamer reicht der Bulldozer locker aus, immer noch lange kein Grund ins Intel Lager zu wechseln.
Intel ist nur gut wenn man die längsten Balken will. ;)
 
Vorsicht BR, wozu gibt's die 25W-ULV-Variante? Wäre als Quad IMHO aber immernoch sparsam genug.

Und dass AMD-Notebooks gleich nach dem Launch ordentlich verfügbar werden, hab ich auch lange nicht erlebt. Da könnte Roary mal zeigen, dass sich was geändert hat - wenn nicht die OEMs und deren "Abmachungen mit Dritten" eine entscheidende Rolle spielen.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben Unten