[Sammelthread] AMD Bulldozer - Next Generation new CPU Architecture - Sammelthread

Status
Für weitere Antworten geschlossen.
Also entweder bin ich blind oder ich sehe einfach keinen Wert für Turbo aus SMT ein.

Turbo ein natürlich, sry. :) Damit wäre belegt, dass SMT auch hier keine Leistung kostet, sondern sogar erheblich (>30% siehe Clarkdale) Leistung bringt. Wie generell unter Windows 7 eben, außer in den Fällen, wo schlicht die Threadzahl das Problem ist - und auch Bulldozer in einer 8-Thread-Version genauso betroffen sein wird. Damit ist das Thema eigentlich durch. Du kannst natürlich gerne noch ein Gegenbeispiel posten, gerne auch per PN das wir hier nicht weiter OT kommen.

Btw: Da CB auch in 800x600 mit hohen Details bencht, ist dein "I/O" Argument sinnlos. Die Auflösung beeinflusst einzig und allein das Rendertarget der GPU, auf die Belastung der CPU hat sie keinen Einfluss. Erkennst du z.B. in Anno, recht durchgängig CPU-limitiert, läuft auf dem i7 975 in 1680x1050 sogar 0,25fps schneller als in 800x600 (was natürlich eine Messtoleranz ist) und generell auf fast allen CPUs im Test auflösungsunabhängig gleich schnell. Nur das dieses Thema mal geklärt wäre. :wink:
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wenn die Westmere 6-Kerner Performanceprobleme bekommt, dann eher weniger durch SMT, zumindest nicht unter 7, denn da sollte SMT so gut wie nie genutzt werden - Win7 priorisiert jeden 2. Kern, also erst alle ohne SMT, danach alle SMT. Sollte es dennoch Probleme geben, dann nutzt das Programm mehr als 6 Threads. Beim Clarkdale stellt sich der Fall völlig anders da. Es gibt mittlerweile ne Menge Spiele, die 4 Threads nutzen. Hier kommt es aber darauf an, ob die von 4 Threads mehr Vorteil ziehen, als Clarkdales SMT Threadsynchonisationen verzögert. Bei DIRT2 fällt es offensichtlich auf, dass die Verzögerungen den Vorteilen überwiegen wohingegen sich Anno mehr über die freien Threads freut - Anno ist allerdings generell leichter parallelisierbar, weil es ein Strategiespiel ist, bei dem sowieso mehr parallel läuft, was nicht unbedingt dauernd Synchonisationen erfordert. Alles in Allem profitiert Clarkdale zwar vom SMT meist, jedoch lange nicht so, wie es theoretisch möglich wäre, vor allem, wenn man bedenkt, dass Spiele die Recheneinheiten eigentlich kaum auslasten und eine Technik wie SMT da besonders viel bringen sollte. Die Praxis zeigt, dass SMT eben nicht so unproblematisch ist, wie Intel das gerne darstellt. Beim BD ist das ganz anders. Er hat den Nachteil nicht, dass Threadsychronisationen zu Verzögerungen führen können, weil er alle Threads auch verzögerungsfrei rechnen kann und deshalb weniger warten muss bei Spielen. Deshalb redet AMD auch von "Kernen", denn das sind echte Kerne, egal ob jetzt breiter (Modul) oder schlanker (Kern) ausgelegt.
 
Zuletzt bearbeitet:
Mit Turbo ein zu vergleichen, ist natürlich Käse. Dass das die Ergebnisse verzerren kann, da Turbo keine Konstante ist, wissen wir ja nun. Sieht man zB schön bei AA2:

i5-661 Turbo aus SMT aus - 21,74
i5-661 Turbo aus SMT ein - 21,75
i5-661 Turbo ein SMT aus - 22,05
i5-661 Turbo ein SMT ein - 22,67

Die SMT Vergleiche vom verlinkten 980X sagen uns also erstmal überhaupt nichts. Es ändert sich also nichts an dem Fakt, dass SMT in bestimmten Szenarien Performance kosten kann, unabhängig von der Anzahl der Threads. Die technischen Gründe dafür wurden hier ja schon oft genannt.

Btw, kleine Auflösungen sind immer noch für I/O weltfremd. Das erkennt man daran, dass CPUs in höheren Auflösungen anders skalieren können, unabhängig von einer möglichen Limitierung der GPU. Nur dass dieses Thema mal geklärt wäre. ;)
 
