Opteron: Probleme mit der SSE2 Geschwindigkeit

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Der neue 64-Bit Prozessor AMD Opteron beinhaltet eine bisher nie dagewesene Anzahl von Befehlssätzen: Neben den Standard-Befehlssätzen x86, i386, i387 und dem neuen x86-64 kennt der Opteron auch noch die SIMD-Befehle MMX und MMX+, sowie 3DNow!, 3DNow!+ und nicht zuletzt die Intel-Befehlssätze SSE und SSE2. So weit, so gut. Doch gerade die lange herbei gesehnte Unterstützung für SSE2 scheint beim Opteron nicht perfekt gelungen zu sein.

Wie die japanische Webseite <a href="http://akiba.ascii24.com/akiba/" TARGET="b">Akiba2go</a> herausgefunden hat und bereits vorab durch <a href="http://www.theinquirer.net/?article=9278" TARGET="b">The Inquirer</A> aufgegriffen wurde, ist die SSE2-Performance beim Opteron verglichen mit dem Pentium 4 mangelhaft. Das SSE2 optimierte TMPGEnc lieferte folgende Werte:<ul><li>Opteron 242 (1.6GHz) : 424 s</li>
<li>Opteron 242-SSE2 OFF : 291 s</li>
<li>Pentium 4 2.8GHz : 295 s</li>
<li>Athlon XP 2600+ : 262 s</li>
</ul>Wie man sieht arbeitet der Opteron ohne Verwendung von SSE2 fast 50% schneller, als mit SSE2. Der Multimedia-Benchmark von SiSoft Sandra spuckte folgende Werte aus:<ul><li>Opteron 242 (1.6GHz) : 6300</li>
<li>Pentium 4 2.8GHz : 11148</li>
<li>Athlon XP 2600+ : 11614</li>
<li>Athlon XP @1600 MHz : 8933</li></ul>Wie man sieht, arbeitet selbst ein auf 1600 MHz zurückgetakteter Athlon XP mit SSE noch deutlich schneller, als ein Opteron mit SSE2.

Wie kann es dazu kommen? Zuerst einmal muß man bedenken, daß sich die SIMD-Befehle von MMX über 3DNow! bis SSE2 ein wenig anders verhalten, als die übrigen x86-Befehle. Ein Prozessor kann SIMD-Befehle in der Regel sehr viel schneller abarbeiten, als herkömmliche x86-Befehle, normalerweise bei jedem CPU-Takt einen Befehl und damit je nach Staffelung z.B. bei MMX bis zu 8 Byte-Berechnungen pro Takt. Anders formuliert bedeutet das aber, daß sich die SIMD-Leistung eines Prozessors bei gleicher Effizienz direkt proportional zur Taktfrequenz verhält - Model-Rating hin oder her. Der Vergleich Opteron 1.6 GHz vs. Pentium 4 2.8 GHz ist also von vorne herein zum Scheitern verurteilt für den Opteron. Zwar besäße der Opteron doppelt so viele SIMD-Register, doch nachdem bisher kein Programm davon Gebrauch macht, kann er daraus natürlich auch keinen Nutzen ziehen.

Dennoch darf es selbstverständlich nicht sein, daß ein Opteron eine Aufgabe mit SSE2 langsamer verarbeitet, als ein Athlon XP bei gleicher realer Taktfrequenz mit SSE. Hier liegt definitiv etwas im Argen und hat nichts zu tun mit direkter Proportionalität zu irgendwelchen Taktfrequenzen. Möglicherweise liegt es an einer anderweitigen Optimierung für den Pentium 4, die dem Opteron mit SSE2 zu schaffen macht, schließlich besaßen bisher nur Pentium 4 Prozessoren SSE2 und die Programmierer/Compiler-Entwickler gingen möglicherweise davon aus, daß wenn schon SSE2 vorhanden ist, auch der Rest des Codes auf den Pentium 4 optimiert sein müsse. Das gilt es nun zu untersuchen. Sobald Takeo Noguchi, der Autor des Berichts, neue Erkenntnisse dazu gesammelt hat, oder AMD eine Stellungnahme dazu abgegeben hat, werden wir natürlich ein Update zu dieser Meldung veröffentlichen.
THX Martin für den Hinweis
 
Bin ja mal gespannt was AMD dazu sagt und wie sie das Problem in den Griff kriegen wollen.

Nur gut dass fast keine Software SSE2 benutzt
 
Vermutlich ist es wirklich so das Programmierer die extra gleich SSE2 Software schreiben die Software auch gleich noch generell an die P4 Architektur anpassen.
Wegen der vielen, unkonplexen Recheneinheiten der 20stufigen P4 Pipeline. Hier wäre die kurze K8 Pipeline im Nachteil und die komplexen Einheiten wären unterfordert und im Halbschlaf.

Könnte aber natürlich auch an der Implementierung liegen, SSE ist im XP ja auch nicht optimal eingebunden im Vergleich zum PIII.
 
Ganz deiner Meinung Claw !
Da ja SSE2 eher für INTEL optimiert ist, wird es wohl daran hapern!

Kommt Zeit, kommt Rat !
 
nobody's perfect ;D
 
