Zambezi - Fehler, Bugs, mangelnde Performance - Woran liegt es?

N1truX schrieb:

Falls noch nicht gepostet, hier mal ein paar Neuigkeiten aus dem Hause x264. Erste BD-Optimierungen (FMA4/XOP) sollen ~10% bringen:
Initial XOP and FMA4 support on AMD Bulldozer
Wenn man sich mal ansieht wie tiefgreifend und Zahlreich die Integration ist, ist davon auszugehen, dass er von AMD schon recht frühzeitig Samples bekommen hat.

Zum Vergrößern anklicken....

Schau mal aufs Datum, das hatten wir schon letzten Monat:
http://www.planet3dnow.de/vbulletin/showthread.php?p=4501020#post4501020

Und ja, der Kollege bekam schon frühzeitig SSH Zugang auf nen dual Interlagos und hat jetzt nen 8120 daheim stehen.

deadohiosky schrieb:

Ähm, ja ok.... Die Website "Benchmarkreviews" hat das MSI 99FX-GD80 getestet und mit dem ASUS Crosshair V Pressesample verglichen:

http://benchmarkreviews.com/index.php?option=com_content&task=view&id=871&Itemid=69

Alles ok soweit unter Stock, eine paar marginale Punktegewinne ein paar Verluste ... bis der FX-8150 übertaktet wird. Beim MSI klappts nur bis 4,6 GHz stabil... bei ASUS sinds 4,8 GHz.

http://benchmarkreviews.com/index.p...k=view&id=871&Itemid=69&limit=1&limitstart=15

Das MSI mit 200 MHz weniger Takt gewinnt, außer bei synthetischen AIDA Tests, (fast) durchgängig die Benchmarks mit zum Teil großen Vorsprung.


Da muss ja was im Argen liegen... könnte natürlich vor Allem am BIOS liegen, hier wurde die PresseReview-Version benutzt... es gibt ja noch ein Overclocking BIOS.

Zum Vergrößern anklicken....

Naja, Mainboardbiosfeintuning. Müßte man jetzt wissen, was die da veranstalten. Die +0,6 Punkte bei 200 Mhz weniger sind schon komisch, das sind fast 10%. Blöderweise haben die keinen vollen AIDA lauf gebencht, ich vermute da mal wieder die L2 Write Schwäche. Aber sie haben nur den Speicherdurchsatz gemessen, und bei Asus auf der Benchseite 18GB/s angegeben, in der Vergleichstabelle aber dann nur ~11, strange und macht nen schlechten Eindruck.

Fabian_HT4U schrieb:

Nein, ich beziehe mich nicht auf den Build von AMD. Die waren - zumindest in unserem Test mit unserem Video - richtig schlecht. Sogar schlechter als Builds aus dem letzten Jahr...

Bzgl des Compilers: Das war auch mein erster Gedanke (ich teste nur die Windows-Version).

Zum Vergrößern anklicken....

Naja, was soll der Compiler noch groß bei Assemblercode optimieren. Vielleicht ein bisschen umsortieren, aber tiefschürfend ist es nicht.


.
EDIT :
.

Nochmal dazu

deadohiosky schrieb:

Da muss ja was im Argen liegen... könnte natürlich vor Allem am BIOS liegen, hier wurde die PresseReview-Version benutzt... es gibt ja noch ein Overclocking BIOS.

Meines Erachtens trotzdem interessant, 200 MHz weniger... in Anwendungen u.U aber keinen Verlust bei MSI.

Zum Vergrößern anklicken....

Hier schreibt einer Folgendes:

Might be worth of mentioning that the bios used (0083) is a internal test version, which has a bug in L3 cache config...
With this bios the compute units get no L3 cache.

In AIDA64 cache benchmark the L3 score is half what it should be (0813 bios and newer).

Zum Vergrößern anklicken....

BIOS war in der Tat das 0083:

Motherboard: MSI 990FXA-GD80 with BIOS E7640AMS V11.5 and ASUS Crosshair V Formula with BIOS 0083

Zum Vergrößern anklicken....

http://benchmarkreviews.com/index.p...sk=view&id=871&Itemid=69&limit=1&limitstart=5

Damit wäre die halbe L3 Rate also kein Multiproblem, sondern einfach ein BIOS Bug.


ciao

Alex

Habe ich auch schon gelesen, und laut dem Typen von XS, wäre ja der L3-Cache "deaktiviert". Das erklärt aber nicht warum die Stock-Werte völlig in Ordnung sind und sobald übertaktet wurde, der fehlende L3-Cache "sichtbar" wird.