Aus fps-Schwankungen von 21,74-22,67 kannst du gar nichts ablesen, da dies unter jeglicher Messtoleranz liegt - nur damit das ein- für allemal geklärt ist. Und nocheinmal, die Auflösung ist für die CPU vollkommen intransparent - sie beeinflusst die Rechenlast nicht, wie du in stark CPU-limitierten Szenarien wie Anno siehst. Hier sind in beiden Auflösungen alle CPUs praktisch gleich schnell, einige durch Messschwankungen in höheren Settings sogar schneller. Wenn du also weiterhin behaupten möchtest, dass es unter Win7 SMT-Einbrüche gäbe, brauchen wir Beispiele, wo

a) klare Differenzen außerhalb der Messtoleranz zu finden sind
b) auch eine klare CPU-Limitierung herrscht - das resultiert letztlich bereits aus a), denn ohne eine solche haben wir keine ausreichenden Leistungsunterschiede

Nochmal: Wenn du solche Fälle kennst, präsentiere sie mir. Über 58,66 vs 59,44fps (Turbo off, so wie du das wolltest) in deinem Dirt 2 Beispiel braucht man nicht weiter diskutieren, dass ist schlicht identisch.
 
Soweit ich weiss, testet CB sehr genau, über mehrere Durchläufe hinweg. Solche Abweichungen sind damit mit Messschwankungen nicht zu erklären. Auch die Tendenz ist ersichtlich. Solche Ausreden haben also schlichtweg keine Basis. Nur dass das ein für alle Mal geklärt ist.
Und noch einmal, niedrige Auflösungen sind völlig weltfremd, weil sie nicht zeigen, was I/O hergibt. Sie sind damit nicht "intransparent" und beeinflussen die Skalierung. Es hat übrigens niemand explizit von Windows 7 gesprochen. Beispiele für Performancenachteile von SMT wurden schon oft genannt. Mittlerweile sollte man sich diese mal notieren, wenn einem diese ständig ins Gedächtnis gerufen werden müssen. Wer das nicht kann, noch ein weiterer Tipp, GIDF. Auch dort findet man jede Menge Material zum Thema.

SMT hat definitiv Performancenachteile. Das ist ein Fakt und wurde hinlänglich nachgewiesen. Auch wenn das deine perfekte Intel Welt zerstören mag. Dieser Fakt ändert sich nicht. Welches Spiel jetzt um wie viel Prozent in welche Richtung schwankt, ist dabei unerheblich. Die Beispiele belegen aber das Grundproblem. Und jetzt zurück zum Thema. Und das heisst Bulldozer und ist wesentlich interessanter als SMT.
 
Zuletzt bearbeitet:
Ersteinmal ein grundsätzlicher Irrtum deinerseits: Mehrfache Durchläufe haben keinerlei Einfluss auf den maximalen Messfehler. Du kannst eine Münze 10x werfen und immer Zahl bekommen - nur die Wahrscheinlichkeit sinkt mit weiteren Wiederholungen. Soviel dazu, widmen wir uns nun der konkreten Abschätzung am Beispiel Dirt 2, wie von dir erwähnt:

Du erwähntest den i5 661 und pochst auf Werte ohne Turbo - von mir aus. Wir haben 58,66 zu 59,44fps, also eine Differenz von ~1,3% - wie hoch sind jetzt die größten Messfehler, die im Test bei CB auftraten?

Beispiel 1:
In 800x600 liegt der Q8200 noch >20% vor dem E8400. Selbst bei völliger CPU-Limitierung würde in 1680x1050 maximal Gleichstand herrschen, was passiert aber? Der E8400 führt auf einmal

-> folglicher Messfehler: Mindestens ~1,1%.

Beispiel 2:
Im Test zum X5 erreicht der 1090T ohne Turbo in 800x600 52,43fps. Selbst bei völliger CPU-Limitierung könnte er in 1680x1050 maximal identisch schnell sein, die Last wird schließlich nicht geringer. Die fps steigen allerdings auf 55,03fps an!

-> folglicher Messfehler: Mindestens ~5%.

Beispiel 3:

Im Test zum i3 530 wird ein i5 ohne Turbo auf Multi 22 gegen einen "echten" i3 530 getestet. Beide CPUs sind performancetechnisch absolut identisch (das deaktivierte AES des i3 ist hier irrelevant) und sollten auch absolut identisch performen. Stattdessen ist der simulierte i3 aber geringfügig langsamer (in 800x600 übrigens noch leicht schneller, macht die Messschwankungen noch deutlicher), selbst bei 133MHz Mehrtakt als simulierter i3 540.