So Lautet der Posting-Titel im Forum von CPU's, witzig daß das Posting noch gar nicht so alt ist, ist jedenfalls eine prima Ergänzung!
THX @Nero24 fur die prompte Rückmeldung!
 
Zuletzt bearbeitet:
wie schön, dass das amd auch jetzt schon auffällt ;(
naja ok die wussten das wahrscheinlich schon viel viel länger ...
 
Ich halte es problematisch, die SSE2-Performance nur an Hand eines einzelnen Benchmarks zu beurteilen, da können auch noch andere Faktoren eine Rolle gespielt haben...
 
Hi,

vielleicht hat AMD die Befehle ja noch nicht hart-verdrahtet sondern läßts noch per Microcode "emuliert" laufen, vielleicht auch, weil es noch einen Bug gab. Das könnte sich eventuell mit dem nächsten Stepping ändern ;-)

ciao

Alex
 
hää?

Hab ich das gerade richtig gesehen, dass der XP2600+ bei TMPEGenc schnelelr ist als ein P4 2.8GHz? Weil bisher hab ich nur Benchmarks gesehen, in denen der P4 beim SSE2 _deutlich_ schneller ist, als vergleichbare Athlon XP's.
 
na toll sowas fehlte noch das der Opteron noch Bugs hat!

Bin mal gespannt ob er nun auch zurück gehalten wird oder den Kunden angedreht wird!
 
Wer sagt denn dass der Bugs hat ? Bisher weiss man noch nicht woran liegt. Und ausserdem: WEN JUCKTS ? Was läuft schon auf SSE2, ausser paar Benchmurks ?

Bis ihr euch nen Opteron kauft vergeht eh noch zeit, also würd ich mal abwarten wie sich das alles Entwickelt
 
@zlurp

Gute Augen!!! Das ist mir nicht aufgefallen!
Da fragt man sich doch, wie zuverlässig die Quelle ist... ;D
 
Vielleicht eine Erklärung:
Ich habe bei AMD gestöbert und einen Optimization Guide gefunden (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.pdf), der einige interessante Einblicke bietet. Unter anderem sind die Dekodierungsarten für SIMD-Befehle aufgeführt (Direct Path = schnell, Vector Code = langsam, da über Microcode dekodiert). Aufgefallen ist mir, dass alle 3DNow! Instruktionen über den schnellen DirectPath dekodiert werden, dahingegen einige SSE- / SSE2-Befehle über den langsamen Vectorpath laufen müssen. Möglicherweise ist das eine Erklärung. Freileich kannd as nicht der Grund sein für das verhälnismäßig grottenschelchte Abschneiden des Opteron...
 
Original geschrieben von Seemann
Vielleicht eine Erklärung:
Ich habe bei AMD gestöbert und einen Optimization Guide gefunden (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.pdf), der einige interessante Einblicke bietet. Unter anderem sind die Dekodierungsarten für SIMD-Befehle aufgeführt (Direct Path = schnell, Vector Code = langsam, da über Microcode dekodiert). Aufgefallen ist mir, dass alle 3DNow! Instruktionen über den schnellen DirectPath dekodiert werden, dahingegen einige SSE- / SSE2-Befehle über den langsamen Vectorpath laufen müssen. Möglicherweise ist das eine Erklärung. Freileich kannd as nicht der Grund sein für das verhälnismäßig grottenschelchte Abschneiden des Opteron...
Das hatte ich auch schon gelesen, AFAIK sind aber beim Opteron mehr SSE Befehle vorhanden, die den schnellen Direct Path nutzen. Auf alle Fälle könnte das ein Teilgrund sein.

Ich denke aber auch, dass das schlechte Abschneiden des Opteron mit der Optimierung der Software zusammenhängt. Schließlich hat der P4 nur eine SIMD Einheit, der Opteron dagegen drei. Allerdings sind diese 3 Einheiten nicht alle gleichwertig (FPMUL, FPADD und FPMISC). Der Opteron kann also nicht automatisch alle Einheiten gleichzeitig benutzen (siehe auch Optimization Guide, manche Befehle nutzen die ADD, andere die Mul Einheit und andere wiederum die MISC Einheit, nur dei wenigsten können in mehreren abgearbeitet werden) Das heißt der Opteron benötigt in gewisser Weise optimierten Code, wo der P4 ihn nicht benötigt.
Bei SSE ist das dagegen anders, wenn ich das richtig interpretiere (siehe hier ) dann hat der PIII zwei echte SIMD Einheiten, sodass der Athlon daraus auch seinen Vorteil ziehen kann.
 
Hmm, komisch, in der c't gabs vor ein paar Wochen mal einen Test des Athlon64, bei dem einige Benchmarks mit aktiviertem SSE2 deutlich flotter liefen.
Nunja, egal ob AMD bei der Implementierung halbherzig gearbeitet hat, oder es ein Kompilerproblem ist, wäre es schon gut, die Sache aufzuklären.
 
ich glaube das problem kriegen sie gelöst beim opteron, wäre ja gelacht. die sind doch nicht bescheuert und geben sse2 rein wenn das den prozessor AUSBREMST.

naja abgesehn mal davon haben sie ja noch ne weile zeit bis zum athlon64, bis dahin wirds auf jeden fall glatt gehn mit sse2,da bin ich mir sicher...
 
Zurück
Oben Unten