SSE3-prestaties van nieuwe Opterons getest

AnandTech heeft kort gekeken naar de prestaties van de SSE3-instructies, waarmee de onlangs geïntroduceerde Opteron 252 is uitgerust. Met behulp van een tweetal benchmarks, die zowel voor SSE2 als voor SSE3 zijn geoptimaliseerd, werd gemeten hoe snel deze waren op een Opteron 250 (SSE2) en een Opteron 252. De Opteron 252 werd hiervoor op dezelfde kloksnelheid ingesteld als de Opteron 250 om het vergelijk zo eerlijk mogelijk te maken.

Als eerste is DivX 5.2.1 aan de beurt. Uit de resultaten blijkt dat het encoden van een videofile met SSE3 nauwelijks sneller is dan met SSE2. AnandTech heeft dit geverifieerd met andere video-encoders en ook deze toonden hetzelfde beeld. De tweede test die gedraaid werd is CPU Rightmark. Uit deze test blijkt dat de pure berekeningen zelf niet sneller zijn als er gebruik wordt gemaakt van SSE3-instructies. Wel blijkt code waarin gebruik wordt gemaakt van SSE3-instructies efficiënter te werken dan dezelfde code met SSE2-instructies. Het lijkt er dus op dat code met SSE3-instructies beter is te optimaliseren.

Met maar twee benchmarks is het nogal moeilijk om met een conclusie te komen. Helaas zijn er nog niet veel geschikte testen die gebruik maken van SSE3-instructies. Voorzichtig hint AnandTech dan ook dat SSE3 voor de normale thuisgebruiker weinig zal brengen. De weinige toepassingen op dit moment met SSE3-instructies, video-encoders, worden er niet echt sneller van. Op het werkstation zouden SSE3-instructies wellicht wel voor een performanceboost kunnen zorgen, vanwege de betere resultaten in de synthetische benchmark CPU Rightmark.

Reacties (25)

[Verwijderd]

Op het werkstation zouden SSE3-instructies wellicht wel voor een performanceboost kunnen zorgen, vanwege de betere resultaten in de synthetische benchmark CPU Rightmark.

Als ik het goed lees geeft tweakers hiermee aan dat door de resultaten van een syntetische benchmark er wellicht een performanceboost is op een het werkstation?

Of course, for those who like to use lower cost Athlon 64 processors in cheaper workstations, there could be some advantage.

Als je het 1:1 probeert te vertalen, doe het dan goed. NFI maar ik kom tegenwoordig wel erg veel "losse pols" vertalingen tegen met erg veel eigen creatieve inbreng.

[Ralph Smeets]

Uit het originele artikel:

As far as physics and graphics go, the added instructions show potential in our synthetic test. For DCC, CAD, scientific, and other workstation software, the E4 stepping could offer a bit of a performance boost.

en wat schrijf ik:

Op het werkstation zouden SSE3-instructies wellicht wel voor een performanceboost kunnen zorgen, vanwege de betere resultaten in de synthetische benchmark CPU Rightmark.

Sorry hoor, maar ik schrijf dus echt niks anders dan AnandTech. Ik vat alleen twee zinnen samen in een zin.

[Verwijderd]

En door die zinnen samen te voegen trek je het verhaal uit zijn verband.

Jij zegt : De SSE3 instructies zorgen wellicht voor een performanceboost op het werkstation vanwege de betere resultaten in de syntetische benchmark.

Dus : Vanwege de resultaten zorgen de SSE3 instructies voor een performanceboost.

Artikel zegt : De SSE3 instructies tonen, door middel van een syntetische benchmark, aan dat ze workstations snelheidswinst kunnen bieden.

Dus : Door de SSE3 instructies zijn de syntetische resultaten beter en dus zorgen ze voor een performanceboost.

Dit klinkt als kommaneuken, maar is wel van belang.

[Verwijderd]

mug·gen·zif·ten
onovergankelijk werkwoord; muggenziftte, heeft gemuggenzift;
afleiding(en): muggenzifter

vitten op kleinigheden
betekenisverwante termen
hyperoniem:
zeuren
synoniem(en):
chicaneren, haarkloven, kommaneuken,
mierenneuken, spijkers op laag water zoeken

[Verwijderd]

For DCC, CAD, scientific, and other workstation software, the E4 stepping could offer a bit of a performance boost

Vertaald: De E4 stepping (zelf!, niet de nieuwe instructies!) kan een performance boost geven

Je schrijft zelf dat het door SSE3 komt, ook al betwijfel ik dat omdat die instructies praktisch onbruikbaar zijn voor de meeste workstationsoftware.

[mr_a]

Jullie vergeten could offer a BIT of a performance boost

Dat betekent los vertaal iets als "[theoretisch] is een beetje snelheidswinst mogelijk"

[noMSforme]

Het is getest met 'Windows XP SP2' ?
Een 32 bits OS op een 64 bits processor.
Ik kan in het artikel ook nergens achterhalen dat er werkelijk gebruikt is gemaakt van een build met SSE3 enabled.

Een flut test dus.

[Tomatoman]

Wat is daar mis mee? Als je een Opteron in een Windowsomgeving inzet is het tot dusverre automatisch 32-bits Windows. WinXP SP2 is dan een voor de hand liggende keuze. De vraag of de build is gedaan met SSE3 enabled is irrelevant; je kunt bij Windows immers niet voor een bepaalde build kiezen.

Het gebruik van SSE3 staat trouwens los van de vraag of het besturingssysteem 32- of 64-bits is, ongeacht of het om Windows of een Unixvariant gaat. In een standaard 32-bits programma kun je gewoon (64-bits) SSE3-instructies inzetten.

[Da_DvD]

Inderdaad een flut test (zoals de meest Anandtech tests de laatste tijd ).

Het schijnt dat bijv DivX ook op de P4 geen voordeel uit SSE3 haalt. Een slechte test om de SSE3 performance van de nieuwe K8 te testen!

Dat excuus in de conclusie slaat ook nergens op. Als je geen benchmarks kan vinden dan schrijf je toch geen review?

[CH4OS]

Het is getest met 'Windows XP SP2' ?
Een 32 bits OS op een 64 bits processor.

Dat maakt (volgens mij) niet eens uit, want de SSE3 instructies veranderen daar niet door, en de software moet ook 64bit instructies kunnen runnen, alvorens er voordeel uit te halen... Jij kan immers ook geen dingen gebruiken, waar jij het bestaan niet van af weet, wel dan?

[Verwijderd]

SSE3 instructies zijn makkelijker om mee te programmeren, maar niet sneller. Door datastructuren en verwerkingsvolgordes aan te passen kan je net zo goed SSE1/2 als SSE3 gebruiken. Een prestatieanalyse is dan ook vrijwel nutteloos. Enig verschil in performantie is niet toe te wijzen aan het al dan niet gebruiken van SSE3 maar de hogerliggende algoritmes.

[Verwijderd]

Ik weet niet wat je precies bedoelt, dus ik weet niet of ik het met je eens ben of niet.
Als je bedoelt dat SSE3 instructies niet sneller zijn dan SSE2, maar slechts de data 'andersom' (horizontaal vs verticaal) bewerken, en hierdoor soms handiger werken, maar dat je het algoritme ook om kunt keren... Dan ben ik het daar wel mee eens.

Als je bedoelt dat die 'omgekeerde' code altijd even snel is, dan ben ik het daar niet mee eens. Je verandert namelijk de patronen van de memory-accesses, en de ene variant kan cache-vriendelijker zijn dan de andere, dus sneller.
Verder is het niet altijd mogelijk om het algoritme om te draaien, omdat je de data op een bepaalde manier binnenkrijgt, of op moet slaan.
En dan is er natuurlijk het geval waarbij je delen horizontaal en delen verticaal moet processen... Zonder SSE3 kun je dat dus nooit optimaal doen.

Dus er is zeker prestatiewinst te behalen met SSE3, maar met een simpele recompile van de sourcecode kom je er inderdaad niet. Het algoritme moet aangepast worden, anders is de winst marginaal.

[Verwijderd]

ook helpt t niet echt dat je de beste optimalisatie krijgt voor sse2/3 als je de intel compiler gebruikt, en die doet net alsof een AMD processor geen sse2/3 aankan

[Verwijderd]

De compiler genereert gewoon code op de manier waarop je het aangeeft met de commandline switches.
Het maakt helemaal niets uit of je SSE2/3 ondersteuning hebt. Ik compileer ook wel eens SSE2/3 code met m'n Athlon XP. Ik kan het zelf wel niet draaien, maar dat maakt niet uit. Genereren kan ik het wel.

[Verwijderd]

Volgens mij kijkt dat ding gewoon of je cpu SSE2/3 ondersteunt en gebruikt die code aan de hand daarvan wel of niet. of je nou een AMD of intel cpu hebt.

[Verwijderd]

is er uberhaupt wel gekeken naar 't aandeel SSE instructies dat gegenereert is door de compiler?

met divx is geen verschil gemeten staat er bijvoorbeeld, maar hoeveel SSE3 instructies zijn er nou echt gebruikt en hoeveel SSE1/2 instructies waren er voorheen gebruikt? dit is zo'n ontzettend simplistische benadering dat 't niet bepaald wetenschappelijk te noemen is, laat staan dat je conclusies moet gaan trekken.

daarnaast zijn 't 10 extra instructies waar over gepraat wordt.. tis niet alsof SSE3 SSE1/2 vervangt, het vult slechts aan. je moet dan ook echt geen grote performance verbetering verwachten.

[Verwijderd]

is er uberhaupt wel gekeken naar 't aandeel SSE instructies dat gegenereert is door de compiler?

Lees de tekst: Met behulp van een tweetal benchmarks, die zowel voor SSE2 als voor SSE3 zijn geoptimaliseerd, werd gemeten hoe snel deze waren op een Opteron 250 (SSE2) en een Opteron 252.
De benchmarks zijn speciaal voor SSE2/3 ontwikkeld lijkt me.

[nAFutro]

Tsja vroger was MMX ook zoiets wat in het begin niet eens altijd sneller was, zelfde als SSE en SSE2.. Als je nu zoiets heb zonder deze instructieset dan kan het eigenlijk niet meer...
Het is gewoon iets voor de toekomst.. pas later komt het echte profijt ervan.

[_JGC_]

Waarom MMX zo revolutionair was, was omdat de Pentium MMX gewoon 2x zo grote L1 cache had en daardoor sneller was. Dit werd opgepikt in tests en samen met de reclame hype moest iedereen MMX hebben.
De implementatie van MMX was alleen enorm flut: MMX op de pentium deelde zn instructie units met de FPU en deze konden niet tegelijkertijd gebruikt worden. Om de ramp nog eens compleet te maken kostte het ook nog een hele zwik kloktikken om een unit over te schakelen tussen MMX en FPU mode.

[GoldenSample]

waarom is het plaatje van intel (zie links onder)

[BikkelZ]

Omdat SSE van Intel is?

[Olaf van der Spek]

Sinds wanneer leverts IBM PCs met Cells?

[Verwijderd]

Ookal is dit waarschijnlijk niet zichtbaar.

IBM maakt dan misschien niets voor de PC, de technologie staat. Ik wacht totdat AMD met een dergelijk concept komen