[Sammelthread] AMD Bulldozer "Zambezi" 32nm "New CPU Architecture" Sockel AM3+ [Part 3]

[Schaffe89]

Der Basistakt spielt bei AMD wohl eher eine untergeordnete Rolle, wenn alle Kerne vom Turbo profitieren sollen.
Intels Turbo der neuen i7 2x00 ist was den Speedup betrifft schwächer als der der letzten Generation.

 

[Thunderburne]

@Schaffe89
Ich schiele da schon in richtung nächste Graka Generation.
Wenn diese bis zu 50% mehrleistung aufwarten kann wird das Eng mit heutigen Cpus .
Mein HD6970 Gespann CF skalierte bei full HD 8MSAA +16Fach noch bis Ca.5,2 GHZ mit Sandy bei BC2 mit NV 2 GTX580 SLi die ich jetzt habe so bis 4,8 GHZ.
Was ich damit sagen will um die nächste Generatrion im Sli voll auszulasten wird es noch viel mehr an Pro MHZ Leistung brauchen um das zu befeuern.
Nun ja nicht jeder nutzt full HD ich weis .

 

[mr.dude]

Das ist halt das Problem bei einer spekulativen Betrachtung. Aber sollte die Rechnung nicht nur zeigen, das es theoretisch möglich wäre, dass der FX6 sogar mit dem i7 2600 mitmischen könnte.

Korrekt. Es spricht jedenfalls nichts dagegen, dass dies in bestimmten Szenarien der Fall sein könnte. Für mehr, zB wie es bei der durchschnittlichen Performance ausschaut, war die Rechnung gar nicht gedacht.

Schon schlimm, wenn man dies von Anfang an so formuliert und einige bekannte Leute es trotzdem nicht lassen können, wieder ein Drama daraus zu machen.

 

[Undertaker 1]

Sehe ich genauso!

Tja. Es bringt doch gar nix, hier irgendwas gut- oder schlecht zu rechnen, je nach dem, wie man es denn selbst sehen möchte. Das scheint nur manchem hier nicht klar zu sein.

 

[Schaffe89]

Ja, aber wahrscheinlich nur, weil ein Overhead vorliegt, welchen man mit einer schnellen Single GPU der nächsten Generation wohl nicht hat.

Die GPU Leistung steigt ja jedes Jahr relativ stark im Vergleich zu Prozessoren.
Imho muss man halt die Überschüssige GPU Performance in mehr BQ umwandeln.

 

[Undertaker 1]

Die GPU Leistung steigt ja jedes Jahr relativ stark im Vergleich zu Prozessoren.
Imho muss man halt die Überschüssige GPU Performance in mehr BQ umwandeln.

Allerdings steigen auch die GPU-Anforderungen deutlich schneller als die der CPUs. Zumindest könnten die Hersteller aber mal anfangen, immer mehr freie CPU-Kerne für bessere KI oder ähnliches zu verwenden...

 

[Thunderburne]

Imho muss man halt die Überschüssige GPU Performance in mehr BQ umwandeln.

Ja ich Fahre eine MIX aus Bildquali und Performance um nahe zu 100% Gpu Load zu gewährleisten zu können mit Inspector ist sowas ganz gut möglich.
Möchte halt auch meine 120 FPS dabei halten für einen 120HERZ TFT.

Für 1ne Gpu der next gen sollte ja so eine BD oder Sandy Cpu dicke reichen.

Bei SLI und CF wirds dan eng da müssen dan schon 22 NM herhalten oder oder Sandy-E.
Lassen wir uns überraschen dieses Jahr bis Anfang 2012 wird viele neue Überaschungen mit sich bringen.
MFG

 

[mr.dude]

Tja. Es bringt doch gar nix, hier irgendwas gut- oder schlecht zu rechnen, je nach dem, wie man es denn selbst sehen möchte.

Hier wurde gar nichts gut oder schlecht gerechnet, sondern lediglich ein mögliches Szenario aufgezeigt. DAS scheint manchem hier nicht klar zu sein. Alleine wer Begriffe wie gut oder schlecht ins Spiel bringt, hat das offenbar nicht kapiert. Denn weder wurde das eine noch das andere impliziert.

 

[Duplex]

