News Hat der Opteron Probleme mit SSE2?

[Anonymous]

"Die Opteron SSE 128bit SIMD Befehle sind somit 30 Prozent langsamer als die MMX 64bit SMD Befehle des Athlon XP?"

Der Athlon XP hat auch die 128 bit SSE Register.
Nur wird halt bei Opteron SSE2 verwendet und beim Athlon XP halt verstaendlicherweise nur SSE(1).
Der Hauptunterschied SSE(1)SSE2 ist eigentlich nur das SSE(1) 4x32bit Gleichkommazahlen in so ein 128bit Register verarbeiten kann und SSE2 2x64bit Gleichkommazahlen.


@Bokill

An der Kompetenz deiner Komentare kann man allerdings auch zweifeln.

Denn dein Beispiel mit dem ignorieren der SSE1 Befehlen kommt hier wohl kaum zum tragen, da ja wohl verschiedene Programme von verschiedenen Hersteller mit Performance Problemen bei aktivierten SSE2 zu kaempfen haben.
Und genutzt wird es ... da TMPGEnc die SSE2 Optionen nur freischaltet wenn der CPUID Befehl es mit auf der Featureliste hat.

Die Sache mit dem Optimierungen auf eine bestimmte Architektur (z.b P4) ... welcher AMD Compiler soll das denn bitte fuer Hammerprozessoren machen ?!
Abgesehen davon das ein grosser Teil der Programme wohl immernoch auf Pentium 1/Pro Architektur optimiert ist, schliesslich muessen die Programme auch auf allen moeglichen CPU-Typen laufen.
Lediglich solche Extensions wie MMX, 3DNow und SSE werden verwendet.
Es sei den man hat Linux/BSD und Kompiliert die Programme fuer einen bestimmten CPU-Typ ... was aber bei Windows wohl kaum gegeben ist.

Und das der Athlon XP 2600+ den Opteron 1.6 Ghz in den hier gezeigten Benchmarks (Sandro und TMPGEnc) fertig macht ... das ist traurig nicht merkwuerdig und beruht wohl auf der langsamen SSE2 Umsetzung.

 

[Anonymous]

seltsam. auf tomshardware steht was ganz anderes...

 

[Anonymous]

Hmm in einem anderen Forum wurde was geschrieben das das B Stepping der Opterons noch spezielle Optimierung fuer SSE2 benoetigt ... das C Stepping aber nicht mehr.
Das wuerde natuerlich die unterschiedlichen Ergebnisse zwischen Tomsharde und Akiba2go erklaeren.
Und falls das Zutrifft, ist das ein Problem das schon erkannt und gefixt wurde, so das Akiba2go dann wohl nur nen veraltetes Stepping genutzt hat.

http://www.aceshardware.com/forum?read=95034862

 

[Anonymous]

Zu meinen Vorrednern, ich bin nicht Mr.Kompetenz, da war ich gestern wohl schon übermüdet. Ich meine nur, daß man nicht vorschnell von einem Bug reden soll, denn AMD ist neu im SSE2-Camp. Keiner kann definitiv sagen, ob der P4 in letzter Zeit scheller geworden ist, weil "nur SSE2" genutzt wird, oder noch weitere Goodies zum Einsatz kommen (dazu kommen noch Benchmarktricks, daß Streaming/Bandbreiten-Benchmarks plötzlich überhand nehmen, bei denen der Athlon natürlich Federn lassen muß).
Hat AMD eigene Compiler?!?!?!
Der Hinweis zur Leistung des XP's galt auch im Bezug zur Leistung eines P4!
Wenn ich nur Flamen wollte, hätte ich nicht den Hinweis auf die Partnerseite gebracht, es ist nur müßig vieles zu wiederholen, was schon in dem Forum angesprochen wurde.

 

[Anonymous]

Andere Benchmarks
http://www.aceshardware.com/read.jsp?id=55000262

http://www.aceshardware.com/read.jsp?id=55000265

soviel zum "buggy" Opteron.

 

[Anonymous]

@raiden
genau - raiden - dort wird genau erklärt.
computerbase erreicht manchmal echt das niveau von der computer bild. bevor ich den inquirer zitiere, würd ich doch noch nach anderen quellen suchen... erst recherchieren dann posten...
don´t feed the trolls.......
beatz - bunteknete

 

[Anonymous]

Naja, für CB scheinen die anderst belegende Test nicht wohl ausreichend genug zu sein wie der Müll vom The Inquirer.

