Phenom-Optimierung der SiSoft Sandra Speicherbandbreite

In unserem <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=325750">AMD Phenom-Review</a> sowie im nachfolgenden <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=326608">Update</a> haben wir gezeigt, dass die Speicherbandbreite im SiSoft Sandra Bandbreitentest sehr bescheiden aussah, während der gleiche Test mit dem Sciencemark genau das Gegenteil zeigte.

Wie wir jedoch ebenfalls erwähnt haben, liegt das schlechte Ergebnis in diesem Test an der genutzen Sandra-Version und der Programmierung des Benchmarks:<ul><i>Der Phenom 9500 schneidet augenscheinlich sehr schlecht ab. Hier muss aber beachtet werden, dass die Entwicklung von SiSoft Sandra noch nicht beim Phenom angekommen ist. Berichte anderer User zeigen ebenfalls eine sehr niedrige Bandbreite. Grund hierfür ist die Programmierung des Tests, welcher erst noch auf die Architektur angepasst werden muss.</i></ul>Bis zur Version, die wir für unsere Reviews genutzt haben (welche die zu diesem Zeitpunkt aktuellste war), wurde während des Bandbreitentests ein Benchmark-Thread pro physischer CPU ausgeführt.

Die Kollegen von Legitreviews.com haben nun einen Vergleich der SiSoft Sandra-Versionen XII sowie XII SP1 vorgenommen. Während die Version XII auf die besagte Abarbeitung eines Berechnungsthreads pro physischer CPU setzt, wird bei der zwischenzeitlich erschienenen Version XII SP1 auf die Abarbeitung eines Threads pro CPU-Kern gesetzt. Als Ergebnis zeigt sich eine Verdoppelung der Speicherbandbreite.

Obwohl dies natürlich gute Nachrichten für den Phenom sind, zeigt sich einmal mehr, wie abhängig das Benchmarkergebnis einer Architektur von der Art der Benchmarkprogrammierung ist. Denn an der Bandbreite selbst hat sich nichts gändert, lediglich die Messung selbiger wurde optimiert.

<b>Links zum Thema:</b> <a href="http://www.legitreviews.com/article/617/1/" target="_blank">AMD Phenom Processors Don't Have Crappy Memory Bandwidth Afterall</a>

wobei die Messung der Speicherbandbreite dort mit aktiviertem TLB-Patch erfolgte.
Dh. ohne geht die Post erst richtig ab.
Aber überhaupt ist die Speicherbandbreite eher uniteressant, siehe C2D, C2Q, die dank grossem und schnellen Cache auch mit weniger Bandbreite noch ganz gut auskommen, dh. bessere Benchmarkresultate liefern.
Die sollten lieber die einzelnen Anwendungen AUCH für den K9/K10 neu optimal compilieren, dann hat der Anwender auch etwas davon. Kommt sicher oft vor, dass da Ressourcen in der CPU brach liegen, weil das Programm bzw. der Compiler diese nicht vorhatte zu nutzen.

MusicIsMyLife schrieb:

Obwohl dies natürlich gute Nachrichten für den Phenom sind, zeigt sich einmal mehr, wie abhängig das Benchmarkergebnis einer Architektur von der Art der Benchmarkprogrammierung ist. Denn an der Bandbreite selbst hat sich nichts gändert, lediglich die Messung selbiger wurde optimiert.

<b>Links zum Thema:</b> <a href="http://www.legitreviews.com/article/617/1/" target="_blank">AMD Phenom Processors Don't Have Crappy Memory Bandwidth Afterall</a>

Zum Vergrößern anklicken....

Genau ..... und wenn wir noch ein halbes Jahr bis zu C2 oder C3 Stepping gehts richtig rund, glaube ich .... weil erstens ham die Sunnyvaler (bzw Dresdner) dann die Kanten glattgefeilt und zweitens die Parzen ihre Benches wenigstens halbwegs angepasst.....

Ich glaub immer noch dass im K10 noch Musigg steckt....

