Ausblick auf Bulldozer-Nachfolger: Vishera, Steamroller, Excavator

[2phil4u]

Ich glaube ja nicht, dass diese 5 ghz CPU rauskommt, denn wer kauft die, wenn die eh schon am Limit laeuft und Intels CPU schneller sind.
Wenn ich überlege, wie hoch damals die Preise für die 2 Kerner waren, mit ein bischen mehr Cache 500 Euro und der FX 1000 Euro und jetzt hauen sie total aufgemotzte FX für unter 200 Euro raus, naja.
Sie sollen halt einen Prozzi bauen, der zumindest 2 sehr starke Threads erlaubt und mit GDDR5 und Logik haben sie die Möglichkeit.
2 starke Kerne und der Rest halt Kleine, aber die Finanzen spielen halt bei AMD nicht mehr mit, keine grossen Experimente möglich.
Die haben soviel Geld verbrannt in den Jahren nach Core Duo, leider, denn sie könnten definitiv mehr, Fertigungsnachteil hin oder her, hat nicht jemand von AMD gemeint, dass kleinere Fertigungstechnologie heute überbewertet ist, weil bei der hohen Dichte der Transistoren sowieso alles schmilzt, wenn man alle Transistoren einschaltet.
Aber was kommt gerade von AMD ?
Irgendwelche low end APUs und die Teile für die Playstation.
Und alles immer schön verspaetet, so 6 Monate.
Intel kann sich schön ausruhen und in andere Nischen investieren.
Wenn sie Geld haetten, könnnten sie doch locker einen PC bauen, der Allinone alles ausnutzt, was geht und Intel die Stirn bieten.

[Schaffe89]

Der 3970X ist im CB 11.5 multithreaded 56% schneller als der 8350.

Könnte auch der weiternetwickelte Cinebench sein.
Aber ich bin diesmal realtiv sicher, dass das so kommen wird. Der Typ spielt mit ES Richland und mit ES Kaveri, Kaveri hat angeblich 25% mehr IPC, denke nicht dass der scheiße labert.

[=Floi=]

garantierte 5ghz wären schon nett.

[S940]

Könnte auch der weiternetwickelte Cinebench sein.Hmm möglich, hatte AMD das nicht letztens schon irgendwo verwendet? Da war doch mal was ..

Davon ab, hier schreibt einer von nem Test mit dem neuesten Cinema4D und ner eigenen Szene:
Auch Interessant:
Ich habe einmal mit der neuesten Version von Cinema 4D eine selbst erstellte Szene gerechnet. Einmal mit dem FX-8 und einmal mit dem i7. Die Resultate:
FX (4.1 GHz): 3829s
i7 (3.3 GHz): 4865s
wobei zu erwähnen ist, dass der FX immer zwischen 4.0 und 4.1 GHz und der i7 immer von 3.3-3.4 GHz schwankte. Die Resultate also eher besser für den FX aussehen.
Auf eine Leistung pro GHz gerechnet ergibt das:
FX: 15698.9s
i7: 16054.5s
Der FX hat also im taktnormierten Vergleich einen hauchdünnen Vorsprung vor dem i7. Finde es noch interessant, dass der FX ein schönes Stück zulegen kann gegenüber den Resultaten vom R11.5. Er kann also schon, man muss ihm nur den Richtigen Code vorsetzen. http://www.planet3dnow.de/vbulletin/showthread.php?p=4768989#post4768989

Wer will kanns ja mal umrechen und schauen, ob die Zahlen dann einigermaßen hinkämen ^^

Edit: Genauere CPU-Info weiter vorne,das ist ein mobile i7:
Intel Core i7-3720QM (Notebook)
Die Leistung des i7-3720QM ist für ein Notebook wirklich brachial, auch wenn ich gestehen muss, dass er im singlecore mit etwa 3.4-3.5 GHz lief (Turbo).http://www.planet3dnow.de/vbulletin/showthread.php?p=4766724#post4766724

[Hübie]

:uclap: Ein Vierkerne ohne SSE, kleinerem Cache und niedrigerem Takt verliert gegen Achtkerner mit SSE. Überraschung Leute. Ich habs längst aufgegeben. Der Bulldozer bzw. die Architektur taugt nicht. :frown:

[mrt]

Der i7 hat nicht nur SSE sondern auch AVX und SMT und ob 6 oder 8 MiB L3-Cache ist bei C4D eher nicht so wichtig. Es fehlt natürlich Takt gegenüber den Desktopmodellen.
Soll natürlich nicht heißen, dass die Werte stimmen müssen. ;)

[S940]

Der i7 hat nicht nur SSE sondern auch AVX und SMT und ob 6 oder 8 MiB L3-Cache ist bei C4D eher nicht so wichtig. Es fehlt natürlich Takt gegenüber den Desktopmodellen.
Jupp, da hat Hübie wohl bei der falschen CPU geschaut. Hier der ARK-Link:
http://ark.intel.com/products/64891/Intel-Core-i7-3720QM-Processor-6M-Cache-up-to-3_60-GHz

[Knuddelbearli]

es sind 8 Threads vs 8 Threads

spätestens mit Haswell wo SMT wohl im Idealfall über 50%, fast 60% Mehrperformance bringt, muss man aufhören 4 Kern + SMT als 4 Kerner zu betrachten

[Ronny145]

Einen Core i7 ohne SSE möchte ich sehen. Oder überhaupt einen Vierkerner von Intel ohne SSE. Wobei das natürlich schon pervers ist, wenn ein 45W Notebook Modell gegen ein 125W Desktop Modell antreten muss. Für mich ist das keine Leistung. Mit 8 Kernen und 4+ Ghz müssten die Bulldozer Core i7 in stark multithreaded Benchmarks mit 50% wegdonnern. Wäre dem Verbrauch und der Chip Größe schon eher angemessen. Dass Bulldozer im neuen Cinebench stärker zulegt, ist sowieso schon länger bekannt. Fragt sich nur, wann es endlich ein neues Cinebench gibt. Die Cinebench r13 Benchmarks sind mittlerweile 9 Monate alt.

[Hübie]

Morgen. Ich meinte SSE 4.1 & 4.2 aber ich seh gerade das der 3720qm das auch hat. Keine Ahnung was ich da geguckt hab ...war spät ;D

[S940]

Morgen. Ich meinte SSE 4.1 & 4.2 aber ich seh gerade das der 3720qm das auch hat. Keine Ahnung was ich da geguckt hab ...war spät ;D
Faustregel bei Intel: ein i7 hat in der Regel alles was das Intel-Regal an Features hergibt ;-)
(Unterschiede nur bei Kleinigkeiten bei den K- und Nicht-K-Modellen).

[Hübie]

Okay habs gespeichert. Bin bei deren mobile-Chips nicht so auf dem laufenden. Momentan guckt ja auch jeder zu Atom / SoCs ;)
Dennoch hinkt der Vergleich der beiden CPUs.

[S940]

Okay habs gespeichert. Bin bei deren mobile-Chips nicht so auf dem laufenden. Momentan guckt ja auch jeder zu Atom / SoCs ;)
Dennoch hinkt der Vergleich der beiden CPUs.
Ich seh da keine großen Probleme. Das einzige was "merkwürdig" ist, ist die deutlich unterschiedliche Verlustleistung der beiden Chips, aber bei ner Leistungsbetrachtung ist das unwichtig.

[robbitop]

The best part of interview came in a nice little tidbit about core performance while discussing how much market and application awareness plays a role in core design. Many things are incremental, one of which is legacy performance on new designs. Jim confidently stated AMD are on track to catch up on high performance core, a function of design improvements. We couldn't pin down a timeline for this, but with a time scale of two years core design and one year build and test, it's not going to be immediate. My expectation is 2015.


http://www.rage3d.com/articles/hardware/amd_worldcast/

AMD will in ~3 Jahren wieder im High End CPU Bereich konkurrenzfähig sein. Kein Zeichen vom Abstoßen der großen CPUs... da bin ich erleichtert...

Wenn ich das mit der Geschichte über AMD auf arstechnica (http://arstechnica.com/business/2013/04/the-rise-and-fall-of-amd-how-an-underdog-stuck-it-to-intel/) kombiniere kommt folgendes dabei heraus:

- AMD hat schon immer recht träge agiert
- war immer zufrieden mit Platz 2
- hat viele Fehlentscheidungen getroffen
- wurde träger und träger (deutlich träger als es für eine Firma dieser Mitarbeiterzahl üblich ist)
- AMD war nur "gut", als Intel gerade "schlecht" war

Offensichtlich hat Rory den Laden jetzt stark konsolidiert und aufgeräumt. Im Anschluss hat er ein Team aus (seiner Meinung nach) sehr guten Leuten zusammengestellt, die den Laden wieder konkurrenzfähig machen sollen und neu aufstellen sollen. Mehr Effizienz in der Entwicklung.

Die Aussage von Keller klingt so als hätte man vor einer kurzen Weile angefangen, ein neues? Design zu entwerfen. Es könnte also in 3 Jahren, sofern AMD sich hält, wieder etwas anständiges kommen. Der Bulldozeransatz scheint nicht der Richtige zu sein.

Was sie natürlich nie kompensieren können, ist der gewaltige Fertigungsnachteil...

[dildo4u]

x86 High-End wird aber vermutlich eher kleiner werden,schade das es keine Infos zu Smartphone SOC's gibt.Qualcomm mach ja schon Heute 5 mal so viel Umsatz wie AMD also wirklich zweiter sind sie schon lange nicht mehr.

[S940]

Jo hatte ich auch schon gesehen, aber die 3 Jahres-Frist glaub ich nicht.

Das Steamroller-Design ist schon ein großer Schritt, da wird dick verbreitert und angebaut. Gut möglich, dass er nur das meinte, nicht mehr. Außerdem ist Excavator schon länger allein auf weiter Flur der Roadmap. Aber gut - Roadmaps machen sich seit R.Read sowieso ziemlich rar.

[robbitop]

x86 High-End wird aber vermutlich eher kleiner werden,schade das es keine Infos zu Smartphone SOC's gibt.Qualcomm mach ja schon Heute 5 mal so viel Umsatz wie AMD also wirklich zweiter sind sie schon lange nicht mehr.
Umsatz ist irrelevant. Gewinn ist relevant. Das blöde bei SFF ist, dass man kaum Gewinnspanne hat bei den Dingern. Da muss man schon verdammt viele davon verkaufen. Es sind nicht grundlos schon einige große SFF IHVs aus dem Geschäft ausgestiegen (ST Ericson, Texas Instruments etc).
SFF ist auf jeden Fall alles andere als einfaches Geld.

[robbitop]

Jo hatte ich auch schon gesehen, aber die 3 Jahres-Frist glaub ich nicht.
Du glaubst Jim Keller von AMD nicht? Wem glaubst du dann? :)



Das Steamroller-Design ist schon ein großer Schritt, da wird dick verbreitert und angebaut. Gut möglich, dass er nur das meinte, nicht mehr. Außerdem ist Excavator schon länger allein auf weiter Flur der Roadmap. Aber gut - Roadmaps machen sich seit R.Read sowieso ziemlich rar.
Vieleicht hat man einfach eingesehen, dass die Erweiterung von Bulldozer nichts besseres sind als Wiederbelebung an einem toten Patienten.
Natürlich spuckt man nicht von heute auf morgen ein neues Design aus. Man braucht etwas für den Übergang. Also belebt man den toten Patienten so lange noch wieder.
Analog dazu hat Intel ja auch sehr lange am Netburst festgehalten, um die Zeit bis zum Conroe zu überbrücken. Der P4 wurde durch 3 Fullnodeshrinks geprügelt und durch mind. 2x größere µ-Archänderungen. Richtig konkurrenzfähig war er gegen den Athlon 64 nie - aber fast. Und das genügte bis, das Nachfolgerdesign fertig war.

[HOT]

Das erklärt die Sache etwas. Es lohnt einfach keine große Server-CPU mehr in 28nm-SHP aufzulegen. Die Entwicklung dürfte in Richtung einer neuen Fertigung gehen, die jenseits der 32/28nm PDSOI/planar-Prozesse laufen wird. Das wird wohl irgend ein FinFET-Prozess sein, 20nm oder darunter, auf den man es mit dem komplett neuen Design abgesehen hat. Man muss eh das Rad neu erfinden, wenn man einen solchen Prozesswechsel anstrebt, also verschwendet man keine unnötigen Ressourcen für die alte, überteuerte und auslaufende SHP-Fertigung. Es ist aber sehr beruhigend, dass AMD am Ball bleibt.

[fondness]

Du glaubst Jim Keller von AMD nicht? Wem glaubst du dann? :)


Hast du den Text überhaupt richtig gelesen? Keller nennt mit keinem Wort einen Termin, die drei Jahre sind reine Spekulation des Autors des Artikels. Es wird auch nicht erwähnt ob man noch mal den Fehler macht und mit viel Aufwand versucht das Rad neu zu erfinden oder ob diese Chips weiter auf Bulldozer-Basis basieren werden.

[S940]

Hast du den Text überhaupt richtig gelesen? Keller nennt mit keinem Wort einen Termin, die drei Jahre sind reine Spekulation des Autors des Artikels.
Genau. Keller sagt nur, dass sie aufholen werden. Wann, sagt er nicht.

Zum BD-Design:
Es bleibt auch bei Steamroller der große Vorteil der gemeinsamen Sprungvorhersagelogik. Da kann man weiter klotzen. Denke also, dass sie das beibehalten werden. Die restlichen Einheiten werden stark verbreitert, die AGLUs bekommen sicherlich auch noch mehr Fähigkeiten, so dass am Ende anstatt eines 2x2 Designs im Optimalfall ein 2x4 Design rauskommt. Dann noch die ganzen Verbesserungen an den Caches .. das wird schon was reißen.

Bei Excavator noch nen µOp-Cache rein, den Fetch vielleicht noch auf 2x32byte (512bit) aufbohren und vielelicht nocht 256bit-FMACs ... fertig, wobei das mit dem µOp-Cache aber wohl alles andere als trivial ist.

[G 80]

Naja die letzten 2x als sie wieder Konkurrenzfähig werden wollten kam Phantom 1 und Sandkastenschaufel-FX. (FX = FornaX ;D)

Phenom 2 und Vishera war ganz brauchbar (bzw. sogar goil als X6) bzw. nicht mehr ganz so schlimm (Vi), von daher würde ich meine Hoffnungen auf den "Fix" vom "wieder Konkurrenzfähig" richten. ;D

[HOT]

Man wird sicherlich bei der BD-Basis bleiben. Eine neue Architektur, die die K7-Technik mit integriert oder gar darauf aufbaut ist zwar auch denkbar, aber dafür ist es sicherlich noch zu früh. Aufgrund der auslaufenden SHP-Fertigung und das Umstellen auf komplett neue Prozesse muss man aber sowieso einen komplett neuen BD aufbauen. Die Frage ist, was ist Excavator. Lt. Roadmap ist das dann die komplett neue Architektur (die steilen Performancebalken usw). Das könnte auch mit 2015 (vermutlich zum Ende hin) gemeint sein.

[S940]

Aufgrund der auslaufenden SHP-Fertigung und das Umstellen auf komplett neue Prozesse muss man aber sowieso einen komplett neuen BD aufbauen.
Wie meinst Du das? Shrinken ist doch nix Kompliziertes ...
Die Frage ist, was ist Excavator. Lt. Roadmap ist das dann die komplett neue Architektur (die steilen Performancebalken usw). Das könnte auch mit 2015 (vermutlich zum Ende hin) gemeint sein.Du meinst das Ansteigen der exponentiellen Kurve? Von der halte ich nichts, reines Photogeshoppe mMn. Auf den ersten Folien wars noch regelmäßig / linear.

[Knuddelbearli]

Shrinken wenn sich die Prozessart ändert ist sehrwohl nichts einfaches

[HOT]

kein PDSOI mehr, dafür FinFETs - kein Gate-first mehr dafür Gate-last, evtl. kein high-herformance mehr sondern evtl. SLP, vielleicht integration von fdSOI... der neue Prozess muss wirklich völlig anders sein als das was jetzt verwendet wird. Allein wegen der FinFETs muss man BD sicherlich recht stark verändern. Das kann man am besten direkt mit einem völlig neuen BD-Design verbinden.

[robbitop]

Wobei Ivy Bridge jetzt von der µ-Arch auch nicht so anders ist als Sandy Bridge. (22 nm und FinFETs)

[mrt]

Vieleicht hat man einfach eingesehen, dass die Erweiterung von Bulldozer nichts besseres sind als Wiederbelebung an einem toten Patienten.
Natürlich spuckt man nicht von heute auf morgen ein neues Design aus. Man braucht etwas für den Übergang. Also belebt man den toten Patienten so lange noch wieder.
Äh wie sieht deiner Meinung nach die Entwicklung von Prozessoren aus? Glaubst du, dass zB Core2 ein kompletter Neuanfang war?

- AMD war nur "gut", als Intel gerade "schlecht" war
Gegenbeispiel: K7

[anddill]

Auch wenn Du den zugrunde liegenden Logikplan bzw. Schaltplan beibehältst wird das ja doch ein komplett anderes Chipdesign wenn der Prozess so umgekrempelt wird. Aber das sollten doch die heutigen Synthese-Tools eigentlich recht fix ausspucken können?

[robbitop]

Äh wie sieht deiner Meinung nach die Entwicklung von Prozessoren aus? Glaubst du, dass zB Core2 ein kompletter Neuanfang war?
Was ist schon ein kompletter Neuanfang? Das müsste man mal definieren. Core 2 hat sicher vieles vom Pentium M (und damit auch vom Pentium 3) und vom Netburst mitgenommen.
Insgesamt wurde dort aber auch vieles verändert (breiteres Front End, andere Pipelinelänge, Cachegrößen, Cacheanbindung, SMT, mehr Execution Units etc).
War Bulldozer ein kompletter Neuanfang?

Das ist immer eine Frage der Definition. Wenn man die Schwelle mit der Definition "Neuanfang" jetzt nicht ganz so pinschieddirg sieht, war BD eine neue µ-Arch. Und die ging - zumindest bis jetzt absolut in die falsche Richtung. IPC sank, Takt stieg. Dass das nicht der richtige Weg ist, weiß man doch seit dem P4. Die Prozesse machen einem bei steigendem Takt nunmal idR einen Strich durch die Rechnung.
AMD hat IPC von > 50 % pro Kern aufzuholen. Intel fügt pro Zyklus immer mehr IPC hinzu. Ob das durch reine Updates der µ-Arch aufholbar ist, wage ich mal zu bezweifeln.
Vieleicht wäre es gesünder, eine andere Grund µ-Arch zu wählen.


Gegenbeispiel: K7
Der K7 war der erste richtige Schritt nach vorn. Aber Intel war mit dem Pentium 3 jetzt nicht so weit vom K7 entfernt. Seit Northwood, war der K7 sogar langsamer als Netburst. Der K8 musste also her.

[Skysnake]

Auch wenn Du den zugrunde liegenden Logikplan bzw. Schaltplan beibehältst wird das ja doch ein komplett anderes Chipdesign wenn der Prozess so umgekrempelt wird. Aber das sollten doch die heutigen Synthese-Tools eigentlich recht fix ausspucken können?
Klar, in einem Tag bis eher einer Woche ist das echt fix gemacht :freak:

Die Simulationen dauern echt ewig. Ok, AMD, Intel und nVidia werden nen kleinen Cluster dastehen haben, mit denen es schneller geht, aber ihre Designs sind auch größer und kritischer, als das was ich kenne.

Also "mal kurz" ist da nichts gemacht.

[mrt]

@robbitop
Bei BD hat man schon sehr tief angefangen umzukrempeln und neue Blöcke zu entwickeln. Mit leeren Verilog/VHDL-Dateien hat man sicher nicht angefangen. Mein Problem am gesagten ist aber ein anderes: Ich seh die Parallele zu P4 nicht wirklich. Das Problem des P4 waren eher Dinge wie Replay, sowas hat BD aber nicht. Bei letzterem krankts eher an den Decodern (+Fetch) und das kann man am vorhandenen Code ändern ohne neuanzufangen. Für mich ist ein BD-Abkömmling mit getrennten Frontend + Mops-Cache (Intel µop-Cache) etc noch immer ein BD-Abkömmling, selbst mit verkürzter Pipeline (nicht nötig, so lang ist die gar nicht, Sandy/ivy haben keine sonderlich viel kürzere). Takt in der Nähe des Design/Prozesslimits brauchen BD und PD ja nur wegen fehlender IPC (u.a. wegen dem Frontend). Mal abgesehen davon, dass BD kein rein auf Takt ausgelegtes Design wie z.B. Netburst ist, sind hohe Taktraten aber per se kein Problem, siehe z.B. IBMs Power.

K7 war nicht selten schneller als P3 und P4 am Anfang und auch später konnte Barton noch gut mithalten mit Northwood C. IMO ist "ein Schritt" ein wenig untertrieben, es war eher DER Schritt. Man sollte dabei nicht vergessen, dass AMD schon damals einen Fertigungsnachteil hatte.

[robbitop]

Bulldozer (ich meine die µ-Arch - also auch alle Nachkömmlinge) hat kleine, langsame L1 Caches, große langsame L2 Caches, zumindest bis Piledriver ein zu schwaches Front-End und nur eine sehr schmale Executioneinheit. Und vermutlich noch tausend andere Dinge, an denen das Ding krankt.
Ich denke, vieles ist dem CMT Konzept geschuldet, das aber nicht aufgeht.
Wenn man schonmal neu angefangen hat, dann hätte man gleich ein Fundament wählen sollen, welches die IPC deutlich steigert und nicht eines, bei der man erstmal 2x Updatezyklen benötigt, um gleichzuziehen.

AMD hatte schon immer einen Fertigungsnachteil - wobei dieser nie so groß war, wie er es heute ist. Barton kam sehr spät.

[mrt]

Der L1 ist nur ein Lesecache, wo siehst du da ein Problem mit der Größe? Ich seh keines. Der L2 ist ein wenig groß und langsam ausgefallen, ja, das kostet insbesondere bei Spielen etwas, den zu verkleinern war sogar von AMD vorgesehen. Durch den eher langsamen L3 hat man sich das bisher wohl gespart, zuerst muss der L3 schneller werden bzw die APUs erst mal einen bekommen, sonst wirds eher langsamer (geringere Hitrate des L2)
Ausführungsresourcen? Mehr als 2 Ops pro Zyklus und Thread haut auch ein Intel nicht raus und das ist dank gemeinsamen Scheduler ja auch einfacher erweiterbar, machte Intel ja grad bei Haswell (da wegen SMT). Wobei es bei AMD gar kein zusätzlich Port braucht, der Scheduler muss ja schon jetzt mit den AGLUs umgehen, einfach die aufbohren (das ist auch geplant).
Bei AMDs beschränkten Resourcen fürchte ich, dass es bei denen ohne 2-3 Aktualisierungen nicht gehen wird. Neben den Katzen und BD ist kein Platz für einen Dritten, der 5+ Jahre Resourcen bindet.

[robbitop]

Intel macht bestimmt nicht aus Spaß den L1 größer (und dabei schneller) als bei Bulldozer. Schreiben muss man sicherlich auch mal. Wird dann nur in den L2 geschrieben bei BD? Das kostet sicher auch wieder Leistung.

Das mit den maximal 2 Ops pro Zyklus behauptet jeder. Und dennoch hatte der K7/8/10, Core 2, Core -i ein 3 fach breites Design. Seit Core 2 sogar 4x Decoder. Das haben die sicher auch nicht aus Spaß gemacht, wenn auch ein 2 fach breites Design reichen würde. (alles oben drauf bringt vermutlich nur wenig, aber bestimmt nicht "nichts")
Vieleicht gibt es ein paar Peaks, die den Durchschnitt dann etwas anheben. Hast du nur 2 issue, kann dein Durchschnitt ja nur unter 2 liegen. Hast du mehr, kannst du den Durchschnitt durch Ausreißer nach oben erhöhen.
Außerdem ist SMT eine nette, Sache, die mit wenig Kernfläche eine nette Leistungssteigerung bietet.

Bei Bulldozer (und dessen Nachkömmlingen) muss es schon substanziell hängen. Ansonsten verliert man keine 50 % IPC.

[mrt]

Intel macht bestimmt nicht aus Spaß den L1 größer (und dabei schneller) als bei Bulldozer. Schreiben muss man sicherlich auch mal. Wird dann nur in den L2 geschrieben bei BD? Das kostet sicher auch wieder Leistung.
Der muss bei Haswell auch 2 Threads bedienen, bei BD nicht. Ja das ist ein reiner Lesecache und ja das kostet etwas Leistung, das Design ist aber schon darauf ausgelegt. Ein schneller L2 hilft da und MUSS nach Steamroller eigentlich kommen. (IMO)
Das mit den maximal 2 Ops pro Zyklus behauptet jeder. Und dennoch hatte der K7/8/10, Core 2, Core -i ein 3 fach breites Design. Seit Core 2 sogar 4x Decoder. Das haben die sicher auch nicht aus Spaß gemacht, wenn auch ein 2 fach breites Design reichen würde. (alles oben drauf bringt vermutlich nur wenig, aber bestimmt nicht "nichts")
Vieleicht gibt es ein paar Peaks, die den Durchschnitt dann etwas anheben. Hast du nur 2 issue, kann dein Durchschnitt ja nur unter 2 liegen. Hast du mehr, kannst du den Durchschnitt durch Ausreißer nach oben erhöhen.
Das stimmt zwar, aber überschätzen sollte man das nicht. Wenn man die Pipeline gut auslastet, erreicht man schon ~ 90% eines 3+fach superskalarem Design.
Ich hab übrigens nicht geschrieben, dass es nichts bringt, würd ich auch nie.
Außerdem ist SMT eine nette, Sache, die mit wenig Kernfläche eine nette Leistungssteigerung bietet.
Ja, es ist aber "nur" eine von mehreren Möglichkeiten ein leistungsfähiges Design auf die Beine zu stellen.
Bei Bulldozer (und dessen Nachkömmlingen) muss es schon substanziell hängen. Ansonsten verliert man keine 50 % IPC.
Da gibts auch sehr viele Kleinigkeiten, PD ist fast aufdem Niveau eines Athlon II. Bei Spielen bis zu 22% mehr Leistung :freak: Das bei den Änderungen eher viel. Der Ur-BD war IMO noch nicht reif genug und wäre wohl nicht veröffentlicht worden, wenn AMD genug Resourcen für K10.5+ (für den X6 hätte es natürlich einen 32nm Nachfolger gebraucht), Katzen und BD gehabt hätte.

[S940]

Wobei Ivy Bridge jetzt von der µ-Arch auch nicht so anders ist als Sandy Bridge. (22 nm und FinFETs)
22nm und Finfet sind jetzt aber keine Charakteristika für µArch, da sind wir uns einig, oder?
Shrinken wenn sich die Prozessart ändert ist sehrwohl nichts einfaches
Gibts denn nen Shrink, wo sich die Prozessart nicht ändert?
Verglichen mit "alles neu macht der Mai" ist es auf alle Fälle trivial. Gate First/Last .. geschenkt, ist lästig ja, aber das schaffen die Ingenieure schon. Kostet nur Zeit/Geld. Deswegen will der CEO ja auf Standardprozesse wechseln.
kein PDSOI mehr, dafür FinFETs - kein Gate-first mehr dafür Gate-last, evtl. kein high-herformance mehr sondern evtl. SLP, vielleicht integration von fdSOI... der neue Prozess muss wirklich völlig anders sein als das was jetzt verwendet wird. Allein wegen der FinFETs muss man BD sicherlich recht stark verändern. Das kann man am besten direkt mit einem völlig neuen BD-Design verbinden.
Jein ... schau Dirs bei Intel an .. tick-tock ... warum? Weil ein neuer Hestellungs-Prozess *und* ne neue µArch doppelt soviele Fehlerquellen liefert. AMD hat das letzte Mal bei Llano und BDv1 ne neue µArch und nen neuen Prozess eingeführt ... beides war sch....lecht.
Das Maximale was mMn sinnvoll ist, ist Feintuning. Größere Puffer, mehr Register, etc. pp. Keine tiefgreifenden Verbesserungen.
Aktuell haben wir doch schon mal wieder Kaveri, der nicht lief. Neuer 28nm Prozess .. neue Steamrollerkerne -> Essig ists. Die Rev. B muss es richten.