Kommen wir jetzt alle zum Thema zurück!

 

[retarded]

Ich verstehe hier nicht wie man soviel auf Ergebnisse von PCmark und co. geben kann,
also für mich ist diese ganze Schiene gestorben, als man bei 3DMark06 automatisch
X+3000 Punkte bekommen hat, wenn man einen Intel verbaute.

 

[miriquidi]

Eine Frage zum Bulldozer: Kann man CMT irgendwie deaktivieren, wenn es negative Auswirkungen hat?

Im Taskmanager die entsprechenden Kerne für die kritische Applikation abwählen?

 

[Chezzard]

Im Taskmanager die entsprechenden Kerne für die kritische Applikation abwählen?

Bis jetzt war es bei mir so, dass diese Methode nur temporär war.

Nach einem Neustart war alles beim alten, das wäre dann auch nervig...

 

[Opteron]

nn man CMT irgendwie deaktivieren, wenn es negative Auswirkungen hat?
Bei SMT gab es damals auch Probleme und für einige Anwendungen war es ohne besser.

Macht bei CMT keinen Sinn, bei SMT hats anfangs gehakt, da die ellenlange P4 Pipeline (Stichwort Replay) aus dem Tritt kam, dazu noch die Überlastung der Caches.
Das hat sich beim Nehalem aber gegeben, zumindest hab ich seitdem keine Beschwerden gehört, vom AMD Marketing mal abgesehen ;-)

Das letzte Problem war der doofe Windows Scheduler, der erstmal 2 Threads auf einen Kern mit 2fach SMT legte, was natürlich für famose Leistung sorgte Aber seit Win7 ist da ja auch alles in Butter.
Vermutlich wird AMD das SMT Flag für BD nutzen, und die Cluster fürs OS als SMT Kerne tarnen, dann bräuchte es nichtmal nen Patch für BD.

Im Unterschied zu SMT könnte es bei CMT aber vielleicht doch Sinn machen, 2 Threads auf einem Modul laufen zu lassen, z.B. wenn die gleichen Daten verwendet werden. KA wie sie das lösen werden, wenn überhaupt. Fürs Erste sollte der "SMT Stealth mode" gute Ergebnisse liefern.

Ansonsten gabs fürs Festpinne von Threads ein kleines Tool, Namen hab ich leider vergessen, hab nur 2 Kerne, macht da keinen Sinn ^^
Aber vielleicht hats einer hier ja im Einsatz und kann weiterhelfen.

 

[mr.dude]

Macht bei CMT keinen Sinn, bei SMT hats anfangs gehakt, da die ellenlange P4 Pipeline (Stichwort Replay) aus dem Tritt kam, dazu noch die Überlastung der Caches.
Das hat sich beim Nehalem aber gegeben, zumindest hab ich seitdem keine Beschwerden gehört, vom AMD Marketing mal abgesehen

Das kommt nicht nur vom AMD Marketing. Man hört auch immer wieder von Serverleuten, dass sie SMT teilweise abschalten. Intel selbst empfiehlt das ja für bestimmte Anwendungen. Ob es bei CMT keinen Sinn macht, sei mal dahingestellt. Das werden wir erst sehen, wenn es genügend Erfahrung damit gibt. Es ist aber zumindest richtig, dass ein Abschalten von CMT weniger Sinn macht als bei SMT. Eine entsprechende Option würde ich mir dennoch wünschen. Das zu implementieren sollte nicht problematischer sein als bei SMT.

 

[Opteron]

Das kommt nicht nur vom AMD Marketing. Man hört auch immer wieder von Serverleuten, dass sie SMT teilweise abschalten.

Hast Du da nen aktuellen Link ? Das letzte, das ich sah waren eben ein oracle Manual, und das bezog sich ebenfalls nur auf die P4 Xeons.

 

[mr.dude]

Frag mich mal was einfacheres. Da müsste ich jetzt erst suchen.


edit:

Hab noch was auf AMDZone gefunden. Um welche Rechner es sich dabei handelt, steht allerdings nicht dort. Hier gibt es auch noch etwas aktuelleres. Aber genug off-topic. Der Punkt war, auch wenn sich seit P4 sicherlich einiges getan hat, die Probleme sind nicht vollständig verschwunden. Können sie auch gar nicht, weil SMT immer mit gemeinsamen Ressourcen zu kämpfen haben wird, die je nach Anwendung mal mehr und mal weniger zum Flaschenhals werden können. Da bleibt zu hoffen, dass CMT diesbezüglich weniger Probleme hat.