-> folglicher Messfehler: Mindestens ~2,2%.

Beispiel 4:

In 800x600 liegt ein i7 870 noch >50% vor einem i3 530. In 1680x1050 führt der i3 gegen den i7 870, mit mehreren fps. Dabei hat der i7 870 mehr Takt, eine schnellere Speicheranbindung, mehr Cache und ist dem i3 in keinem einzigen Punkt unterlegen. Er liegt sogar leicht hinter dem identischen, aber niedriger taktenden i7 860! Das ist schlicht vollkommen unmöglich, außer durch Messfehler.

-> folglicher Messfehler: Mindestens ~5,6%

Das sollte an Beispielen vorerst genügen, es gibt unzählige weitere. Klar ist: Eine Differenz von 1,3% liegt ganz erheblich unter der Messfehlergrenze.
Ich warte übrigens weiter auf deine Erklärung, in wie weit das Rendertarget der GPU einen Einfluss haben soll. Notwendig wäre eine Erläuterung, wie in diese Vorstellung das Bild von Anno passt, wo mehrere CPUs - ich erwähnte den i7 975, ein weiteres Beispiel wäre der X4 925 oder auch der i3 530 mit SMT(!) - mit der höheren Auflösung sogar schneller werden. Das ist schlicht durch Messfehler zu erklären, es wird aber deutlich: Die Auflösung ist für die Framerate, die eine bestimmte CPU ohne Limitierungen durch die Grafikkarte liefern kann, vollkommen irrelevant. Begrabe deine I/O Theorien bzw. wende sie dort an, wo sie Sinn machen: Z.B. auf den VRAM der Grafikkarte. Das hat mit dem Einfluss von SMT aber auch wirklich rein gar nichts mehr zu tun.

Also, auch wenn es deine perfekte AMD-Welt zusammenbrechen lässt: SMT kostet als Feature heutzutage keine Leistung mehr. Solange du auch immer wieder nur ohne Quelle und mit "Fakt" um dich wirfst macht das nur noch deutlicher, dass dir einfach jeglicher Beleg zu fehlen scheint. Ich wette bereits jetzt darauf, dass auch dein nächstes Posting einen solchen nicht enthalten wird - woher soll er auch kommen. Über Windows XP/Vista oder Probleme verschiedener Software mit zu hohen Threadzahlen brauchen wir dabei nicht reden, dass hat mit der SMT-Problematik nichts zu tun.

Es wäre schön, wenn wir damit zum Thema zurückkehren könnten. Wenn du allerdings weiterhin falsche und schlicht provokativ intensionierte Behauptungen wie diese Diskussion mit ihrem Ausgang in #251 postest, wird es auch weiterhin entsprechende Korrekturen geben. Es liegt ganz an dir.

Over and out.
 
Ersteinmal ein grundsätzlicher Irrtum deinerseits: Mehrfache Durchläufe haben keinerlei Einfluss auf den maximalen Messfehler. Du kannst eine Münze 10x werfen und immer Zahl bekommen - nur die Wahrscheinlichkeit sinkt mit weiteren Wiederholungen

das stimmt nicht ganz. dass die wahrscheinlichkeit zahl zu würfeln nach dem ein mal zahl gefallen ist, sink stimmt.
die tatsache, dass mehrfache durchläufe nicht den maximalen fehler beeinflussen auch.

nur haben die beiden sachen nichts mitinander zutun :). Messungenauigkeiten haben nichts mit wahrscheinlichkeiten zutun. du kannst allerdings ausrechnen wie wahrscheinlich es ist, dass der maximale fehler bei den 3-5 versuchen auftritt die du gemachst hast.

insofern haben merhfache durchläufe sehr wohl etwas mit dem maximalen fehler zutun, solange man nicht den schnitt aller versuche nimmt, sondern nur die maximale abweichung davon! den je öffter du einen versuch machst, desto genauer kannst du die maximale abweichung bestimmen.
 
Zuletzt bearbeitet:
insofern haben merhfache durchläufe sehr wohl etwas mit dem maximalen fehler zutun, solange man nicht den schnitt aller versuche nimmt, sondern nur die maximale abweichung davon!

Absolut korrekt! :) Nur CB macht ja wie auch jede andere Seite genau das, was du geschrieben hast: Man nimmt den Schnitt aller Versuche, die Spitzenwerte sind uns unbekannt. Praktisch bin ich allerdings dennoch maximal defensiv vorgegangen und habe angenommen, die zwingenden Messfehler (z.B. die fps-Steigerung bei Auflösungserhöhung, Bsp. 2) meiner 4 Beispiele seien auch bereits die jeweils maximal möglichen - obwohl das völlig unbelegt ist bzw. vielmehr sogar extrem unwahrscheinlich.
 