Mmoe

Das ist mir schon öfter aufgefallen, daß die Benchmarks sich mit den aktuellen Intels besser auskennen als mit gleichalten AMDs und angesichts der Tatsache, daß doch viele ihre Kaufentscheidungen von solchen Ergebnissen abhängig machen, finde ich es bedenklich, wenn Benchmarks da nicht unparteiisch sind.

Ich frag mich gerade wie sinnlos so ein Bench eigentlich ist, der auf die Hardware angepasst wird.

Vollkommen sinnlos um genau zu sein. Wenn ein Programm so geschrieben wird, das maximale rauszuholen, kann man gleich theoretische Bandbreite minus ein paar Prozent Overhead nehmen, dazu brauche ich keinen Benchmark.

Theoretische Ergebnisse schön und gut aber das ist ja nun vollkommen bekloppt.

Ole schrieb:

Ich frag mich gerade wie sinnlos so ein Bench eigentlich ist, der auf die Hardware angepasst wird.

Vollkommen sinnlos um genau zu sein. Wenn ein Programm so geschrieben wird, das maximale rauszuholen, kann man gleich theoretische Bandbreite minus ein paar Prozent Overhead nehmen, dazu brauche ich keinen Benchmark.

Theoretische Ergebnisse schön und gut aber das ist ja nun vollkommen bekloppt.

Zum Vergrößern anklicken....

Wenn der Benchmark sich an realen Anwendungen orientiert sicher schon...

Als Refernzergebnis für die Softwareentwickler - wieviel sie denn aus ihrem Code herausholen könnten - finde ich sie jedenfalls sehr sinnvoll.
Wenn die Programme am Ende nicht so optimiert werden, wie sie könnten, ist das IMHO nicht der Fehler des Benchmarks.

Wer also nicht eine doppelt so schnelle CPU will, weil seine Software nur 50% herausholt, sollte einmal über ein selbskompilliertes OS nachdenken - oder die teure optimierte Software anschaffen

Ole schrieb:

Ich frag mich gerade wie sinnlos so ein Bench eigentlich ist, der auf die Hardware angepasst wird.

Zum Vergrößern anklicken....

Du sprichst mir gerade aus der Seele.

Wenn es nur nach mir ginge, wäre SiSoft Sandra bereits völlig aus meinen Benchmark-Durchläufen gestrichen. Aber immer wieder wird der Test zugrunde gelegt und da ihn fast jeder nutzt, gehört er auch zu unserem Parcours dazu.

Privat nutze ich seit dem nForce 2 kein Sandra mehr, da ich damals mitbekommen habe, wie merkwürdig der Bandbreitentest programmiert sein muss. Damals habe ich für mich einige Tests gemacht, in denen unter anderem die asymmetrische Bestückung der Speicherkanäle vorkam. Obwohl DualChannel, fiel dort die Bandbreite um ein gutes Stück ab. Im Gegensatz dazu zeigten andere Anwendungen praktisch kaum einen Unterschied zwischen symmetrischer und asymmetrischer Speicherkanal-Bestückung.

Ähnliches ist bei Einführung des AM2 vorgekommen. Während bei der damalig aktuellsten Version der DualCore schlechter abgeschnitten hatte, ist das Bild heute um 180 Grad gedreht.



Die eigentliche Frage, die sich mir stellt, ist die:

Legitreviews.com schreibt ja sinngemäß, dass alle von einer schlechten Bandbreite ausgegangen sind.

legitreviews schrieb:

It seems SiSoftware Sandra XII was not correctly optimized for the Phenom processors! We contacted SiSoftware after we were informed by AMD that nearly every memory bandwidth score on the internet was incorrect. Why AMD waited weeks to let us know this is beyond me, but nothing is shocking in this industry.

Zum Vergrößern anklicken....

Wissen nur wir, was für eine zweifelhafte Aussagekraft der Bandbreitentest in Sandra hat? Ist das niemand anderem aufgefallen?