Nachdem AMD dazu überzugehen scheint, immer ne Rev. A verkaufen zu wollen, werden sie da in Zukunft eher kleinere Schritte machen. Dafür halt jedes Jahr was Neues.
Intel macht bestimmt nicht aus Spaß den L1 größer (und dabei schneller) als bei Bulldozer. Schreiben muss man sicherlich auch mal. Wird dann nur in den L2 geschrieben bei BD? Das kostet sicher auch wieder Leistung.Kostet alles, ist halt die Frage, wieviel ^^

Das mit den maximal 2 Ops pro Zyklus behauptet jeder. Und dennoch hatte der K7/8/10, Core 2, Core -i ein 3 fach breites Design. Seit Core 2 sogar 4x Decoder. Das haben die sicher auch nicht aus Spaß gemacht, wenn auch ein 2 fach breites Design reichen würde. (alles oben drauf bringt vermutlich nur wenig, aber bestimmt nicht "nichts")
Vieleicht gibt es ein paar Peaks, die den Durchschnitt dann etwas anheben. Hast du nur 2 issue, kann dein Durchschnitt ja nur unter 2 liegen. Hast du mehr, kannst du den Durchschnitt durch Ausreißer nach oben erhöhen.
Außerdem ist SMT eine nette, Sache, die mit wenig Kernfläche eine nette Leistungssteigerung bietet.Richtig, aber für die Peaks hat AMD seine AGLUs vorgesehen, damit kommt man im Notfall dann auch über 2. Mal schauen, was die Steamroller AGLUs alles können und wie das klappen wird.

[robbitop]

Die bisherigen AGLUs konnten praktisch nichs (ein winziger Bruchteil der x86er Befehle). Soll da noch deutlich was dazu kommen? Hauptsächlich machen die sicherlich store/load oder?

[S940]

Die bisherigen AGLUs konnten praktisch nichs (ein winziger Bruchteil der x86er Befehle). Soll da noch deutlich was dazu kommen? Hauptsächlich machen die sicherlich store/load oder?
Ne normale AGu berechnet die Adressen für Ops mit Speicheradresse. Falls aber gerade nur Ops berechnet werden, die nur die Register beackern, liegen die AGUs demnach brach. Die könnten dann was "richtiges" rechnen (falls sie dafür nicht auch ne Adresse brauchen ^^).

Bei den Piledriver mit 20h waren schon immerhin 5 Befehle vorgesehen, die die AGLUs können sollen:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1328302051

Bei Steamroller gehe ich davon aus, dass sie das dort noch weiter aufgebohrt haben. Macht mit den fetten Decodern ja noch mehr Sinn.

[mrt]

Geplant wars eigentlich schon, bei AMD kann man sich ja nicht mehr sicher sein was noch kommt und was nicht.
AGU = address generation unit, Load/Store sind eigene Einheiten.

[anddill]

Klar, in einem Tag bis eher einer Woche ist das echt fix gemacht :freak:

Die Simulationen dauern echt ewig. Ok, AMD, Intel und nVidia werden nen kleinen Cluster dastehen haben, mit denen es schneller geht, aber ihre Designs sind auch größer und kritischer, als das was ich kenne.

Also "mal kurz" ist da nichts gemacht.

Mir war schon klar daß wir hier nicht von 42 Minuten reden, wenn von Jahren Entwicklung die Rede ist. Aber halt auch nicht von einem Jahr für die Berechnung eines Designs.

[Skysnake]

Dir ist aber schon klar, das da dann kein "fertiges" Design dann raus kommt, sondern meist:

Es gab 324 Timeing violations.

10>x µs
100>y ns
...

Und selbst wenn du die Tools mit den gleichen Daten startest, kann das eine mal ein funktionsfähiges Desaign und das nächste mal eins mit Fehlern bei rum kommen. Die Dinger laufen nicht deterministisch, und lösen das Problem auch nicht vollständig, sondern nur näherungsweise.

Timeings zu treffen ist gar nicht so trivial. Da muss man schon wissen, wo man wie und vor allem welche Constraints man setzt.

Ohne ein Gefühl für die Sache bist du da ziemlich verloren. Vor allem kann eine "Verbesserung" auch ein Schuss nach hinten sein. Man muss also auch alles im Blick haben, wie sich welche Änderung auswirkt, sonst übersieht man schnell etwas, und rennt im Kreis...

[robbitop]

Ne normale AGu berechnet die Adressen für Ops mit Speicheradresse. Falls aber gerade nur Ops berechnet werden, die nur die Register beackern, liegen die AGUs demnach brach. Die könnten dann was "richtiges" rechnen (falls sie dafür nicht auch ne Adresse brauchen ^^).

Bei den Piledriver mit 20h waren schon immerhin 5 Befehle vorgesehen, die die AGLUs können sollen:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1328302051

Bei Steamroller gehe ich davon aus, dass sie das dort noch weiter aufgebohrt haben. Macht mit den fetten Decodern ja noch mehr Sinn.
5 Befehle - das ist bezogen auf die Gesamtsumme an x86 Befehlen praktisch gar nichts.
Da müsste man schon deutlich aufgekohlt haben, damit das etwas bringt.

[S940]

5 Befehle - das ist bezogen auf die Gesamtsumme an x86 Befehlen praktisch gar nichts.
Da müsste man schon deutlich aufgekohlt haben, damit das etwas bringt.Jo, aber wenn da Wald- und Wieseninstruktionen drankommen wie z.B. ADD/SUB, die häufig verwendet werden, kann man da schon was reißen.
Nicht vergessen, es geht nur um die Peaks.

[mczak]

5 Befehle - das ist bezogen auf die Gesamtsumme an x86 Befehlen praktisch gar nichts.
Da müsste man schon deutlich aufgekohlt haben, damit das etwas bringt.
Na also soviele Instruktionen brauchst du nicht, denn nur relativ wenige Befehle werden wirklich häufig verwendet. IIRC sind z.B. mov's gut für üblicherweise etwa 10% aller Befehle, wenn du die also in der AGU ausführen kannst und dafür die ALUs was sinnvolleres tun können bringt das wohl schon messbar was (und mov soll ja einer der Befehle sein die in der AGU ausgeführt werden können). Normales Add wäre z.B ein weiterer häufiger Kandidat (wobei xadd und die anderen in dieser Fünferliste gelisteten allesamt zu den raren Spezies gehören mit Ausnahme eben von mov).
Wobei eigentlich könnte man die mov's statt auszuführen auch vom renamer erledigen lassen (zumindest die BD-simd-Einheit kann das auch schon).

[HOT]

[...]

Jein ... schau Dirs bei Intel an .. tick-tock ... warum? Weil ein neuer Hestellungs-Prozess *und* ne neue µArch doppelt soviele Fehlerquellen liefert. AMD hat das letzte Mal bei Llano und BDv1 ne neue µArch und nen neuen Prozess eingeführt ... beides war sch....lecht.
Das Maximale was mMn sinnvoll ist, ist Feintuning. Größere Puffer, mehr Register, etc. pp. Keine tiefgreifenden Verbesserungen.
Aktuell haben wir doch schon mal wieder Kaveri, der nicht lief. Neuer 28nm Prozess .. neue Steamrollerkerne -> Essig ists. Die Rev. B muss es richten.

Schon klar, dass es schwieriger ist. Dennoch ist das jetzt eine besondere Situation, in der es besonders viel Sinn ergibt eine neue Architektur mit einem neuen Prozess zu kombinieren, da diese dann aufeinander abgestimmt werden können. Ich halte es für sinnlos teuer, die neue Arch auf 28nm SHP aufzulegen um dann nochmal alles umzustossen für den Prozesssprung, der da bervorsteht. Bei einem einfachen Shrink würde ich dir zustimmen, wenn AMD Geld für Experimente hätte, dann auch, aber da sich der Prozess so stark verzögert muss man halt in den saueren Apfel beißen und gleich zum Excavator auf 20nm FinFET springen. Die einzige Option, die ich da noch sehe, wäre eine SR (2.0?)-APU mit moderaten Taktraten auf 20nm zu shrinken um den Prozess einzufahren ein halbes Jahr vorher oder so. Ist ja garnicht nötig SR zu shrinken, der neue Prozess wäre dann ja auch für Bobcat-Derivate interessant - man könnte ihn mit einer Custom APU einfahren und auch die Jaguar-Nachfolgearchitektur direkt auf dem neuen Prozess bringen.
Sicherlich kostet dieser große Schritt eine Menge Zeit, aber es geht ja jetzt auch schon eine ganze Zeit ins Land bis Ende 2015 und das ohne neue High-End-Produkte (es sei denn meine Kaveri-MCM-Theorie greift).

Nachdem AMD dazu überzugehen scheint, immer ne Rev. A verkaufen zu wollen, werden sie da in Zukunft eher kleinere Schritte machen. Dafür halt jedes Jahr was Neues.
Kostet alles, ist halt die Frage, wieviel ^^
Richtig, aber für die Peaks hat AMD seine AGLUs vorgesehen, damit kommt man im Notfall dann auch über 2. Mal schauen, was die Steamroller AGLUs alles können und wie das klappen wird.
Das wird keinen Bestand haben mMn. AMD wird sicherlich zu längerfristiger Entwicklung im High-End-Bereich zurückgehen. Das ist noch Dirk Meyer-Strategie mit der Rev.A-Politik und/oder einfach aus der Not geboren, da man dringend neue Produkte brauchte. Mit dem offensichtlich guten Kabini/Temash und den Custom-APUs hat man sich jetzt Luft verschafft, um die neuen Produkte reifen zu lassen.

[anddill]

Dir ist aber schon klar, das da dann kein "fertiges" Design dann raus kommt, sondern meist:

...

Nein, ist mir nicht klar. Meine Kenntnisse in diesem Bereich sind dazu zu begrenzt. Ich weiß wie sowas im Detail funktioniert, also wie zB. eine einfache Logikzelle aussieht nachdem sie im Chip realisiert wurde.
Was schon sehr interessant ist, da einige der seltsamen Schaltungsdesigns, die auf dem Papier mit klassischen Schaltzeichen dargestellt unnötig kompliziert aussehen sich in der Praxis in ein paar dotierte Inseln und zwei Lagen Kupfer auflösen. Und plötzlich macht es Sinn.
Aber wie man von so einer Zelle zu den schicken bunten Blockschaltbildern in den PR-Folien kommt kann ich leider nicht nachvollziehen.

[Skysnake]

Das ist nur noch eine logische Abstraktion.

Du programmierst da ja irgend welchen VHDL Code, und versiehst den mit den entsprechenden Constraints. Die Lokalisierung kommt allein von den Constraints, und die Blockschaltbilder sind nur noch grobe Abstraktionen der sinngemäßen Funktionseinheiten, die eine grobe Aufteilung auf dem Chip darstellt. Real können die einzelnen Funktionsblöcke aber durchaus komplett verwaschen sein und ineinander übergehen. Das ist eigentlich sogar relativ normal. Je stärker die Lokalisierung ist, desto stärker sind die Constraints.

Ein Kollege von mir hat z.B. das Problem, dass der Placer ganze Funktionsblöcke einfach mal an komplett! andere Stellen vom Chip packt, weil er in der Simulation halt das gerade als "geschickt" ansieht. ~ 3 von 4 Varianten sind dabei total fürn Arsch, weil Sie immer! zu "kaputten" FPGA Designs führen. Es gibt aber schlicht in dem Tool keine Möglichkeit das zu Constrainen....

Teilweise ist das echt total bekloppt, was da dann raus kommt, und man wundert sich ECHT oftmals darüber, was für kranke Placings am Ende doch funktionieren, und das sogar deutlich besser als die vermeindlich gute Lösung, die "schön" aussieht.

Heutige Chips bestehen einfach aus viel zu vielen Transistoren, und viel zu viel ist zu beachten. Das kann man kaum noch überblicken.

[2phil4u]

Wenn es AMD schafft die Pro/Takt Leistung um 20% zu steigern und das ganze mit 5 ghz zu verkaufen, dann wird Steamroller gut, alles andere waere dann wieder langsamer als Haswell.
Oder halt gleich 12 Cores.
Kann man eigentlich CPU so bauen, dass 2 Threads besonders stark sind und der Rest eher für Parallelisierung genutzt wird ?
Den Trumph mit der schnelleren Speicheranbindung müssten sie auch noch ausspielen, dann könnten sie etwas aufholen, Frage ist halt finanzierbar und profitabel ?

FD-SOI ist ja auch als Finfetalternative im Gespraech, Globalfoundries will ja in 28 nm schon produzieren können.
Keine Ahnung, wann 20 nm fertig sein wird, aber 28 nm FDSOI dürfte eh performanter sein.
20 nm in Bulk zu produzieren ist halt gewagt wegen Leckströmen.

[samm]

Wenn es AMD schafft die Pro/Takt Leistung um 20% zu steigern und das ganze mit 5 ghz zu verkaufen, dann wird Steamroller gut, alles andere waere dann wieder langsamer als Haswell.Ist kaum vorstellbar, dass AMDs kommende Chips auf einmal *schneller* als Haswell sein werden. Bestenfalls bleibt es so wie mit Vishera vs. Ivy, dass man in Optimalfällen am oberen Ende der Anwendungsperformance mitmischen kann. Das ist auch für mich gut genug, aber kritisch für die Akzeptanz im Massenmarkt... Wenn der Abstand verkürzt würde durch Steamroller bin ich schon absolut zufrieden.
Kann man eigentlich CPU so bauen, dass 2 Threads besonders stark sind und der Rest eher für Parallelisierung genutzt wird ?Turbo. Funktioniert ja mehr schlecht als recht (minimale Performancegewinne bei unproportionalem Verlustleistungsanstieg).

[mczak]

Jein ... schau Dirs bei Intel an .. tick-tock ... warum? Weil ein neuer Hestellungs-Prozess *und* ne neue µArch doppelt soviele Fehlerquellen liefert. AMD hat das letzte Mal bei Llano und BDv1 ne neue µArch und nen neuen Prozess eingeführt ... beides war sch....lecht.
Llano war definitiv keine neue uarch, sondern ein Athlon II mit ein bisschen Feintuning (vor allem Powermanagement, scheduler etwas aufgebohrt und ähnliches). Auch der GPU-Teil war natürlich nicht neu, und beides zusammen auf den Chip klatschen macht auch keine neue Architektur (ok das braucht ein paar Aenderungen in der Northbridge die auch sonst wegen Integration von pcie etc. anders ist zählt aber trotzdem nicht). Für beide Teile neu war aber tatsächlich der verwendete Herstellungsprozess. Und so wahnsinnig schlecht war der Chip doch gar nicht.
BD kam ja nach Llano raus, man könnte also argumentieren es gab immerhin schon Erfahrungen mit dem 32nm SOI Prozess. War allerdings zeitlich wohl zu nah.

[S940]

Llano war definitiv keine neue uarch, sondern ein Athlon II mit ein bisschen Feintuning (vor allem Powermanagement, scheduler etwas aufgebohrt und ähnliches). Auch der GPU-Teil war natürlich nicht neu, und beides zusammen auf den Chip klatschen macht auch keine neue Architektur (ok das braucht ein paar Aenderungen in der Northbridge die auch sonst wegen Integration von pcie etc. anders ist zählt aber trotzdem nicht). Für beide Teile neu war aber tatsächlich der verwendete Herstellungsprozess.
Ja µArch stimmt in den Zusammenhang nicht, aber es kommt aufs gleiche raus. Keiner hatte zuvor ne high-perf CPU mit hohem Takt und hohen Leckströmen zusammen mit ner niedrig getakteten GPU auf einen Siliziumträger gebaut. Das Resultat waren 2 Probleme, der Chip und der Prozess.
Da gabs doch letztens irgendwo nen Artikel, der schön beschrieb, dass ne CPU und ne GPU eigentlich 2 unterschiedliche Sachen sind und deshalb unterschiedliche Prozesse benötigten. Ne APU ist sowas wie die Quadratur des Kreises.
Und so wahnsinnig schlecht war der Chip doch gar nicht.
Hab ich nicht behauptet, der Chip war gut - nur hatte er halt dicke Fertigungsprobleme und wurde 2x verschoben. Eben weil man 2 Sachen auf einmal wollte und dass dann famos in die Hose ging.

Da hätten sie mal besser vorher bei 45nm mit ner K10 dual-core APU geübt.

[Locuza]

AMD hat glaube ich gesagt, dass 45nm einfach nicht angepasst und geeignet für eine APU waren.
Der 32nm Prozess wurde extra mit dem Hintergrundgedanken entwickelt, um eine APU bzw. die unterschiedlichen Charakteristikas von CPU und GPU besser vereinen zu können.

[S940]

AMD hat glaube ich gesagt, dass 45nm einfach nicht angepasst und geeignet für eine APU waren.
Der 32nm Prozess wurde extra mit dem Hintergrundgedanken entwickelt, um eine APU bzw. die unterschiedlichen Charakteristikas von CPU und GPU besser vereinen zu können.
Hab ich nicht gehört. Halte ich außerdem eher für ne Marketingaussage. Es geht einfach nicht viel zu "vereinen". Das einzige was da mMn wirklich helfen würde wäre FD-SOI mit back biasing. Da bekommt der Kreis dann ein paar Ecken. Einerseits hat man per default Low-Power-Stromspar-Transistoren, andrerseits kann man die dann aber mit BBiasing noch auf vernünftige Taktraten bringen.

Viel kanns auch nicht gebracht haben, sah man ja an den ganzen Verschiebungen. Im Endeffekt haben sie Llano eher Richtung GPU optimiert, ansonsten wären die Taktraten besser ausgefallen. 3 Ghz fürs 3870 Spitzenmodell waren für nen Full-Node Shrink ja eher peinlich. Damit startete schon der Phenom2 940 ein paar Jahre früher. Gut - ein Teil wird da auch noch der Stromverbrauch der GPU ne Rolle spielen, aber trotzdem ziemlich wenig.

[Locuza]

Das ging glaube ich um die Sache die du angesprochen hast.
Das wenn man sich die Logikoptimierungen eines CPU und GPU-Transistors anschaut, dass bei einem das wie ein Z aussieht und bei dem anderem wie ein T oder so ähnlich.
Man soll versucht haben den Unterschieden mit der 32nm Fertigung mehr Rechnung beizutragen, um eine physikalische Integration natürlich besser hin zu bekommen.

Neben den Optimierungen, die gewinnbringend sein könnten, könnte vielleicht gate-first die Sache torpediert haben?
Das war bis vor kurzem wohl einer der Hauptgrunde, wieso es so schlecht mit der Fertigung lief.

[fondness]

AMD in Zukunft mit 256-Bit-FPU-Pipelines
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1368122313

[mczak]

AMD in Zukunft mit 256-Bit-FPU-Pipelines
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1368122313
Musste ja früher oder später kommen. Wobei da spekuliert wird dass es für Excavator zu spät sein könnte. Scheint mir eine gewagte These denn es handelt sich ja nicht um neue Befehle sondern nur ein Bit das anzeigt ob man schnelle 256-Bit AVX Ausführung erwarten kann. Sicher ist aber dass 256bit AVX ohne AVX2 beim BD (bzw. SR gibt dort ja doch einige Aenderungen) nicht sinnvoll ist, so wie die simd-Einheit aufgebaut ist (gut mal abgesehen von gather denn dieses Feature hat eigentlich gar nichts mit "normalen" AVX2-Befehlen zu tun). Ausserdem ist ist ja mit blossem Aufbohren der simd-Einheiten auf 256bit nicht getan, auch die load/store Einheiten (die ja bei BD selbst nicht zu der FPU gehören) müssen das zwingend mitmachen sonst bringt das nix. Scheint mir aber für Excavator trotzdem realistisch, sonst fällt AMD doch da sehr arg zurück.

[S940]

Wobei da spekuliert wird dass es für Excavator zu spät sein könnteFür den Excavator in 2014 ;-)
Nicht für Excavator generell.

Ich hab mittlerweile den Eindruck, dass AMD Codenamen so auf Entwicklungsprojekte umlegt wies gerade passt.

Der ursprgl. Excavator kommt jetzt mMn im Kaveri als Steamroller, schließlich brauchte man da ne 2. Rev, die erste war ein Totalausfall und machen wir uns nichts vor, Richland ist nur ein verbesserter Trinity, auch wenn das Stepping nun offiziell RL-A1 heißt.

Der neue Excavator wäre damit ein größerer Wechsel und eher 2015, nicht mehr 2014.

Außerdem würde das auch etwas den Wechsel im µArch-Roadmap-Design erklären. Von linear wurde auf exponentiell gewechselt. Möglicherweise doch nur aus Designgründen, aber nen Design-Wechsel bei Excavator könnte man auch vermuten.

Aber naja, ziemlich dicke Speku.

[Locuza]

Wieso ursprünglicher Excavator?
Sieht schon arg nach dem Steamroller aus, denn man von Anfang an geplant hat, immerhin hat man ihn vor vielen Monaten schon präsentiert.
Wobei man kann ja nie kleine Verbesserungen an XYZ ausschließen was mitgenommen wurde.

Piledriver hat ja im Grunde zwei verschiedene Versionen, den Trinity Piledriver mit paar Unterschieden und den Vishera Piledriver, der die meisten Verbesserungen enthält, aber auch nur eine Revision C von Bulldozer darstellt.
Von den technischen Veränderungen her war Piledriver ja wirklich sehr unspannend und dennoch 10-20% mehr Power bei Anwendungen und Spielen.

Ab wann definieren wir eig. ein Design-Wechsel?
Excavator ist ja im Grunde schon als Bulldozer Erbe definiert.
Steamroller hat ja jetzt auch 2 Decoder pro Int-Core, hier sind ja schon grundlegende Änderungen geschehen.

[OBrian]

Ab wann definieren wir eig. ein Design-Wechsel? Ich würde sagen, wenn man im Blockdiagramm die Kästchen anders malen muß.

Danach würde ich Piledriver nicht als ernsthaft anderes Design ggü. BD bezeichnen, Steamroller aber schon, wenn die vermuteten Änderungen am Frontend zutreffen.

[S940]

Wieso ursprünglicher Excavator?
Na AMD spielt mit den Kunden ziemlich herum, spätestens seit sie jetzt bei den Roadmaps als einzige Info den Herstellungsprozess angeben, kann sich hinter dem Codenamen alles Mögliche verbergen.
Da gibts im Hintergrund großes Stühlerücken und keiner bekommts mit.

Sieht schon arg nach dem Steamroller aus, denn man von Anfang an geplant hat, immerhin hat man ihn vor vielen Monaten schon präsentiert.
Wobei man kann ja nie kleine Verbesserungen an XYZ ausschließen was mitgenommen wurde.Jo, aber halt Steamroller Rev. B. die Version "A" fällt ja aus.

Piledriver hat ja im Grunde zwei verschiedene Versionen, den Trinity Piledriver mit paar Unterschieden und den Vishera Piledriver, der die meisten Verbesserungen enthält, aber auch nur eine Revision C von Bulldozer darstellt. Lol, ja, das kommt noch dazu ^^
Von den technischen Veränderungen her war Piledriver ja wirklich sehr unspannend und dennoch 10-20% mehr Power bei Anwendungen und Spielen. Jo schon nett, aber da sieht man mal, wie verbuggt die B2 Revision noch war.
Excavator ist ja im Grunde schon als Bulldozer Erbe definiert.
Steamroller hat ja jetzt auch 2 Decoder pro Int-Core, hier sind ja schon grundlegende Änderungen geschehen.Jo, Steamroller ist ohne Zweifel der "echte" BD 2.0.
Nachdem da vorwiegend beim Int-Cluster und Front-End optimiert wird, wäre beim nächsten Schritt die FPU eigentlich naheliegend.
Ich würde sagen, wenn man im Blockdiagramm die Kästchen anders malen muß.

Danach würde ich Piledriver nicht als ernsthaft anderes Design ggü. BD bezeichnen, Steamroller aber schon, wenn die vermuteten Änderungen am Frontend zutreffen.

Stimme ich zu, mit dem kleinen Zusatz: Entwender "Kästchen anders malen", oder "neue Kästchen hinzukommen".

Da denke ich v.a. an nem µOp-Cache.

Wobei wir jetzt darüber streiten könnten, ob ein "Steamroller 2.0" mit 256bit FPUs ne grundlegende Design-Änderung wäre.

[OBrian]

kommt drauf an, ob aus den beiden 128ern eine 256er gemacht wird oder beide auf 256 aufgebohrt werden.

Ich könnte mir beides vorstellen. Sicher ist mehr FPU-Power immer gut, aber es macht die CPU auch größer und heißer. Evtl. will AMD möglichst alle großen FPU-Rechenlasten auf die GPU auslagern und dann die FPU in der CPU nur als nicht sonderlich starke Grundausstattung für das lassen, was sich nicht auf die GPU auszulagern lohnt.

[HOT]

Die neuen FPUs sind sicherlich schon im SR drin oder spricht da irgendwas dagegen?

Und neue Fertigung und neue Arch sind nicht immer problematisch. die 32nm-Fertigung war eben an sich genausowenig optimal wie beispielsweise 65nm. Ich sehe das ja eher so, dass BD eigentlich sogar recht gut auf 32nm lief während Llano übertrieben hohe Spannungen brauchte. BD war zu dem Zeitpunkt noch halb kaputt, das lag aber nicht an der Fertigung. Damit war die neue Arch auf der neuen Fertigung erfolgreicher als der Shrink. Das sollte man dabei nicht unberücksichtigt lassen. Außerdem wie war das denn beim K10 in 65nm? Die Fertigung war einfach unzureichend für die Arch, wenn man sich 45nm-Rev.C ansieht, war das definitiv das Hauptproblem, denn da waren plötzlich 50-60% mehr Takt drin. Mit ULK sogar noch zwei zusätzliche Kerne. Den alten Prozess für eine neue Arch zu nutzen hat sich für AMD in den letzten Jahren einfach nicht bewährt. Deswegen glaube ich auch nicht daran, dass es so noch mal laufen wird. Sollte Excavator (steht ja für 2015 auf der Roadmap i.Ü.) die NachfolgeArch von SR sein (also nicht das Upgrade) so kommt der auch auf einem neuen Prozess, das halte ich für absolut sicher.
AMD hatte mit 32nm einfach wieder pech wie bei 130 und 65nm auch. 28nm ist einfach die Optimierung zu 32nm um die Probleme auszubügeln, aber ich glaube nicht, dass es sich lohnt darauf eine komplett neue Arch nach SR noch darauf laufen zu lassen. Da AMD mit 180, 90 und 45 immer pünktlich war und immer Glück mit Ausbeute und Taktraten hatte, wird das auch bei 20nm funktionieren, selbst wenn die Unterschiede diesmal deutlich krasser ausfallen. Aber das ist doch eher ein Ansporn darauf, tatsächlich die neue Arch genau auf diesen Prozesswechsel auszulegen! Denn von da aus kann man dann kostengünstig durchstarten.

Mein Anspruch an Excavator wäre:
- weiterer Neuaufbau der BD-Arch mit den Erfahrungen von SR
- Berücksichtigung der zu erwartenden niedrigeren Taktraten durch höhere IPC und geringere Latenzen aufgrund der LP-Fertigung
- Vollintegration von GCN-Nachfolger
- Flexible Modulanzahl bis 8 Module und 2048 Shader (nicht gleichzeitig und mit Hinblick auf einen Shrink und Custom-Designs).
- Fertigung bei GloFo und TSMC möglich
- Fokus des Arch-Designs auf möglichst niedrige Spannungen
- Optional fdSOI und ClockMeshing für High-End-Modelle
- BD-HD-Design V2.0 für den neuen Prozess