Ich kann nichts über die einzelnen Programme/Benches sagen, in wieweit der L3-Cache genutzt wird, aber ich schätze mal min. bei x264 und Cinebench müsste es deutlich zu sehen sein... also unter normalen Bedingunen.

Wie wärs mit der dunklen Seite,was funktioniert überhaubt bei Bulldozer.(mal L1 cache ,mal L2 Cache und die grosse Unbekannte Windows Scheduler.C6 oder Turbo meiner Meinung nach hätte man das bei Server belassen sollen.

Keine Ahnung was du uns damit sagen willst... ich schätze mal du möchtest ein wenig Dampf ablassen. Mach doch ein bisschen Sport oder geh Spazieren, das hilft, glaube mir.



@ Topic


Ist der Compiler Guide schon bekannt? Werden die ganzen flags aufgelistet:

http://wp.cscs.ch/wp-content/uploads/2011/10/CompilerOptQuickRef-Interlagos_Valencia-2.pdf

Kommt von diesem Eintrag beim CSCS/SNSC


http://user.cscs.ch/news/2011/10/17...w-interlagos-compiler-flags-for-xop-and-fma4/

Due to the new instructions such as AVX, XOP and FMA4 of the new AMD Opteron Interlagos processor, is it absolutely necessary to use the correct compiler flags. Currently only two compilers support the new instructions.

Open64 4.2.5.1 (May 2011)

gcc 4.6.0, (March 2011)

The important compiler option is

-march=bdver1

please also make sure, that you link to the correct ACML (libacml_fma4.a). ACML5.0 is the latest version.Without using this option or without the optimized ACML, we measured for synthetic benchmarks an performance degradation of 50% on Interlagos.

PGI 11.9 with full Interlagos support is available soon

Zum Vergrößern anklicken....

Hmm, müsste demzufolge mit -march=native automatisch gewählt werden. Gibt es ja schon seit GCC 4.3.0 und seitdem nutze ich das auch.

@deadohiosky : Ich möchte einfach nur wissen warum Bulldozer der reinste Kuhfladen ist.

Er mag ja für deine (und meine) Ansprüche nicht der beste/tollste/wasauchimmer Prozessor sein, aber ich wette mein ganzes Hab und Gut der Kuhfladen rechnet schneller als du.
ich fände es ganz schön wenn man so was unterlassen könnte allerdings auch so manche persönlichen Kommentare von anderen Usern.

hoschi_tux schrieb:

Hmm, müsste demzufolge mit -march=native automatisch gewählt werden. Gibt es ja schon seit GCC 4.3.0 und seitdem nutze ich das auch.

Zum Vergrößern anklicken....

Das schon nur gibt es bdver1 in der Version 4.3 noch nicht.
Selbst bis 4.5.3 ist die Option noch nicht vorhanden.

lg
__tom

Phoronix hat inzwischen auch einen 8150 Benchmark Parcours veröffentlicht.
Ich muss sagen, der steht da zu großen Teilen richtig gut da. Und in ffmpeg geht der ab wie Schmidt's Katze.

Edit:

tomturbo schrieb:

Das schon nur gibt es bdver1 in der Version 4.3 noch nicht.
Selbst bis 4.5.3 ist die Option noch nicht vorhanden.

Zum Vergrößern anklicken....

Ist mir bewusst. Für mich ist es aber bequemer native zu nutzen, da automatisch das meiste herausgeholt wird.
Wird 'bdver2' dann Piledriver sein?

FIFA 2012:

@ stock mit 6 Kernen zugeordnet
Frames, Time (ms), Min, Max, Avg
10110, 60000, 102, 314, 168.500

230 Ref.t. 2070 HTT/NB 3CU/3C Zuordnung
Frames, Time (ms), Min, Max, Avg
11922, 60000, 143, 348, 198.700

@stock mit 3CU/3C Zuordnung
Frames, Time (ms), Min, Max, Avg
10337, 60000, 109, 366, 172.283

30 % höhere Min. FPS, 15 % mehr average ggü. @stock mit 3CU/3C
40 % höhere Min. FPS, 18 % mehr average ggü. @stock mit 3CU/6C
15 % höhere Max.fps ggü. @stock mit 3CU/6C

ONE_FOR_ALL schrieb:

Wie wärs mit der dunklen Seite,was funktioniert überhaubt bei Bulldozer.(mal L1 cache ,mal L2 Cache und die grosse Unbekannte Windows Scheduler.C6 oder Turbo meiner Meinung nach hätte man das bei Server belassen sollen.

Zum Vergrößern anklicken....

Kleiner Realitycheck:
Aus welchem Grund macht es nochmal Sinn eine neue Architektur nur auf einen Markt zu beschränken und die teildefekten Dies wegzuschmeißen anstatt sie in einem anderen Marktsegment zu verkaufen?

Natürlich, klar, es hätte vielen ein langes Gesicht erstpart... aber der Schutz vor langen Nasen ist leider nicht wettbewerbswirksam.
Fakt ist, Orochis nur im Serversegment zu verkaufen wäre nichts anderes als freiwillige Selbstkasteiung.
1. Müsste man dann die 45nm Linie bis zum Sankt Nimmerleinstag weiterführen um den Enthusiast-Desktop abzudecken
2. Könnte man eine ganze Latte teildefekte oder nur mit höheren Spannungen betreibbare Orochis eiskalt in die Tonne entsorgen, die man so vielleicht wenigstens noch als FX-4000 oder FX-6000 verkaufen kann.
3. Wäre die ganze AM3+-Plattoform mit einem schlag sinnlos und obsolet.

Also was bitte wäre der Vorteil des Ganzen?

Zurück On Topic:
war marach = native nicht das flag das sowas sagt wie "optimier für die CPU die das Ganze grade kompiliert" ?
Wie ist denn das mit der ACML in den ganzen bisherigen Tests gewesen?

Die Phoronix-Benches zeigen ja eigentlich das übliche Bild... wenn multithreading zum Tragen kommt kann BD glänzen.
Besondere Stärken scheinen im Crypto-Bereich zu liegen und bei FFMPEG.
Also wer viel kodiert und/oder mit Kryptografie zu tun hat, kann bei BD wirklich Vorteile haben.
Was mich immer wieder erstaunt ist die Tatsache, dass der Turbo doch eigentlich genau dafür da ist, das freiwerdende "Headroom" der übrigen Kerne, im Singlethread-Betrieb auf den einen arbeitenden draufzuschlagen.
Bei perfekter skalierung würde das bedeuten, dass man bei 1 thread 8 mal höher takten kann wie bei 8 threads.
Dass das nicht der Praxis entspricht ist natürlich auch klar.
Ich schätze hier funken die Spannungen noch dazwischen was ggf. mit besserem Prozess dann auch besser wird.
Im Moment ist aber auch noch kein "single thread turbo" implementiert,sondern nur ein "nur max. die hälfte cores aktiv" Turbo.
da fehlt IMHO ne zweite Turbostufe die ne Schippe drauflegt wenn wirklich nur 1 Modul an ist.

hoschi_tux schrieb:

Wird 'bdver2' dann Piledriver sein?

Zum Vergrößern anklicken....

Jup.

Herr Melin schrieb:

Ich habe einige interessante Details meines FX-6100 entdeckt, die sich auf Crystalmark beziehen. Der Fibonacci Wert unter ALU ist @stock dramatisch ausgebremst und steigt um über 40 % per höherem Ref.tkt+NB/HTT synchron. Spiele profitieren ebenfalls von zweistelligen % höheren min frames und 5-15 % average.:

Zum Vergrößern anklicken....

Machen wirs mal in ne Tabelle, dann sieht mans besser:

Verständnisfrage noch:
HTr Takt@default sind 2,6, oder? Und der NB und HTr Takt mir 225MHz Reftakt war nicht 2200, sondern 2250 mit Multi 10, oder?

Abgesehen von Fib. finde ich auch noch den MikoFPU Bench interessant, +50% ist nicht übel ^^

Was ich nicht ganz kapiere sind die Werte bei 225Mhz. Der NB Takt stieg da ja nur marginal, der Speicher war durch schlechte Timings eher langsamer, aber trotzdem ein Plus. Ist der Bench dann RAM Bandbreitenabhängig, oder gibts da noch irgendeine Taktdomäne, die am HTr Takt hängt, wir aber nicht kennen ?? Oder hattest Du noch Multi 11 eingestellt? Dann wärens 2450MHz NB Takt gewesen, was es natürlich erklären würde
Bestätigung für die Taktdomäne incognita ist der eintige Wert mit 230 Reftakt, nur 2,1GHz NB Takt, niedrige RAM Bandbreite (nur DDR3-1200), und trotzdem wieder ein höheres Ergebnis. Wegen magerer +5MHz NB Takt. Irgendwas mysteriöses muss es da noch geben ^^
Interessant auch der MikoFPU Bench, der scheint ählich zu skalieren, legt als einziger bei den 225er Settings mit schlechten RAM Timings zu.

Edit:
Ist der mysteriöse Takt vielleicht der CPU Kerntakt *g* Wieviel Takt hattest Du da jeweils ? Eventull sind das so Mikrobenches, die im L1/L2 ablaufen.

Wie ist das zu verstehen bei erster und zweiter Spalte? Niedrigere Werte trotz höherem HT Takt?

hoschi_tux schrieb:

Wie ist das zu verstehen bei erster und zweiter Spalte? Niedrigere Werte trotz höherem HT Takt?

Zum Vergrößern anklicken....

Jupp - aber noch unter Vorbehalt, bin mir nicht sicher, was der Standardtakt des 6100er ist.
(hab außerdem noch ein paar Kommentare dazu editiert).
.
EDIT :
.
Default NB Takt des 6100 ist nur 2,0 GHz, nicht 2,2, wird editiert.

Heißt das, dass irgendwo ein Teiler anspringt der für die niedrigen Messwerte verantwortlich ist?

Ich habe mit immer mit 2 Kernen gemessen. Leider scheint mein Gigabyte Board Murks zu sein. Es lassen sich keine zwei Tests per Dualcore hintereinander mit gleichem Ergebnis reproduzieren. Bei Anschluss einer USB 3 Platte hakt das ganze System wenn man die Maus lange genug im Kreis bewegt. Das verbessert sich nur, wenn man im BIOS "Unlock Cores" für Kernfreischaltung aktiviert.
Manchmal gibt es nachvollziehbare Werte bei Benchmarks und dann nach 2 Mal reboot und mit exakt den gleichen Einstellungen, kommt nur Müll heraus. Mache ich einen BIOS Reset per Schalter und wenn dann ein blauer Bildschirm mit Nachfrage kommt, dann bekomme ich mit viel Glück wieder einen Benchmark mit 5-10 % mehr. Das gilt aber nur für den ersten Durchlauf. Danach ists wieder Essig. Der Wert von MikoFPU schwankt zwischen 2500 und selten über 4000. Keine Ahnung, was das soll.

Weder die 10.000 Punkte, noch die 7.000 Punkte bei Fibonacci konnten jemals wieder reproduziert werden. Die Textdatei vom Export habe ich aber gespeichert, da war kein Turbo aktiv und 3,3 GHz stehen auch drin. Anfangs hatte ich noch Verbesserungen durch HTT und oder Referenztakt erzielt in Crystalmark. Das ist nun auch futsch. Dafür klappt nun aber nach dem zigsten Reset das C6 mit Idle Wattzahlen um die 50 Watt, hatte ich das ganze We über noch nicht gesehen.

Was definitiv etwas bringt, ist das Heraufschalten des NB Taktes auf 2200 MHz. Das ist Standard für FX-8150 und optimal, beim FX-6100 offensichtlich verkehrt. Die Crystalmark Werte also bitte entsorgen! Entweder waren die Zufall, oder keine Ahnung. Bin leicht genervt von dem Mist gerade.

Ah ok, dann also nur der klassische Mist-Meß-Fall ^^

Meine Probleme haben sich nun gelöst. Es lag an einem dämlichen mitgelieferten Gigabyte Tool, welches im Hintergrund alle paar Sekunden einen neuen Prozess gestartet hat. Mittlerweile bekomme ich gute Ergebnisse.

Eine kurze Zwischenfrage zum Verständnis,
ich starte Crystalmark mit 2 Kernen auf 2CU/2C und erhalte:

Memory
Read 8800 Mb/Sek.
Write 8800 Mb/Sek.
Read/Write 12500 Mb/Sek.
Cache 51000 Mb/Sek.

Starte ich es auf einem Modul 1CU/2C, erhalte ich:
Read 6600 Mb/Sek.
Write 6600 Mb/Sek
Read/Write 8100 Mb/Sek
Cache 19300 Mb/Sek

Ein einzelner Kern bringt Folgendes:
Read 4400 Mb/Sek.
Write 4400 Mb/Sek
Read/Write 6200 Mb/Sek
Cache 28500 Mb/Sek


getestet wurde mit DDR 1600 RAM.

Zwei Kerne auf dem gleichen Modul lesen 28500 Mb-19300 MB = 9200 Mb pro Sekunde weniger aus dem Cache als ein einzelner Kern? Ist das plausibel?

Ist im DC bereich schon irgendwo ein FX gesichtet worden ?!

@ denjo: Hab einen FX-8150 bestellt weil ich einfach meine eigenen Erfahrungen machen und mich nicht auf div. Tests/Benchmarks verlassen wollte. Nur ist er mittlerweile leider wieder nicht mehr lieferbar. Ich hoffe auf den 31.10.2011 (lt. km-elektronik.de). Dann gibt's natürlich bei p3d von mir ein paar erste Eindrücke voraussichtlich am darauffolgenden Wochenende.

Gruß,
Ritschie

Ritschie schrieb:

@ denjo: Hab einen FX-8150 bestellt weil ich einfach meine eigenen Erfahrungen machen und mich nicht auf div. Tests/Benchmarks verlassen wollte. Nur ist er mittlerweile leider wieder nicht mehr lieferbar. Ich hoffe auf den 31.10.2011 (lt. km-elektronik.de). Dann gibt's natürlich bei p3d von mir ein paar erste Eindrücke voraussichtlich am darauffolgenden Wochenende.

Gruß,
Ritschie

Zum Vergrößern anklicken....

das hört sich doch gut an ^^ da bin mal auf die cmt ergebnisse gespannt

ich habe gerade ein fx6100 gekauft, konnte es nicht mehr aushalten,der basteldrang war doch zu gross.

Herr Melin schrieb:

Meine Probleme haben sich nun gelöst. Es lag an einem dämlichen mitgelieferten Gigabyte Tool, welches im Hintergrund alle paar Sekunden einen neuen Prozess gestartet hat.

Zum Vergrößern anklicken....

Wieso das denn? Hört sich ja recht komisch an.

Herr Melin schrieb:

Mittlerweile bekomme ich gute Ergebnisse.

Eine kurze Zwischenfrage zum Verständnis,
ich starte Crystalmark mit 2 Kernen auf 2CU/2C und erhalte:

Memory
Read 8800 Mb/Sek.
Write 8800 Mb/Sek.
Read/Write 12500 Mb/Sek.
Cache 51000 Mb/Sek.

Starte ich es auf einem Modul 1CU/2C, erhalte ich:
Read 6600 Mb/Sek.
Write 6600 Mb/Sek
Read/Write 8100 Mb/Sek
Cache 19300 Mb/Sek

Ein einzelner Kern bringt Folgendes:
Read 4400 Mb/Sek.
Write 4400 Mb/Sek
Read/Write 6200 Mb/Sek
Cache 28500 Mb/Sek


getestet wurde mit DDR 1600 RAM.

Zwei Kerne auf dem gleichen Modul lesen 28500 Mb-19300 MB = 9200 Mb pro Sekunde weniger aus dem Cache als ein einzelner Kern? Ist das plausibel?

Zum Vergrößern anklicken....

Plausibel schon, man würde ja so Pi*Daumen die Hälfte annehmen, aber mess es mal per RMMT.exe nach, ist Bestandteil der Rightmark Memory Testsuite:

http://cpu.rightmark.org/download/rmma38bin.rar

Wenn man da SSE2 Reads mit Prefetches einstellt, hat man das Maximum, mehr geht nicht, bei Crystalmark weiß man nicht, was die da genau testen.

Die Caches kannst Du über die Größe testen, Teste den L2 mal mit jeweils 512kB, sollte dann auf alle Fälle reichen. 1MB kann schon zuviel sein, da gabs mal nen Bericht zu den alten C2D L2s, die schon bei 1,5MB L2 Probleme zeigten. Sollte bei BD ähnlich sein. Also maximal ~700kByte

Wenn Du den L3 testen willst, dann halt 2-3MB, falls Du nicht mehr als 2 Threads hast. Für den Speicher dann irgendwas mit 100++ MB

Einführung hier:
http://ixbtlabs.com/articles2/cpu/rmma-general-3-add7.html

Edit:
Ein paar Graphen aus RMMA wären auch nicht schlecht, z.B. die D-Cache Latency. Einfach den Test laufen lassen und dann den Screenshot hochladen. Der wird schon defaultmäßig irgendwo gespeichert, schau ich mal selbst nach, und editiers dann rein.
Falls Du Win7/Vista x64 hast und eine RTCore Fehlermeldung am Anfang bekommst, tausch die alte gegen die hier aus:
http://www.mediafire.com/?dddsxacd9qgvejx

ciao

Alex

denjo schrieb:

Ist im DC bereich schon irgendwo ein FX gesichtet worden ?!

Zum Vergrößern anklicken....

Ja, hier:
http://www.overclock.net/overclock-net-boinc-team/1143670-fx-8120-boinc-benchmarks-real-world.html
sieht nicht so rosig aus. ist aber nicht verwunderlich, warum sollte der BD plötzlich im DC besser dastehen als er in den diversen reviews wegkam.