Ole schrieb:

Ich frag mich gerade wie sinnlos so ein Bench eigentlich ist, der auf die Hardware angepasst wird.

Vollkommen sinnlos um genau zu sein. Wenn ein Programm so geschrieben wird, das maximale rauszuholen, kann man gleich theoretische Bandbreite minus ein paar Prozent Overhead nehmen, dazu brauche ich keinen Benchmark.

Theoretische Ergebnisse schön und gut aber das ist ja nun vollkommen bekloppt.

Zum Vergrößern anklicken....

Absolut. Wenn das von mir benutzte Programm nun Speicherzugriffe so organisiert, wie der "alte" Sandra-Speicherbench, dann hab ich nämlich auch nichts davon, dass der neue Bench nun irgendwelche tollen Werte zeigt......
Diese theoretischen Benches waren schon immer und sind immer noch Käse. Egal ob nun Intel oder AMD. Entscheidend ist, dass die Aufgaben, die man macht, schneller oder langsamer abgearbeitet werden.

Wissen nur wir, was für eine zweifelhafte Aussagekraft der Bandbreitentest in Sandra hat? Ist das niemand anderem aufgefallen?

Zum Vergrößern anklicken....

Zumal du ja von Anfang gesagt hast, dass der Benchmark sozusagen "entsorgt" gehört...

Aber schau dir doch mal die Qualität der durschnittlichen Reviews im Netz so an....
Ohne dir jetzt Honig um den Bart schmieren zu wollen, hat man bei dir doch das Gefühl, dass du einfach bisschen mehr Ahnung von der Materie hast, was sich auch in deinen Reviews wiederspiegelt.....

Diese theoretischen Benches waren schon immer und sind immer noch Käse. Egal ob nun Intel oder AMD. Entscheidend ist, dass die Aufgaben, die man macht, schneller oder langsamer abgearbeitet werden.

Zum Vergrößern anklicken....

Aber auch nur weil die meisten Benchmarks viel zu überbewertet werden, meiner Meinung nach...Es wird objektivität suggeriert....
Benchmarks sind insofern hilfreich um die Grund - Funktion der Hardware zu testen, Fehler aufzuspüren. zu optimieren... Dafür nutze ich sie persönlich... Für Vergleiche zwischen Produkten ist das immer so eine Sache, grade bei ganz neuen Produkten, wie der Speichertest hier zeigt....Vor allem auch, weil die Produkte auch "streuen", man also für 100% objektivität einen Mittelwert mehrerer Setups bräuchte. Insofern immer nur ein Anhaltspunkt...

Grüße!

Tjoa...

zum Thema Durchsatz, nicht zum Thema Bench ( ):

Was es zeigt ist, dass man beim Phenom für einen einzelnen Thread nur noch eine relativ schwache Bandbreite hat.

So wie ich es sehe, wurde die Architektur optimiert für den Fall, dass zwei Threads parallel laufen, die viel Speicherbandbreite benötigen ( so viel sie kriegen können). Ein einzelner Thread der viel Bandbreite braucht (der weitaus häufigere Fall?), dem gehts jetzt aber schlechter... so gesehen nicht grad ne Optimierung?

Bzw., ggf. kriegt man ne bessere Bandbreite hin wenn man einen bandbreiten-hungrigen Thread auf mehrere Bandbreiten-hungrige Threads verteilt; was dann aber wieder mehr overhead und (sonst unnötiger) Synchronisationaufwand bedeutet - unter'm strich wirds langsamer sein als vorher?!

Na gut, vielleicht gibt's dadurch noch andere (Latenz- ?) Optimierungen, wenn nun die Hälfte der Threads beim Memorycontroller in der Queue stehen?

Die Latenz könnte ja durchaus auch von starker Bedeutung sein...

.. wer misst, misst Mist.

Was es zeigt ist, dass man beim Phenom für einen einzelnen Thread nur noch eine relativ schwache Bandbreite hat.