[Gipsel]

kommt drauf an, ob aus den beiden 128ern eine 256er gemacht wird oder beide auf 256 aufgebohrt werden.

Ich könnte mir beides vorstellen.Ich kann mir nicht vorstellen, daß es statt zweier 128bit FMACs nur noch eine 256Bit FMAC-Einheit gibt. Das wäre ein Rückschritt.

[Coda]

Würde auch nicht wirklich viel nützen, nicht?

Das würde nur dann Sinn ergeben, wenn man wieder auf eine FPU pro Integer-Core geht.

[robbitop]

Ich sehe das ja eher so, dass BD eigentlich sogar recht gut auf 32nm lief während Llano übertrieben hohe Spannungen brauchte.
Wobei sich bei den Reviews der Desktopmodelle zeigte, dass man den bei Standardtakt massiv undervolten konnte. Und dann war die Leistungsaufnahme schon ziemlich ok. Frage mich, warum AMD die Standardspannung so hoch gewählt hat.


- Berücksichtigung der zu erwartenden niedrigeren Taktraten durch höhere IPC und geringere Latenzen aufgrund der LP-Fertigung

Dann müsste man aber noch ordentlich IPC herausholen. Ist abschätzbar was man durch die Wald-und-Wiesen-Prozesse (statt custom) an Taktbarkeit verliert? ~20 %?



- Optional fdSOI
Die Frage ist, ob sich das lohnt. fdSOI sieht aus, wie ein totes Pferd. Das gibt es für 28 nm und für 20 nm. Danach ist offenbar Schluss. Die Integration ist sicher auch nicht trivial. Was macht man dann nach 20 nm? Das ganze wieder zurück auf Bulk optimieren? Hü-hott-hü-hott? :D


------------------------------------------------


Was mir zu zukünftigen Änderungen der Architektur als Laie einfällt:
Man verdoppelt die Decoder und man verdoppelt die FPUs - am Ende sieht das aus wie eine stetige Abkehr vom CMT Gedanken (der eh IMO für die Katz war). Dann hätte man von Anfang an lieber Intels Ansatz gewählt: große Kerne mit viel Execution/Decoderleistung + SMT. Oder aber mehr kleine Kerne (also hochgetaktete Cats - was aber mangels IPC auch für die Katz wäre).

[fondness]

Dürfte wohl eher auf zwei 256-bit FPUs pro Modul hinaus laufen:

http://img197.imageshack.us/img197/6034/filegw.jpg (http://imageshack.us/photo/my-images/197/filegw.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

[robbitop]

Alles andere wäre auch kein Upgrade oder? :)
Was meint ihr, wann AMD AVX2 implementiert?

[HOT]

Wobei sich bei den Reviews der Desktopmodelle zeigte, dass man den bei Standardtakt massiv undervolten konnte. Und dann war die Leistungsaufnahme schon ziemlich ok. Frage mich, warum AMD die Standardspannung so hoch gewählt hat.

Das stimmt zwar, es muss aber auch einige faule Eier gegeben haben, die instabil wurden bei zu niedriger Spannung. AFAIK war sogar bei den Mobilteilen die Spannung recht hoch.
Im allgemeinen sollte Llano den AthlonII ersetzen, die Spannungen wurden bei AMD bei den OEM-CPUs immer sehr hoch angesetzt.

Dann müsste man aber noch ordentlich IPC herausholen. Ist abschätzbar was man durch die Wald-und-Wiesen-Prozesse (statt custom) an Taktbarkeit verliert? ~20 %?

Na ja, nachdem was ich gesehen hab, halte ich 4GHz mit einem jetzigen LP-Prozess bei solchen Leistungsdesigns für unmöglich. Da dürfte 3GHz das absolut höchste der Gefühle sein. Ist die Frage, wie gut man die neuen Prozesse skalieren kann, das weiss aber nur GloFo. Kann ja sein, dass mit 20nm LP oder SLP 4GHz drin sind, aber dann sicher nicht zuverlässig. Jedenfalls muss man mMn von den 4GHz wieder weg, wenn man solche Prozesse nutzen möchte. Das ist einfach Unsinn sowas zusammenbringen zu wollen. Allein dafür braucht man also eine echte neue Arch.

Die Frage ist, ob sich das lohnt. fdSOI sieht aus, wie ein totes Pferd. Das gibt es für 28 nm und für 20 nm. Danach ist offenbar Schluss. Die Integration ist sicher auch nicht trivial. Was macht man dann nach 20 nm? Das ganze wieder zurück auf Bulk optimieren? Hü-hott-hü-hott? :D

Na jo, es lohnt sich wenn die Integration einfach ist. So einfach und billig, dass man damit hohe Takte bei Server-CPUs erreichen kann ohne einen komplett neuen Prozess bezahlen entwickeln zu müssen. Angeblich soll das so billig sein - schaun mer mal.


------------------------------------------------


Was mir zu zukünftigen Änderungen der Architektur als Laie einfällt:
Man verdoppelt die Decoder und man verdoppelt die FPUs - am Ende sieht das aus wie eine stetige Abkehr vom CMT Gedanken (der eh IMO für die Katz war). Dann hätte man von Anfang an lieber Intels Ansatz gewählt: große Kerne mit viel Execution/Decoderleistung + SMT. Oder aber mehr kleine Kerne (also hochgetaktete Cats - was aber mangels IPC auch für die Katz wäre).
Guter Einwand. Vielleicht hats ja dennoch ein paar Vorteile.

[fondness]

Na ja, nachdem was ich gesehen hab, halte ich 4GHz mit einem jetzigen LP-Prozess bei solchen Leistungsdesigns für unmöglich. Da dürfte 3GHz das absolut höchste der Gefühle sein. Ist die Frage, wie gut man die neuen Prozesse skalieren kann, das weiss aber nur GloFo. Kann ja sein, dass mit 20nm LP oder SLP 4GHz drin sind, aber dann sicher nicht zuverlässig. Jedenfalls muss man mMn von den 4GHz wieder weg, wenn man solche Prozesse nutzen möchte. Das ist einfach Unsinn sowas zusammenbringen zu wollen. Allein dafür braucht man also eine echte neue Arch.


Wer sagt das AMD für zukünftige Chips irgend einen Low-Power-Prozess verwendet? Nur weil man GF nicht mehr extra dafür bezahlt Prozesse zu entwickeln bedeutet das noch lange nicht das es keine Alternativen gibt. IBM wird für die Power-CPUs bsw. auf jeden Fall eine SHP-Prozess entwickeln, warum sollte AMD dort nicht fertigen können? Man betont doch gerade immer neuen Chips so zu entwickeln das man möglichst flexibel zwischen den Foundries wechseln kann. Qualcomm und Nvidia wollen auch mittelfristig in höhere Leistungsregionen vordringen, dafür bedarf es SHP-Prozesse, die sicherlich auch von anderen Foundries wie Samsung oder TSMC angeboten werden bei entsprechender Nachfrage.

[Gipsel]

Was mir zu zukünftigen Änderungen der Architektur als Laie einfällt:
Man verdoppelt die Decoder und man verdoppelt die FPUs - am Ende sieht das aus wie eine stetige Abkehr vom CMT Gedanken (der eh IMO für die Katz war).Die zwei Integer-Kerne teilen sich doch immer noch eine FPU, die eben nur doppelt so breit ist. Das ist keine Abkehr von CMT.

[HOT]

Wer sagt das AMD für zukünftige Chips irgend einen Low-Power-Prozess verwendet? Nur weil man GF nicht mehr extra dafür bezahlt Prozesse zu entwickeln bedeutet das noch lange nicht das es keine Alternativen gibt. IBM wird für die Power-CPUs bsw. auf jeden Fall eine SHP-Prozess entwickeln, warum sollte AMD dort nicht fertigen können? Man betont doch gerade immer neuen Chips so zu entwickeln das man möglichst flexibel zwischen den Foundries wechseln kann. Qualcomm und Nvidia wollen auch mittelfristig in höhere Leistungsregionen vordringen, dafür bedarf es SHP-Prozesse, die sicherlich auch von anderen Foundries wie Samsung oder TSMC angeboten werden bei entsprechender Nachfrage.

Da hast sicher auch wieder recht. AMD ging es ja vor allem darum, keine Finanzierung für einen eigenen Prozess mehr anstoßen zu wollen. Wenn man jemand anderes dafür bezahlt seinen Prozess mitnutzen zu können ginge das sicherlich auch. Guter Einwand. Das entspannt die Sache und ermöglicht vllt wirklich einen Shrink.

Die zwei Integer-Kerne teilen sich doch immer noch eine FPU, die eben nur doppelt so breit ist. Das ist keine Abkehr von CMT.

Ich glaub er meinte die tatsächliche Verdopplung der FPU und nicht die Verbreiterung auf 256Bit. Also 2 FPU-Cores und 2 Integer-Cores pro Modul. Ich glaub aber auch nicht, dass das passieren wird. Der Trick ist ja dieses wärmeerzeugende Monstrum zu zähmen und nicht es sinnlos zu vermehren :D.

Aber noch was zu Entwicklungszeiten: Eine echte neue Arch braucht sehr viel Zeit. Das ist auch das, was AMD bezüglich der neuen Arch nach SR sagte. Man muss sich folgendes vergegenwärtigen: BD brauchte 4 gescheiterte Anläufe (Ur-K8, K9, Ur-K10 und 45nm BD) und damit mindestens 10 Jahre Entwicklungszeit, hat also ursprünglich Nexgen als Grundlage. Der K10 brauchte mindestens 3 Jahre (also primär die on-Die-Infrastruktur eigentlich, die Kerne sind ja eher ein Minimalupgrade), beim Sandy-Bridge waren es 5 1/2 Jahre bis zum Release, Core2 brauchte 3 Jahre (echt wenig, Intels Glückskind, gab aber mit Banias auch eine hervorragende Grundlage), eine echte neue Arch von Intel nach Sandy ist sicherlich das Tock nach Skylake, das wären wieder 5 Jahre. Bei Intel darf man nicht vergessen, dass die mehrere Entwicklungsteams haben, von denen sich einge ausschließlich mit Verbesserungen beschäftigen (wie Ivy, Yonah, Dothan, Lynnfield, Westmere oder Wolfdale beispielsweise, da dürfte sich noch Skylake zugesellen, Broadwell ist ja offenbar wirklich ein ausschließlicher Shrink ohne jede architektonische Veränderung). Auch Nehalem war sicherlich 5 Jahre in Entwicklung, also seit des Canceln des Netburst/IA64-Hybriden, hab den Codenamen leider vergessen, war AFAIK irgendwas mit T... Tejas. Haswell müsste also seit Ende 2008 in Entwicklung sein, war das Projekt nach Nahelem für das Ami-Team (dafür ist das Ergebnis ganz schön bescheiden, aber das Isreal-Team hat mit Sandy mal wieder eine überragende Vorlage gegeben).

Natürlich tauschen die Erfahrungen und Architekturmerkmale aus, die Ähnlichkeiten sind ja frappierend z.T., dennoch muss man unterscheiden wer was wie lange wo gemacht hat.
AMD hat da nicht so klare Abgrenzungen und die Teams sind kleiner, deshalb kann man da nicht so genaue Grenzen ziehen wie bei Intel. Aber BD dürfte immer mal zwischendurch wieder als neues Projekt gestartet sein, bis es letztendlich zulasten eines weiteren K7-Successors gecancelt oder auf Eis gelegt wurd. AMD konnte sich die lange Entwicklungszeit für ein echtes neues Design nicht erlauben, bis mit dem K7 garnichts mehr ging. Und selbst jetzt hat man noch Probleme. Vielleicht versucht man jetzt die Vorteile der BD/Nexgen-Welt mit den Vorteilen der K7-Welt zu verschmelzen, das wär doch mal was.

[robbitop]

Ich glaube mit maximal 3 GHz hätten sie ein gewaltiges Problem. Dann müsste man ja noch mehr IPC bringen als Intel eh schon hat. 4 GHz im größten Design sind eigentlich Pflicht. Oder man konzentriert sich halt nur noch auf mobile und Energieeffizienz. Dann ist's nicht tragisch...

Die zwei Integer-Kerne teilen sich doch immer noch eine FPU, die eben nur doppelt so breit ist. Das ist keine Abkehr von CMT.
Aber immerhin eine halbe. Man hat ja nun die sehr transistorintensiven Decoder verdoppelt. Eine weitere FPU wäre bestimmt auch nicht mehr soo teuer oder? Am Ende ist man dann wieder beim K7/8/10 Grundgedanken, wenn man wieder alles doppelt pro Modul hat.

[Locuza]

Aber immerhin eine halbe. Man hat ja nun die sehr transistorintensiven Decoder verdoppelt. Eine weitere FPU wäre bestimmt auch nicht mehr soo teuer oder? Am Ende ist man dann wieder beim K7/8/10 Grundgedanken, wenn man wieder alles doppelt pro Modul hat.
(Grobe Einordnung)
http://logout.hu/dl/upc/2011-02/13063_amd-bulldozer-core-module.jpg

Man müsste ja auch die FPU stark anpassen, bzw. das Layout, wenn man versucht eine schöne Fläche für das die zu konstruieren.
Von den groben Einheiten ist ein Haswell ja auch "fast" ein BD-Modul.
4 Int-Pipelines, eine FPU, eine fetch-unit etc.
Bloß bei Intel ist es halt ein gemeinsamer Sheduler und per SMT werden 2 Threads erreicht.
Intel trennt auch nicht FP und Integer-Sheduler, AMD bisher immer noch.
Klar auch ganz grob, aber oberflächlich gesehen ist das ja auch nicht mehr ein so dramatischer Unterschied.

[robbitop]

Ah OK - doch recht fett das ganze. Und mit 2x 256 bit wird's nicht kleiner.
Nachteil vom BD ist eben, dass man Singlethread unterlegen ist und erst Multithread wieder in ähnliche Regionen kommt (1x Core mit SMT vs 1x Modul mit CMT).
Dann würde ich auch eher die erste Lösung wählen. Erscheint mir vielseitiger zu sein - insbesondere vor dem Hintergrund, dass sich eben nicht alles beliebig parallelisieren lässt.

[Skysnake]

Was mir zu zukünftigen Änderungen der Architektur als Laie einfällt:
Man verdoppelt die Decoder und man verdoppelt die FPUs - am Ende sieht das aus wie eine stetige Abkehr vom CMT Gedanken (der eh IMO für die Katz war). Dann hätte man von Anfang an lieber Intels Ansatz gewählt: große Kerne mit viel Execution/Decoderleistung + SMT. Oder aber mehr kleine Kerne (also hochgetaktete Cats - was aber mangels IPC auch für die Katz wäre).
Nein, das ist überhaupt keine Abkehr. Man verdoppelt halt nur die Ressourcen, die für die FPU da sind.

Die CPU kann dann ja im Optimalfall auf eine "256Bit" FPU zugreifen ;)

Das ist btw. genau die FPU, wie ich Sie mir von AMD gleich am Anfang gewünscht/erwartet habe.. -.- Ich war total verblüfft, als ich irgendwann gerafft habe, das ein Modul nur 2x 128Bit FPU hat.

Gerade die starke FPU war ja zusammen mit HT ein Grund, warum man die Opterons durchaus gern zum rechnen genommen hat.

AMD hat die FPU aber total vernachlässigt, und eben auch die Decoder etwas schleifen lassen. Das Design ist eher auf viele I/O lastige Threads ausgelegt, die nicht lange am Stück rechnen können. Da tut der Decoder nicht weh, und auch nicht die "schmale" FPU.

AMD hat da in meinen Augen die Microserver etwas übersehen, die sich für derartige Workloads einfach deutlich besser eignen mit ihren Designs.

Naja, seis drum. Die Fehler in meinen Augen werden angegangen, jetzt muss sich nur noch zeigen, wie gut die Lösungen implementiert werden.

[Locuza]

Nachteil vom BD ist eben, dass man Singlethread unterlegen ist und erst Multithread wieder in ähnliche Regionen kommt (1x Core mit SMT vs 1x Modul mit CMT).
Dann würde ich auch eher die erste Lösung wählen. Erscheint mir vielseitiger zu sein - insbesondere vor dem Hintergrund, dass sich eben nicht alles beliebig parallelisieren lässt.
Ich würde zuerst zwar auch sagen, dass Intels Lösung flexibler ist, da keine fest eingeteilten Ressourcen bestehen und man zwischen ST und MT Betrieb im Core entscheiden kann, aber bringt das Intel auch wirklich etwas?
Haswell profitiert von der vierten Integer-Pipeline scheinbar 0, also 4 Pipelines können mit einem Thread gar nicht ausgelastet werden.
Im P3D fand ich die Aussage, dass im Schnitt eine dritte Integer-Pipeline für einen Thread nur 5% mehr IPC bedeutet hat, einer der Gründe wieso man aus Preis/Leistungssicht sich bei BD auf 2 Integer-Pipelines pro Thread beschränkt hat.
Ziehe ich SB 5-10% der IPC weg, dann ist die IPC ja immer noch brutal höher, als bei Bulldozer, da hat Intel einfach bei den ganzen anderen Sachen eine bessere Implantation.

Es wäre mir deutlich lieber, wenn Intel all ihre Prozessoren mit SMT verkaufen würde, dass würde die ST-Performance sicherlich nicht schmälern, aber auch die Core i5 Reihe hätte ordentliche MT-Performance.
Scheinbar will man das aber auf das Premium-Segment beschränken oder auf die Core i3, die es dringender gebrauchen.
Wäre auch interessant einen Haswell Core i3 mit SMT gegen einen Core i5 zu stellen und zu schauen, wie SMT dort skaliert.

Weiß eig. jemand wie der SMT Betrieb funktioniert?
Werden bei 2 Threads einem Thread 2 Integer-Pipelines zugewiesen und dem zweitem Thread nur eine?
Und wie ist das insgesamt mit mehreren Threads?
Wird erst einmal jeder Core mit einem Thread befüllt bis dann ab dem fünften Thread ein Core per SMT mit zwei Threads befüllt wird und immer so weiter oder wird bei zwei Threads gleich in den SMT-Betrieb geschaltet und ein Core damit befüllt?

[S940]

Wobei sich bei den Reviews der Desktopmodelle zeigte, dass man den bei Standardtakt massiv undervolten konnte. Und dann war die Leistungsaufnahme schon ziemlich ok. Frage mich, warum AMD die Standardspannung so hoch gewählt hat.Na das Teil war hoffnungslos verspätet, da haben sie dann Chips so schnell wie möglich rausgehauen und das geht am Schnellsten, wenn man die Chips mit ner hohen Vcore testet, da man dann ne hohe Ausbeute hat.
Das viele Chips übervoltet werden nimmt man dabei in Kauf.


Dann müsste man aber noch ordentlich IPC herausholen. Ist abschätzbar was man durch die Wald-und-Wiesen-Prozesse (statt custom) an Taktbarkeit verliert? ~20 %?
Kommt halt drauf an welcher Wald und welche Wiese ... :freak:
FDSOI sähe ja ganz gut aus. Ansonsten mit normal-Bulk wären es wohl so 10-20%, je nachdem wie gut der Bulk-Prozess nun ist.


Die Frage ist, ob sich das lohnt. fdSOI sieht aus, wie ein totes Pferd. Das gibt es für 28 nm und für 20 nm. Danach ist offenbar Schluss. Die Integration ist sicher auch nicht trivial. Was macht man dann nach 20 nm? Das ganze wieder zurück auf Bulk optimieren? Hü-hott-hü-hott? :DNe es gibt immerhin ne Roadmap für FD-SOI. 20nm wurde da vor ein paar Monaten für ne 14nm Node gestrichen:
http://www.abload.de/img/neueroadmapwcu74.png

Es hat halt den Designvorteil, dass man ähnliche Takt- und Stromverbrauchs-Vorteile wie Finfets hat, aber sich nicht mit dem komplizierten Finfets-Design-Prozess befassen muss. Das geht wie aktuell jetzt auch schon.
IBM hat auch nen Kombi-Prozess in Entwicklung, FD-SOI plus Finfets.

Was mir zu zukünftigen Änderungen der Architektur als Laie einfällt:
Man verdoppelt die Decoder und man verdoppelt die FPUs Die FPUs ändern nichts, die Decoder etwas, aber beim Front-End ist v.a. die Sprungvorhersagelogik der Flächengroßverbraucher. Die ist weiterhin gemeinsam benutzt und wird bei Steamroller mal eben verdoppelt. Das könnte man sich bei nem Single-Thread Design nicht leisten.
Wer sagt das AMD für zukünftige Chips irgend einen Low-Power-Prozess verwendet? Nur weil man GF nicht mehr extra dafür bezahlt Prozesse zu entwickeln bedeutet das noch lange nicht das es keine Alternativen gibt. IBM wird für die Power-CPUs bsw. auf jeden Fall eine SHP-Prozess entwickeln, warum sollte AMD dort nicht fertigen können?Weil sie bis 2024 nen Exklusivvertrag mit GF haben. Die Mehrzahl der Produkte muss bei GF hergestellt werden. Entweder sie zahlen GF, wenn sie diese Exklusivität verletzen, wie aktuell mit Kabini, oder GF müsste den Prozess bei IBM einkaufen und den dann zur Verfügung stellen. Damit wäre der Prozess quasi "standard" wie der AMD-CEO mal meinte.
Das würde dann zwar sicher auch nicht billig werden, aber da GF und IBM ne gemeinsame Fab betreiben, würde es eventuell auch nicht zu kompliziert sein.
AMD hat die FPU aber total vernachlässigt, und eben auch die Decoder etwas schleifen lassen. Das Design ist eher auf viele I/O lastige Threads ausgelegt, die nicht lange am Stück rechnen können. Da tut der Decoder nicht weh, und auch nicht die "schmale" FPU.Einspruch Euer Ehren ^^
Die FPU ist Klasse, Du vergisst da das SSE5 / AVX und FMA3/FMA4- Hickhack im Vorfeld. Das nur 128bit kamen war klar, da das Grunddesign auf SSE5 aufbaute, das nur 128bit vorsah. Das dann trotzdem AVX256 ging und auch schon FMA unterstützt wurde, ist doch Klasse. Intel ist fast 2 Jahre bei FMA hintendran.
Also wenn etwas beim BD gut war, dann wars die FPU. Halt blöd, dass keiner FMA-Code nutzt, aber rein vom technischen Standpunkt her gesehen ist die FPU ein Sahnestückchen :)

[Triskaine]

Weiß eig. jemand wie der SMT Betrieb funktioniert?
Werden bei 2 Threads einem Thread 2 Integer-Pipelines zugewiesen und dem zweitem Thread nur eine?
Und wie ist das insgesamt mit mehreren Threads?
Wird erst einmal jeder Core mit einem Thread befüllt bis dann ab dem fünften Thread ein Core per SMT mit zwei Threads befüllt wird und immer so weiter oder wird bei zwei Threads gleich in den SMT-Betrieb geschaltet und ein Core damit befüllt?

SMT steht für Simultaneous Multithreading, die Ressourcen werden von beiden Threads dynamisch genutzt und verteilt. Früher wurden noch bestimmte Strukturen (L/S-Buffer z.B.) statisch aufgeteilt, aber hier hat Intel mit jeder sukzessiven Architekturgeneration die Verteilung flexibler gemacht.

Für das Backend (also die Execution-Units) existieren überhaupt keine Threads, es wird ausgeführt was da ist.

[robbitop]

Ich würde zuerst zwar auch sagen, dass Intels Lösung flexibler ist, da keine fest eingeteilten Ressourcen bestehen und man zwischen ST und MT Betrieb im Core entscheiden kann, aber bringt das Intel auch wirklich etwas?
Haswell profitiert von der vierten Integer-Pipeline scheinbar 0
Ist das so? Im Multithreadfall (alle Kerne und alle virtuellen Kerne sind ausgelastet) sollte es unter hoher Integerlast was bringen.
Das es im FPU limitierten Cinebench nichts bringt, war abzusehen.
Ich kann mir gut vorstellen, dass ein Haswell Core i3 in Spielen deutlich näher am 4C/4T Modell liegt, als es noch bis Ivy Bridge der fall war.

[Locuza]

SMT steht für Simultaneous Multithreading, die Ressourcen werden von beiden Threads dynamisch genutzt und verteilt. Früher wurden noch bestimmte Strukturen (L/S-Buffer z.B.) statisch aufgeteilt, aber hier hat Intel mit jeder sukzessiven Architekturgeneration die Verteilung flexibler gemacht.

Für das Backend (also die Execution-Units) existieren überhaupt keine Threads, es wird ausgeführt was da ist.
Mh, also werden alle Instruktionen von den zwei Threads bei allen EX-Pipes berechnet?
Ab IVB hat Intel die uop queue auch dynamisch dann in zwei Hälften beim SMT Betrieb aufgeteilt, ohne waren halt alle Einträge für einen Thread nutzbar.

Ist das so? Im Multithreadfall (alle Kerne und alle virtuellen Kerne sind ausgelastet) sollte es unter hoher Integerlast was bringen.
Das es im FPU limitierten Cinebench nichts bringt, war abzusehen.
Ich kann mir gut vorstellen, dass ein Haswell Core i3 in Spielen deutlich näher am 4C/4T Modell liegt, als es noch bis Ivy Bridge der fall war.
Ich meinte natürlich im ST-Fall.
Meine Spekulation läuft ja darauf hinaus, dass AMDs CMT-Design wenig Nachteile bei ST hat.
Wobei Intel beim ST-Betrieb dann eig. alle Fenster und Einträge für einen Thread zur Verfügung hätte, was ja natürlich Vorteile haben müsste.
Aber man sieht bei den ersten Vergleichen kaum Steigerungen.
Also limitiert vor dieser Betrachtung etwas anderes?
Oder sind das Vorteile, die bei Intels sehr hohen IPC sich kaum noch auf den Durchschnitt niederschlagen?

Wird auf jeden Fall schon einmal kompliziert.
Dresdenboy hatte glaube ich mal einen schönen Vergleich zwischen einem CMT-Modul und einem SB oder Nehalem Kern, pro Modul und pro Integer-Core, mit Einträgen, Buffern usw.
Aber erst einmal mache ich eine Denkpause.

[mczak]

Einspruch Euer Ehren ^^
Die FPU ist Klasse, Du vergisst da das SSE5 / AVX und FMA3/FMA4- Hickhack im Vorfeld. Das nur 128bit kamen war klar, da das Grunddesign auf SSE5 aufbaute, das nur 128bit vorsah. Das dann trotzdem AVX256 ging und auch schon FMA unterstützt wurde, ist doch Klasse. Intel ist fast 2 Jahre bei FMA hintendran.
Also wenn etwas beim BD gut war, dann wars die FPU. Halt blöd, dass keiner FMA-Code nutzt, aber rein vom technischen Standpunkt her gesehen ist die FPU ein Sahnestückchen :)
Nun ja also dass der FMA kann war ja klar das war ja schon bei SSE5 dabei. Wurde dann halt eine andere Variante als ursprünglich gedacht. AVX256 brauchte ja jetzt auch nicht so gewaltige Aenderungen...
Auch sonst kann ich mich dem Lob nicht ganz anschliessen. Die SIMD-Einheit sieht zwar auf den ersten Blick vielleicht gut aus aber hat doch auch gravierende Nachteile:
- ist eigentlich überdesignt, hat ja 2xInt + 2xFP Pipes, SR reduziert das auf 3 (wobei dann vermutlich die einzelnen Pipes mehr verschiedene Befehle ausführen können, wird trotzdem einfacher und kleiner).
- die Latenzen sind ziemlich grottig, insbesondere haben auch alle obersimplen Befehle (logic ops, int add etc.) eine Latenz von 2 (d.h. die Grundlatenz ist schlecht). Ist aber nicht neu bei BD, haben alle AMD Designs seit K7 nur Bobcat hat das "gefixt". Aber selbst der olle Atom kriegt das besser hin, VIA Nanos etc. auch die einzige Ausnahme bei intel ist der P4 zu dem brauche ich mich glaube ich nicht weiter zu äussern...
- verwandt mit obigem Problem, Befehle die Daten von SIMD nach INT Domain transferieren oder umgekehrt haben extrem hohe Latenz, typischerweise 10 Takte oder mehr was Sandy Bridge mit 2 hinkriegt, bei so nützlichen Dingen wie movmskps. Das liegt natürlich vor allem daran dass die SIMD-Einheit eben ziemlich separat ist (auch Bobcat vollbringt hier keine Wunder ist aber etwas besser, auch dort ist die Kopplung nicht so eng wie bei Sandy Bridge das ja denselben Scheduler für Int+SIMD hat).
- manche Befehle sind bloss aus Kompatibilitätsgründen implementiert, die Implementation ist aber derart mies dass man die aus Performancegründen nicht brauchen sollte (mein Lieblingsbefehl hier ist DPPS, die Menge an uops etc. ist wirklich zum Schreien).