Ich hatte JF ja schon mal darauf angesprochen, ob sich AMD der Problematik bewusst ist, Threads zuerst auf unterschiedlichen Modulen ausführen zu lassen und erst dann den zweiten logischen Prozessor eines Moduls zu nutzen. Offenbar sah er dort keine Probleme und sagte, dass jeder "Kern" gleich behandelt werden würde. Ehrlich gesagt bin ich da nach wie vor skeptisch.

 

[santa clause]

Sehe ich genauso.
AMD hat ja (soweit ich mich erinnern kann) behauptet, dass man mit einem "Modul", welches zwei Int.-Einheiten besitzt und sich die anderen Resourcen teilt 20% weniger Leistung haben wird (180%), als wenn jeder Int.-Kern seine eigenen Resourcen hätte (200%). Wenn man den 4Modul Bulldozer jetzt mit 4 Threads belastet, hätte man natürlich diese 10% mehr Leistung, wenn Windows jeden Thread je einem Modul zuweist (ich glaub das meintest du mit der SMT-Flag).

Könnte aber auch sein, dass man lieber die vier Threads auf 2 Module verteilt, damit man die anderen stark heruntertakten oder evtl. sogar gänzlich in den Ruhezustand versetzen kann. Sollte mehr Leistung benötigt werden, könnte ja immer noch der Turbo eingreifen und die zwei Module entsprechend übertakten.

 

[Opteron]

thx füs Suchen!

Frag mich mal was einfacheres. Da müsste ich jetzt erst suchen.


edit:

Hab noch was auf AMDZone gefunden. Um welche Rechner es sich dabei handelt, steht allerdings nicht dort.

Das ist garantiert ein P4, er schreibt ja "way back", und die erwähnte Oracle Doku hab ich auch gelesen.

Hier gibt es auch noch etwas aktuelleres.

Hmm klingt eher nach Softwareproblemchen.
Erst gibts zwei Windows OS Hotfixes, und dann wird über die App selbst gesprochen:

MAXDOP (Maximum Degrees of Parallelism). Everything I read indicates that having this unbounded is probably a bad idea, and the Microsoft documentation says:

Setting this option [MAXDOP] to a larger value [than 8] often causes unwanted resource consumption and performance degradation.
​

Default ist 0, d.h. bei nem dual Quad mit HT wird das wohl auf 16 stehen ...

Am Ende gibts zwar noch ne L2 Theorie, aber bewiesen ist sie leider nicht.
Falls sie stimmen sollte, sollte BD aber kein Problem haben, der L2 Cache wird pro Thread ja sogar etwas größer (1MB statt 512kB)

Aber genug off-topic. Der Punkt war, auch wenn sich seit P4 sicherlich einiges getan hat, die Probleme sind nicht vollständig verschwunden. Können sie auch gar nicht, weil SMT immer mit gemeinsamen Ressourcen zu kämpfen haben wird, die je nach Anwendung mal mehr und mal weniger zum Flaschenhals werden können. Da bleibt zu hoffen, dass CMT diesbezüglich weniger Probleme hat.

Na OT finde ich es nicht, wird überlegen ja, ob CMT an ähnlichen Symptomen leiden könnte wie SMT.

 

[CyLord]

Gab´s nicht mal ein Video, wo ein AMD-Mann darüber geredet hat. Man wollte ja danach die Schwächen mit CMT gegenüber SMT ausmerzen. Auch wegen deren Problemen.

 

[miriquidi]

Maximum Degrees of Parallelism gibt's auch in den Parallel Extentions für C# (.NET 4.0) als Option für die Parallel.for-Tasks usw. Hin und wieder wird ein Thread von Windows trotzdem auf einen virtuellen Kern verschoben, ist also kein echter Ausschalter.

 

[mr.dude]

Das ist garantiert ein P4, er schreibt ja "way back", und die erwähnte Oracle Doku hab ich auch gelesen.

Kann sein. Er schreibt aber auch nicht, dass es mittlerweile anders wäre.