Zum Vergrößern anklicken....

Hm, so weit würd ich mich nicht aus dem Fenster lehnen. Ich könnte mir vorstellen das bei Sandra an noch mehr Stellen gedreht wurde, als die reine Umstellung auf einzelne Threads. Wir wissen nicht was für Compiler Einstellungen usw. noch geändert wurden. Ich halte von synthetischen Benchmarks nicht viel, bei denen man die Sourcen nicht sehen kann. Ich kann mich nicht darauf verlassen, das was ich messen will auch wirklich gemessen wird und annähernd der Realität entspricht.
Benchmarks mit sog. "Realworld" Anwendungen sind relevanter, weil ich als Benutzer sehen kann was mir neue Technologien bringen.

Grüße

kirsche

Was interessiert mich eine Bnadbreite, die im normalen Betrieb nie zum Tragen kommt

Luxo schrieb:

Das ist mir schon öfter aufgefallen, daß die Benchmarks sich mit den aktuellen Intels besser auskennen als mit gleichalten AMDs und angesichts der Tatsache, daß doch viele ihre Kaufentscheidungen von solchen Ergebnissen abhängig machen, finde ich es bedenklich, wenn Benchmarks da nicht unparteiisch sind.

Zum Vergrößern anklicken....

Das liegt eigentlich in der Natur der Sache - denn Intel liefert den Referenz-C Compiler, auf den der weitläufig benutzte Compiler von MS aufbaut! Kaum jemand setzt eine Compiler-Suite von Pathscale, NAG oder PGI ein, geschweige denn der wesentlich 'vergleichbarere' GNU gcc. Letzterer ist angeblich zu langsam - wohl aber auf allen Architekturen eben gleich lahm!

Insofern sind mir unter Windoof getätigte Benchmarks eh suspekt! Interessanter sind die Meßwerte der SPEC Suite. Sie sagen wirklich etwas über die Leistungsfähigkeit einer CPU aus, wenn man sie zu lesen versteht. Wer aber auf bunte Bilder und schicke bunte Balken in sog. Diagrammnen steht ...

Scour schrieb:

Was interessiert mich eine Bnadbreite, die im normalen Betrieb nie zum Tragen kommt

Zum Vergrößern anklicken....

Als es darum ging den Phenom zu bashen hat es erstaunlich viele interessiert.

Berniyh schrieb:

Als es darum ging den Phenom zu bashen hat es erstaunlich viele interessiert.

Zum Vergrößern anklicken....

Ich hab Sandra nie ernstgenommen, egal was ich gerade hatte, ob Intel oder AMD da führte war mir immer egal

Benchmarks die immer erst Updates benötigen um neue Hartware richtig zu testen sind gelinde gesagt suspekt. Es geht da nicht um irgendwelche Besonderheiten die noch nie da waren die getestet werden müssen, sondern nur um die Speicherbandbreite. Die gibt es schon seit was weis ich...

Ich glaube das solche Benchmarks dann auch nur so gut testen wie die Optimierung für das neue System ausgefallen ist. Aber nicht die tatsächliche Leistung.

Ist das den nicht normal, Nvidia macht es auch nicht anders. Da wird mal eben der neuste Treiber optimiert, damit sie im Benchmark noch besser darstehen.

Von daher sollte man sich nicht wundern, wenn das jetzt überall dort gemacht wird, wovon man sich was versprechen kann. Man wäre ja ein Looser wenn man es nicht tut.

Wobei ich mich trotzdem Frage das man keine anderen Programme dafür nutzen kann, mit Everrrest z.b in der Ultimate Edition läßt sich ja auch ziemlich viel dahingehend messen. Oder wird SIS benutzt, weil jeder es mittlerweile nutzt, oder weil sonst kein vgl. mit älteren Benchmarks möglich ist. Irgendwo muß man ja ein Schnitt machen.

Drohne schrieb:

Das liegt eigentlich in der Natur der Sache - denn Intel liefert den Referenz-C Compiler, auf den der weitläufig benutzte Compiler von MS aufbaut! Kaum jemand setzt eine Compiler-Suite von Pathscale, NAG oder PGI ein, geschweige denn der wesentlich 'vergleichbarere' GNU gcc. Letzterer ist angeblich zu langsam - wohl aber auf allen Architekturen eben gleich lahm!

Insofern sind mir unter Windoof getätigte Benchmarks eh suspekt! Interessanter sind die Meßwerte der SPEC Suite. Sie sagen wirklich etwas über die Leistungsfähigkeit einer CPU aus, wenn man sie zu lesen versteht. Wer aber auf bunte Bilder und schicke bunte Balken in sog. Diagrammnen steht ...

Zum Vergrößern anklicken....

Ooch, die c´t macht aus Spec-Werten auch bunte Balken, warum auch nicht?

Man sollte für real-life Anwendungen die Bedeutung der compiler aber auch nicht überbewerten. Die AMD-Architektur ist IMHO so ausgelegt, dass sie mit relativ unterschiedlichem code jeweils gut zurecht kommt. Wer einen leistungsfähigen Prozessor als kleinerer Mitbewerber basteln will, ist auch immer gut beraten, das so zu machen. Und grundsätzliche Schwächen, wie die SSE2/3-Schwäche des K8 (im K10 ja nun behoben) lassen sich auch mit dem tollsten Compiler nicht umgehen. Solange ein Intel-Compilat nicht grundsätzliche code-Funktionen auf einem AMD verweigert (gabs ja durchaus auch) ist der Code vom Intel-Compiler sogar oft immer noch schneller auf AMD-Systemen als Code von sog. AMD-optimierten Compilern.......

BLJ schrieb:

So wie ich es sehe, wurde die Architektur optimiert für den Fall, dass zwei Threads parallel laufen, die viel Speicherbandbreite benötigen ( so viel sie kriegen können). Ein einzelner Thread der viel Bandbreite braucht (der weitaus häufigere Fall?), dem gehts jetzt aber schlechter... so gesehen nicht grad ne Optimierung?

Zum Vergrößern anklicken....

Der Phenom hat eine NUMA Architektur, da er zwei unabhängige Speichercontroller hat, verhält sich also eher wie ein SMP System als Multicore.

Es ist keine Benchmark Optimierung, wenn man mehrere Threads startet um die aggregierte Speicherbandbreite zu messen, sondern das ist der normale use case, daß man mehrere Threads auf einer Multicore CPU laufen läßt... Wen interessieren noch single threaded benchmarks?

PrakashP schrieb:

Der Phenom hat eine NUMA Architektur, da er zwei unabhängige Speichercontroller hat, verhält sich also eher wie ein SMP System als Multicore.

Es ist keine Benchmark Optimierung, wenn man mehrere Threads startet um die aggregierte Speicherbandbreite zu messen, sondern das ist der normale use case, daß man mehrere Threads auf einer Multicore CPU laufen läßt... Wen interessieren noch single threaded benchmarks?

Zum Vergrößern anklicken....

Was nützen einem mehrere concurrent Threads wenn die keine solchen Bandbreiten benötigen?

Mit Optimierung habe ich nicht Optimierung auf Benchmarks gemeint sondern auf Bandbreiten-hungrige Anwendungen die produktiv eingesetzt werden sollen.

Aber die Anmerkungen oben sind vermutlich korrekt und es ist das bessere Design...

BLJ schrieb:

Was nützen einem mehrere concurrent Threads wenn die keine solchen Bandbreiten benötigen?

Zum Vergrößern anklicken....

Interessanter ist die Latenz, welche sich meines Wissens auch mit NUMA reduziert (sofern man nicht auf den an den anderen controller angekoppelten Speicher zugreift). Denn Zugriffe auf Hauptspeicher verlangsamen eine CPU ungemein und es wird sehr viel Aufwand betrieben um solche Zugriffe um Fraktionen von Prozenten zu reduzieren.