Sry aber das stimmt auch nicht... Rein rechnerisch ist die Möglichkeit bzw. Wahrscheindlichkeit das Zahl kommt IMMER 50%. Glück oder Schicksal gibts nicht in der Technik.

Mal eine Frage die mich schon ein Weilchen beschäftigt: Macht euch das sauer oder so wenn ihr miteinander Schreibt oder ist das mehr unterhaltend?
 
Sry aber das stimmt auch nicht... Rein rechnerisch ist die Möglichkeit bzw. Wahrscheindlichkeit das Zahl kommt IMMER 50%. Glück oder Schicksal gibts nicht in der Technik.

Nur um das mal noch zu klären: Etwas gegenteiliges behauptet keiner. ;) Es geht um die Wahrscheinlichkeit, das z.B. 5x hintereinander Zahl kommt - die beträgt nur 0,5^5. Das Beispiel eines Benchmarks ist ähnlich, nur das wir dort kontinuierliche und keine diskrete Zufallsvariablen besitzen. Heraus kommt dann eine Verteilungsfunktion, z.B. eine Binomialverteilung - zu xx% weicht der Wert um maximal yy% ab wäre damit eine mögliche Aussage. Das sollte den Exkurs dann aber auch so langsam schließen. ;)
 
Zuletzt bearbeitet:
Ok stimmt... wenn man mehrere als ganzes betrachtet simmts natürlich wieder ;-)
Weiter machen! XD
 
Mal eine Frage die mich schon ein Weilchen beschäftigt: Macht euch das sauer oder so wenn ihr miteinander Schreibt oder ist das mehr unterhaltend?
Ich empfehle für sowas immer diesen Kurzcomic:
Jamiri: Nennt mich T(r)oll ! - SPIEGEL ONLINE - Nachrichten - Netzwelt
:asthanos:

Damits nit OT wird, gibt wieder neue Spekualtionen, dass die 2 BD CLuster vielleicht doch an einem Thread arbeiten können. Das ganze basiert aber arg wacklig auf der Verwendung des wörtchen "accelarated" ... also das ist max. ne 10%ige Chance - aber nichtsdestoweniger eine gültige Spekulation :)
More signs of Bulldozer - Patent based research regarding AMD's future MPUs
 
hab ich ja auch schon gesagt http://www.hardwareluxx.de/community/14778263-post268.html

ein Modul mit 2 Cores oder 1 Modul & 1 Monster Core
Ja, aber das ist halt noch nicht sicher.
Im Moment ist das "Monster" Core nur ein INT Cluster, der den kompletten L2 zur Verfügung hat, und höchstwahrscheinlich mit Turbomode hochtaktet (Wenn der 2te INT Cluster schläft und keinen Strom braucht).

Ob die 2 Cluster wirklich an 1 Thread arbeiten können werden, ist nicht sicher. Patente gibts - aber wer weiss, vielleicht sind die schon für BD 2.0.

ciao

Alex
 
sicher wird AMD für die 2. BD Generation schon einiges vorbereitet haben ;)
 
Was sein kann, wenn nur ein Thread pro Modul abgearbeitet wird, dass für diesen Thread mehr Instruktionen pro Takt durchs Frontend geschleust werden und das Backend in irgendeinen "accelerate mode" geht, um nicht zu viele Stalls zu verursachen.

...und/oder der eine INT-Core wird massiv höher getaktet. So à la Turbo-Mode.
 
Das wäre eine Option für einen solchen "accelerate mode". Ich habe allerdings mehr den Eindruck, dass es irgendwas auf Logikebene ist.
 
...aufgeräumt...
 
Wie ComputerBase meldet, soll es auf dem Hot Chips Symposium im August neue Details zu Bulldozer geben.
 