Hmm klingt eher nach Softwareproblemchen.

Eher weniger. Wenn man sich mal alle Kommentare durchliest, ist der Tenor ziemlich eindeutig. Du hättest mal den Text davor und danach noch zitieren sollen:

at best the recommendation is "try HyperThreading on your workload and see what happens". ...
you should probably always start with HyperThreading disabled, as that is safest
...
But honestly these feel like workarounds; I think the true solution for our workload (full-text index heavy) is to disable HT.

Und genau solche Sachen liest man leider häufiger. Das ist ja genau das, weshalb AMD nichts von SMT hält. Es kann je nach Workload einfach völlig unterschiedlich reagieren und ist damit unberechenbar. Stell dir einen Server vor, auf dem mehrere Anwendungen laufen. Ein Teil davon profitiert von SMT, ein anderer Teil wiederum nicht bzw verliert sogar an Performance. Was machst du nun? Schaltest du SMT ab oder nicht? Was du auch immer machst, es bleibt ein fauler Kompromiss.

 

[miriquidi]

Was machst du nun? Schaltest du SMT ab oder nicht? Was du auch immer machst, es bleibt ein fauler Kompromiss.

Das bleibe es auch mit der Doppel-Integer-Kern Lösung. Doppelte Thread-Zahl bedeutet nun zwangsläufig halben Cache pro Thread. Greift man auf größere Datenmengen (andere Daten pro Thread) mit stochastischen Mustern zu, sinkt die Wahrscheinlichkeit sie im Cache anzutreffen. Die Anwendungsspezifität hat man auch dort.

Bei meinen bisherigen Aufgaben war Hyperthreading aber immerhin für ca. 20 % Mehrleistung gut. Bei Bulldozer wirds interessant, was man mit zusätzlichen Integer-Kernen bei Gleitkomma-Berechnungen gewinnt.

 

[giga lightstorm]

Weiß jemand von euch eigentlich, was in heutigen CPUs der "Flaschenhals" ist. Ich hab hier im Thread mal gehört dass bei typischen Anwendungen die INT mit 100%, die FP mit 40% und die Decoder mit 20-40% ausgelastet sind. Deshalb auch das neue Design bei AMD. Aber wie steht es mit den Caches?

Hätte es bei BD nicht Sinn gemacht, den L1DCache für beide INT-Cores zusammen zu benutzen und die Pipelines frei nach Last auf beide Threads zu verteilen? Oder geht das nicht? Müssen die Scheduler an die DCaches fest gebunden sein?

 

[Schaffe89]

Interessante Überlegung, allerdings würde man dann kaum 80% der Performance eines "nativen" Bulldozer Dualcores erreichen und die Modulbauweise würde an Sinnverlieren.
Wenn man für beide Integer Cores den L1 gemeinsam nimmt, müsste man diesen dann wieder vergrößern und das kostet dann wohl auch nochmals Performance und macht das ganze langsamer.

 

[y33H@]

Die beiden INTs haben einen eigenen L1D von je 16 kB, teilen sich aber die 64 KB L1I pro Modul.

 

[mr.dude]

Das bleibe es auch mit der Doppel-Integer-Kern Lösung.

Wieso? Dafür sind ja mehr dedizierte Einheiten vorhanden und die Gewinne durch CMT im Endeffekt zu gross. Aber gut, wir werden es sehen. Es kann möglich sein, dass 2 Threads auf 2 Modulen schneller sind als 2 Threads auf einem Modul. Es ist aber wenig wahrscheinlich, dass 2 Threads auf einem Modul langsamer sind als ein Thread auf einem Modul.

 

[Opteron]

Eher weniger. Wenn man sich mal alle Kommentare durchliest, ist der Tenor ziemlich eindeutig. Du hättest mal den Text davor und danach noch zitieren sollen:

at best the recommendation is "try HyperThreading on your workload and see what happens". ...
you should probably always start with HyperThreading disabled, as that is safest
...
But honestly these feel like workarounds; I think the true solution for our workload (full-text index heavy) is to disable HT.

Und genau solche Sachen liest man leider häufiger. Das ist ja genau das, weshalb AMD nichts von SMT hält. Es kann je nach Workload einfach völlig unterschiedlich reagieren und ist damit unberechenbar. Stell dir einen Server vor, auf dem mehrere Anwendungen laufen. Ein Teil davon profitiert von SMT, ein anderer Teil wiederum nicht bzw verliert sogar an Performance. Was machst du nun? Schaltest du SMT ab oder nicht? Was du auch immer machst, es bleibt ein fauler Kompromiss.

Ja, SMT Abschalten behebt es, aber das bedeutet nicht, dass SMT daran schuld wäre.
Ich hab das so verstanden, dass die Software die Arbeit bei mehr als X Threads sch..lecht aufteilt, und die CPUs deswegen abschmieren.
Ähnlich wie beim Windows Scheduler, Abschlaten von SMT hat geholfen, aber Schuld war der Scheduler, nicht SMT.

Aber gut, solange man keinen Gegentest auf nem Nehalem Server mit gleicher Threadanzahl *ohne* SMT hat (da braucht man ne dicke Kiste ^^) weiss mans nicht.

Kann sein. Er schreibt aber auch nicht, dass es mittlerweile anders wäre.[/QUOTE]Der Haupt(einzig?)grund wurde schon beim Prescott gefixt:
Replay: Unknown Features of the NetBurst Core. Page 15 - X-bit labs
Nehalem/Sandy hat eh kein replay, also Wayne ^^
Bulldozer hat vielleicht Replay, aber mit Patent und eigenem L1 sollte da nichts anbrennen ^^
Edit:
Hatte den Link übersehen, Microsoft hat getestet und gemeint, dass es ein BIOS oder Hardwareproblem ist:

After Microsoft support went through all the pssdiag logs, they were not able to find out what was the database waiting for. When looking at the performance counters I/O numbers were dismal; 2 MB/s when writing, 10 MB/s when reading when HT was ON.
Changing the CPU and I/O affinity made no changes to the performance.
Once HT was turned OFF, we had peaks of 240 MB/s reading and writing.
Microsoft is stating that we might have a BIOS or Hardware problem.

Read more: http://ozamora.com/2010/09/microsof...-wrong-with-sql-server-2008-r2/#ixzz1MDift3tO
Copyright 2010 Oscar Zamora. All Rights Reserved. ​

Man könnte jetzt höchstens noch vermuten, dass MS seine Fehler unter den Teppich kehren, und den schwarzen Peter weitergeben will, aber glauben wir MS mal, dann haben wir nen starken Beweis für Hardwareprobleme, aufgrund SMT.

@giga lightstorm:
Na ne, ein Cache für 2 Cores gibt zuviel Behinderung. Vor allem L1 Caches müssen schnell sein, wenn Du da noch Read/Writeports für nen 2ten Thread hinbastels, wird die Latenz nicht kleiner. Oder man bastelt keine hin, und läßt die 2 Cluster abwechselnd zugreifen - hat aber dann gleichen Effekt ^^

Das passt schon so, beim 22nm Shrink können sie sich hoffentlich ne Größenverdopplung auf 32kB erlauben, dann bin ich persönlich mit dem Cachedesign zufrieden, besser dürfte es kaum gehen, v.a. über die 2MB L2 freue ich mich wie ein Honigkuchenpferd, da man ja seit Intel Conroe weiß, dass Cache nicht verkehrt ist

Irgendwo gabs mal nen L2 Cachegrößenvergleich der Intel Dual Cores, da war der Optimalpunkt bei ~2MB, darunter gings relativ steil bergab, darüber flachte die Kurve ab. Das ganze war zwar noch von der sinkenden Cache Assoziativiät abhängig, aber so Pi*Daumen kommt das schon hin.
Intel hatte bei 2MB L2 8fach, AMD hat 16fach, sollte also schon gute Leistung bringen




ciao

Alex

 

[LookOut]

bisher gibts aber noch keine fetten Boards für AM3+ ...mhm...

 

[Duplex]

Das Crosshair-5 sollte bald kommen.

 

[Opteron]

bisher gibts aber noch keine fetten Boards für AM3+ ...mhm...

*Lach* es gibt bisher auch noch keine AM3+ CPUs
900er Chipsatzstart ist Anfang ist am Monatsende, dann gibts auch Bretter.
Geduld