Der Phenom führt als erster x86 Prozessor auch out-of-order Loads durch, bin mal gespannt, ob damit das bekannte x86 memory model aufgeweicht wird und es Richtung Itanium geht.

Phenom-CPUs auf Basis der Barcelona Architektur haben KEINE zwei unabhängige Speichercontroller! Das Attribut 'unabhängig' ist hier falsch! Der Speichercontroller des Phenom ist in der Lage zwei 64 Bit Worte unabhängig zu lesen oder schreiben, vorausgesetzt sie befinden sich in zwei unterschiedlichen Bänken.

Eine NUMA haben alle Zwei- bis n-Sockel Opteron/Barcelona.

MusicIsMyLife schrieb:

Wissen nur wir, was für eine zweifelhafte Aussagekraft der Bandbreitentest in Sandra hat? Ist das niemand anderem aufgefallen?

Zum Vergrößern anklicken....

Jo, im rauhen Internet treiben sich viele zweifelhaften Gestalten mit erstaunlich großem Halbwissen rum ...

Das 1 thread benches nicht die volle RAM Bandbreite von Multicore CPUs mit integriertem Speicherkontroller nützen, vermute ich schon seit über nem Jahr .. aber auch wenn ich in allen möglichen Foren schreib ... bis sich sowas rumspricht .. dauert es

ciao

Alex

MusicIsMyLife schrieb:

Wissen nur wir, was für eine zweifelhafte Aussagekraft der Bandbreitentest in Sandra hat? Ist das niemand anderem aufgefallen?

Zum Vergrößern anklicken....

Ich halte den bench allgemein für recht zweifelhaft. Ich habe den kram zwar schon ne weile nicht mehr genutzt aber ich erinnere mich noch an Zeiten wo bei den Prozessortests die SSE Einheit bei intel CPUs genutzt wurde und bei den AMD Prozessoren lediglich die FPU zum Einsatz kam.....obwohl diese ebenfalls SSE unterstützte.
Somit wird mit zweierlei Maß gemessen, die Vergleichbarkeit ist dahin und das Programm war somit für mich gestorben.

Drohne schrieb:

Phenom-CPUs auf Basis der Barcelona Architektur haben KEINE zwei unabhängige Speichercontroller! Das Attribut 'unabhängig' ist hier falsch! Der Speichercontroller des Phenom ist in der Lage zwei 64 Bit Worte unabhängig zu lesen oder schreiben, vorausgesetzt sie befinden sich in zwei unterschiedlichen Bänken.

Zum Vergrößern anklicken....

Nun ja, ich kann nur das wiedergeben, was Mike Wall von AMD auf der TechEd Developers in Barcelona über den Barcelona zum besten gegeben hatte.

Ferner scheint http://www.channelinsider.com/print_article/AMD+Unveils+Barcelona+QuadCore+Details/191008.aspx oder auch http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2939&p=7 das zu bestätigen, daß es sich um unabhängige controller handelt (wie auch immer man nun "unabhängig" definieren mag). Man müßte mal in AMD's whitepapers nachlesen, um das endgültig zu verifizieren, was ich aber auch nicht getan habe.

Ok, hier scheint was beschrieben zu sein: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.pdf den Punkt 2.8. Das TEil hat zwei DRAM Controller DCT0 und DCT1, die im "ganged" oder "unganged" mode betrieben werden können. Letzteres wird unter 2.8.4 empfohlen und entspricht meinem Verständnis einer NUMA Architektur, [EDIT] wobei es wohl auch ankommt, wie die cores dran geknüpft sind. Hmm. Wenn ich den L3 cache auch noch bedenke, denn sich ja alle cores teilen, und der ja vor den memory controllern liegen sollte, macht es in der Tat nicht viel Sinn von NUMA zu reden. Also nehme ich das zurück. Der Effekt der höheren Bandbreite ist aber ähnlich.