JF hat auch noch einige Informationen dazu.
There will be a new blog (the bulldozer blog) that will be starting up in a few weeks. That will give you a weekly, or so, update on the product, with more depth on the features (but not the stuff I don't talk about - schedules, launch date, frequencies and pricing.)

Hot chips will have some product disclosures happening and once that event is over I will need to go more in depth on a lot of the features that get disclosed there through my blog.

I am planning to do another "20 questions" blog on bulldozer like we did on Magny Cours, look for a blog post announcing that.

Stuff should start to heat up in the near future.
 
@mr.dude
wie würdest du aus deiner Seite den 4 Modul BD im vergleich zum Thuban einschätzen? 50% mehr Leistung sollte das minimum sein denke ich mal, mehr IPC als K10, höhere Taktraten durch HighK, weniger Stromverbrauch bei gleicher Leistung durch den 32nm HP Prozess, AVX Boost in bestimmten anwendungen usw.
 
Zuletzt bearbeitet:
Hängt natürlich auch von der Anwendung ab. Wenn ich einfach mal fröhlich drauf los spekulieren soll, könnte ich mir folgendes vorstellen:

Thuban -> Valencia

+20% IPC
+12,5+% Takt (3,2 -> 3,6+ GHz + Turbo)
+33% Kerne (6 -> 8)
ähnliche Skalierung der Kerne
gleiche TDP (125 W)

Das könnte in entsprechend hoch parallelisierten Anwendungen also auf 80+% mehr Performance hinauslaufen. Mit AVX wäre dann sicherlich noch mehr drin.
 
Hängt natürlich auch von der Anwendung ab. Wenn ich einfach mal fröhlich drauf los spekulieren soll, könnte ich mir folgendes vorstellen:

Thuban -> Valencia

+20% IPC
+12,5+% Takt (3,2 -> 3,6+ GHz + Turbo)
+33% Kerne (6 -> 8)
ähnliche Skalierung der Kerne
gleiche TDP (125 W)

Das könnte in entsprechend hoch parallelisierten Anwendungen also auf 80+% mehr Performance hinauslaufen. Mit AVX wäre dann sicherlich noch mehr drin.


Aber entsprechen jeweils 2 BD "Kerne" nicht nur 1,8 Thuban Kernen?

Dann käme bei der Rechnung ja folgendes bei raus:

+20% IPC
+12,5+% Takt (3,2 -> 3,6+ GHz + Turbo)
+20% Kerne (6 Kerne -> 4 Module)

= 62%
 
nein, ein BD Kern ist ein K10 Kern überlegen!
 
Da bin ich ja mal gespannt, was der dann in der Realität für Wert erreicht.
 
nein, ein BD Kern ist ein K10 Kern überlegen!

Die überlegene IPC steckt doch schon drin. 1,8 ist imo also korrekt. Davon abgesehen sinds halt eh nur grobe Schätz- und Spekulationswerte, denn wie viel besser die IPC ist weiß außer den AMD Ingenieren wohl keiner so genau. Genauso kennt man den Durchschnittsperformancegewinn durch CMT nicht, auch wenn die 80%+ halbwegs bestätigt scheinen. Genauso wie niemand die Taktraten kennt.
 
nein, ein BD Kern ist ein K10 Kern überlegen!
Davon geht man momentan aus. Nichts genaues weiss man noch nicht. Ist bisher alles mehr oder weniger Spekulatius.

Fakt ist, ein K10 Kern besitzt eine 3-fach OoO Execution Engine. Ein Bulldozer Kern besitzt eine 4-fach OoO Execution Engine. Zusätzlich geht man von vielen Verbesserungen bei Bulldozer aus, Trace Cache/RRC, MakroOp-Fusion, schnellerer Cache, etc.pp. Daher spekuliere ich mal auf ~20% mehr IPC gegenüber K10 pro Kern.
AMD gibt als Skalierung pro Modul zwar 80% an. Hat in dem Zusammenhang aber wenig zu bedeuten. Das heisst im Endeffekt nur, dass zwei Kerne eines Moduls nicht schlechter skalieren als zwei aktuelle Kerne. Beispiel Cinebench R10 auf einem X6, 6 Kerne, Speedup ~5, Skalierung ~83%.
 
Zuletzt bearbeitet:
Fakt ist, ein K10 Kern besitzt eine 3-fach OoO Execution Engine. Ein Bulldozer Kern besitzt eine 4-fach OoO Execution Engine. Zusätzlich geht man von vielen Verbesserungen bei Bulldozer aus, Trace Cache/RRC, MakroOp-Fusion, schnellerer Cache, etc.pp. Daher spekuliere ich mal auf ~20% mehr IPC gegenüber K10 pro Kern.

Bei 33% mehr Ausführungseinheiten (3 zu 4-fach Pipeline) sollten aber mehr als 20% IPC drin liegen, auch wenn man die schwerere Auslastbarkeit einbezieht.

Oder bezieht sich die höhere IPC auf eine einzelne Pipeline?
 
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh