Bulldozer - AMD Fam 15h - allgemeiner Infothread

Allerdings bleibt zu bedenken, dass dem Bulldozer i7 optimierter Code viel besser schmeckt als Code, welcher auf die eigene Vorgängergeneration K10 optimiert ist. Das liegt hauptsächlich am kleinen L1 Cache des BD, welcher bei Intel schon länger zu finden ist.
 
gruffi schrieb:
Interessant ist eigentlich, dass es mit K10 Optimierungen langsamer läuft als mit K8 Optimierungen. Das würde meinen Verdacht weiter erhärten, dass K10 Optimierungen dem Bulldozer nicht sonderlich schmecken. Was auch ein Grund sein könnte, warum sich Bulldozer in diversen Benchmarks, zB Cinebench 11.5, kaum vom K10 absetzen kann. Anhand der Werte von Nero liegen immerhin fast 18% zwischen K10 und Bdver1 Build. Nicht schlecht.
Zum Vergrößern anklicken....
Ja das CB11.5 nervt mich auch schon lange. Vor allem da CB10 ganz gut skaliert.

Bastle gerade an nem VM-Ware "Patch" für meinen Nehalem, aktuelles Resultat:
xeonbd_vmtddzv.png

(Besonders stolz bin ich aufs 3DNow! ;D )
Aber Spass beiseite: Wollen wir das mal mit nem Bulldozer machen? Ich würde mal vorschlagen ihn als P4 Modell Prescott zu "tarnen". Schätze, dass das am Besten laufen sollte und max. SSE3 sollte genügen. K8 könnten man natürlich auch ausprobieren.
Edit: Wobei: Hatte der P4 schon 128bit SSE? Glaube nicht, aber ich erinnere mich dunkel, dass der ICC trotzdem schon 128b Code generierte. Naja, notfalls dann halt ne Conroe-Tarnung. Alles nur "Abschreibarbeit".
Wie wahrscheinlich sind SSE4.1 Befehle bei CB11? Vielleicht sollte man doch von Anfang an ne Conroe-Tarnkappe überziehen.

Cinebenchresultate-mäßig hab ich mit dem Nehalem@BD etwas geringere Werte im single-thread Bench (maximal -0,07), aber das kann auch einfach die Messungenauigkeit sein. Ist aber auch die Frage, ob es den Nehalem nennenswert jucken würde, wenn er anderen Code bekäme. Bulldozer ist da sicherlich zickiger.
 
Nero24 schrieb:
Normalerweise lösche ich nicht mehr benötigte WAV-Audiostreams gleich wieder. Sollten allerdings noch weitere Compilate folgen - gruffi :) - würde ich den Steam der Vergleichbarkeit halber behalten, um noch weitere Tests unter identischen Voraussetzungen durchführen zu können.
Zum Vergrößern anklicken....

Ich hatte vor einiger Zeit mal vorgeschlagen das fette Kaninchen als Source und das Testmaterial durch Angabe von Start- und Endzeit zu definieren. Damit könnten verschiedene Leute auf verschiedenen Plattformen unabhängig voneinander vergleichbare Testreihen fahren.
 
Nero24 schrieb:
Normalerweise lösche ich nicht mehr benötigte WAV-Audiostreams gleich wieder. Sollten allerdings noch weitere Compilate folgen - gruffi :) - würde ich den Steam der Vergleichbarkeit halber behalten, um noch weitere Tests unter identischen Voraussetzungen durchführen zu können.
Zum Vergrößern anklicken....
Habe noch ein bisschen mit den Einstellungen rumgespielt. Das soll aber vorerst reichen. Werde eventuell noch ein paar Tests machen, wenn mein Trinity System endlich steht.

Die Assemblerroutinen scheinen zumindest beim K10 noch ein paar Prozent zu bringen. Auch das -ffast-math Flag bringt nochmal einen Schub. Allerdings kann es sein, dass mit diesem Flag IEEE konforme Ergebnisse nicht mehr garantiert sind. Ist also mit Vorsicht zu geniessen.

play/CPU

K10 (asm): ~36,62
K10 (asm, fast-math): ~39,68


Ach menno, jetzt spackt auch der MySQL Server von file-upload rum. Dann halt der nächste Hoster.

http://www.uploadstube.de/download.php?file=315322

lame_x64_amdfam10_asm.exe
lame_x64_amdfam10_asm_fastmath.exe
lame_x64_bdver1_asm.exe
lame_x64_bdver1_asm_fastmath.exe
 
Hier nochmal alles auf einen Blick (Testsystem AMD FX-6100, Turbo und CnQ an + Win7 x64):

Encodierzeit meiner bisherigen Version auf Basis der 3.99.4
lame_x64_win64: 2:36 min

Und nun gruffis Versionen auf Basis der 3.99.5
lame_x64_k8: 2:52 min

lame_x64_amdfam10: 3:07 min
lame_x64_amdfam10_asm: 2:59 min
lame_x64_amdfam10_asm_fastmath: 2:53 min

lame_x64_bdver1: 2:39 min
lame_x64_bdver1_asm: 2:45 min
lame_x64_bdver1_asm_fastmath: 2:33 min

lame_x64_bdver2_fma: absturz
lame_x64_bdver2_fma4: absturz

asm scheint beim Bulldozer kontraproduktiv zu sein, erst durch asm mit fastmath gelingt es, "mein" Referenz-Compilat zu unterbieten. Bedingt der Parameter fastmath eigentlich asm? Falls nicht, könntest Du nochmal eine bdver1-Version nur mit fastmath ohne asm kompilieren? Das müsste dann das schnellste sein auf dem Zambezi. 8)

Allerdings hat gruffi ja bereits angedeutet, dass durch fastmath die Genauigkeit der Berechnungen leiden könnte. Zwar sind die Dateien, die bdver1 und bdver1_asm_fastmath erstellen, gleich groß, ein FC jedoch zeigt "unendlich" viele Unterschiede. Die Output-Datei ist also nicht identisch.
 
Wurde eigentlich nur mit -march oder auch mit -mtune kompiliert? Ersteres bezieht sich ja auf die Instruktionen und zweites auf Optimierungen für die Architektur.

Man könnte ja auch mal testen ob ein auf Nehalem oder Sandybridge optimierter Code auf dem Bulldozer besser läuft als ein auf K10 optimierter. Wie von Lynxeye erwähnt wäre ja eigentlich davon auszugehen.
Edit: Bei -mtune könnte man ebenfalls mal das bdver2 tag testen.
 
Zuletzt bearbeitet:
Nero24 schrieb:
Bedingt der Parameter fastmath eigentlich asm?
Zum Vergrößern anklicken....
Eigentlich nicht. Die Assembler Routinen werden mittels NASM übersetzt. Da spielt das Flag keine Rolle.

Nero24 schrieb:
Falls nicht, könntest Du nochmal eine bdver1-Version nur mit fastmath ohne asm kompilieren?
Zum Vergrößern anklicken....
Jup. Werde es noch nachliefern.


tex_ schrieb:
Wurde eigentlich nur mit -march oder auch mit -mtune kompiliert?
Zum Vergrößern anklicken....
Mit beidem.

tex_ schrieb:
Man könnte ja auch mal testen ob ein auf Nehalem oder Sandybridge optimierter Code auf dem Bulldozer besser läuft als ein auf K10 optimierter. Wie von Lynxeye erwähnt wäre ja eigentlich davon auszugehen.
Edit: Bei -mtune könnte man ebenfalls mal das bdver2 tag testen.
Zum Vergrößern anklicken....
Kann ich auch noch nachliefern. Letzteres wird aber vermutlich keine grossen Auswirkungen auf die bisherigen bdver1 Builds haben.
 
@Nero24: Die fma/fma4-exen krachen weg beim Bulldozer weil der Code 3DNow!-Befehle enthält. Ich fand z.B. Prefetch mit Opcode 0F 0D..., und der läuft nur auf AMD-CPUs mit 3DNow!-Unterstützung.
 
Die Prefetch-Befehle sind meines Wissens erhalten geblieben. Würde wohl auch kaum Sinn machen, FMA - was BD als neues Feature integriert bekommen hat - mit Befehlen fest zu kombinieren, die der BD nicht kennt.
 
Yep, Kommando zurück, sehe gerade, dafür gibt es inzwischen ein eigenes CPUID-Flag namens "3DNowPrefetch". Ist bei mir gesetzt (FX-8120). Andere (ursprüngliche) 3DNow!-Instruktionen habe ich nicht gefunden. Ich muss mal meine AMD-Dokumentation erneuern... Sorry!
 
Hätte mich auch stark gewundert, wenn GCC mit -march=bdver1 nicht mehr unterstützte 3DNow! Instruktionen erzeugt.


Ok, folgende Builds habe ich noch:

bdver1 mit -ffast-math Flag
-mtune=bdver2 + -march=bdver1 mit und ohne -ffast-math Flag
corei7-avx mit und ohne -ffast-math Flag

lame_x64_bdver1_fastmath.exe
lame_x64_bdver1+bdver2.exe
lame_x64_bdver1+bdver2_fastmath.exe
lame_x64_corei7-avx.exe
lame_x64_corei7-avx_fastmath.exe

http://www.uploadstube.de/download.php?file=63515


Ergebnisse kann ich leider keine liefern, da alle Builds auf meinem Regor nicht laufen.
 
Hier nochmal alles auf einen Blick (Testsystem AMD FX-6100, Turbo und CnQ an + Win7 x64):

Encodierzeit meiner bisherigen Version auf Basis der 3.99.4
lame_x64_win64: 2:36 min

Und nun gruffis Versionen auf Basis der 3.99.5
lame_x64_k8: 2:52 min

lame_x64_amdfam10: 3:07 min
lame_x64_amdfam10_asm: 2:59 min
lame_x64_amdfam10_asm_fastmath: 2:53 min

lame_x64_bdver1: 2:39 min
lame_x64_bdver1_asm: 2:45 min
lame_x64_bdver1_asm_fastmath: 2:33 min
lame_x64_bdver1_fastmath: 2:35 min

lame_x64_bdver1+bdver2: 2:45 min
lame_x64_bdver1+bdver2_fastmath: 2:35 min
lame_x64_bdver2_fma: absturz
lame_x64_bdver2_fma4: absturz

lame_x64_corei7-avx: 2:43 min
lame_x64_corei7-avx_fastmath: 2:37 min
 
Danke für deine Mühe. Scheint so, dass GCC schon einiges an Bulldozer Optimierungen mitbringt. Wollen wir hoffen, dass der Desktop Trintiy nicht mehr allzu lange auf sich warten lässt. Mal schauen, was sich da an der Architektur getan hat.
 
interessant dass der corei7-avx mit fastmath doch recht gut rennt. nur minimal langsamer auf BD wie die referenz.
Und während FMA nen abflug macht, scheint AVX zu laufen... und die corei7 builds schmecken dem BD wesentlich besser als amdfam10... könnte an der L1-Cachegröße liegen.
 
Ich habe es nicht überprüft, aber könnte es da nicht um diesen ach so geheimen Debug-Modus der AMD-Prozessoren gehen?
 
Im Grunde keine neue Erkenntnis. Ohne FMA läuft die FPU nur mit halber Kraft.

Mich würde viel eher interessieren, ob die Implementierung eines FMAC Rechenwerkes ohne Latenzverlust möglich ist, wo bei Bedarf trotzdem MUL und ADD parallel ausgeführt werden können. Bei Bulldozer kann ja nur eines von beiden ausgeführt werden.
 
gruffi schrieb:
Im Grunde keine neue Erkenntnis. Ohne FMA läuft die FPU nur mit halber Kraft.
Zum Vergrößern anklicken....
Jo, v.a. wird auch das Frontend um die Hälfte entlastet, da auch nur eine x86-Instruktion anfällt anstatt zwei, bestehend aus MUL+ADD.
Mich würde viel eher interessieren, ob die Implementierung eines FMAC Rechenwerkes ohne Latenzverlust möglich ist, wo bei Bedarf trotzdem MUL und ADD parallel ausgeführt werden können. Bei Bulldozer kann ja nur eines von beiden ausgeführt werden.
Zum Vergrößern anklicken....
Das hatten wir doch mal vor Jahr und Tag, such mal nach bridged FMA oder so, da hat Dresdenboy mal Patente gefunden.
Edit: Schnelle Google suche:
http://www.otc.utexas.edu/ATdisplay.jsp?id=337&m=Comp
http://www.powershow.com/view/10f52...h_Fused_MultiplyAdders_flash_ppt_presentation
 
gruffi schrieb:
Im Grunde keine neue Erkenntnis. Ohne FMA läuft die FPU nur mit halber Kraft.

Mich würde viel eher interessieren, ob die Implementierung eines FMAC Rechenwerkes ohne Latenzverlust möglich ist, wo bei Bedarf trotzdem MUL und ADD parallel ausgeführt werden können. Bei Bulldozer kann ja nur eines von beiden ausgeführt werden.
Zum Vergrößern anklicken....

Vielleicht hilft dir da auch Eric Quinnell's Meinung in einem RWT-Thread weiter:
http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=117803&threadid=117688&roomid=2

Er arbeitete im Wesentlichen an den BD FMAs mit u. hat auch die erwähnten Three-Path und Bridged-FMAs (mit-)entworfen/entwickelt.
 
Dann wirds zeit dass so ein Teil mal in realem Silizium ankommt.
Ob das für Steamroller langt?
Irgendwie scheint es AMD kaum zu stören dass BD derart "schwach" in FP-code abschneidet... Dass die FPU shared ist war ja eingeplant und dass sie bei nicht-FMA-Code auch nur den halben Durchsatz liefert dürfte ebenso bekannt gewesen sein. Also was ist los?
Ich meine, es war doch auch abzusehen dass Intel nicht grade die FPU kastrieren wird bei SB und IB... also frage ich mich ernsthaft warum man nicht gleich eine Bridged-FPU o.ä. eingebaut hat?
Läuft das nach dem Motto "das schafft der Decoder sowieso nicht, daher überflüssig" oder wie?
Ist eigetnlich schon irgnedwas durchgesickert über die DIE-Größe bei vishera? - Wir haben uns doch bei den bisherigen Orochis so darüber gewundert warum das Die vergleichsweise groß ist gegenüber einem Sandy Bridge, und auf mangelnde Flächenoptimierung geschoben. Da sie die selbige aber jetzt für Trinity durchziehen mussten, wäre es ja auch nicht ganz abwegig dass sie da für Rev C von Orochi auch ein bisschen Fläche gespart haben damit sich die Fertigung besser lohnt... *noahnung*
Ich bin ja eigentlich keiner der üblichen schwarzmaler, aber verglichen mit SB, braucht Zambezi mehr fläche, mehr strom und liefert nur in Ausnahmefällen direkt konkurrenzfähige Performance ab....
Wenn wir dann noch veranschlagen dass 1 BD-Modul trotz CMT-Konzept zur flächeneinsparung immernoch nicht wirklich kompakter ist als ein SB-Kern, der ebenfalls 2 Threads beherrscht und dabei aber deutlich mehr FP Ressourcen zur Verfügung zu haben scheint, frage ich mich ernsthaft was AMD mit der ganzen Fläche angefnagen hat. Wenn Piledriver kompakter ist ok, mangelnde Flächenoptimierung im ersten Wurf, akzeptiert. Aber wenn Vishera immernoch so "fett" ist... müssen die ganzen Transistoren wohl in nicht dokumentierte NSA-Super-Spionage-Schatkreise geflossen sein *lol*
 
Wo sieht man denn das Bulldozer in FP-Code besonders schlecht aussieht?
Sowohl beim Rendering (z.b. Cinebench) und theoretischen Tests (Sandra Benches) liegt der FX-8150 relativ knapp hinter dem i7-2600K. Ist ja nicht so als würde das in INT-Code besser aussehen.

Die Bridged FMA Unit, wurde ja nur dazu entworfen um möglichst wenig Overhead in der Schaltung zu erzeugen und so die Latenzen auch möglichst klein zu halten. Da die dazugehörige Studie von AMD schon etwas älter ist gehe ich mal davon aus die FMA Einheit in Bulldozer auch so implementiert wurde oder hat sich AMD anderweitig dazu geäußert?
Ebenfalls würde ich nicht unbedingt sagen, dass die aktuellen core-i Prozessoren mehr FP-Ressourchen haben. Diese liegen bei 1x256bit add und 1x256bit mul. Bei Bulldozer sind es prinzipiell 2x128bit add und 2x128bit mul mit Option auf FMA.
Wenn nur normaler SSE Code genutzt wird kann man bei beiden Architekturen auf 2 128bit Pipelines zurückgreifen, bei Bulldozer aber sogar mit mehr Freiheiten bezüglich add und mul Befehlen.

Das relativ gesehen schlechte abschneiden hat da durchaus andere Probleme und lässt sich nicht zwangsweise auf irgendwelche Ressourcen in der Architektur zurückführen.
Das dem Design die wahrscheinlich noch nicht sehr ausgeprägten Flächenoptimierungen dann noch zusätzlich zu schaffen machen ist natürlich ein weiteres Problem. Aber das wird wohl auch ein eher kontinuierlicher Fortschritt mit der Zeit werden und nicht von heute auf morgen mit dem nächsten Design plötzliche perfektioniert.
 
Ge0rgy schrieb:
Irgendwie scheint es AMD kaum zu stören dass BD derart "schwach" in FP-code abschneidet... Dass die FPU shared ist war ja eingeplant und dass sie bei nicht-FMA-Code auch nur den halben Durchsatz liefert dürfte ebenso bekannt gewesen sein. Also was ist los?
Ich meine, es war doch auch abzusehen dass Intel nicht grade die FPU kastrieren wird bei SB und IB... also frage ich mich ernsthaft warum man nicht gleich eine Bridged-FPU o.ä. eingebaut hat?
Läuft das nach dem Motto "das schafft der Decoder sowieso nicht, daher überflüssig" oder wie?
Zum Vergrößern anklicken....
Nicht nur die FPU Leistung ist schwach, sondern auch die Integer Leistung!
Interlagos hat 33% mehr Threads als Magny Cours ist aber kaum schneller, das gleiche gilt auch für den FX vs. Thuban (Bezogen ohne die neuen SSE/AVX/FMA Befehle.)
Ge0rgy schrieb:
Ist eigetnlich schon irgnedwas durchgesickert über die DIE-Größe bei vishera?
Zum Vergrößern anklicken....
Würde mich nicht wundern wenn Piledriver wieder in richtung Thuban DIE Space geht.

Ge0rgy schrieb:
Ich bin ja eigentlich keiner der üblichen schwarzmaler, aber verglichen mit SB, braucht Zambezi mehr fläche, mehr strom und liefert nur in Ausnahmefällen direkt konkurrenzfähige Performance ab....
Zum Vergrößern anklicken....
Exakt! http://www.ww.anandtech.com/show/5057/the-bulldozer-aftermath-delving-even-deeper/6



Und sobald AMD dann genügend Piledriver DIEs ausliefern kann gibt es bereits den Xeon E5 Nachfolger auf 22nm IB Basis, dann wirds bzgl. Leistungsaufnahme noch düster für AMD!
Ge0rgy schrieb:
Wenn wir dann noch veranschlagen dass 1 BD-Modul trotz CMT-Konzept zur flächeneinsparung immernoch nicht wirklich kompakter ist als ein SB-Kern, der ebenfalls 2 Threads beherrscht und dabei aber deutlich mehr FP Ressourcen zur Verfügung zu haben scheint, frage ich mich ernsthaft was AMD mit der ganzen Fläche angefnagen hat. Wenn Piledriver kompakter ist ok, mangelnde Flächenoptimierung im ersten Wurf, akzeptiert. Aber wenn Vishera immernoch so "fett" ist... müssen die ganzen Transistoren wohl in nicht dokumentierte NSA-Super-Spionage-Schatkreise geflossen sein *lol*
Zum Vergrößern anklicken....
Ich frage mich auch schon die ganze Zeit warum das DIE so groß geworden ist, man bedenke das Bulldozer im vergleich zum K10 (Deneb/Shanghai) doch nur noch halb soviele FPU & Decoder Einheiten hat...

Shanghai
64KB L1D
3 ALU / 3 AGU
2 Kerne = 2 Decoder
2 Kerne = 2 FPUs

Bulldozer
16KB L1D
2 ALU + 2 AGU
2 Kerne = 1 Decoder
2 Kerne = 1 FPU
 
Duplex schrieb:
Würde mich nicht wundern wenn Piledriver wieder in richtung Thuban DIE Space geht.
Zum Vergrößern anklicken....
  • Llano 5,17 Mio/mm²
  • Trinity 5,30 Mio/mm²
  • Orochi 3,81 Mio/mm²
Quelle

Da Trinity eine höhere Packdichte als Llano schafft (und das obwohl das 4D-VLIW eine niedrigere Packdichte hat als 5D-VLIW) sollte Vishera diese auch steigern können.


Duplex schrieb:
Shanghai
64KB L1D
3 ALU / 3 AGU
2 Kerne = 2 Decoder
2 Kerne = 2 FPUs

Bulldozer
16KB L1D
2 ALU + 2 AGU
2 Kerne = 1 Decoder
2 Kerne = 1 FPU
Zum Vergrößern anklicken....

Was ist mit:
  • 8MB (4x2MB) L2 statt 3MB (6x512KB)
  • AVX, XOP, FMA4, SSE4.x, AES usw.
  • L3 hat 8MB statt 6MB
?
 

Ähnliche Themen

P3D-Bot
Projektnews Asteroids@home : New AVX512 application released
Antworten
1
Aufrufe
290
Sabroe SMC
Sabroe SMC
P3D-Bot
Projektnews SiDock@Home: Vote for the next target!
Antworten
1
Aufrufe
219
Sabroe SMC
Sabroe SMC
pipin
PR AMD Reports Third Quarter 2023 Financial Results
Antworten
1
Aufrufe
478
Sabroe SMC
Sabroe SMC
pipin
PR AMD Introduces New AMD Ryzen Threadripper 7000 Series Processors and Ryzen Threadripper PRO 7000 WX-Series Processors for the Ultimate Workstation
Antworten
0
Aufrufe
849
pipin
pipin
P3D-Bot
News SETI.Germany : Einstein@Home: verbesserte GPU-Anwendung zur Gravitationswellensuche benötigt weniger VRAM
Antworten
0
Aufrufe
335
P3D-Bot
P3D-Bot
Zurück
Oben Unten