Wieviele Falschmeldungen von The Inquirer hat CB schon auf dem Konto bezüglich über AMD?

Soviel dazu von mir über eine fundierte Recherche von CB.

 

[Anonymous]

Der Inquirer hat Vor- und Nachteile, er ist verdammt schnell, hat eine blumige Sprache, und korrigiert sich auch von selbst wenn grobe Schnitzer passieren.
Der Autor dieser Seite weiß um die Nachteile schneller Meldungen, aber eines ist auch sicher, viele Quellen sind verdammt nahe an der Hardwarefront!

 

[Anonymous]

joa... und der Axel Springer Verlag is moralisch unbeschmutzt.

 

[Anonymous]

Jippi, die AMD Jünger versuchen den Opteron wieder mit allen Mitteln zu verteidigen. Worüber regt ihr euch so auf, seht euch mal um, CB ist nicht die einzige Seite die das übernommen hat und irgendwas scheint ja nicht zu stimmen beim Opteron mit SSE2, siehe CT usw.
Außerdem stehen in der News ? und dass man weiteres ergänzen wird, wenn bekannt.
Also ganz ruhig, alle die sich hier so aufregen.
Manchmal übertreibt ihr es echt.

 

[Anonymous]

lol...also son krassen gegensatz zwischen den CB werten und denen vom post 24 haette ich nu net erwartet... hoho

 

[Anonymous]

Die genannten Bench von Bokill stammen vom 24.04.03, The Inquirer brachte seine News am 02.05.03, zgesteckt von´nem Japaner.
Es wäre doch kein Prob gewesen einen um eine Woche älteren Benchmark auszugraben und die Bench vom Akibo2go jederzeit (d.h. jetzt immernoch) in Frage zu stellen.

 

[Anonymous]

Also Leute, dass ist doch klar. Der Athlon hat drei (!) x87 Einheiten zum verarbeiten von Fließkommadaten, aber nur eine SSE2 Einheit für den gleichen Zweck. Darum ist der Athlon im gegensatz zum P4 ja bei manchen Anwendungen so schnell, weil der P4 nur eine doppelte x87 Einheit hat. "Optimiert" man den Code jetzt auf SSE2 (double Precision) Befehle, dann kann der Opteron seine drei x87 Einheiten nicht benutzen und es wird mit der einen SSE2 Einheit gearbeitet. Der Opteron hat jetzt in etwa die gleiche Leistung wie ein P4 bei gleicher Frequenz, da die SSE2 Einheit ja von Intel Lizensiert wurde. Nun ist der Opteron aber eben mit nur 1,8GHz getaktet, der P4 aber mit 2,8 bzw 3GHz. Der P4 hat jetzt deutliche Vorteile.
Ich glaube allerdings wenn single precision Datentypen im SIMD Modus auf den 128bittigen SSE2 Registern angewendet wird, was dann 4 32Bit Recheneinheiten entspricht, wird der Opteron sehr viel schneller als der Athlon XP sein, wenn dieser die x87 Einheit verwendet. Leider schreibt sowohl CB als auch theinquirer.net nichts über die verwendeten Datentypen. Gegen den P4 kann allerdings ein Opteron aufgrund der geringeren Frequenz nichts ausrichten.

 

[Anonymous]

Man kann einfach nicht ein einziges Programm nehmen und dann pauschal sagen, daß dieser oder jener Prozessor hier oder da besser ist.

Als der P4 rausgekommen ist, hatte SiSoft Sandra auch noch keine SSE2 Unterstützung und alle sagten man ist das Teil lahm. Warum sollte SiSoft Sandra den Opteron den gleich erkennen? In der c't haben die auch drauf hingewiesen, daß nicht jede Software automatisch die SSE2 Einheiten des Opteron voll nutzen kann.

Fakt ist, daß wenn die SSE2 Einheiten des Opteron gut genutzt werden er trotzdem weit schneller ist als ein P4 bei gleichem Takt.

 

[Anonymous]

@32

Es gibt keine SSE2 Register ... SSE1 und SSE2 benutzen die selben 128 bit Register.

SSE1 = 4x32bit
SSE2 = 2x64bit
So das du davon ausgehen kannst das double precision Datentypen verwendet wurden ... ansonster waer es ja SSE1.