[Skysnake]

Einspruch Euer Ehren ^^
Die FPU ist Klasse, Du vergisst da das SSE5 / AVX und FMA3/FMA4- Hickhack im Vorfeld. Das nur 128bit kamen war klar, da das Grunddesign auf SSE5 aufbaute, das nur 128bit vorsah. Das dann trotzdem AVX256 ging und auch schon FMA unterstützt wurde, ist doch Klasse. Intel ist fast 2 Jahre bei FMA hintendran.
Also wenn etwas beim BD gut war, dann wars die FPU. Halt blöd, dass keiner FMA-Code nutzt, aber rein vom technischen Standpunkt her gesehen ist die FPU ein Sahnestückchen :)
Ich habe nicht von der ISA gesprochen, sondern von der breite der FPU, also vom Durchsatz. Das ist einfach zu wenig. Gerade bei AVX Code hat man nicht mehr FP-Power als ein Sandy mit nur einem Core, weil ja ein Thread die komplette FPU belegt, genau wie bei Sandy.
Bei Sandy liegt nur die halbe FPU brach, sobald man kein AVX nutzt.

Hier hätte ich mir eben 2x 256Bit FPUs gewünscht, die sich dynamisch aufteilen lassen, so das im Optimalfall eben auch 2 AVX Befehle pro Takt von einem Core kommen können.

DAS wäre wieder eine richtig starke FPU gewesen, ganz unabhängig von der ISA. Die ist nämlich durchaus gut, auch wenn man an der Performance (Latenz) einiger Befehle arbeiten muss.

Mh, also werden alle Instruktionen von den zwei Threads bei allen EX-Pipes berechnet?
Ab IVB hat Intel die uop queue auch dynamisch dann in zwei Hälften beim SMT Betrieb aufgeteilt, ohne waren halt alle Einträge für einen Thread nutzbar.

Es ist ganz einfach.

Du kannst von 2 Threads parallel Instructionen entgegennehmen/decodieren, wenn du SMT hast. Die Aufteilung der Hardwareressourcen zwischen den Instructionen der beiden Threads unterliegt dabei (eigentlich) keinerlei Restriktionen. Du kannst alle Pipes beliebig aufteilen, je nachdem, was eben gerade frei ist.

[S940]

@mczak (http://www.forum-3dcenter.org/vbulletin/member.php?u=31450):
Mag sein, aber im Vergleich zum Rest des Chips ist die FPU immer noch gut ^^
Bei der 2-Takt-Latenz hast Du schon recht, da hat AMD eindeutig auf mehr Takt gewettet, was aber dann doch in die Hose ging. Bin mal gespannt ob sie die Latenz bei der 256er FPU verbessern. Wenn sie in Zukunft eher bulk Prozesse verwenden wollen, dann sollten sie vielleicht kleinere Kuchen backen. Es hieß ja schon, dass die synth. FPU mit nur noch 3 Ports ein bisschen weniger Takt-Spielraum böte. Da böte es sich wiederum an die Latenzen auf 1 runterzuschrauben.

Die Latenzen fpr Transfers in andere Domains hat Piledriver glaube ich schon etwas verbessert. Aber gut waren die auch nicht auch klar. Aber halt immer noch besser als der restliche Chip ^^ Bei den INT-Clustern lief anfangs ja nichtmal der Hardware-Dividierer.

Ich habe nicht von der ISA gesprochen, sondern von der breite der FPU, also vom Durchsatz.Ja das ist mir schon klar was Du meintest, nur hat AMD die FPU halt nach ihrer SSE5-ISA entworfen. Dass der Chip dann auf die schnelle auch noch AVX256 kompatibel gemacht wurde sehe ich eher positiv, mehr war in der Zeit einfach nicht drin.

Edit:
Also limitiert vor dieser Betrachtung etwas anderes?
Oder sind das Vorteile, die bei Intels sehr hohen IPC sich kaum noch auf den Durchschnitt niederschlage
Ja es limitiert der Code, mehr als ~2 unabhängige Befehle im Schnitt gibts nur sehr selten. 3 macht vielleicht noch bei Peaks nen Sinn, aber das zusätzliche Rechenwerk, das Intel jetzt mit Haswell eingeführt hat bringt ziemlich sicher nur etwas beim SMT Betrieb. Höchstens ein paar Promill bei Single-Thread, oder bei irgendwelchen Superspezialfällen.

Der Rest der Verbesserungen stehen alle im Zeichen von FMA und AVX2. Ein doppelt so breites L1-Interface, anstatt 2x128bit jetzt 2x256bit zum L1 ist schon ne tolle Sache, aber ohne FMA oder zwei parallelen 256bit AVX Instruktionen bringt das auch fast nichts.

Allerdings hatte ich mit auch mehr SMT-Leistung erhofft. Aber naja mal abwarten, bis es bessere Tests gibt.

Haswell zu Ivy ist quasi sowas wie der Bulldozer zum K10, nur ohne den IPC-Einbruch, deswegen nicht so schlimm. :biggrin:

[robbitop]

Ne es gibt immerhin ne Roadmap für FD-SOI. 20nm wurde da vor ein paar Monaten für ne 14nm Node gestrichen:
http://www.abload.de/img/neueroadmapwcu74.png
Ist ST in dem Bereich nicht mausetot? Oder ordne ich da was falsch ein? Führt das sonst jemand weiter?

Die FPUs ändern nichts, die Decoder etwas, aber beim Front-End ist v.a. die Sprungvorhersagelogik der Flächengroßverbraucher. Die ist weiterhin gemeinsam benutzt und wird bei Steamroller mal eben verdoppelt. Das könnte man sich bei nem Single-Thread Design nicht leisten.
Mit verdoppelt meinst du die Breite der FPUs nicht deren Anzahl oder?


Die FPU ist Klasse, Du vergisst da das SSE5 / AVX und FMA3/FMA4- Hickhack im Vorfeld. Das nur 128bit kamen war klar, da das Grunddesign auf SSE5 aufbaute, das nur 128bit vorsah. Das dann trotzdem AVX256 ging und auch schon FMA unterstützt wurde, ist doch Klasse. Intel ist fast 2 Jahre bei FMA hintendran.
Also wenn etwas beim BD gut war, dann wars die FPU. Halt blöd, dass keiner FMA-Code nutzt, aber rein vom technischen Standpunkt her gesehen ist die FPU ein Sahnestückchen :)
Toller Beitrag. :) Da lernt man immer wieder was neues.


Haswell zu Ivy ist quasi sowas wie der Bulldozer zum K10, nur ohne den IPC-Einbruch, deswegen nicht so schlimm. :biggrin:
Mal wieder aus Laiensicht (also nicht sauer sein, wenn ich BS schreibe - freue mich um jeden Hinweis und jede Korrektur):
Die Aussage verwundert mich jetzt etwas. Bulldozer und K10 sind AFAIK vollkommen unterschiedliche Grund-µ-Archs. Haswell ist AFAIK ein erweiterter Ivy-Sandy-Nehalem-Conroe. Ich habe das immer als Evolution einer Grund-µ-Arch verstanden, die ihren Ursprung im Conroe (oder sogar schon im Banias) hatte.

Außerdem fügte Haswell im Kern Ausführungsressourcen hinzu (4 way statt 3 way) anstatt diese zu entfernen und zu verteilen (K10 3way zu BD 2x 2 way).

[Skysnake]

@mczak (http://www.forum-3dcenter.org/vbulletin/member.php?u=31450):
Ja das ist mir schon klar was Du meintest, nur hat AMD die FPU halt nach ihrer SSE5-ISA entworfen. Dass der Chip dann auf die schnelle auch noch AVX256 kompatibel gemacht wurde sehe ich eher positiv, mehr war in der Zeit einfach nicht drin.

Nein ist dir offenbar nicht. Die BD FPU ist pro Int-Core schlechter als bei K10, bzw schlechter als bei SB.

Der K10 hat noch den dritten Issue-Port. Bulldozer hat, sobald nicht ein Int-Core sich die ganze FPU schnappen kann nur 2 128er Bit FMAC. Klar, das ist besser als 1x128Bit ADD und 1x128Bit MUL, aber AMD operiert nicht im Vakuum, und da bekomme ich dann jetzt auch die Kurve zu SB. ;)

K10 hatte damals ne starke FPU. BD im Prinzip auch, aber im Vergleich nicht mehr so stark wie K10. Bei AVX Code z.B. leistet 1 ganzes Modul nur so viel wie SB Core, einfach weil ein Int-Core sich die komplette FPU dafür schnappen muss.

Intel hat dafür den "Fehler" gemacht, das man die breitere FPU eben nur für AVX nutzen kann, und Sie sonst tot daliegt. Korrigiert mich bitte, wenn ich falsch liege, aber meines Wissens wird nicht einfach ein AVX Befehl auf 2 Takte aufgesplittet. Macht ja auch keinen Sinn, dann wäre man ja nicht schneller als mit SSE im Prinzip.

Hätte AMD bereits mit BD 1.0 die 2x256Bit FPU gebracht, das Ding wäre wohl ziemlich hot gewesen für sehr FP lastigen Code. Gerade im HPC-Bereich hätte man damit wohl wieder glänzen können, auch wenn man an anderen Stellen dennoch Schwächen hat.

[robbitop]

AMD ist bei der Modulbauweise eben davon ausgegangen, dass die FPU selten der Flaschenhals ist, oder? Sonst hätte man die doch kaum geteilt pro Modul. Die Int Execution hingegen hat man doppelt pro Modul.

[Locuza]

Hätte AMD bereits mit BD 1.0 die 2x256Bit FPU gebracht, das Ding wäre wohl ziemlich hot gewesen für sehr FP lastigen Code. Gerade im HPC-Bereich hätte man damit wohl wieder glänzen können, auch wenn man an anderen Stellen dennoch Schwächen hat.
Also das es "hot" gewesen wäre, dem kann ich zustimmen, aber nicht unbedingt positiv gemeint.
Mit 2x 256 Bit FMACs, würde die Hälfte wie bei Intel eben brach liegen, für den Consumer meistens ohne Nutzen, dafür wäre das ganze Design komplizierter geworden und Bulldozer noch fetter als 315mm².
Im HPC-Bereich hätte AMD deswegen ja deutlich mehr Verkäufe tätigen müssen, um wirtschaftlich besser mit einer fetten FPU dazustehen.

[Skysnake]

AMD ist bei der Modulbauweise eben davon ausgegangen, dass die FPU selten der Flaschenhals ist, oder? Sonst hätte man die doch kaum geteilt pro Modul. Die Int Execution hingegen hat man doppelt pro Modul.
Mit den doppelten Int-Cores holt man sich halt schlicht Core-Count und versucht den Kontextwechseloverhead zu minimieren.

Man ging wohl beim Design von vielen kleinen Threads aus, die recht Integerlastig sind, aber zwischendurch auch mal breite FP-Insturctionen absetzen können. Aber eben nicht Dauerhaft, da z.B. einfach I/O-Bound.

Die Entwicklung der Microserver schlägt aber genau in die Kerbe. AMD war einfach viel zu langsam in der Entwicklung, wie es scheint.

Dass die FPU selten der Flaschenhals ist, würde ich nicht sagen, auch nicht bei den Designüberlegungen. Dann hätte man sich die FlexFPU sparen können. Man ging wie gesagt wohl eher von I/O-Bound aus.

Also das es "hot" gewesen wäre, dem kann ich zustimmen, aber nicht unbedingt positiv gemeint.
Mit 2x 256 Bit FMACs, würde die Hälfte wie bei Intel eben brach liegen, für den Consumer meistens ohne Nutzen, dafür wäre das ganze Design komplizierter geworden und Bulldozer noch fetter als 315mm².
Im HPC-Bereich hätte AMD deswegen ja deutlich mehr Verkäufe tätigen müssen, um wirtschaftlich besser mit einer fetten FPU dazustehen.
Ja, "hot" wäre das wohl durchaus gewesen ;D

Man hätte aber wohl auch "einfach" den Takt etwas senken können.

Ich seh aber keinen Grund, warum die Hälfte hätte brachliegen müssen. Man müsste nur die Datenpfade anpassen müssen, oder eben das nur auf Registerebene voll ausschöpfen. Du vergisst hier ja, das man mit der FlexFPU genau hierfür ja die Vorarbeiten bei AMD bereits gemacht hat. Man hätte eben nur 2 AVX Instructionen maximal absetzen müssen, statt nur 2 pro Core. Das sollte aber durchaus machbar sein. Ich seh da jetzt keinen Grund, warum in AMDs Design das Ganze so laufen sollte wie bei Intel. Bei Intel sieht das für mich eher nach "noch am Ende drangeflanscht" aus mit AVX.

Rückblickend betrachtet wären 2 Module mit 2x256Bit FPU wohl besser gewesen, als 4 Module mit 2x128Bit FPU, also zumindest in meinen Augen.

Man hätte halt die ganze Cachekohärenz leicht machen können bzgl Latenzen usw usw usw.

Das ganze Design wäre einfacher geworden, auch wenn man sich natürlich die Tür offenlassen muss für 4&8 Moduler. Die Architektur soll ja noch etwas halten.

AMD halt wohl die Entwicklung einfach falsch eingeschätzt. Dumm gelaufen sozusagen. Am Ende stehen aber die gleichen Ergebnisse, wie es aussieht.

1. viele Kerne, dann stark machen
2. weniger, aber starke Kerne die man dann vermehrt

Tja, AMD hat sich für Variante 1 entschieden, Intel für 2, und hat damit die Bedürfnisse von Software besser getroffen als AMD.

Wobei Intel "einfach" 1 und 2 gleichzeitig gemacht hat, wenn man ehrlich ist :freak:

[HOT]

[...]

Haswell zu Ivy ist quasi sowas wie der Bulldozer zum K10, nur ohne den IPC-Einbruch, deswegen nicht so schlimm. :biggrin:

Hey den Vergleich find ich richtig gut, weil er zeigt, dass Haswell kein Nachfolger von Sandy ist, sondern in Wirklichkeit von Bloomfield, da Haswell vom amerikanischen Designteam parallel entwickelt wurde, während Sandy der eigentliche Conroe-Nachfolger vom israelischen Entwicklungsteam ist. Sandy Bridge hat gewissermaßen Banias als Stammvater und Haswell Banias und Tejas. Ich könnt mir vorstellen, dass Haswell ursprünglich als High-End-Design geplant war, während Sandy eher ein Mobildesign ist. Wie beim Core2 aber war Sandy so stark, dass man ihn letztendlich auf allen Märken untergebracht hat.




Entweder AMD bezahlt IBM für die Mitbenutzung der High-End-Prozesse oder GloFo erbt diese Prozesse und AMD bezahlt dafür. Wie auch immer, AMD wird an seinen HP-Prozess kommen, dieser Meinung kann ich mich anschließen. Es macht einfach keinen Sinn ein High-End-Design auf LP-Prozessen aufzusetzen und ich glaub auch nicht mehr dran, dass man es versuchen wird. Man will nur keine eigenen mehr entwickeln, wenn andere diese Arbeit tun können, das kann ich verstehen.

[robbitop]

Mit den doppelten Int-Cores holt man sich halt schlicht Core-Count und versucht den Kontextwechseloverhead zu minimieren.

Man ging wohl beim Design von vielen kleinen Threads aus, die recht Integerlastig sind, aber zwischendurch auch mal breite FP-Insturctionen absetzen können. Aber eben nicht Dauerhaft, da z.B. einfach I/O-Bound.

Die Entwicklung der Microserver schlägt aber genau in die Kerbe. AMD war einfach viel zu langsam in der Entwicklung, wie es scheint.

Dass die FPU selten der Flaschenhals ist, würde ich nicht sagen, auch nicht bei den Designüberlegungen. Dann hätte man sich die FlexFPU sparen können. Man ging wie gesagt wohl eher von I/O-Bound aus.

Danke an euch für all diese lehrreichen Hintergründe. :)

Wäre es denn sinnvoll aus 2x FPUs -> 4x FPUs zu machen oder ist die Verdopplung der Breite (nur für AVX nutzbar?) sinnvoller?

Hey den Vergleich find ich richtig gut, weil er zeigt, dass Haswell kein Nachfolger von Sandy ist, sondern in Wirklichkeit von Bloomfield, da Haswell vom amerikanischen Designteam parallel entwickelt wurde, während Sandy der eigentliche Conroe-Nachfolger vom israelischen Entwicklungsteam ist. Sandy Bridge hat gewissermaßen Banias als Stammvater und Haswell Banias und Tejas. Ich könnt mir vorstellen, dass Haswell ursprünglich als High-End-Design geplant war, während Sandy eher ein Mobildesign ist. Wie beim Core2 aber war Sandy so stark, dass man ihn letztendlich auf allen Märken untergebracht hat.

Das würde ja bedeuten, dass Intel 2x µ-Archs parallel laufen hat. Dazu sehen sie einfach zu gleich aus. Das ist IMO schon eine Evolution. Nur weil die Teams räumlich getrennt sind, heißt das nicht, dass der Entwicklungsprozess getrennt ist. Die werden sich schon absprechen, was wer wann einbaut und die Einbauten des anderen möglichst versuchen mit zu nutzen. Ich gehe davon aus, dass die beiden versuchen, halbwegs synchron mit gleicher Datenbasis zu arbeiten. Alles andere wäre doch Ressourcenverschwendung.

[S940]

Nein ist dir offenbar nicht. Die BD FPU ist pro Int-Core schlechter als bei K10, bzw schlechter als bei SB.
Weiss ich doch, aber wenn Du mir wieder so pauschal kommst, komm ich pauschal mit dem Spezialfall FMA :biggrin: Mit dem hast Du identische Flops, da FMA wie 2 extra ADD-Pipes zählen.
128bit FMACs waren nunmal schon laaange geplant. Das dann auch noch auf 256bit umzuarbeiten wäre sicherlich "nett" gewesen, aber viel zu kompliziert in der Zeit, die AMD hatte. BDv1 war doch sowieso schon ein unfertiges Flickwerk. In dem Kontext bleib ich dabei, dass die FPU topp war, der Rest ist doch nur noch schlechter ^^

Der K10 hat noch den dritten Issue-Port. Bulldozer hat, sobald nicht ein Int-Core sich die ganze FPU schnappen kann nur 2 128er Bit FMAC. Klar, das ist besser als 1x128Bit ADD und 1x128Bit MUL, aber AMD operiert nicht im Vakuum, und da bekomme ich dann jetzt auch die Kurve zu SB. ;)Ja, wenn Du da jetzt meinst, dass FMA so gut wie keiner nützt, muss man dazu dann aber erwähnen, dass die HPC-Kunden, die eigene Spezialprogramme haben, das sicherlich nutzen.

K10 hatte damals ne starke FPU. BD im Prinzip auch, aber im Vergleich nicht mehr so stark wie K10. Bei AVX Code z.B. leistet 1 ganzes Modul nur so viel wie SB Core, einfach weil ein Int-Core sich die komplette FPU dafür schnappen muss.
Ja und mit FMA Code? ;-)
(sorry fürs wiederholen, aber es passt halt immer wieder und ich schrieb oben ja ausdrücklich, dass ich das "Sahnestückchen" nur unter technischen Gesichtspunkten sehe (damit meinte ich, dass Coding-Sachen ausgeklammert werden)^^).

Intel hat dafür den "Fehler" gemacht, das man die breitere FPU eben nur für AVX nutzen kann, und Sie sonst tot daliegt. Korrigiert mich bitte, wenn ich falsch liege, aber meines Wissens wird nicht einfach ein AVX Befehl auf 2 Takte aufgesplittet. Macht ja auch keinen Sinn, dann wäre man ja nicht schneller als mit SSE im Prinzip.
Jo, die FPU liegt ohne AVX256 Code brach, da die alten SSE-Programme nur 128bit nutzen.
Da gibts auch immer wieder mal Berichte, dass übertaktet Sandys und Ivys bei der AVX-Version von LinX deutlich wärmer werden und eigentliche Stabile-OC-Konfigurationen abschmieren. ISt aber ja ach kein Wundern, immerhin wird da mal plötzlich die doppelte FP-Rechenleistung abgerufen.
Hätte AMD bereits mit BD 1.0 die 2x256Bit FPU gebracht, das Ding wäre wohl ziemlich hot gewesen für sehr FP lastigen Code. Gerade im HPC-Bereich hätte man damit wohl wieder glänzen können, auch wenn man an anderen Stellen dennoch Schwächen hat.Ja hätte wäre wenn ... das Leben ist nunmal kein Wunschkonzert. Hätte AMD BD 2007 in 20nm mit 7 Ghz gebracht, wärs auch dodaaaal hot gewesen ;-)
Ich sehs da wohl noch ein Stück pragmatischer als Du. Für das was AMD hat(te) und in der Zeit war die FP schon gut.
Ist ST in dem Bereich nicht mausetot? Oder ordne ich da was falsch ein? Führt das sonst jemand weiter?
Das ist die große Preisfrage, die ich mir im Moment auch stelle. ST wird nach 28nm nichts mehr in Ihrer eigenen Fab machen. Trotzdem haben sie die Roadmap vorgestellt, das würde implizieren, dass sie GF dann dafür zahlen und/oder das ein "eine Hand wäsche die Andere"-Geschäft wird, bei dem ST die Grundlagenforschung macht, GF dafür den Prozess bekommt und ihn anbietet.
Verglichen mit nem Bulk-Prozess ist ein SOI Prozess eigentlich kein High-Tech, High-TEch ist eigentlich nur die super-dünne SOI-Schicht auf den Wafer gleichmäßig aufbringen zu können. Das ist also eher Soitecs Problem, dass sie scheinbar aber schon gelöst haben.

Mit verdoppelt meinst du die Breite der FPUs nicht deren Anzahl oder?Joho, klar :)

Die Aussage verwundert mich jetzt etwas. Bulldozer und K10 sind AFAIK vollkommen unterschiedliche Grund-µ-Archs. Haswell ist AFAIK ein erweiterter Ivy-Sandy-Nehalem-Conroe. Ich habe das immer als Evolution einer Grund-µ-Arch verstanden, die ihren Ursprung im Conroe (oder sogar schon im Banias) hatte.
Ja da hast Du schon recht, die Ausgangslage ist schon unterschiedlich. Die Aussage stimmt natürlich nur bei ner gewissen Grobansicht, geh nicht zu sehr ins Detail. Sie war eher spassig/flapsig gemeint ;-)

Daran, dass Haswells IPC nicht deutlich ansteigt sieht man schon, dass es nicht so trivial ist ne FMA-FPU in ein Design zu integrieren. Intel hatte da jetzt noch den "Vorteil", dass sie ein bestehendes Design hatte, AMD machte auch noch den Rest neu und musste erstmals nen SMT-Betrieb der FPU debuggen.

Gut - Intel liefert auch noch AVX2 in den INT-Pipes nach, aber das ist keine so große Änderung, das Prinzip wurde ja schon bei AVX getestet. Der Herstellungsprozess bleibt auch gleich, also bleibt unterm Strich nur FMA als große Neuerung übrig. Außer der GPU natürlich noch, aber das soll hier mal kein Thema sein.


Die Entwicklung der Microserver schlägt aber genau in die Kerbe. AMD war einfach viel zu langsam in der Entwicklung, wie es scheint.
Tja .. schau auf AMDs Umsatz und auf Intels Gewinn und Du wirst sehen, dass Intel bei den Zahlen vorne liegt .. AMD war schon immer hintendran, das ist normal, deswegen erwarte ich vielleicht auch weniger ;-)

Man hätte aber wohl auch "einfach" den Takt etwas senken können.Ja, aber dann sind wir wieder bei anderen Designüberlegungen wie den FP-Instruktionen, die 2 Takte brauchen, dem für die Mickergröße von 16kB ziemlich langsamen L1 Takt und all dem anderen Zeugs. Sie hatten das Design wohl schon für mehr Takt eingeplant.
Wobei man dazu sagen muss, dass so ein Design auch für 3-4 Shrinks geplant ist.
A.Stiller von der ct schrieb anno dazumal beim Athlon, der mit 500 Mhz debütierte, dass das Design für 1GHz++ gut sei, das wars am Ende auch, Intel hatte dagegen um die 1 GHz größere Probleme. Eventuell könnte AMD den Coup wiederholen.
Schauen wir mal, was der Takt in 14nm macht *G*

Blöderweise hatte AMD mit BD aber erstmal ne schlechtere IPC, ganz im Gegensatz zum Athlon vs. K6 *G* und außerdem hat man mittlerweile Cores, Cores, Cores.

Ich seh aber keinen Grund, warum die Hälfte hätte brachliegen müssen. Man müsste nur die Datenpfade anpassen müssen, oder eben das nur auf Registerebene voll ausschöpfen. Du vergisst hier ja, das man mit der FlexFPU genau hierfür ja die Vorarbeiten bei AMD bereits gemacht hat. Man hätte eben nur 2 AVX Instructionen maximal absetzen müssen, statt nur 2 pro Core. Das sollte aber durchaus machbar sein. Ich seh da jetzt keinen Grund, warum in AMDs Design das Ganze so laufen sollte wie bei Intel. Bei Intel sieht das für mich eher nach "noch am Ende drangeflanscht" aus mit AVX.Naja, drangeflanscht vielleicht, aber ich würde sagen, dass das mit dem Re-Use der INT-Leitungen sehr elegant und praktisch gelöst ist. Das ginge bei AMD nicht. Die müssen da neue Leitungen legen, das kostet ...
Außerdem hätte das L1-Interface dann schon damals verdoppelt werden müssen. Für 256bit FMA braucht man halt 2x256 = 512 bit Breite. Das wiederum erhöht auch den Druck auf den L2, das Interface dorthin sollte man wohl auch verbessern, insbesondere deswegen, da der bei AMD ja gemeinsam benützt wird.

Da hakte es aber auch schon ohne 256bit FPU. Wahrscheinlich wären die 256bit Pipes im Endeffekt verhungert.

So oder so zieht 256bit nen Rattenschanz an tieferen Designeingriffen hinterher. Dass sich AMD das bei BDv1 nicht auch noch aufbürdeten haben sie mein Verständnis. Genutzt wirds sowieso nicht oft, und selbst HPC-Assembler-Profis hätten womöglich mit vielen Limits kämpfen müssen.

Rückblickend betrachtet wären 2 Module mit 2x256Bit FPU wohl besser gewesen, als 4 Module mit 2x128Bit FPU, also zumindest in meinen Augen.Kann man sicherlich so sehen, aber die große Frage ist, obs zeitig machbar gewesen wäre ... ich denke eher nicht.

Man hätte halt die ganze Cachekohärenz leicht machen können bzgl Latenzen usw usw usw.
Ja aber dafür hast Du eben das Problem die Pipes mit Daten zu versorgen. Pro 256bit FMAC 512bit, also bei 2 Pipes 1 Mbit ... das ginge sicherlich noch zu zwei L1-Caches, aber dann beim L2 .. *öörks*

Das ganze Design wäre einfacher geworden, auch wenn man sich natürlich die Tür offenlassen muss für 4&8 Moduler. Die Architektur soll ja noch etwas halten.Naja sehe ich etwas anders, siehe oben. Im Zweifelsfall lieber 4 einfachere Module, als 2 komplexe, die dann nicht fertig werden.

Tja, AMD hat sich für Variante 1 entschieden, Intel für 2, und hat damit die Bedürfnisse von Software besser getroffen als AMD.
Jo da wären wir wieder bei Software und damit FMA (das passt echt immer ^^).
Wobei Intel "einfach" 1 und 2 gleichzeitig gemacht hat, wenn man ehrlich ist :freak:Ja wobei sie bei den "vielen Kernen", also den -E Varianten ziemlich schwächeln,. Andauernd irgendwelche Bugs und verspätungen bei Ivy-E. Da scheint der 22nm Finfet-Prozess bei großen Dies wohl noch Probleme zu bereiten.
Entweder AMD bezahlt IBM für die Mitbenutzung der High-End-Prozesse oder GloFo erbt diese Prozesse und AMD bezahlt dafür.
Jo irgendeiner muss zahlen und Zwischenhändler verteuern den Endpreis ...
Eventuell war das bei AMD einfach nur ne Sparmaßnahme und sie Stottern den SHP-Preis zukünftig in ner Art Raten-Form über teurere SHP-Wafer-Preise ab.
Intel bietet AMD gerade ne Chance, bei Haswell stagniert die Leistung, wenn sie da nun demnächst 256bit FPUs nachrüsten könnte das Rennen wieder offener sein, die AMD-Chips konkurrenzfähiger und ein teurerer SHP-Wafer dadurch eventuell bezahlbar/rentabel.

Aber mal die nächsten Roadmaps abwarten...

Edit:
@robbitop:
Wäre es denn sinnvoll aus 2x FPUs -> 4x FPUs zu machen oder ist die Verdopplung der Breite (nur für AVX nutzbar?) sinnvoller?Intel bewirbt AVX256 und Intel hat fast 90% des Markts. Damit ist klar, dass sich 256bit durchsetzen werden. 2x256bit FMACs sollten demnach gegenüber 4x128 Pipes vorzuziehen sein, man spart sich dabei auch Schedulerports/Decodingaufwand(anstatt 2x128bit Ops muss nur 1x256 decodiert werden) und Plätze in der Pipeline (statt 2 Ops gibt nur eine in den diversen Puffern zwischen den Pipelinestufen).

[Skysnake]

Danke an euch für all diese lehrreichen Hintergründe. :)

Wäre es denn sinnvoll aus 2x FPUs -> 4x FPUs zu machen oder ist die Verdopplung der Breite (nur für AVX nutzbar?) sinnvoller?

Für AVX ist es natürlich optimal, weil eben jeder Int-Core dann sinnvoll AVX nutzen kann.

Aber auch bei SSE kannst du deine Vorteile daraus ziehen, so lange du eben die Daten schnell genug rangeschafft bekommst, damit die Pipeline nicht leer läuft, und eben immer 2 SSE Instructionen hast, die unabhängig voneinander sind.

Das sollte aber im Normalfall nicht DAS Problem sein. Wenn man nichtmal 2 unabhängige SSE Instructionen hat, dann wird man wohl gar nicht erst anfangen SSE zu nutzen, da viel zu selten eingesetzt.

Das Problem ist wirklich, wie ich die Daten zu den Registern bekomme, denn Registerrenaiming blablub wird natürlich viel schwieriger für 2 parallele Instructionen als nur für eine. Man muss halt mit weniger Ressourcen auskommen, oder die Hardwareressourcen mit steigern.

Im Optimalfall brüchte man halt für 2x256 Bit Datenpfade, die so dreimal so breit sind, also 1536 Bit, damit man in jedem Takt die A*B=C komplett mit laod/store durchführen kann.

Dann hätte man halt 0 Datenreuse, und würde quasi direkt aus dem L1 heraus arbeiten.

So breit wird man aber nicht gehen.

[Locuza]

Man hätte aber wohl auch "einfach" den Takt etwas senken können.

Ich seh aber keinen Grund, warum die Hälfte hätte brachliegen müssen. Man müsste nur die Datenpfade anpassen müssen, oder eben das nur auf Registerebene voll ausschöpfen. Du vergisst hier ja, das man mit der FlexFPU genau hierfür ja die Vorarbeiten bei AMD bereits gemacht hat. Man hätte eben nur 2 AVX Instructionen maximal absetzen müssen, statt nur 2 pro Core. Das sollte aber durchaus machbar sein. Ich seh da jetzt keinen Grund, warum in AMDs Design das Ganze so laufen sollte wie bei Intel. Bei Intel sieht das für mich eher nach "noch am Ende drangeflanscht" aus mit AVX.

Rückblickend betrachtet wären 2 Module mit 2x256Bit FPU wohl besser gewesen, als 4 Module mit 2x128Bit FPU, also zumindest in meinen Augen.

Man hätte halt die ganze Cachekohärenz leicht machen können bzgl Latenzen usw usw usw.

Das ganze Design wäre einfacher geworden, auch wenn man sich natürlich die Tür offenlassen muss für 4&8 Moduler. Die Architektur soll ja noch etwas halten.

AMD halt wohl die Entwicklung einfach falsch eingeschätzt. Dumm gelaufen sozusagen. Am Ende stehen aber die gleichen Ergebnisse, wie es aussieht.

Jetzt mal NUR den Gedanken 2x 256-Bit weiter gespult:
Bulldozer hätte damit zwar doppelten AVX -Durchsatz gehabt, allerdings keinen höheren Output bei 128-Bit Erweiterungen, wie SSE.
Man würde das Design wegen der Anpassung fett machen, zusätzliche Entwicklung hineinstecken müssen und hätte dann nur einen Vorteil bei einer Erweiterung, die beim Consumer sowieso auf Jahre eine Nische sein wird.
Aus Preis/Leistungssicht überhaupt nicht clever in meinen Augen.

Die dadurch höhere Attraktivität auf dem HPC-Markt hätte die Nachteile aus meinen Augen nicht ausgleichen können, bzw. es wäre nicht mehr Geld hinein gewandert, als dieses Design zusätzlich gekostet hätte.

Der andere Gedanke mehr auf Big-Cores zu gehen mit mehr IPC und besseren Latenzen wäre sicherlich auch zu Teilen begrüßenswert gewesen, allerdings hat AMD mit Absicht auf stärkere Parallelisierung gesetzt, man hätte ansonsten wohl in keiner Disziplin mitziehen können, allerdings denke ich das wäre durchaus besser balanced und hätte global mehr Abnehmer gefunden und sich mehr rentiert, solange AMD ein guten Preis verlangt hätte.

[Skysnake]

@Locuza und teils auch an S940:
Na du darfst das nicht isoliert sehen. Die Auslegung auf Fetcores statt Modulen zieht halt einen Rattenschwanz an Anpassungen hinter sich her, die sich von den Decodern bis hoch zum L3 zieht.

Da bleibt praktisch kein Stein auf dem anderen. Die Modulbauweise mit den vielen Cores macht z.B. Kohärenz ziemlich schwierig. Intel hat da auch mit zu kämpfen. AMD hat da insbesondere mit HT damals schon einen richtig guten Griff gemacht. MIC z.B. hat 61 Cores, und trickst teilweise ganz schön, Kohärenz ist dort aber ein ziemliches thema, einfach weils dir das die Performance total in den Keller rauschen lassen kann.

Weniger Cores wären also einfacher kohärent zu halten, die FlexFPU wäre einfacher zu machen usw usw.

So was muss man aber SEHR früh in der Designphase mal entscheiden, und dann ist das halt so. Da kannste nicht anfangen mal kurz zu wechseln. Da fängste ziemlich von Null wieder an.

@S940:
Ist auch richtig überwiegend.

Du darfst wie oben gesagt, das aber nicht isoliert sehen. AMD konnte sich klarerweise nicht mehr umentscheiden, und musste den Weg gehen, es war halt wohl nur der Falsche. Leider für sie...

Der Weg, der jetzt eingeschlagen wird/ist, ist meiner Meinung nach auch schon durchaus länger geplant. Man kann aber eben nicht alles machen, und braucht einige grundlegende Aufbauarbeiten für die neuen Sachen.

Ist halt wie wenn man von Stuttgart nach Frankfurt will. Gleich am Anfang muss man sich entscheiden, ob man über Karlsruhe oder Heilbronn fährt. Hü oder Hot. Eine Entscheidung muss her, und es passiert oft, das man eben sich falsch entscheidet, und in den Stau fährt, auch wenn am Ende das gleiche Ziel steht.

[Locuza]

Ich verstehe nicht Skysnake wie du auf die Punkte kommst?
Genau das meinen wir doch bzw. ist offensichtlich.
Es ging ja nur um Meinungen bezüglich AMDs Weg und der möglichen, fiktiven Alternative, wo du selber das mit weniger Modulen vorgeschlagen hast.

[Ronny145]

Hey den Vergleich find ich richtig gut, weil er zeigt, dass Haswell kein Nachfolger von Sandy ist, sondern in Wirklichkeit von Bloomfield, da Haswell vom amerikanischen Designteam parallel entwickelt wurde, während Sandy der eigentliche Conroe-Nachfolger vom israelischen Entwicklungsteam ist. Sandy Bridge hat gewissermaßen Banias als Stammvater und Haswell Banias und Tejas. Ich könnt mir vorstellen, dass Haswell ursprünglich als High-End-Design geplant war, während Sandy eher ein Mobildesign ist. Wie beim Core2 aber war Sandy so stark, dass man ihn letztendlich auf allen Märken untergebracht hat.


Das ist falsch. Haswell baut auf Ivy Bridge auf. Sandy Bridge/Ivy Bridge ist die Ursprungsbasis für Haswell.


Nur weil die Teams räumlich getrennt sind, heißt das nicht, dass der Entwicklungsprozess getrennt ist. Die werden sich schon absprechen, was wer wann einbaut und die Einbauten des anderen möglichst versuchen mit zu nutzen. Ich gehe davon aus, dass die beiden versuchen, halbwegs synchron mit gleicher Datenbasis zu arbeiten. Alles andere wäre doch Ressourcenverschwendung.

Davon ist auszugehen. Aktuelles Beispiel: Der C9/C10 Stromsparmodus für Haswell ULT war ursprünglich erst für Skylake vorgesehen. Skylake wird von den Israelis entwickelt. Es gab regelmäßige Besuche der Israelis nach Oregon, um C9/C10 schon für Haswell ULT einzubauen.

[S940]

Weniger Cores wären also einfacher kohärent zu halten, die FlexFPU wäre einfacher zu machen usw usw.
Auf die Kohärenz komm ich später nochmal zurück, aber wieso sollte das Auswirkungen auf die FPU haben?

So was muss man aber SEHR früh in der Designphase mal entscheidenJo, das ist der springende Punkt.


Du darfst wie oben gesagt, das aber nicht isoliert sehen. AMD konnte sich klarerweise nicht mehr umentscheiden, und musste den Weg gehen, es war halt wohl nur der Falsche. Leider für sie...
Ja gut, dann sind wir uns eigentlich einig, bzw. redeten vorbei. Ich finde die CPU für den eingeschlagenen Weg topp, Du kritisierst dagegen eher den eingeschlagenen Weg.

Der Weg stand ja schon seit 2003 oder so fest, seit der p6 Entwickler bei AMD angestellt war und das Modulkonzept erfand. Seitdem doktorten noch viele Leute daran herum, aber 128bit blieb fest, was anderes gabs damals ja gar nicht.

Da kann man jetzt wieder den Weg zurück zur Kohärenz finden. Ursprünglich war das Teil wohl nur als Single-Core mit 2 Threads angedacht und die Kohärenz wurde nachträglich "hinzugepfuscht".

Da wir jetzt bei der Kohärenz sind, hab ich ne interessante Frage, letztens hab ich mir die CPU-ID-Bits in den AIDA-Dumps angeschaut. Wenn ich die richtig entziffer, dann steht der L3 bei den Orochis auf "ist inklusive". Der L2 kann damit aber wohl ja nicht gemeint sein .. also muss es der L1 sein. Sind die L1 im L3 ebenfalls gespiegelt? Wusste ich entweder nicht, oder ich habs vergessen ^^

Bit-Erklärung:
Cache inclusivity. A value of 0 indicates that this cache is not inclusive of lower
cache levels. A value of 1 indicates that the cache is inclusive of lower cache
levelshttp://support.amd.com/us/Processor_TechDocs/24594_APM_v3.pdf

CPU Dump:
CPUID 8000001D: 00000121-00C0003F-0000003F-00000000 L1D-Cache
CPUID 8000001D: 00004122-0040003F-000001FF-00000000 L1I-Cache
CPUID 8000001D: 00004143-03C0003F-000007FF-00000001 L2-Cache
CPUID 8000001D: 0001C163-0FC0003F-000007FF-00000001 L3-Cache Quelle: http://instlatx64.atw.hu/

Wenn da nun der Kohärenztraffic über den L3 liefe, wäre das eventuell die Erklärung, weshalb ein L3 übertakten selbst beim Orochi noch relativ viel bringt. Eigentlich hatte ich erwartet, dass sich da nicht mehr viel tut, da ja der L2 schon ziemlich groß ist.

Wäre in der Tat dann "etwas" kompliziert, aber naja, sind halt 8 Kerne ... dafür sind sie schlank und takten besser ^^

Das ist eindeutig ein konzeptueller Nachteil von CMT. Aber das wird mit HSA und der kohärenten GPU dann nur noch schlimmer. Irgendwie werden sie das hoffentlich schon deichseln ;-)

Wäre mal interessant, ob AMD wg. der Kohärenz in Zukunft vielleicht auch auf L2-inklusive L3-Caches wechselt? Sollte sich doch rentieren, oder?
Aber das wäre wohl auch wieder eher gegen den CMT-Ansatz, denn dann stiege der L3-Traffic und 2 Kerne eines Modules würden bei nem engen Interface zu stark ausgebremst werden. Naja lassen wir uns überraschen ^^

[Locuza]

@ S940

Sicher vergessen.
Aber ich habe in Erinnerung gehabt, dass es bei Bulldozer etwas matschig ist:
Interessanterweise erwähnt AMD, dass der L2-Cache keine exakte Kopie des L1-Daten-Caches beinhaltet, trotz dessen Write-Through-Politik. Der L2-Cache ist also nicht vollständig inclusive. Ein Grund scheint zu sein, dass Daten, die nicht im L1-Daten-Cache und nicht im L2-Cache liegen, wohl aber im L3-Cache vorhanden sind, bei Bedarf nur im L1-Daten-Cache abgelegt werden

http://ht4u.net/reviews/2011/amd_bulldozer_fx_prozessoren/index10.php

Bei hUMA kommen ja dann noch einmal Systemübergreifend Snoop-Filter zum Einsatz.

Da bin ich doch sehr gespannt auf Kaveri, wie sich Steamroller schlägt und wie sich hUMA auswirkt.

[S940]

@ S940

Sicher vergessen.
Aber ich habe in Erinnerung gehabt, dass es bei Bulldozer etwas matschig ist:

Jo das war schon noch bekannt, das hatte ich nicht vergessen, da gehts ja nur um L1 <> L2-Inklusivität. Der L2 hat das Inklusive-Bit auch gesetzt, was mich aber wundert ist, dass der L3 das auch hat ...
Gut jetzt gibts da sicherlich auch anderer schwammige Sachen und Spezialfälle, dass ein paar Daten aus nem L2 auch in den L3 kommen, aber dafür gleich das inklusive Bit setzen?
Da bin ich doch sehr gespannt auf Kaveri, wie sich Steamroller schlägt und wie sich hUMA auswirkt.Jo, das wird sicher lustig, der Snoop-Filter muss es wohl richten ^^
BIn mal gespannt, ob der auch für CPU-Kohärenz untereinander benutzt werden kann, oder nur zw. CPU und GPU.
Falls der auch für die CPUs untereinander genutzt wird, könnte das auch noch ein paar IPC-Pünktchen ggü. Piledriver bringen.

[HOT]

Das ist falsch. Haswell baut auf Ivy Bridge auf. Sandy Bridge/Ivy Bridge ist die Ursprungsbasis für Haswell.
[...]
Nein das ist richig. Er ist eine andere Architektur und baut definitiv nicht auf Ivy auf. Der hat ungefähr soviel mit Ivy zu tun wie Lynnfield mit Sandy. Die Cachegrößen sind gleich und sie basieren auf Pentium-M-Architektur, damit erschöpfen sich die Gemeinsamkeiten. Das wär viel zu wenig Entwicklungszeit und es gibt von Haswell wieder etliche Revs. Es gibt Einflüsse aus der Sandy-Entwicklung, uncore auch von Ivy. Haswell selbst hat also nur wenig mit Ivy zu tun. Haswell ist wie gesagt schon seit spätestens 2008 in Entwicklung. Würde Haswell von Ivy abstammen, wäre er sicher in allen Belangen schneller - ist er aber nicht. Nach dem bisherigen Benchmarks weist Haswell auf dem hohen IPC-Niveau sogar ein durchaus differentes Leistungsverhalten zu Ivy auf. Er braucht ja auch offenbar mehr Strom beispielsweise.

Davon ist auszugehen. Aktuelles Beispiel: Der C9/C10 Stromsparmodus für Haswell ULT war ursprünglich erst für Skylake vorgesehen. Skylake wird von den Israelis entwickelt. Es gab regelmäßige Besuche der Israelis nach Oregon, um C9/C10 schon für Haswell ULT einzubauen.
Skylake kommt denke ich nicht von dort, das ist wahrscheinlich eher nen Haswell-Refresh. Gibts dazu Quellen, dass Skylake von dort kommt? Und die Stromsparmodi stammen sicherlich tatsächlich aus Israel, da die einfach mehr Erfahrung in solchen mobil-Entwicklungen haben. Das spricht aber eher dagegen, dass Skylake von da hinten kommt, da die Stromsparmodi sonst nicht für Haswell notwendig gewesen wären. Skylake ist ja der direkte Haswell-Nachfolger, also ein Refresh. Erst die danach folge Architektur kommt wieder aus Israel und hatte als Basis Sandy-Bridge. Man darf gespannt sein, was die daraus machen.

[robbitop]

Naja - aber die Verbesserungen des anderen Teams nimmt man sicher auch immer mit. Die sollten schon relativ eng zusammenarbeiten.
Ich glaube zumindest nicht an 2 wirklich grundverschiedene µ-Architekturen.

[Ronny145]

Nein das ist richig. Er ist eine andere Architektur und baut definitiv nicht auf Ivy auf.


Sorry du liegst falsch.

our starting point was the Sandy Bridge and Ivy Bridge generation
http://intelstudios.edgesuite.net/idf/2012/sf/ti/SPCS001/index.htm#

Ab 3:50


Skylake kommt denke ich nicht von dort, das ist wahrscheinlich eher nen Haswell-Refresh. Gibts dazu Quellen, dass Skylake von dort kommt? Und die Stromsparmodi stammen sicherlich tatsächlich aus Israel, da die einfach mehr Erfahrung in solchen mobil-Entwicklungen haben. Das spricht aber eher dagegen, dass Skylake von da hinten kommt, da die Stromsparmodi sonst nicht für Haswell notwendig gewesen wären. Skylake ist ja der direkte Haswell-Nachfolger, also ein Refresh. Erst die danach folge Architektur kommt wieder aus Israel und hatte als Basis Sandy-Bridge. Man darf gespannt sein, was die daraus machen.

Zu Skylake gibt es einige Profile von israelischen Intel Ingenieuren, die Skylake als Projekt im Profil stehen haben.

http://il.linkedin.com/pub/alon-rot/1b/200/32a
http://il.linkedin.com/in/avivshalgi
http://il.linkedin.com/pub/jawad-haj-yihia/44/80a/48a


DP Eng. at INTEL Israel.
FUB design in the SKYLAKE project.


- Design electrical circuits on Intel’s 2015 processor lineup - SkyLake.
- Work closely with engineers from Intel R&D sites in the USA.

"Jawad showed extraordinary initiative by proactively partnering with MDG Architecture to accelerate the delivery of C9/C10 technology developed for Skylake onto the Intel road map. This included frequent (every 2-3 week) intercontinental trips from IDC to OR to ensure a smooth TR and technology transfer into Haswell ULT."


Sandy Bridge+Ivy Bridge= Israel
Haswell+Broadwell= USA
Skylake= Israel

[Duplex]

Ronny145 hat recht, hatte das genauso in meinen Gedanken.

Core2 > Israel
Nehalem > USA
Sandy > Israel
Haswell > USA
Skylake > Israel

Und soweit ich weiß sind es auch 2 unterschiedliche Designs (aber sehr ähnliche), die Pipeline der Entwickler aus den USA soll etwas länger sein,
Sandy > 14 Stage Pipeline
Nehalem > 16 Stage Pipeline

[HOT]

Sorry du liegst falsch.
[...]
Du sagst doch in einem anderen Thread selber, dass das nicht sein kann. Es gibt schon seit es 22nm gibt Samples von Haswell, also fast genauso lange wie es Ivy gibt. Sicherlich gibt es Querverbindungen zwischen der Entwicklung von Haswell und Sandy-Bridge, aber es sind dennoch unterschiedliche Architekturen von unterschiedlichen Teams. Der kann also gar nicht auf Ivy aufbauen. Wie kommt man auf so einen Quatsch? Haswell ist seit vielen Jahren in Entwicklung, da war an Ivy nicht zu denken. Ivy ist ein geshinkter Refresh von Sandy. Haswell hat damit gar nichts zu tun.

Skylake scheint dann ja tatsächlich eine komlett neue Arch aus Israel zu sein. Man darf gespannt sein, was das wird :D. Wenn man sieht, was von den Jungs so kam, wird das Bombe.

[robbitop]

Wenn man davon ausgeht, dass jede CPU 2x Jahre vor dem Erscheinen bereits funktionstüchtig in einem Labor läuft, gleicht sich die Verschiebung doch wieder aus und die Anfangsaussage gilt wieder. :D

[HOT]

Die kann ja nur laufen, wenn der Fertigungsprozess auch so weit ist.

[Duplex]

Skylake scheint dann ja tatsächlich eine komlett neue Arch aus Israel zu sein. Man darf gespannt sein, was das wird :D. Wenn man sieht, was von den Jungs so kam, wird das Bombe.

Warum Bombe? Die letzten großen Sprünge waren nur Core2 & Nehalem, jeweils +30% IPC gegenüber den Vorgänger, Sandy Bridge nur 15% (aber durch mehr CPU/Turbo Takt waren es gesamt rund 25% mehr Leistung als Nehalem).

[Ronny145]

Du sagst doch in einem anderen Thread selber, dass das nicht sein kann. Es gibt schon seit es 22nm gibt Samples von Haswell, also fast genauso lange wie es Ivy gibt. Sicherlich gibt es Querverbindungen zwischen der Entwicklung von Haswell und Sandy-Bridge, aber es sind dennoch unterschiedliche Architekturen von unterschiedlichen Teams. Der kann also gar nicht auf Ivy aufbauen. Wie kommt man auf so einen Quatsch? Haswell ist seit vielen Jahren in Entwicklung, da war an Ivy nicht zu denken. Ivy ist ein geshinkter Refresh von Sandy. Haswell hat damit gar nichts zu tun.



Dir ist schon klar, welche Zeiträume zwischen Planung und Endprodukt liegen? Anscheinend nicht. Lange bevor es lauffähiges Silizium gibt, kennt Team A die Architektur und dessen Änderungen von Team B. Haswell war 2011 lauffähig. Das gleiche gilt für dessen Vorgänger. Seit Core 2 war jeder neue Tock eine weitere Aufbohrung/Weiterentwicklung vom letzten Tock. Das ist das, was Intel sagt. Du stellst Behauptungen ohne Quelle in den Raum. Wie soll das systematisch auf Dauer funktionieren wenn Team A nicht weiß, was Team B treibt? Das ist Unsinn. In einen der Profile steht geschrieben Work closely with engineers from Intel R&D sites in the USA.....welch Überraschung.

[S940]

Jungs nicht OT werden, für Intel gibts andere Threads :)

[Coda]

Ronny145 hat recht, hatte das genauso in meinen Gedanken.

Core2 > Israel
Nehalem > USA
Sandy > Israel
Haswell > USA
Skylake > Israel

Und soweit ich weiß sind es auch 2 unterschiedliche Designs (aber sehr ähnliche), die Pipeline der Entwickler aus den USA soll etwas länger sein,
Sandy > 14 Stage Pipeline
Nehalem > 16 Stage Pipeline
Das sind garantiert keine unterschiedlichen Designs. Dafür sind die Instruction-Timing, die Pipeline und alles drumherum viel zu ähnlich

[robbitop]

Wäre auch völlige Ressourcenverschwendung. Entwicklungsprozesse sind heute unabhängig vom Ort schon extremst integriert. Sonst müsste man ja vieles doppelt machen. :)

[AnarchX]

220W Vishera mit 5GHz? http://www.sweclockers.com/nyhet/17101-amd-forbereder-fx-9000-pa-upp-till-50-ghz

[boxleitnerb]

Irgendwie unnötig, wenn man schon die Steamroller-Kerne dieses Jahr angeblich in Form von Kaveri bereit hat. Für absolute Enthusiasten, die aus Prinzip kein Intel kaufen wollen, aber sicherlich nett :D

[M4xw0lf]

220W Vishera mit 5GHz? http://www.sweclockers.com/nyhet/17101-amd-forbereder-fx-9000-pa-upp-till-50-ghz
Äh ja. Und welches Mainboard soll diese Saftschleuder aufnehmen?

[fondness]

Es zeigt zumindest was die Architektur liefern könnte, wenn man einen ordentlichen Prozess hätte.

[boxleitnerb]

Es zeigt zumindest was die Architektur liefern könnte, wenn man einen ordentlichen Prozess hätte.

Ob man das damals vom P4 auch gesagt hätte? :rolleyes:

[fondness]

Ob man das damals vom P4 auch gesagt hätte? :rolleyes:

Nein, denn der hatte den besten Fertigungsprozess der gesamten Industrie zur Verfügung, davon ist AMD meilenweit entfernt. Ändert natürlich nichts daran dass es dringend Fortschritte beim Design bedarf.

[boxleitnerb]

Und? Man kann jedes Design bis zum Gehtnichtmehr hochtakten ohne auf den Verbrauch zu achten, das wäre beim P4 genauso gegangen.

[fondness]

Und? Man kann jedes Design bis zum Gehtnichtmehr hochtakten ohne auf den Verbrauch zu achten, das wäre beim P4 genauso gegangen.

Tja und mit einem konkurrenzfähigen Fertigungsprozess wäre die Schwelle höher, ganz einfach. Was ist daran so schwer zu verstehen? Mit 5Ghz ist Vishera sicherlich noch immer kein Überflieger, aber 25% mehr Leistung können schon den Unterschied zwischen fail und noch halbwegs konkurrenzfähig machen.

[boxleitnerb]

Wenn man soviel über den Takt herausholen muss, ist das nicht gerade ein Gütezeichen der Architektur. Insofern stimme ich deiner Aussage nicht zu.

[fondness]

Wenn man soviel über den Takt herausholen muss, ist das nicht gerade ein Gütezeichen der Architektur. Insofern stimme ich deiner Aussage nicht zu.

Das ist ein Vorurteil, mehr nicht. Unterschiedliche Designs erlaube unterschiedlich hohe Taktraten. Die IPC-Früchte sind immer schwerer zu holen, doch wieder etwas mehr über den Takt zu gehen ist in Zukunft durchaus naheliegend. Bevor Intel mit Prescott an die Wand gefahren ist, hatte niemand ein Problem damit das man die geringere pro-Takt-Leistung hatte solange die Leistung insgesamt höher war. Auch Silvermount wird eine geringere IPC als Jaguar haben, insgesamt aber dank höheren Taktraten vorne liegen.

[2phil4u]

Naja, was bringt der hohe Takt schon, eine gut gehende overgeclockte CPU schafft das wohl auch.
Und wer so ein Enthusiast und AMD Fanboy ist, der kann doch selbst overclocken.
Keine Ahnung, wer sowas kauft, soll ja richtig teuer werden, oder hat sich der Preis geaendert.

Steamroller sollte doch locker mehr Leistung haben, aber offensichtlich haben sie keinen in naher Zukunft.

[robbitop]

Irgendwie unnötig, wenn man schon die Steamroller-Kerne dieses Jahr angeblich in Form von Kaveri bereit hat. Für absolute Enthusiasten, die aus Prinzip kein Intel kaufen wollen, aber sicherlich nett :D
Kaveri kann Vishera nicht ersetzen. Kein L3, nur 2 Module, weniger Takt.
Nur ein FX mit Steamrollerkern könnte das. Sowas wird es aber vermutlich nicht mehr geben.

Es zeigt zumindest was die Architektur liefern könnte, wenn man einen ordentlichen Prozess hätte.
Intel würde das mit ihrer Architektur bei 220 W auch schaffen. Und selbst mit 5 GHz schaffen sie es nicht, an der Spitze zu sein. Intel braucht für gleiche Leistung keine 3,4 GHz.

Das ist ein Vorurteil, mehr nicht. Unterschiedliche Designs erlaube unterschiedlich hohe Taktraten. Die IPC-Früchte sind immer schwerer zu holen, doch wieder etwas mehr über den Takt zu gehen ist in Zukunft durchaus naheliegend. Bevor Intel mit Prescott an die Wand gefahren ist, hatte niemand ein Problem damit das man die geringere pro-Takt-Leistung hatte solange die Leistung insgesamt höher war. Auch Silvermount wird eine geringere IPC als Jaguar haben, insgesamt aber dank höheren Taktraten vorne liegen.
Silvermont liegt in entspannten Taktregionen. Auch Prescott ging nicht über 4 GHz. Ab einem gewissen Takt bekommst du einfach massiv Probleme mit Schaltgeschwindigkeiten, verschliffenen Signalflanken, Signallaufzeiten etc pp.

[Ronny145]

AMD is expected to introduce the FX-9000 and FX-8770 at the E3 games show on 11-13 June. Some rates are not yet known.


Na dann werden wir sehr bald erfahren, ob Fake oder nicht.

[Schaffe89]

220W Vishera mit 5GHz?

Wenn da die IPC nicht gesteigert wurde ist das ding im Vergleich zu einem Haswell nur zum heizen da. :D
Sollte es die letzte AMD High End CPU werden, könnte das aber was für die Galerie werden, aber eher zum Weinen als zum Lachen...

Es zeigt zumindest was die Architektur liefern könnte, wenn man einen ordentlichen Prozess hätte.

Ach komm, selbst mit einem guten Prozess wäre dieser Takt niemals drinnen, eher vielleicht 4,6 ghz, aber nicht 5ghz.

Ob man das damals vom P4 auch gesagt hätte?

Als wenn es da jemals am Fertigugsprozess gemangelt hätte.
Globalfoundries ist einfach ne kack Fertigungsstätte, sie können keine AMD Grafikkarten produzieren und haben keine guten Fertigungsprozesse für AMD CPU´s.
Da kommen die Konsolen AMD gerade recht, damit können sie Globalfoundries auslasten und endlich die wichtigen Chips bei TSMC fertigen, wahrscheinlich fertigen sie dort auch Kaveri.

rgendwie unnötig, wenn man schon die Steamroller-Kerne dieses Jahr angeblich in Form von Kaveri bereit hat.

Naja, bisher ist kein Produkt ohne IGP basierend auf der Bulldozer Architektur herausgekommen, vielleicht ist das die letzte leidige Inkarnation?

Wenn man soviel über den Takt herausholen muss, ist das nicht gerade ein Gütezeichen der Architektur.

DU hast doch gar keine Ahnung von Architekturen. Eine hohe IPC schließt einen hohen Takt nicht unbedingt aus, genauso ist es umgekehrt.
Oder denkst du der Takt bei Steamroller wird sinken, weil die IPC steigt?

Die Architektur ist gut, es liegt lediglich an vielen Mängeln die man nicht lösen könnte, schau mal bei Planet3D Now rein, da gibt es sinvolle Analysen.

Intel würde das mit ihrer Architektur bei 220 W auch schaffen.

Und der enorme Rückstand bei der Fertigung existiert nicht oder wie?

Ab einem gewissen Takt bekommst du einfach massiv Probleme mit Schaltgeschwindigkeiten, verschliffenen Signalflanken, Signallaufzeiten etc pp.

Davon ist man bei 5ghz noch relativ weit davon entfernt.

[Skysnake]

Davon ist man bei 5ghz noch relativ weit davon entfernt.

Ähm...

Nein...

Rate mal, warum du die Spannung erhöhen musst ;)

[S940]

Rate mal, warum du die Spannung erhöhen musst ;)Hmm, weil der Prozess schlecht ist? :biggrin:
(sorry, musste sein ^^)

[robbitop]

Und der enorme Rückstand bei der Fertigung existiert nicht oder wie?

Das habe ich nie gesagt - und predige es auch immer wieder. Vermutlich würde Intel das auch mit 150 W schaffen.


Davon ist man bei 5ghz noch relativ weit davon entfernt.
Aha...weil...? Das ist auch immer Design-Abhängig. Klar gibt es Designs (Power7), die so hohe Taktfrequenzen packen. Irgendwo ist aber schluss. Es wird immer schwieriger. Und das nicht linear sondern expotenzial. Takt ist nie eine gute Lösung, wenn man schon stark im Bereich des sinkenden Grenzertrags ist. Und der ist bei 4 GHz augenscheinlich erreicht.

[Gipsel]

Aha...weil...? Das ist auch immer Design-Abhängig. Klar gibt es Designs (Power7), die so hohe Taktfrequenzen packen. Irgendwo ist aber schluss. Es wird immer schwieriger.Mit dem Power7 sind sie doch wieder auf mehr IPC bei niedrigerem Takt (4,25GHz@45nm oder 4,4GHz in 32nm) gegangen. Das Hochtakt-Design war der Power 6 mit 5,0GHz in 65nm. Aber es hat schon einen Grund, warum IBM mit dem Power7 sich jetzt lieber wieder mit etwas weniger Takt zufrieden gibt.

[S940]

Aber es hat schon einen Grund, warum IBM mit dem Power7 sich jetzt lieber wieder mit etwas weniger Takt zufrieden gibt. Meinst Du das 4fach SMT? Da wird dann die Pipeline öfters zu 100% genutzt und ausgelastet.

[HOT]

Das sind garantiert keine unterschiedlichen Designs. Dafür sind die Instruction-Timing, die Pipeline und alles drumherum viel zu ähnlich
Dann schau dir mal die Die-Plots von Haswell und Ivy an. Das sind wirklich unterschiedliche Designs. Natürlich gab es regen Austausch zwischen den Teams.
Das ist ein bisschen so wie eine Autoentwicklung (ich weiss die Vergleiche hinken immer, aber es geht ums Prinzip). VW setzt ein eigenes Design gegen ein Design von Audi (Audi ist ja Teil von VW) - meinetwegen einen Passat gegen einen A6. Die Erkenntnisse sind ähnlich, die Karosserien sind ähnlich, die Motoren sind ähnlich, die Teile sind ähnlich, viele Mitarbeiter pendeln, technologisch Erkenntnisse werden getauscht und dennoch hast du ein anderes Auto. Intel setzt die US-Entwicklung mit der Isreal-Entwicklung auch ein bisschen in eine Art freundschaftliche Konkurrenz, natürlich mit aller Hilfe der jeweiligen Teams. Dennoch handelt es sich um eigene Projekte, die 4-5 Jahre Entwicklungszeit brauchen. Haswell ist definitiv kein Nachfolger von Sandy-Bridge, genausowenig wie Sandy-Bridge kein Nachfolger von Nehalem/Lynnfield ist. Dennoch steckt viel Technologie von Nehalem/Lynnfield in Sandy-Bridge und viel Technologie von Sandy-Bridge in Haswell. Wenn du nur eine Entwicklungslinie fährst sieht das auf den ersten Blick effizient aus, aber das ist es nicht. Du musst Kreativität fördern und andere Technologien zulassen, damit man in künftigen Entwicklungen davon profitieren kann.


Die PPC-Vergleiche hinken doch oder? Ein PPC braucht doch Befehlssatzbedingt weniger Frontend, deshalb lohnt sich 4-Fach-SMT überhaupt erst. Bei x86 wär das mutmasslich völlig sinnfrei, weil man soviel Frontend bräuchte, dass man gleich auch das Backend verbreitern kann... Oder bin ich da total auf dem Holzweg? Hab immer im Kopf, dass PPC-ISA mehr RISC ist als x86.

[Skysnake]

Meinst Du das 4fach SMT? Da wird dann die Pipeline wirklich zu 100% genutzt und ausgelastet.
Pauschalaussagen-Bullshitbingo...

Sorry, aber das triffts einfach wie die Faust aufs Auge. Nur weil etwas xfach ist, macht das noch gar keine Aussage bzgl der Auslastung. Je nach Anwendung kann schon ein Thread ohne SMT ~100% Auslastung bringen, und in nem anderen Falll schaffst du selbst mit 4xSMT nicht mal 50% (aus der Luft gegriffen).

Es kommt halt EXTREM! auf den Code drauf an, und eben WAS du genau machen willst. Hab viel I/O und bescheidenen Datenreuse, dann bekommste auch mit drölf Millionen fach SMT keine Auslastung hin, weil du am Speicherinterface nuckelst...

Dann schau dir mal die Die-Plots von Haswell und Ivy an. Das sind wirklich unterschiedliche Designs. Natürlich gab es regen Austausch zwischen den Teams.
Das ist ein bisschen so wie eine Autoentwicklung (ich weiss die Vergleiche hinken immer, aber es geht ums Prinzip). VW setzt ein eigenes Design gegen ein Design von Audi (Audi ist ja Teil von VW) - meinetwegen einen Passat gegen einen A6. Die Erkenntnisse sind ähnlich, die Karosserien sind ähnlich, die Motoren sind ähnlich, die Teile sind ähnlich, viele Mitarbeiter pendeln, technologisch Erkenntnisse werden getauscht und dennoch hast du ein anderes Auto. Intel setzt die US-Entwicklung mit der Isreal-Entwicklung auch ein bisschen in eine Art freundschaftliche Konkurrenz, natürlich mit aller Hilfe der jeweiligen Teams. Dennoch handelt es sich um eigene Projekte, die 4-5 Jahre Entwicklungszeit brauchen. Haswell ist definitiv kein Nachfolger von Sandy-Bridge, genausowenig wie Sandy-Bridge kein Nachfolger von Nehalem/Lynnfield ist. Dennoch steckt viel Technologie von Nehalem/Lynnfield in Sandy-Bridge und viel Technologie von Sandy-Bridge in Haswell. Wenn du nur eine Entwicklungslinie fährst sieht das auf den ersten Blick effizient aus, aber das ist es nicht. Du musst Kreativität fördern und andere Technologien zulassen, damit man in künftigen Entwicklungen davon profitieren kann.

Du kannst anhand von DIE-Shots erkennen, in wie weit sich VHDL-Code/Blöcke unterscheiden? Respekt, da würde ich aber sofort mal bei Intel anfragen :up:

Schon allein eine neue Synthese kann dir komplett andere Layouts liefern... Klar, bei den Sachen dreht es sich vorzugsweise um handgestrickte Sachen, aber da ist auch IMMER! die Frage, wie groß die einzelnen Blöcke dann am Ende wirklich sind, die handgestrickt sind, und vor allem auch, was hier noch "handgestrickt" bedeutet.

Ist das wirklich komplett frei gezeichnet, oder hat man einfach nur EXTREM! viele und EXTREM! harte constraints, so dass das Design ziemlich vorhersagbar ist?

Kurz um, da von außen irgendwelche Prognosen treffen zu wollen ist für mich total hahnebüchen...

[HOT]

Sei mal nicht so kleinkariert, das weiss ich auch. Dennoch sind die Plots schon sehr unterschiedlich. Natürlich kann man von Hand was gleiches machen, was hinterher total unterschiedlich aussieht, wenn man x Optimierungsstadien durchläuft. Es war auch nur als Indiz gemeint, nicht als Beweis oder ähnliches.
Auch ändert das nichts daran, dass die CPUs ziemlich gleichzeitig sampelten als 22nm verfügbar war. Ich sage ja nicht, dass es keine Abhängigkeiten gibt, ich sage ja nur, dass es keine direkte Linie gibt auf der das evolutionär entwickelt wird. Das sieht nur so aus, ist aber Marketing.

[Gipsel]

Meinst Du das 4fach SMT? Da wird dann die Pipeline wirklich zu 100% genutzt und ausgelastet.Power6 hatte 2fach SMT, aber das ist nicht, was ich meinte. Power6 war im Unterschied zum Power5 und Power7 ein in-order-Design (der hätte also ein 4fach SMT vermutlich auch gut vertragen können). Die haben beim Power6 für den relativ großen Frequenzsprung ziemlich viel geopfert (aber dafür eben die Frequenz auch um mehr als den Faktor 2 hochgeprügelt).

[S940]

Power6 hatte 2fach SMT, aber das ist nicht, was ich meinte. Power6 war im Unterschied zum Power5 und Power7 ein in-order-Design (der hätte also ein 4fach SMT vermutlich auch gut vertragen können). Die haben beim Power6 für den relativ großen Frequenzsprung ziemlich viel geopfert (aber dafür eben die Frequenz auch um mehr als den Faktor 2 hochgeprügelt).Ja, aber Power7 hat 4fach SMT, das kostet sicherlich auch ein paar MHz Takt, so meinte ich das. Aber das meintest Du anscheinend nicht.

@Skysnake:
Mißverständnis, ich schreib mal anstatt "wirklich" ein "öfters" rein ... dann sollte es klar sein, was ich meinte. Und das nächste Mal ruhig locker bleiben und die BS-Bazooka steckenlassen, auch wenn Montag und das Wetter draußen besch..eiden ist, musst Du nicht erklären, dass auf nem CPU Kern unterschiedliche Anwendungen laufen können ;-)

Die PPC-Vergleiche hinken doch oder? Ein PPC braucht doch Befehlssatzbedingt weniger Frontend, deshalb lohnt sich 4-Fach-SMT überhaupt erst. Bei x86 wär das mutmasslich völlig sinnfrei, weil man soviel Frontend bräuchte, dass man gleich auch das Backend verbreitern kann... Oder bin ich da total auf dem Holzweg? Hab immer im Kopf, dass PPC-ISA mehr RISC ist als x86.Naja, kommt halt drauf an wie man das ganze löst. Bei Intel sind die Dekoder die meiste Zeit wg. des µOp-Caches abgestellt und sparen Strom. Vermutlich hätten die mit 2 Threads mehr auch kein großes Problem. Optimal wärs sicherlich nicht, aber so super effizient müssen sie ja auch nicht sein, denn die Einheiten laufen nur im SMT-Betrieb, d.h. 100% der Resourcen liegen *nicht* brach. Ein schnellerer Dekoder würde die Ops möglicherweise nur schneller in den Scheduler befördern. Gibt dann möglicherweise ein paar kleine Vorteile im OoO-Betrieb, aber solange der Scheduler nicht leer war, nicht allzuwichtig.

[Gipsel]

auch wenn Montag und das Wetter draußen besch..eiden ist,Ach was, blauer Himmel, Sonnenschein und 20°C hier in Hamburg. :tongue:

[Triskaine]

Der Austausch zwischen den Entwicklerteams läuft bei Intel meines Wissens folgendermaßen ab:
Sobald ein Design Feature Complete und formal verifiziert ist, also nur noch Bug Fixes eingereicht werden, geht der Verilog Code an das Team für die nachfolgende Entwicklung, die darauf aufbauend ihr eigenes Design umsetzen.

[Skysnake]

@Skysnake:
Mißverständnis, ich schreib mal anstatt "wirklich" ein "öfters" rein ... dann sollte es klar sein, was ich meinte. Und das nächste Mal ruhig locker bleiben und die BS-Bazooka steckenlassen, auch wenn Montag und das Wetter draußen besch..eiden ist, musst Du nicht erklären, dass auf nem CPU Kern unterschiedliche Anwendungen laufen können ;-)

Siehs als kompliment, wenn ich bischen "klarer" formuliere ;)

Ich mach das, damit keine auf die Idee kommt, das für bare Münze zu nehmen. Ich denke du hast durchaus viel Ahnung, und daher glauben dir Leute auch relativ leicht, was du sagst, daher hau ich da dann auch eher gleich mit der dicken Keule drauf :tongue:

Bei manchen Aussagen bin ich halt ziemlich allergisch geworden in den letzten Jahren. Bei manchen simplen Sachen schnappen die Leute halt was auf, und das frisst sich dann wie ein Tumor durch ihr Hirn... Das bekommt man dann nur noch GANZ schwer wieder raus....

[S940]

Hehe ok, aber soviel Nichtswisser treiben sich im 3DC eigentlich nicht herum, die sind eher bei Computerbase, PCGH etc. aber wurst, Schwamm drüber, bei mir ist gerade Sonnenuntergang bei +17 ;-)
Wünsche Allen einen schönen Abend :)

[horn 12]

Es kommt doch ein Stolzer 5 Ghz FX daher, und wohl auch weitere Modelle.
Zudem auch ein Neues Board von Gigabyte für AM3+ Sockel

Es wird spannend werden, Konkurrenz für Haswell :-)

Seht Euch bitte einfach das Video an ....
http://www.donanimhaber.com/islemci/haberleri/AMDnin-5GHzde-calisan-FX-islemcisi-resmiyet-kazandi-Ozel-Video.htm

[samm]

Auf dem Video sehe ich nur viel, das ich nicht verstehe, und eine Plakette zu einem Gigabyte-Mainboard, was irgendwas von "next gen Am3+ 5GHz FX series" steht - sofern das nicht weit in die Zukunft (zu Steamroller) geht, müsste es der durch die Gerüchtewelt geisternde 2xxW-Vishera sein. Sollte das wirklich kommen wäre das... ein peinliches Produkt, ausser sie könnten die Verlustleistung auf Ebene eines 8350 @stock halten, was nie der Fall sein wird.

[Knuddelbearli]

scheiss auf die 5Ghz lieber 3Ghz+ Uncore für den FX

[john carmack]

Wenn Steamroller 15% IPC drauflegt könnte man wieder in Schlagdistanz zu Intel kommen.
Zumindest was die Performance CPU´s angeht...

Ich hätte schon mehr von Haswell erwartet...

[fondness]

Die Sache dürfte damit jedenfalls bestätigt sein:

http://img526.imageshack.us/img526/4189/clipboard01qj.jpg (http://imageshack.us/photo/my-images/526/clipboard01qj.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

[boxleitnerb]

Von wo kommt das Bild?

[Effe]

Von der Computex nehme ich mal an?

[Tarkin]

jep... genauer gesagt von hier: http://www.donanimhaber.com/islemci/haberleri/AMDnin-5GHzde-calisan-FX-islemcisi-resmiyet-kazandi-Ozel-Video.htm

(bei 01:00)

[boxleitnerb]

Thx. Jetzt ist nur noch die TDP interessant. 220W wären schon heftig.

[fondness]

Thx. Jetzt ist nur noch die TDP interessant. 220W wären schon heftig.

220W ist durchaus realistisch. Ausgehend von den 125W eines FX8350 habe ich schon alleine durch den 25% höheren Takt 156.25W. Wenn ich dann die Spannung noch um 20% erhöhe wäre ich bereits bei 225W.

[anddill]

Ausgerechnet Gigabyte. Dann läuft vielleicht die CPU mit 5GHz, aber der Ram nur mit 1,33.

[Raff]

scheiss auf die 5Ghz lieber 3Ghz+ Uncore für den FX

Beides zusammen dürfte ganz anständig kloppen. Ich habe mit meiner Kiste unzählige Benchmarks mit ~5,0/2,7 GHz gemacht und das skaliert gegenüber dem 4,0/2,2-GHz-Standard fast immer linear (mit schnellem RAM).

Abartig, dass der 5-GHz-FX tatsächlich kommt. Die TDP wird echt interessant, denn an die 220 Watt glaubt doch auch niemand ...

MfG,
Raff

[Cyphermaster]

Ich zweifle schon wegen der Kühlungsproblematik bei derartigen Abwärmemengen stark daran, daß man eine reguläre CPU mit TDP 200W+ anbieten würde - außer vielleicht pro forma. Wahrscheinlicher wäre nach meinem Dafürhalten, daß es sich wenn, dann um eine kleinere Menge stark selektierter Visheras mit verringerter Spannung handelt, die dann trotz 5GHz vielleicht noch grob in der von AMD schon mal bemühten 140W-Klasse der PhII-CPUs bleiben könnten (die mit gängigen Kühlern im 120er Format noch erträglich zu zähmen ist). Damit könnte man wenigstens nominell Intel etwas gegenhalten.

[Raff]

Ein Binning gibt's bestimmt (siehe TWKR), aber 5 GHz bei "nur" 140 Watt wäre für AMD-Verhältnisse sehr effizient. AMD könnte die 5-Gigahertzchen auch zusammen mit einer (Kompakt-)WaKü bündeln, dann wäre das Kühlproblem vom Tisch.

MfG,
Raff

[fondness]

Ich zweifle schon wegen der Kühlungsproblematik bei derartigen Abwärmemengen stark daran, daß man eine reguläre CPU mit TDP 200W+ anbieten würde - außer vielleicht pro forma. Wahrscheinlicher wäre nach meinem Dafürhalten, daß es sich wenn, dann um eine kleinere Menge stark selektierter Visheras mit verringerter Spannung handelt, die dann trotz 5GHz vielleicht noch grob in der von AMD schon mal bemühten 140W-Klasse der PhII-CPUs bleiben könnten (die mit gängigen Kühlern im 120er Format noch erträglich zu zähmen ist). Damit könnte man wenigstens nominell Intel etwas gegenhalten.

200W zu kühlen ist mit aktuellen Tower-Kühlern kein Problem. Diverse OC-CPUs schlucken das auch, nur merken das die Leute oft nicht weil sie den Einfluss von mehr Spannung völlig unterschätzen. Es werden Grafikkarten mit 375W und Zwei-Slot Kühlern verkauft.

[Cyphermaster]

200W zu kühlen ist mit aktuellen Tower-Kühlern kein Problem.Ich rede aber auch nicht davon, daß man so ein Kaliber als boxed-Kühler beilegt, das halte ich einfach für abwegig. Sich so nah an die Grenzen "gängiger" Kühlungslösungen zu bewegen, ist bisher noch immer negativ von den Käufern gouttiert worden. Auch und gerade im Oberklasse-Bereich, denn auch da will man noch Spielraum für OC oder leise Konfigurationen, ohne gleich auf Wasserkühlung setzen zu müssen. Schon bisher war die hohe TDP der Bulldozer-CPUs immer ein dicker Minuspunkt in den Medien. Daher vermute ich -wie gesagt- eher einen etwas konservativeren Ansatz diesbezüglich, weil man sich kaum einen neuen Negativrekord an die Backe nageln lassen wollen wird.

[Dr. Lloyd]

Über wie viele Module/Pseudo-Kerne wird der 5GHz-Bolide überhaupt verfügen?

[M4xw0lf]

Natürlich 4/8.

[Ronny145]

Ausgerechnet Gigabyte. Dann läuft vielleicht die CPU mit 5GHz, aber der Ram nur mit 1,33.


Laut Webseite: Support for DDR3 2000(O.C.)/1866/1600/1333/1066 MHz memory modules

[Skysnake]

Beides zusammen dürfte ganz anständig kloppen. Ich habe mit meiner Kiste unzählige Benchmarks mit ~5,0/2,7 GHz gemacht und das skaliert gegenüber dem 4,0/2,2-GHz-Standard fast immer linear (mit schnellem RAM).

Abartig, dass der 5-GHz-FX tatsächlich kommt. Die TDP wird echt interessant, denn an die 220 Watt glaubt doch auch niemand ...

MfG,
Raff
Wieviel schluckt denn dein FX? Und hat der jetzt schon RCM? Ich glaube nicht oder?

Könntest du eventuell auch mal Tests bzgl Temp<->Verbrauch machen? Sprich kann man signifikant etwas einsparen, wenn man kühler bleibt?

Ich bin aber auch sehr sehr sehr überrascht, dass Sie das wirklich bringen wollen. Wird aber sicherlich nur ein Boost auf einem Core, und das sicherlich auch nicht lange. Anders kann ich es mir kaum vorstellen. >20% mehr Takt ist einfach krank :ugly:

Ein Binning gibt's bestimmt (siehe TWKR), aber 5 GHz bei "nur" 140 Watt wäre für AMD-Verhältnisse sehr effizient. AMD könnte die 5-Gigahertzchen auch zusammen mit einer (Kompakt-)WaKü bündeln, dann wäre das Kühlproblem vom Tisch.

Ich glaub eher an 150W, denn an 140W. Aber selbst 150W wären klasse. Die Effizienz sollte doch trotzdem steigen oder?

Gabs da nicht auch was, das AMD genau wie Intel beim P4 andere Transistoren verwendet, die ne Art "preload" haben, also quasi auf einen Zwischenzustand gefahren werden bevor Sie schalten sollen, was die Schaltgeschwindigkeit erhöht, da der ganze Schaltvorgang "instabiler" ist, aber eben erst bei wirklich hohen Taktraten wirklich gut ist, da man davor zu große statische Ströme hat und den "preload"?

Zusammen mit Resonant Clock Mash könnte das eventuell dann ja richtig gut funktionieren. :confused:

[S940]

Abartig, dass der 5-GHz-FX tatsächlich kommt. Die TDP wird echt interessant, denn an die 220 Watt glaubt doch auch niemand ...
Also mich würde es nicht wundern ...

@Skysnake: Nö Vishera hat kein RCM, ist von AMD bestätigt. Außerdem bringt RCM über 4 Ghz nichts mehr, da gabs mal ne Grafik, der Optimalpunkt ist um 3 GHz herum.

[marc-05]

Der FX 8150 verbraucht für 4.4 GHz (1.4V) etwa 193 Watt CPU+Wandler
Laut HT4u-Messung (http://ht4u.net/reviews/2011/amd_bulldozer_fx_prozessoren/index25.php)

Beim Verbrauch sind ja Bully und Piledriver fast gleich auf
http://s14.directupload.net/images/130604/3lc2gpic.jpg (http://www.directupload.net)
http://www.hartware.de/review_1544_4.html

[Gipsel]

@Skysnake: Nö Vishera hat kein RCM, ist von AMD bestätigt. Außerdem bringt RCM über 4 Ghz nichts mehr, da gabs mal ne Grafik, der Optimalpunkt ist um 3 GHz herum.
Meinst Du die hier?

http://diit.cz/sites/default/files/amd_piledriver_32nm_resonant_clock_mesh_.png

Was da aufgetragen ist, ist die Stromverbrauchsersparnis (nur für das Taktsignal) gegenüber einer nichtresonanten Variante. Das gibt zwar ein Optimum um 3GHz, aber auch bei 4+GHz geht das längst noch nicht auf Null zurück. Letztendlich ist das zu einem großen Teil eine Abstimmungsfrage, nämlich wie gut man die Resonanz auf die jeweilige Frequenz des Taktsignal tunen kann.

Edit: Also um es klarer zu sagen, das Maximum der Effizienz bei ~3,3GHz ist nicht fest gegeben, es ist dahin designed. Man kann es auch auf 4 oder 5GHz legen. Ganz stark vereinfacht ist das resonante Mesh ein (etwas komplizierter aufgebauter) Schwingkreis mit einer Resonanzfrequenz, die abhängig von den Kapazitäten und Induktivitäten ist (Widerstände spielen auch ein Rolle, allerdings mehr für die Breite der Resonanz). Durch geeignete Wahl dieser (praktisch muß man für einen RCM zusätzliche Induktivitäten einbauen) kann man die Resonanzfrequenz hinlegen, wo immer man sie haben möchte (und die sogenannte Güte des Resonators bestimmt die Breite der Resonanz [und auch die maximale Verbrauchseinsparung]).

[S940]

Was da aufgetragen ist, ist die Stromverbrauchsersparnis (nur für das Taktsignal) gegenüber einer nichtresonanten Variante. Das gibt zwar ein Optimum um 3GHz, aber auch bei 4+GHz geht das längst noch nicht auf Null zurück. Letztendlich ist das zu einem großen Teil eine Abstimmungsfrage, nämlich wie gut man die Resonanz auf die jeweilige Frequenz des Taktsignal tunen kann.
Ja die meinte ich. Dass es bei 4 Ghz noch ein bisschen was bringt wusste ich, aber wir reden hier ja über 5 GHz, da sehe ich Pi*Daumen Plus/Minus 0.

Ist aber sowieso egal, da Vishera das nicht hat. Aber Du meinst sie könnte auch ne Spezial-Variante für ~5 Ghz bringen? Wäre interessant in Hinblick auf das 4thread-Kern von Letztens, der hat auch breitere Clockdriver zw. den Units, also wohl mit RCM.
Edit: Ah hab jetzt Dein Edit gesehen, Danke ;-)