@33
Warum sollte es SSE2 nicht gleich erkennen.
Ob eine CPU SSE2 beherscht kann man ganz einfach ermitteln indem man die Antwort des CPUID Befehls auswertet.
Und das ist beim Opteron der selbe Flag wie beim P4.
Der Banias hat aus SSE2 und ist kein P4 ... kann mich nicht erinnern jemals gelesen zu haben das Software das SSE2 nicht richtig erkennen kann.
Und wenn das SSE2 des Opterons nicht Befehlsmaessig identisch mit dem der Intels ist ... dann wuerde ueberhaupt keine SSE2 Appliktion laufen die entspechende Befehle nutzt.
Aber das ist nunmal nicht der Fall.

Und wenn der bisherige SSE2 Code nicht optimal auf dem Opteron laeuft ... welcher Compiler soll das Problem den bitte beheben ?
Der von Intel mit Sicherheit nicht, was schlecht ist das er mit Abstand den schnellsten Code erzeugt.
Der GCC wird sicher den Code Opteronfreundlich gestalten nur waer es mir neu das Windowsprogramme mit den GCC compiliert werden.
Nicht zu vergessen das auch der GCC dem Intelcompiler nicht das Wasser reichen kann was die Geschwindigkeit des erzeugten Codes betrifft.
Das kann man den GCC auch nicht vorwerfen den immerhin gibt es ihn ja fuer fast jede Platform.
Bleibt dann noch der MS Compiler ... nur der kommt auch nicht an den Intelcompiler ran.
Die letzte Moeglichkeit ist es per Hand SSE2 Code zu schreiben ... aber das werden mit Sicherheit nur wenige tun.
Es ist toll das AMD SSE2 implementiert und sogar die Anzahl der SSE Register verdoppelt, nur sollte man vielleicht langsam mal dran denken auch nen eigenen Compiler raus zu bringen der dann auch genau wie bei Intel optimalen Code erzeugt.

Allerdings schlaegt sich der Opteron auf den nicht Akiba2go Benchmarks hervorragend und das sogar bei Sandra, welches bei Akiba2go katastrophale Werte fuer den Opteron geliefert hat.
Darum wuerd ich mal Abstand von der Therorie nehmen das es nur an der Software liegen muss.

 

[Anonymous]

Es gibt sicher nicht allzuviele Anwendungen, in denen ein XP2600+ einen P4 2,8 schlägt. So ist es doch um so erstaunlicher, dass die schwächere CPU in einer Anwendung, die zudem noch auf SSE2 - also P4 - optimiert ist, um immerhin 12,6% versägt.
Hier frage ich mich eher, ob statt dem Opteron nicht vielmehr SSE2 selbst das Problem ist, oder vielmehr ein Marketinggag, der sich als heisse Luft entpuppt.
Wie schnell ist der P4 hier ohne SSE2 ?

 

[Anonymous]

@hapelo

Naja beim Athlon XP wird sicherlich SSE1/3Dnow mit verwendet worden sein.
Das bedeutet dann aber auch das der Athlon mit 32bit Gleitkommazahlen und der P4 mit 64bit Gleitkommazahlen gerechnet hat.
Man angeommen so ein 128bit SSE Register wird bei SSE1 und SSE2 gleichschnell durchgerechnet.
Dann haette das SSE1 die doppelte Anzahl an Ergebnissen im vgl zu SSE2 vorzuweisen ... allerdings hat mit niedrigerer Genauigkeit.
Ganz so wirds zwar nicht sein aber ich koennte mir doch vorstellen das SSE1 schneller als SSE2 ist.
Oder der SSE2 Code ist halt doch nicht so optimal wie er sein sollte.

Nachdem was ich bisher zum P4 und SSE2 gelesen habe ist der P4 mit SSE2 ein ganzes Stueck schneller als mit seiner FPU.
Grad bei solchen Multimediasachen.

 

[Anonymous]

Der hat warscheinlich nur SSE2 aktiviert als deaktiviert und hat das nicht gemerkt *lol* Oder die Funktion wurde einfach verdreht

 

[Anonymous]

@34 (raiden)

Das sich SSE und SSE2 ein und dieselben Register für ihre Berechnungen teilen ist schon klar. Trotzdem gibt es Single Precision SSE2 Befehle. Währe auch unsinnig wenn's anders währe.

Wo wir gerade davon reden: Weiß einer von euch wie man per CPUID Befehl die Prozessorstrings auslesen kann bzw. in welche Register die "chars" zurückgeschrieben werden?