[R.I.P.]

Schaut euch mal Richland an: Topmodell 300 Mhz mehr und unter Last ca. 40W weniger als der 5800K (laut ersten Tests aus China, google übersetzt). Warum nicht ähnliche tweaks (wir werden ja sehen welche) auch bei Vishera 2.0?

[S940]

Schaut euch mal Richland an: Topmodell 300 Mhz mehr und unter Last ca. 40W weniger als der 5800K (laut ersten Tests aus China, google übersetzt). Warum nicht ähnliche tweaks (wir werden ja sehen welche) auch bei Vishera 2.0?
Wieder der gleiche Grund: Kein RCM.
Gibt ernstzunehmende Hinweise, dass RCM bei Trinity nicht funktionierte. An die große Glocke wollte das bei AMD natürlich keiner hängen ...

[Locuza]

Wieder der gleiche Grund: Kein RCM.
Gibt ernstzunehmende Hinweise, dass RCM bei Trinity nicht funktionierte. An die große Glocke wollte das bei AMD natürlich keiner hängen ...
Charlie hat ja einen Artikel veröffentlicht, das große Geheimnis von Richland und die Hintergründe der Energieeinsparung.
Woher hast du eig. die Vermutung, dass RCM bei Trinity nicht funktionierte?
Hört sich langsam aber plausibel an.

[Schlammsau]

Schaut euch mal Richland an: Topmodell 300 Mhz mehr und unter Last ca. 40W weniger als der 5800K (laut ersten Tests aus China, google übersetzt). Warum nicht ähnliche tweaks (wir werden ja sehen welche) auch bei Vishera 2.0?
Hast nen Link? :smile:

[Gipsel]

Wieder der gleiche Grund: Kein RCM.
Gibt ernstzunehmende Hinweise, dass RCM bei Trinity nicht funktionierte. An die große Glocke wollte das bei AMD natürlich keiner hängen ...
Nun, vor etwa einem Jahr, am 18.Mai 2012, gab es einen Vortrag von AMD über RCM in Piledriver (http://ewh.ieee.org/r5/denver/sscs/2012_05_Sathe.html) (da gibt es auch die Folien) bei der IEEE Solid State Conference, wenn ich das richtig sehe. Da erfährt man z.B. auch, wie die KondensatorenSpulen eigentlich genau gebaut werden oder daß unter 2,9GHz das Clock-Mesh konventionell betrieben wurde (also die Spulen abgeklemmt werden). Und in der Zusammenfassung am Ende steht da Folgendes:
Rclk [resonant clock] Measurement Summary Successfully ran SST (System Stress Test) over 2 weeks
Latest Fmax impact data on a larger set of parts shows an Fmax
overhead of ~0.2%
Up to 34% energy efficiency achieved in the global clock using
Pulse Mode
Not production ready due to excessive Fmax impact driven by
phase offset to NB and L2 clock interface
Phase offset issue resolved in current design
...

Da fragt man sich, welches das aktuelle Design ist, in dem das gefixed wird/wurde (Steamroller oder schon die Richland-Revision von PD?) oder ob es weitere Probleme gab.

[Skysnake]

Ja die meinte ich. Dass es bei 4 Ghz noch ein bisschen was bringt wusste ich, aber wir reden hier ja über 5 GHz, da sehe ich Pi*Daumen Plus/Minus 0.

Ist aber sowieso egal, da Vishera das nicht hat. Aber Du meinst sie könnte auch ne Spezial-Variante für ~5 Ghz bringen? Wäre interessant in Hinblick auf das 4thread-Kern von Letztens, der hat auch breitere Clockdriver zw. den Units, also wohl mit RCM.
Edit: Ah hab jetzt Dein Edit gesehen, Danke ;-)
Gipsel hat es ja schon gesagt. Im Prinzip ist es für jedwede Frequenz konfigurierbar. Du kannst das sogar so deichseln, dass du mehrere Frequenzen unterstützt, dann wirds halt nochmals extrem viel komplexer, weil du eben dann Kapazitäten und Induktivitäten ändern musst.

Im Prinzip ist das aber eh der Fall durch die schwankende Temperatur. Man sieht ja auch sehr schön, dass die Temperatur einen recht starken Einfluss hat.

Dazu kommen ja noch die Produktionsschwankungen.... Es macht also definitiv Sinn, die Parameter, die die Resonanzfrequenz bestimmen, im Bertieb "durchstimmen" zu können. Trivial ist was anderes...

Nun, vor etwa einem Jahr, am 18.Mai 2012, gab es einen Vortrag von AMD über RCM in Piledriver (http://ewh.ieee.org/r5/denver/sscs/2012_05_Sathe.html) (da gibt es auch die Folien) bei der IEEE Solid State Conference, wenn ich das richtig sehe. Da erfährt man z.B. auch, wie die Kondensatoren eigentlich genau gebaut werden oder daß unter 2,9GHz das Clock-Mesh konventionell betrieben wurde (also die Kondensatoren abgeklemmt werden). Und in der Zusammenfassung am Ende steht da Folgendes:

Da fragt man sich, welches das aktuelle Design ist, in dem das gefixed wird/wurde (Steamroller oder schon die Richland-Revision von PD?) oder ob es weitere Probleme gab.
Ja, das ist ne SEHR gute Frage.

Vor allem stellt sich mir aber auch die Frage, wie Sie mit den Produktionsschwankungen umgehen. Das ist meiner Meinung nach nämlich ein extrem großes Problem, das sich auch nicht trivial lösen lässt. Wenn man es gelöst hat, dann sollte man aber eben auch durchstimmen können :biggrin:

[Gipsel]

Gipsel hat es ja schon gesagt. Im Prinzip ist es für jedwede Frequenz konfigurierbar. Du kannst das sogar so deichseln, dass du mehrere Frequenzen unterstützt, dann wirds halt nochmals extrem viel komplexer, weil du eben dann Kapazitäten und Induktivitäten ändern musst.Irgendwo meine ich gelesen zu haben, daß irgendwann bei Steamroller oder so das sowohl bei idle, base, als auch Turbotakt im resonanten Modus laufen soll.
Dazu kommen ja noch die Produktionsschwankungen.... Es macht also definitiv Sinn, die Parameter, die die Resonanzfrequenz bestimmen, im Bertieb "durchstimmen" zu können. Trivial ist was anderes...

Ja, das ist ne SEHR gute Frage.

Vor allem stellt sich mir aber auch die Frage, wie Sie mit den Produktionsschwankungen umgehen. Das ist meiner Meinung nach nämlich ein extrem großes Problem, das sich auch nicht trivial lösen lässt. Wenn man es gelöst hat, dann sollte man aber eben auch durchstimmen können :biggrin:
Die Kapazitäten im Clock-Mesh sollten nicht so übermäßig schwanken. Die Fertigungsschwankungen sind z.B. bei den Gates der Transistoren deutlich kritischer. Da kommt es praktisch auf einzelne Atomlagen an.
Die Spulen für die zusätzlich nötige Induktivität im Mesh (Kapazität hat das Ding von alleine) sind praktisch wohl eine Art Spirale (man kann ja nicht in die Höhe wickeln, es muß also quasi 2D bleiben mit nur wenigen genutzten Ebenen der Metal-Layer). Wenn man das clever anstellt, könnte man vermutlich die Anzahl der gerade genutzten Windungen einstellen (bei dem Test haben sie einfach die komplette Spule abgeklemmt, wenn die Taktfrequenz <2,9GHz war und das konventionell betrieben) und somit die Induktivität passend zur gerade anliegenden Taktfrequenz etwas nachfahren (größere Induktivität [mehr Windungen] => kleinere Resonanzfrequenz). Das kostet natürlich etwas mehr Fläche für größere Spulen als welche, die nur im hohen Frequenzbereich funktionieren.
Na außerdem haben die in der Präsentation (oder war es eine andere, keine Ahnung) auch gesagt, daß sie nur sehr kleine Änderungen am Clock-Mesh ausgeführt haben, weil es als Backup auch noch ganz normal funktionieren sollte und alle Optimierungen des Meshes auf die konventionelle Betriebsart ausgerichtet waren (was vermutlich einen Teil der Probleme mit dem resonanten Betrieb erklärt), da ansonsten als Zeitrahmen für die Entwicklung und Validierung eines neuen Clock-Meshes ~1 Jahr angegeben war und man das relativ schnell testen wollte. Bei einer Optimierung auf den resonanten Betrieb bzw. einem Design, das von Anfang an darauf ausgelegt ist, sollte das insgesamt auch noch besser funktionieren.

[Skysnake]

Man kann die Spule auch komplett in 2D ausführen (Flach-Spule). Das ist jetzt nicht wirklich ein Problem. Wie das Feld genau aussieht ist ja hier nicht wirklich relevant. Man will ja nur die Induktivität. Müsste man aber mal ausrechnen, wie das dann genau aussieht und wirkt.

Man kann also je nachdem, an welcher Stelle man die Falchspule durchkontaktiert andere Induktivitäten erreichen.

Die Temperatur halte ich hier aber sicherlich für nicht egal.

Durch den Ausdehnungskoeffizient verändert sich die Geometrie deines Mashes und auch die deiner Spule. Das kann sich ziemlich doof kombinieren. Daher darf die Resonanzfrequenz auch nicht zu scharf sein, obwohl man ja eigentlich genau das will....

Die Kapazitäten ändern sich ja auch leicht durch die Temperatur. Man hat ja überall praktisch kleine Plattenkondensatoren -.-

So was wird extrem schnell extrem hässlich... Ich will gar nicht wissen, wie lange die da für Simulationen brauchen, die überhaupt was taugen. Man muss ja echt jeden SCHEIS da dann berücksichtigen...

[2phil4u]

5 ghz sind schon heftig. Wenn AMD Erfahrung mit dem Bau von Mainboards haette, könnten sie das ganze gleich mit 3500 mhz GDDR5 anbieten, da das Teil ja eh so teuer werden soll.
5 ghz mit GDDR 5 3500mhz, kann jemand ausrechenen, was das bringen würde, kenne mich mit damit nicht so aus, weiss aber das Vishera gut von höherem Speichertakt profitiert.
Wenn die Latenzen nicht viel schlechter sind, vorallem prozentual, dürften mit 5 ghz @ 3500mhz Speicher gut 35% mehr Leistung drin sein.
Warum nicht bei Steamroller ?

Wenn das Teil wirklich so genial paralleisierbar ist, wie hier einige vermuten (hoffen) mit 4 Threads pro Modul.
Dann waren es 16 threads bei 5 ghz und damit würde man doch Intel auch im Servermarkt und vorallem im Desktop High End gut paroli bieten können.

28 nm FDSOI würde auch einiges bringen, vorallem könnte man damit 8 Moduler mit niedriger Taktfrequenz und sehr niedriger Spannung rausbringen, da FDSOI vorallem bei wenig Spannung Vorteile bietet.
32 Threads bei 2.5 ghz und 0.6 Volt waeren doch supi.

[Knuddelbearli]

ddr5 bringt für die cpu sogut wie gar nichts

und wie schon gesagt zumindest für spiele müssten sie nur mal den Uncore ordentlich aufdrehen,

da erreicht man dan auch bei selben Takt bis zu 30% mehr FPS

[Cyphermaster]

Ja, das mit dem Uncore verstehe ich auch nicht so ganz. Ich bin zwar kein Schaltungsexperte, aber wenn so viele CPUs mit einem höheren Uncore-Takt problemlos in der Praxis betrieben werden, und sich damit grade in Spielen was reißen läßt, warum läßt dann AMD dieses Potential so brach liegen? Hat ein gesteigerter Uncore irgendwelche massiven Nachteile? Instabilität kann es bzgl. der Praxiserfahrungen der Leute ja nun nicht wirklich in dramatischem Umfang sein.

[boxleitnerb]

Leistungsaufnahme?

[HOT]

2012 Trinity -> 2013 Richland (RCM aktiv) -> 2013 Kaveri (RCM + Shrink + HD-Libs; 28nm Prototyp und erste hUMA/HSA-CPU) -> 2014 Excavator Fusion (28nm SHP) -> Ende 2015 komplett neue Arch in 20nm FinFET GloFo
2012 Vishera -> 2013 Centurion (RCM aktiv) -> 2014 Excavator CPU (28nm SHP) -> Ende 2015 komplett neue Arch in 20nm FinFET GloFo

Bei Centurion müsste aber noch was anderes hinzukommen, wenn man 5GHz will. Vllt eine Wiederauferstehung von ULK?

[robbitop]

Uncore bringt auch nicht immer so viel Mehrleistung wie oben sugg. Da gibt es ein paar Einzelfälle, in denen es fast linear durchschlägt.

[fondness]

2012 Trinity -> 2013 Richland (RCM aktiv) -> 2013 Kaveri (RCM + Shrink + HD-Libs; 28nm Prototyp und erste hUMA/HSA-CPU) -> 2014 Excavator Fusion (28nm SHP) -> Ende 2015 komplett neue Arch in 20nm FinFET GloFo
2012 Vishera -> 2013 Centurion (RCM aktiv) -> 2014 Excavator CPU (28nm SHP) -> Ende 2015 komplett neue Arch in 20nm FinFET GloFo

Bei Centurion müsste aber noch was anderes hinzukommen, wenn man 5GHz will. Vllt eine Wiederauferstehung von ULK?

Gib endlich deine Träumereien von einer komplett neuen Architektur auf. :)
Excavator wird mit hoher Wahrscheinlichkeit in 20nm kommen, genaueres erfährt man Ende des Jahres.

[Cyphermaster]

Schon klar, daß das kein Wunderfeature ist - aber auch im Durchschnitt eher geringes Potential würde man doch in der jetzigen Situation wohl nicht verschenken? Braucht höherer Uncore so viel mehr Saft?

[HOT]

Gib endlich deine Träumereien von einer komplett neuen Architektur auf. :)
Excavator wird mit hoher Wahrscheinlichkeit in 20nm kommen, genaueres erfährt man Ende des Jahres.
Nein! :D

[Undertaker]

2012 Trinity -> 2013 Richland (RCM aktiv)

Hat das mal irgendjemand bestätigt? Weil die Richland-Papers das nirgends erwähnen, und warum sollte man das nicht anpreisen?

[robbitop]

Vieleicht weil das schon bei Trinity geplant war und dann doch nicht funktioniert hat. Ggf. möchte man das nicht an die große Glocke hängen?

[HOT]

Und man sieht ja, dass es einiges an Strom spart, ohne das sich der Kern verändert hat.

[Undertaker]

Das kann ein neues Stepping und Fertigungsverbesserungen im Laufe der Zeit auch so bewirken, die Taktraten sind ja "nur" um knapp 5-10 Prozent gestiegen. Wie gesagt, bei einer bedeutsamen Änderung wie RCM hätte ich erwartet, dass dies vom Hersteller angepriesen wird. Ich würde darum erstmal vermuten, dass Richland noch nicht darüber verfügt.

[Gipsel]

Wie gesagt, bei einer bedeutsamen Änderung wie RCM hätte ich erwartet, dass dies vom Hersteller angepriesen wird. Ich würde darum erstmal vermuten, dass Richland noch nicht darüber verfügt.Nur wurde das ja angeblich schon mit Piledriver bei Trinity eingeführt. Wie soll man das jetzt nochmal neu einbauen? ;)

[Locuza]

Ich hätte ähnlich wie Undertaker schon eine Meldung diesbezüglich erwartet.
z.B. "enhanced RCM", dass es nicht vollständig bei Trinity funktioniert hat, müsste man nicht an die Glocke hängen, aber man könnte ja schon sagen, dass man es "verbessert" hätte.
Bei Richland sehen die Mhz-Updates aber nur nach Foundry-Verbesserungen + Neues Stepping aus, also nicht nach einem spekulierten "funktionierenden" RCM.

[Gipsel]

Ich hätte ähnlich wie Undertaker schon eine Meldung diesbezüglich erwartet.
z.B. "enhanced RCM", dass es nicht vollständig bei Trinity funktioniert hat, müsste man nicht an die Glocke hängen, aber man könnte ja schon sagen, dass man es "verbessert" hätte.
Bei Richland sehen die Mhz-Updates aber nur nach Foundry-Verbesserungen + Neues Stepping aus, also nicht nach einem spekulierten "funktionierenden" RCM.
Auch mit RCM sinkt der Stromverbrauch wohl um maximal 10% (eher nur 5%), was dann in ein Taktupdate zwischen 5% und maximal 10% (was dann schon kleinere Verbesserungen der Fertigung einbezieht) mündet. Man sollte davon nicht zu viel erwarten.

[Locuza]

Viel habe ich auch nicht erwartet, aber Richland und Trinity performen sehr ähnlich. Es gibt auch Verbrauchsmessungen, wo Richland auch das ein oder andere Watt mehr Schluckt.
Also ich sehe da kaum Anzeichen für ein funktionierendes RCM, sondern tatsächlich nur Verbesserungen dank neuem Stepping und Foundry-Verbesserungen.
Oder es ist wirklich nur ein enhanced RCM, mit paar Verbesserungen was hier und da 1-2% zusätzlich bringt.

[Knuddelbearli]

Da leonidas vermutlich eh nicht antworten wird stelle ich die Fragen auch mal hier

woher kommt eigentlich die Gewissheit von 225W?

habe dazu bisher keine Quelle gefunden, und wenn man Richland so ansieht würde ich eher 140W vermuten. ( Richland = ~10% mehr Takt das wäre bei Bulli ja schon 4,4 / 4,7Ghz dazu die höhere TDP von 140W )

selbes gilt für den Takt, woher hast du den Leonidas? auch da würde ich persönlich! eher einen sehr aggressiven Turbomode vermuten. sowas wie 4,6 / 5Ghz., 200Mhz sind ja bereits bei 4Ghz ja eigentlich ein Witz. Ein ordentlicher Turbo sollte ja auch bei singlecore die 125W ausnutzen und da sind sicher locker 4,6Ghz drinn wenn Rest schlafen gelegt wird.
Verstehe ich ja auch bei Intel nicht wo der 1 Kern turbo dann 40W verbraucht bei allen Kernen aber 84W

und last but not least hast du bei dieser News komplett den L3 unterschlagen, wenn es wirklich! 225W sind dann wurde sicher auch der L3 gut aufgebohrt. bei OC auf 2,8Ghz legt in Spielen ja schon der 8350 gut 20-30% zu ( selten auch weniger kommt immer aufs spiel an SC2 profitiert zB enorm und skaliert 1:1 mit )

[boxleitnerb]

140W? Das ist reichlich...optimistisch. Richland hat 2 Module, dieser neue FX hat derer 4. Ab einem gewissen Punkt muss man auch die Spannung erhöhen, um die 5 GHz im Turbo stabil zu bekommen.

[Knuddelbearli]

ob 2 oder 4 Module dürfte komplett egal sein, verbrauch blieb ja gleich bei Richland.

[boxleitnerb]

Ich verstehe nicht, was du meinst. Wir sprechen schon vom "Centurion", oder?

[Duplex]

Was ist überhaupt mit den PD 2.0 "20h" Kerne, geht ihr davon aus das die weniger Strom verbrauchen?

[Knuddelbearli]

ja nur wenn es bei Richland bei selben Verbrauch knapp 10% mehr Takt gibt wäre das bei einem 4 Modul Vishera auch der Fall, nur der L3 ist eine unbekannte, eventuell profitiert der nicht so sehr vom Fertigungsfortschritt eventuell aber auch noch mehr.

und ja reden von Centurion, diskutiere gerade mit peter von HT4U wenn wir damit fertig sind kommt sicher noch was von mir dazu

[boxleitnerb]

Ich glaub schon, dass es einen Unterschied bzgl. der Spannung machen kann, wieviele Module aktiv sind. Nicht umsonst sind viele Rekord-OC-Versuche mit nur einem oder zwei Kernen/Threads gemacht worden.

[Knuddelbearli]

ja weill man sich dann

1.) das beste Modul raussucht
2.) man sich in ganz anderen Verbrauchgrenzen bewegt wenn alle Kerne an wären, da verbraucht der 1 Kern ja schon fast soviel wie der Centurion ^^ gegen 2V helfen auch keine -100C°

besonders aber wegen 1.)
da es um Rekorde geht da gibt es keinen 2ten Platz ^^

[boxleitnerb]

Eben. Deshalb glaube ich nicht, dass man das mit dem Mehrtakt/Verbrauch nicht so einfach von einem 2-Modul Richland auf einen 4-Modul FX übertragen kann.

[Knuddelbearli]

kann deiner Argumentation nicht folgen bzw sehe ich nicht worauf du dich beziehst

[S940]

Laut Gerüchten soll der 5 Ghz Vishera nächste Woche zur E3 vorgestellt werden, würde vorschlagen wir sparen uns die Diskussion und warten einfach ab. Die paar Tage sind egal.

[boxleitnerb]

kann deiner Argumentation nicht folgen bzw sehe ich nicht worauf du dich beziehst

Es ist einfacher, weniger Module hoch zu takten als viele Module, denn da müssen alle den Takt mitmachen. Dafür braucht man evtl. mehr Spannung als bei weniger Modulen, und das treibt die Leistungsaufnahme dann in die Höhe. Daher kann man die Takt-Verbrauchs-Charakteristik nicht unbedingt zwischen CPUs mit unterschiedlicher Modulzahl vergleichen.

[Knuddelbearli]

nach so naja dafür wird ja selektiert, gibt ja nicht nur dieses spitzenmodell mit dem chip,
Schätze eh das centurio eher ne ganze reihe werden wird so wie Richland, und selbst wenn nicht gibt es ja weiterhin die anderen FX

[Skysnake]

Naja, es ist schon aufgefallen, dass die Zahlen für FX dann voll wären? :D

[Knuddelbearli]

wieos ? gibt es irgenwelche zuverlässigen quellen zu fx-9 ?

der name ist sowieso unsinnig da er ja keine 4,5 Module hat ( oder releast AMD jetzt doch den 5 moduler aber nur teildeaktiviert? ^^ )

[Skysnake]

Wieso FX9?

Es war doch von FX89xx die Rede.

[Knuddelbearli]

http://www.3dcenter.org/news/amd-scheint-tatsaechlich-bulldozer-prozessoren-mit-5-ghz-zu-bringen

FX-9000

[bio]

der direkte Vergleich zu Intel fehlt mal wieder so das man nicht vergleichen soll ? 220W finde ich recht viel

[Duplex]

Schade das "OBR" keine Infos mehr liefert, bei BD/PD hat er ordentlich recht gehabt.

Große Server DIEs wird man vermutlich nicht mehr bauen, PD soll bis 2015 halten...

[HOT]

Quark. AMD hat doch unlängst angekündigt da wieder partizipieren zu wollen. Das geht aber nunmal nicht mit dieser Architektur. Da brauchts ne neue (und wahrscheinlich auch ne neue Fertigung ;)). Das dauert eben auch bis 2015. OBR hatte recht damit, das vorerst nichts Neues kommt in diesen Bereichen, aber er hat nunmal auch keine Glaskugel.

[mironicus]

Nachgefragt werden die neuen Bulldozer aber schon:
http://geizhals.de/?o=4

Der FX-9590 auf Platz 4! :D

[Screemer]

Nur gucken, nicht anfassen.

[fondness]

On the mainstream side of things, AMD will launch the “Carrizo” APU in 2015. It will be based on the “Excavator” CPU core and Bolton-D4 A88X chipset. AMD hasn’t named the GPU yet, only stating it will have an unnamed “next generation” GPU. AMD lists its TDP at 65W, but says it is “scoping” 45W. AMD also says that “Carrizo” will be scoping DDR4, meaning that they haven’t confirmed support but are planning on having it. It will also support third-generation PCI express, and, of course, the HSA programming model.

Read more: http://vr-zone.com/articles/new-confirmed-details-on-amds-2014-apu-lineup-kaveri-delayed/47455.html#ixzz2aLyHLMpn

[Schaffe89]

Und da wird auch jetzt wieder vom Nachfolger geredet, wenn Kaveri eigentlich jetzt schon am Markt sein müsste, man hat ja früher mal gesagt mitte 2013.

Das kann nur ein schlechtes Zeichen sein. Kaveri wird womöglich ein Flopp.

[HOT]

Nicht umsonst sind die großen SR gecancelt worden. Die GPU wird toll, HSA auch, aber SR glaub ich nicht unbedingt. Von Excavator wird auch wirklich nur dann eine echte CPU kommen, wenn der sich spürbar abhebt, ansonsten bleibts bei Carrizo. Wahrscheinlich wird die nächste CPU eher pre-BD-Ära in 2016 sein.

[Duplex]

Bei SR hat man lediglich das Frontend ins Visier genommen, Cache & Decoder, ich gehe von 10-15% mehr IPC aus, das ist nicht viel wenn man den Rückstand zu Intel betrachtet, über der Effizienz brauchen wir erst garnicht reden, man wird weiterhin mehr Energie als Intel benötigen, auch die DIEs werden weiterhin groß ausfallen.
AMD hat eben auf das falsche Design gesetzt, hohe IPC mit >4Ghz ist effizienter als kleine IPC mit viel Takt.

[OBrian]

Wenn es nur noch reine APUs geben sollte, wäre das nicht wirklich ein Nachteil, auch Intel baut ja nur noch APUs, sie bezeichnen sie nur nicht so. Gäbe es von Kaveri einen 4-Moduler, dann wäre AM3+ wirklich überflüssig.

Das Problem ist einfach die fehlende CPU-Power. Der Takt ist ja nett, aber die IPC muß unbedingt gesteigert werden. Dabei ist die Leistungsaufnahme auch gar nicht mal so das Hauptproblem, weil in den meisten Absatzmärken der Strom viel billiger ist als bei uns und davon abgesehen die meisten CPUs sowieso meistens im Teillastbetrieb laufen. Aber wenn man mal Leistung braucht, dann muß sie auch lieferbar sein. Und das sind eben im Privatbereich oft Spiele, da muß AMD wirklich ranklotzen.

Es kann gut sein, daß die Verbesserungen mit Steamroller recht deutlich ausfallen, wenn das Frontend die hauptsächliche Handbremse war. Und Excavator wird sicher auch kein Rückschritt.

Aber diese ständigen Roadmap-Verschiebungen sind echt ungünstig. Vielleicht sollten sie mal einfach weniger detaillierte Roadmaps rausgeben, denn andere Firmen haben auch Verzögerungen, da fällt es aber nicht so auf.

[sklave_gottes]

Sicher ist die IPC ein Problem, aber ich sehe das größte Problem bei der Modulbauweise und der daraus resultierenden schwäche bei Anwendungen die alle Kerne unterstützen (nicht umsonnst rudert AMD wieder zurück). Desweiteren sind die Module einfach viel zu groß, ich sehe überhaupt nicht wo hier platz gespart wird bei der Modulbauweise. Ganz im gegenteil die Module nehmen mehr Platz ein als alles was AMD vorher hatte.
Nehmen wir einfach mal einen AMD A10-6700 und einen uralten AMD Phenom II X4 945(beide im Rechner). In single thread Anwendungen kann der A10 locker mithalten b.z.w. ist durchaus schneller. Aber sobald maximale Auslastung auf 4 Kerne/2Module besteht knickt der A10 ein und muss sich selbst einem Phenom II X4 945 mit 3ghz geschlagen geben. Und das kann einfach nicht sein!

[Palpatin]

In single thread Anwendungen kann der A10 locker mithalten b.z.w. ist durchaus schneller. Aber sobald maximale Auslastung auf 4 Kerne/2Module besteht knickt der A10 ein und muss sich selbst einem Phenom II X4 945 mit 3ghz geschlagen geben. Und das kann einfach nicht sein!
In den Reviews die ich jetzt so in Erinnerung hab war der A10 6800k auch bei Anwendungen die alle Kerne nutzen im Schnitt vor dem 965er Phenom II. Müsste also der 6700 eigentlich auch den 945er schlagen?

[Knuddelbearli]

hmm also ein A10 ist anch abzug der IGP doch ein gutes stück kleiner als der Phenom 2

[Schaffe89]

Man könnte mit etwas Anpassung heutzutage mit einem Phenom II x6 schneller und effizienter sein, im Vergleich zu einem FX-8350.

Erhöhter Nothbridgetakt auf 2,6hz, 3,7ghz Takt auf allen Kernen, 4ghz Turbo, innerhalb von 125 Watt und das noch in 45nm.

Man hätte Bulldozer sofort streichen sollen, wo man es noch konnte, eben Anfang 2011.

[Knuddelbearli]

wie oft den noch das stimmt einfach nicht. für avx fma usw hätte man so oder so die cpu massiv umbauen müssen

[boxleitnerb]

Beide Theorien wird man wohl nie beweisen können.

[Schaffe89]

wie oft den noch das stimmt einfach nicht. für avx fma usw hätte man so oder so die cpu massiv umbauen müssen

Man braucht den Firlefanz doch gar nicht, oder wo siehst du heute Anwendungen die das unterstützen, die existieren gar nicht in einem realen Anwendungsfeld.

[Schaffe89]

Beide Theorien wird man wohl nie beweisen können.

Zumindest konnte ich einen Phenom II x6 so sogar noch mit dem Boxedkühler betreiben.

[MR2]

Was mich nervt....

Früher ging es bei AMD immer irgendwie weiter. Der Thunderbird war ne Wucht, bei 1400 MHZ war er wirklich schnell, aber heiß, man fragte sich wie geht es weiter? PENG! kam der TBredA, das gleiche wieder, hart an der Schmerzgrenze, BÄM! Der TbredB, der Athlon64 war ne Welt, der X2 genauso. Auch wenn es Verzögerungen gab, AMD konnte immer ne Schippe drauf legen, wenn man dachte es ist vorbei...
Und jetzt? Sind die guten Leute geflogen, gegangen oder schläft der Laden? Es kommt einfach nix mehr. Nichts...
Irgendwie traurig....mir kommt es so vor als wären die Verbesserungen damals schneller, fließender umgesetzt worden, aber vielleicht kommt es mir auch nur so vor.

[S940]

Man braucht den Firlefanz doch gar nicht, oder wo siehst du heute Anwendungen die das unterstützen, die existieren gar nicht in einem realen Anwendungsfeld.Naja, die x264-Hacker gibts immerhin. Nicht viel, aber besser als überhaupt gar nichts.
BDv1/2 hab ich mittlerweile abgehakt, das war ne Kompromisslösung (AVX statt SSE5, 32nm ohne ULK), alles schnell zusammengewürfelt. Mal schauen wie sie den Core in Zukunft tunen werden und wie Die-Shrinks helfen werden.

Aus der Sicht nerven die ganze Steamroller-Verzögerung wirklich :freak:

Wenn man 1+1 zusammenzählt wirds wohl dann auch kein Zufall sein, wieso AMD noch ne neue Piledriver-Version für Server nachschiebt ...

@MR2:
Naja das Geschäft läuft schlecht, die 32nm Produkte waren anfangs einfach zu mieß und dann kauft auch noch alle Welt Smartphones statt Notebooks/Desktops. Richland ist jetzt ganz passabel, aber davor gabs einfach zuviel Probleme. AMD kann die besten Chips designen, aber wenn GF sie nicht fabben kann hilft das herzlich wenig. Wenn dann Not zu Elend kommt und auch noch das Design schlecht ist ... tja dann ..
Von daher müssen sie in Zukuft Intel bei der Fertigung ziehen lassen. GF hat versucht mit den Ankündigungen gleichzuziehen, aber wieviel Glauben man dem schenken kann hat man bei 32nm und auch bei 28 gesehen.

Immerhin sind ein paar gute Entwickler zurück, aber deren Einfluß wird man erst später sehen. Ich denke mal ab Excavator und/oder bei 20nm. Eventuell auch schon bei Kaveri, angeblich kommt da jetzt ne B-Version, muss man abwarten.

[HOT]

Es gibt mittlerweile auch zu viele Unsicherheitsfaktoren um da Schlüsse ziehen zu können.
1.) Was ist 28SHP wirklich?
a.) 28nm Bulk HP
b.) 28nm PDSOI-Shrink
c.) 28nm FDSOI

2.) Was ist von 20nm zu erwarten?
a.) FDSOI nutzbar?
b.) 14XM pünktlich?
c.) Standard-Bulk-Prozesse leistungsfähig genug?

3.) Warum wurde SR-Server gestrichen?
a.) simple Kostengründe
- Entwicklung zu teuer, Ertrag zu gering
- passt nicht mehr in die Strategie
- Infrastruktur nicht mehr vorhanden, neue Infrastruktur zu weit weg (ziemlich wahrscheinlich)
b.) Schwäche von SR
- holt nicht nicht genug auf als das es sich lohnen würde, ist aber dennoch schnell
- hebt sich zu wenig ab von PD
- BD technologische Sackgasse?
c.) weil man was in der Hinterhand hat
- dicke APU
- Excavator

Man kann das Spiel noch weiter treiben: Woran scheitert BD?
1.) Modulbauweise? (lt. diversen Tests ist der Ertrag 90% und mehr, kann also nicht sein, die Aussage ist schlicht falsifizierbar)
2.) Zu wenig Rechenleistung pro Modul und in der FPU (kann sicherlich limitieren, löst Excavator dann wohl)
3.) "Zusammengewürfeltes" Notprodukt? (sehr wahrscheinlich, vom 2008 begonnenen 45nm BD zum "fertigen" BD Anfang 2011 verging nur sehr wenig Zeit)
4.) Zu unflexibles Frontend (sicherlich größtes Problem, löst SR sicherlich weitgehend)
5.) kein Tracecache
6.) zu langsame I/O-Bereiche und L3-Cache

Fakt ist aber auch, dass nach Warsaw was kommen muss. Für eine komplett neue Arch wär die Zeit zu knapp, also muss nach dem gecancelten SR ein Excavator in die Bresche springen, das geht gar nicht anders. Vllt eine dicke APU? würde auch die geringe TDP der Carizos erklären. Vielleicht lässt sich der Ausfall des Server-SR auch schlicht mit dem Ausfall des Sockels 2012 begründen. Warum sollte man jetzt noch einen neuen Sockel für DDR3 planen, was SR sicherlich geworden wär? Mit dem Cancel von Komodo ist mal eben die gesamte SR-Nachfolge mit gestorben, einfach weil die gesamte Plattform gestorben ist. Ersatz: Orochi-Aufguss. Wegen DDR4 und APU hätte Excavator sowieso einen neuen Sockel gebraucht.

[StefanV]

Was mich nervt....

Früher ging es bei AMD immer irgendwie weiter. Der Thunderbird war ne Wucht, bei 1400 MHZ war er wirklich schnell, aber heiß, man fragte sich wie geht es weiter? PENG! kam der TBredA, das gleiche wieder, hart an der Schmerzgrenze, BÄM! Der TbredB, der Athlon64 war ne Welt, der X2 genauso. Auch wenn es Verzögerungen gab, AMD konnte immer ne Schippe drauf legen, wenn man dachte es ist vorbei...
Und jetzt? Sind die guten Leute geflogen, gegangen oder schläft der Laden? Es kommt einfach nix mehr. Nichts...
Irgendwie traurig....mir kommt es so vor als wären die Verbesserungen damals schneller, fließender umgesetzt worden, aber vielleicht kommt es mir auch nur so vor.
Jetzt hat man einfach kein Geld mehr, man dümpelt so rum und versucht irgendwie zu überleben.
Für die jetzige Situation kannst dich bei Intel und den entsprechenden Fans bedanken, die zu K7 und insbesondere K8 eine weitgehende Verbreitung von AMD Systemen verhindert haben.

Und jetzt gibts die Quittung dafür...

Man könnte mit etwas Anpassung heutzutage mit einem Phenom II x6 schneller und effizienter sein, im Vergleich zu einem FX-8350.
Hast du einen FX8350 und einen Phenom II X6, um diese Aussage auch belegen zu können?
Wenn nein, ists einfach nur irgendein Unsinn, den irgendwer in die Welt gesetzt hat.

Mein Eindruck der letzten Tage ist, dass der FX8350 bei SWTOR 'nen ganzes Stückerl schneller denn der Phenom II 955BE (C2 Stepping) ist...
Und das wird bei anderen Dingen ähnlich sein, so dass man unterm Strich sagen kann, dass der FX8350 grundsätzlich 'nen Upgrade von einem 955BE ist.


Erhöhter Nothbridgetakt auf 2,6hz, 3,7ghz Takt auf allen Kernen, 4ghz Turbo, innerhalb von 125 Watt und das noch in 45nm.
Und was denkst du, wo der FX8350 stehen würde, wenn der NB Takt bei 2,5-3GHz stehen würde? ;)

Man hätte Bulldozer sofort streichen sollen, wo man es noch konnte, eben Anfang 2011.
Und dann wäre man total am Arsch gewesen...
Nee, wirklich, das wäre echt das dümmste gewesen, was AMD hätte machen können.

Und so übel (wie ein P4) ist der BD ja nun auch wieder nicht...
Und auch die nicht so tolle Performance sollte man bei der Architektur auch hinbekommen, das Backend ist ja soweit ganz OK, es scheitert eher am Frontend sowie dem I/O System. Die Architektur an sich ist ja ganz OK...


Man kann das Spiel noch weiter treiben: Woran scheitert BD?
1.) Modulbauweise? (lt. diversen Tests ist der Ertrag 90% und mehr, kann also nicht sein, die Aussage ist schlicht falsifizierbar)
2.) Zu wenig Rechenleistung pro Modul und in der FPU (kann sicherlich limitieren, löst Excavator dann wohl)
3.) "Zusammengewürfeltes" Notprodukt? (sehr wahrscheinlich, vom 2008 begonnenen 45nm BD zum "fertigen" BD Anfang 2011 verging nur sehr wenig Zeit)
4.) Zu unflexibles Frontend (sicherlich größtes Problem, löst SR sicherlich weitgehend)
5.) kein Tracecache
6.) zu langsame I/O-Bereiche und L3-Cache
Ich denke, dass die letzten 3 Punkte die wichtigsten sind.

Insbesondere der unglaublich lahme L3 Cache dürfte hier einiges ausmachen. Wenn man dem einen Hotclock geben würde (=Faktor 1,5 von der NB bzw den ganzen L3 Cache Krams mit Coretakt laufen lassen), dürfte das schon einiges ausmachen.

Das ist aber auch ein Grundsätzliches Problem bei AMD, dass die Caches relativ lahm sind...

[S940]

Es gibt mittlerweile auch zu viele Unsicherheitsfaktoren um da Schlüsse ziehen zu können.
1.) Was ist 28SHP wirklich?
a.) 28nm Bulk HP
b.) 28nm PDSOI-Shrink
c.) 28nm FDSOI

Das würde ich so aufteilen:
a) 5%
b) 90%
c) 5%


2.) Was ist von 20nm zu erwarten?
a.) FDSOI nutzbar?
b.) 14XM pünktlich?
c.) Standard-Bulk-Prozesse leistungsfähig genug?

Naja, wichtig ist da eher d) Bekommts GF zeitnah gebacken, oder nicht. 32nm war ein Desaster und 28nm nicht besser, fast noch schlecht mit den knapp 2 Jahren Verspätung. Bei FDSOI ist "nur" wichtig, ob Soitec die Schichtdichten bei den Wafern packt. DAs was GF dann damit macht ist Standard.
3.) Warum wurde SR-Server gestrichen?
Wahrscheinlich schlichtes Kostenrechnen, AMD verliert, die Zukunft ist laut AMD bei 1P und Seamicro, ergo braucht man kein Hypertransport mehr, ergo auch keine neue Plattform damit. Frage ist nun, ob AMD noch nen neuen high-end Sockel aka Plattform ohne Hypertransport bringt. Der bräuchte dann nur mehr Speicherkanäle und mehr PCIe-Lanes. Aber das wird dann wohl auch eher gestrichen.
Erstens brauchts mit PCIe3 und DDR4 nicht mehr Kanäle/Lanes, da sich die Bandbreite sowieso verdoppelt, zweitens dürfen die DIEs für Seamicros Dense-Server nicht zu groß werden bzw. zuviel verbrauchen und drittens hat BD sowieso schon ziemlich viel Cache, der mit mehr Modulen pro Die noch weiter ansteigen würde.

Im Moment hoffe ich auf ein 12 Kern / 6 Module-Die in 20nm mit Dual-DDR4 und PCie3 für FM3. Das sollte so einigermaßen das Preis/Leistungsmaximum, sein je nachdem wie gut 20nm wird. Das DIE nicht zu groß, aber nicht zu wenig Kerne, Stromverbrauch der guten DIEs sollte auch passabel sein. Aber pures Wunschdenken ^^


Man kann das Spiel noch weiter treiben: Woran scheitert BD?
6.) zu langsame I/O-Bereiche und L3-Cache
Darf man wohl als gesichert annehmen, nachdem AMD das auf 256bit aufbohrt.

Fakt ist aber auch, dass nach Warsaw was kommen muss. Wieso ist das Fakt? Sehe ich überhaupt nicht so, Ich hoffe halt darauf, siehe oben das 12core-Wunschdenken, aber dem neuen Management trau ich auch zu die großen x86-Dies komplett einzustampfen und komplett auf APUs zu setzen.

Mit dem Cancel von Komodo ist mal eben die gesamte SR-Nachfolge mit gestorben, einfach weil die gesamte Plattform gestorben ist. Ersatz: Orochi-Aufguss. Wegen DDR4 und APU hätte Excavator sowieso einen neuen Sockel gebraucht.Ja da ist wohl auch was dran. Alte Plattform weg, deswegen wird auch der Nachfolgechip gestrichen. Dachte zuerst, dass man einfach ne DDR4-Version der Plattform bringt, aber dann kam die Seamicro-Akquise.

[HOT]

Das Wichtigste ist, dass die Plattform dann auch mindestens 5 Jahre halten muss. Das wär mit SR als Riesen-APU nicht drin gewesen und auch DDR4 wär einfach zu knapp geworden. Von daher finde ich die neue Plattform für die nächsten Jahre mit frühestens dem Excavator-Start ziemlich logisch. Kann natürlich auch sein, dass die dicke Plattform erst nach der Excavator-Generation mit der neuen µArch losgeht, aber wie überbrückt man das? Noch ein Orochi? Glaub ich nicht mehr dran, dass die so lange eine Lücke lassen. Excavator wirds schon werden, aber eben als große APU und nicht mehr als CPU. Mit neuer Fertigung (für am wahrscheinlichsten halte ich bei GloFo 20nm FinFET, also 14XM) und neuer µArch wird man frühestens Mitte 2016 kalkulieren können (wir kennen GloFo und wir kennen AMD). Von Warsaw zu der neuen Groß-APU wär einfach eine zu große Zeitlücke - die muss Excavator schließen. Und da als kleine Variante Carizo maximal 65W kommt muss da auch was größeres in der Pipeline sein mMn.

[robbitop]

Du meinst hoffe ich 12 Kerne / 6 Module? 12 Module wäre ganz schön viel.

[Brillus]

Du meinst hoffe ich 12 Kerne / 6 Module? 12 Module wäre ganz schön viel.


Ich glaub er meint 12 Module, wie ich es gelesen habe sind wir bei Server-CPUs und die sind nach meinem Wissen jetzt schon bei 8 Modulen,

[fondness]

20nm würde ggü. 32nm immerhin auch 2,56 mal so viele Transistoren pro Fläche erlauben, ist immerhin Full- plus Halfnode-Shrink. Da sollten 6 Module plus eine ordentliche GPU schon in unter 300mm² machbar sein.

[robbitop]

Ich glaub er meint 12 Module, wie ich es gelesen habe sind wir bei Server-CPUs und die sind nach meinem Wissen jetzt schon bei 8 Modulen,
Das sind dann aber 2 Dies auf einem Package oder?

[Knuddelbearli]

jup

[S940]

Du meinst hoffe ich 12 Kerne / 6 Module? 12 Module wäre ganz schön viel.Jupp, 12 Module wären wirklich etwas viel ^^
Je nachdem, wieviel Platz man durchs weglassen von HTr spart, könnte man sich auch 16 überlegen, aber soviel wird das nicht sein, ausserdem würde dann wohl sogar DDR4 limitieren. So 12 Kerne/6 Module wäre mMn ein guter Kompromiss, aber wie gesagt ... abwarten, vielleicht kommt auch gar nichts mehr, wer weiss :(

[Knuddelbearli]

wieso sollte dort ddr4 limitieren?

ist dann ja quadchannel

und duachannel + 4 Moduler wird selbst bei 1333 nur sehr selten ausgebremst ( paar prozent peformamnce gewinn/verlust ist nicht ausbremsen )

[S940]

wieso sollte dort ddr4 limitieren?

ist dann ja quadchannel
Ne eben nicht, die Rede war doch von einem einzigen Die für FMx, unter der Annahme, dass AMD in den totalen Sparmodus geht und sich keine extra Server-Plattformen mehr leisten. Der eine Ex-Marketing-Chef redete doch auch mal davon, dass es sündhaft teuer wäre ne Plattform zu validieren.

Wenn man sich die Seamicro-Server anschaut, dann sieht man, dass sie dort keine Sockel 2011 CPUs verwenden, sondern Sockel 1155. Der Schlüssel der Teile ist, dass sie die billigen 1P-Xeons verbauen, da die 2P oder gar 4P-Xeons überproportional teurer sind, der Preis steht in keiner (guten) Relation zur Rechenleistung.

Ergo spekuliere ich darauf, dass AMD zwar etwas Größeres als die aktuellen CPus bringen wird, aber keine Experimente mit Riesendies macht.
6Module/12Kerne, Dual DDR4, 12MB L2 + 12 MB L3 und PCIe3 x16 @20nm klängen da mMn relativ vernünftig. Aber wie gesagt, pures Wunschdenken.

[robbitop]

Ich tippe darauf, dass sie nur noch APUs machen und die auch im Server einsetzen. 4 Module Excavator + L3 + GPU wäre für 20 nm schon ziemlich gut. Oder?

[Twodee]

Ich tippe darauf, dass sie nur noch APUs machen und die auch im Server einsetzen. 4 Module Excavator + L3 + GPU wäre für 20 nm schon ziemlich gut. Oder?
wenn das teil dazu noch eine 45TDP hat, dann ja :biggrin:

[mironicus]

Wunschvorstellung:
8 Module (16 Kerne) ohne GPU in 20 nm für AM3+ (nur Biosupdate nötig) für 150 Euro. ^^

[S940]

Ich tippe darauf, dass sie nur noch APUs machen und die auch im Server einsetzen. 4 Module Excavator + L3 + GPU wäre für 20 nm schon ziemlich gut. Oder?
Hätte auch was, aber da ist die Preisfrage ob man anstatt L3 nicht lieber mehr GPU-Shader verbaut.
GPUs sind ja per-se nicht latenzabhängig, wozu also nen L3?

[robbitop]

Hätte auch was, aber da ist die Preisfrage ob man anstatt L3 nicht lieber mehr GPU-Shader verbaut.
GPUs sind ja per-se nicht latenzabhängig, wozu also nen L3?
Na für die CPU. Die sollte doch sicher gut 10-15 % IPC Zugewinn bekommen (insbesondere bei FullClock Anbindung!!).

4 Module/8 Kerne reichen doch für soziemlich alles aus pro DIE. Intel kommt sogar mit 4 Kernen und SMT aus. Letztenendes nutzt man in letzter Zeit viel Platz für die GPU. Am Ende müssen vor allem die Kerne per se schneller werden.

[S940]

Na für die CPU. Die sollte doch sicher gut 10-15 % IPC Zugewinn bekommen (insbesondere bei FullClock Anbindung!!).
Fullclock wird man wohl ausschließen können. Das mag bei Spielen was bringen, aber sonst? Wir reden hier ja eher von Server-Tasks. Bei Intel brachte es v.a. etwas, da sie nur 256kB L2 haben.

So ne APU mit L3 wäre weder Fisch noch Fleisch. Für die CPU-Tasks keine Verbesserung ggü. den aktuellen Design (abgesehen von IPC-Verbesserungen) und der GPU-Part wird ebenfalls nicht recht viel größer bei den aktuellen Chips ausfallen können.
Da wär mir ne APU mit schön viel Shadern und ne reine CPU mit schön viel CPU-Kernen und L3 lieber.
4 Module/8 Kerne reichen doch für soziemlich alles aus pro DIE. Im Desktop ja, aber so ein Seamicrosystem besteht nicht nur aus einer CPU ;-) Wer sowas kauft will viele Kerne haben :)
Am Ende müssen vor allem die Kerne per se schneller werden.Ja das wäre natürlich wünschenswert - aber das ist wieder Desktopsicht. Falls der komische Die-Shot von Letztens echt sein sollte, würde das aber auch eher bedeuten, dass auch AMD auf noch mehr Threads setzen würde.

[fondness]

Das mag bei Spielen was bringen, aber sonst? Wir reden hier ja eher von Server-Tasks. Bei Intel brachte es v.a. etwas, da sie nur 256kB L2 haben.

So ne APU mit L3 wäre weder Fisch noch Fleisch. Für die CPU-Tasks keine Verbesserung ggü. den aktuellen Design (abgesehen von IPC-Verbesserungen) und der GPU-Part wird ebenfalls nicht recht viel größer bei den aktuellen Chips ausfallen können.
Da wär mir ne APU mit schön viel Shadern und ne reine CPU mit schön viel CPU-Kernen und L3 lieber.


Dir ist schon bewusst, dass die einzige AMD-CPUs mit L3-Cache stets Server-Designs waren? Das bringt gerade im Server-Bereich bei großen Daten und reger Kommunikation zwischen den Kernen etwas. Allerdings muss AMD ohnehin etwas am Cache-Design ändern wenn sie wieder konkurrenzfähig sein wollen, hoffentlich kommt das mit Exavator. Ein inklusives Cache-Design mit schnellem LL-Cache hat in punkto Stromverbrauch und Leistung einfach deutliche Vorteile, bei Jaguar hat man das ja bereits umgestellt. Dazu braucht es endlich konkurrenzfähige Prefetching-Algorithmen.

[MR2]

Vielleicht haben sie bis jetzt gespart:-)
http://www.computerbase.de/news/2013-08/amd-eroeffnet-neues-soc-design-zentrum-in-indien/

100te Ingenieure, Bau und Ausrüstung kosten sicher massig Geld.

[S940]

Dir ist schon bewusst, dass die einzige AMD-CPUs mit L3-Cache stets Server-Designs waren?
Nein, das ist mir neu :freak:
Das bringt gerade im Server-Bereich bei großen Daten und reger Kommunikation zwischen den Kernen etwas.Richtig, v.a. bei Datenbanken braucht man den Cache. Aber es stellen sich da 2 Fragen:
1. Gibts Datenbankanwendungen für GPGPU?
2. Falls ja, braucht man dafür wirklich den großen Cache, und wäre mehr GPU-Power stattdessen nicht besser?

GPUs brauchen konzeptuell wenig Caches, seit GPGPU wurden nun ein paar kleine L1+L2 Caches eingeführt, aber das ändert nichts am Konzept, dass auf ner GPU ein paar hundert Threads laufen. Jede Software die nun die GPU nutzt, wird von dieser Threadanzahl gebrauch machen, ansonsten kann man sich den GPGPU-Aufwand gleich sparen.
Kurz: Sobald man Algorithmen hat, die die GPU nutzen können, braucht man auch keine großen Caches.

Allerdings muss AMD ohnehin etwas am Cache-Design ändern wenn sie wieder konkurrenzfähig sein wollen, hoffentlich kommt das mit Exavator.
Das kommt teilweise schon mit Steamroller ;-)
Erstens größer, zweitens bessere Modulanbindung.
In Sachen inclusive frag ich mich derzeit, ob der L3 auch L1-inclusive ist (die CPUID-Infos legen das nahe), das würde für die Kohärenzsachen eigentlich schon reichen.

Vielleicht haben sie bis jetzt gespart:-)
http://www.computerbase.de/news/2013-08/amd-eroeffnet-neues-soc-design-zentrum-in-indien/

100te Ingenieure, Bau und Ausrüstung kosten sicher massig Geld.
Hmm nett, aber die hatten da schon früher ne Niederlassung, da haben sie anscheinend "nur" neu gebaut bzw. expandiert.

[HOT]

Wenn man für Server-APUs einen L3 haben möchte wird das wohl eher Stacked-RAM werden oder sowas. On-Die ist da sicherlich vorbei. Vielleicht führt man eher noch einen L1,5 Cache irgendwann ein.

[Knuddelbearli]

einen cache auf den alle Module zugreifen können wird man im Server Bereich immer brauchen

[Skysnake]

Hätte auch was, aber da ist die Preisfrage ob man anstatt L3 nicht lieber mehr GPU-Shader verbaut.
GPUs sind ja per-se nicht latenzabhängig, wozu also nen L3?
Kommt darauf an. Wenn du ne apu richtig nutzen willst, dann ist eine niedrige Latenz zwischen CPU und gpu schon erstrebenswert, da man dann mehr auf die igpu schieben kann.

Caches sind aber NICHT nur dafür da die Latenz zu senken, sondern auch um die datenlikalität aus zu nutzen, um damit die Bandbreite zu steigern und sogar noch Strom zu sparen, da man kürzere signalwege hat und nixht offchip muss.
Fullclock wird man wohl ausschließen können. Das mag bei Spielen was bringen, aber sonst? Wir reden hier ja eher von Server-Tasks. Bei Intel brachte es v.a. etwas, da sie nur 256kB L2 haben.

So ne APU mit L3 wäre weder Fisch noch Fleisch. Für die CPU-Tasks keine Verbesserung ggü. den aktuellen Design (abgesehen von IPC-Verbesserungen) und der GPU-Part wird ebenfalls nicht recht viel größer bei den aktuellen Chips ausfallen können.
Da wär mir ne APU mit schön viel Shadern und ne reine CPU mit schön viel CPU-Kernen und L3 lieber.

Siehe oben, ein Cache hilft auch einer igpu. Insbesondere wenn die Datenzugriffe etwas irregulärer werden hilft ein Cache extrem. Die igpu bricht dann einfach nicht so schnell ein wie ohne Cache. Und das ist wirklich ein Problem von gpus! Sie erfordern einen hohen datenrese auf recht kleinen Datensätzen. Deswegen sind gpus auch schwieriger effiziente zu programmieren, vor allem weil man ja auch noch schneller sein muss als einfach mit der CPU. Caches sind daher sehr schön, weil man damit das Problem des leistungseinbruchs reduzieren kann, was wiederum dazu führt, dass man die igpu für mehr Aufgaben sinnvoll einsetzen kann.