Opteron Seti@Home-benchmarks

De mensen van AMD Zone wisten hun handen te leggen op een AMD Opteron-processor en hebben deze processor aan een benchmark met het distributed computing-programma SETI@Home onderworpen. Het draaien van deze benchmarks leverde echter nog enkele problemen op: Zo had de schrijver van het artikel geen rekening gehouden met het verschillen in grootte en in "zwaarte" van SETI@Home workunits. Een oplossing vond men door de SETI@Home-benchmarktool van ArsTechnica te gebruiken. Doordat met dit programma slechts één workunit wordt getest, neemt de totale betrouwbaarheid van de test echter wel iets af.

De schrijver legt dan ook vooral de nadruk op het feit dat de test puur als een indicator voor het verschil tussen 64bit- en 32bit-processors moet dienen. Op een MSI K8D Master-F moederbord wordt een AMD Opteron 244 (1,6GHz) geprikt, waarna men de recenste stabiele versie van SuSe en de SETI@Home 3.08 linuxclient gebruikt om te testen. Zowel de x86-64 als de i686-versie van het programma worden gebruikt om te testen. Een AMD Athlon XP 1800+ wordt ter indicatie meegetest.

Opvallend is dat uit de test blijkt dat de x86-64 versie langzamer is dan de i686-versie. Een verklaring hiervoor noemt de schrijver van het artikel de mogelijkheid dat SETI@Home geen SIMD-instructies gebruikt. De schrijver durft zelfs te stellen dat SETI@Home waarschijnlijk zeer weinig veranderingen heeft toegepast in de code ten opzichte van de i386-versie. Dit om de resultaten accuraat te houden en de versies beter op elkaar af te stemmen. Tot nu toe heeft de schrijver echter nog geen SETI@Home-medewerker kunnen bereiken om hier commentaar op te kunnen geven.

Reacties (22)

[TheCameleon]

Ik zal wel gek zjin hoor maar kan iemand mij nou uitleggen wat hier het idee van is..

Als ik het goe begrijp begint men een test om de opteron te testen. Dan blijkt de test überhaupt al; niet correct te zijn en word het doel aangepast om dan maar het veschil tussen 32- en 64 bit processoren in het algemeen te laten zine. En dan is het resultaat zo'n beetje 180 graden de verkeerde kant op en ligt het aan de "benchmark" en dient de test opeens om de benchmark te testen.

Verbeter me alsjeblieft (anders had deze post ook geen nut) en vertel me ff hoe het hier nou echt zit..

[mcB]

1. De opteron 64 bit wordt getest.
2. Test blijkt niet te werken wegens onvoorzien probleem
3. SETI test programma wordt gedraaid
4. Scores worden vergeleken met de opteron 32 bit en de Athlon XP.

Het is helemaal geen test om het verschil tussen 32 bit en 64 bit te laten zien. Het is een benchmark. Benchmarks hebben verschillende data nodig om de resultaten tegen elkaar uit te zetten, in dit geval de 3 genoemde procs.

Wanneer blijkt dat de uitkomst niet is zoals verwacht/gehoopt wordt er dieper in gegaan op de oorzaak ervan.

Prima test naar mijn mening, al zou het mooi zijn geweest als een opteron 64 bit geoptimaliseerde seti-client gebruikt kon worden.

[The Third Man]

Ik heb een tijdje terug ook een roddel gelezen dat de ontwikkelaarst van s@h opzettelijk een bug in het programma laten zitten, die ervoor zorgt dat de processorcache nét niet gebruikt kan worden, doordat de datablokken net 1 KB te groot zouden zijn.

Die bug was op een bepaald moment ontdekt maar de ontwikkelaars zouden hebben geweigerd er iets aan te doen aangezien "ze het nu al te druk hadden qua dataverkeer".

Als ze die policy over het algemeen zouden gebruiken zou dat ook kunnen verklaren waarom er ook geen optimalisaties voor 64 bit processoren zijn geïmplementeerd.

Slechte zaak eigenlijk, ze benadrukken zelf dat het dé nuttigste oplossing is om je idle-cycles te gebruiken, terwijl je dan alsnog gedeeltelijk voor Piet Snot staat te rekenen.

EDIT
Bron reeds gevonden: http://www.jc-news.com/pc/parse.cgi?distributed/seti
Lees alinea 4!

[Kwai_gon_jinn]

Daar bij verbruikt het ook onnodig veel resources die eigenlijks niet nodig zijn.
Maar veel over de S@H clients kunnen we niet zeggen. Aangezien het niet opensource is (lijkt me ook logisch.. dan zou net zoals bierings zei teveel afwijkende resultaten ontvangen).

S@H werd laatst toch nog gefinanceerd, gaan ze daarmee ook hien clients voor deze opteron proc's optimizen? Naar mijn gevoel doen ze nog niks aan om de ook nog de 64-bit versie te coden..

Ben benieuwd wat de opteron nog meer "benchmark" resultaten kan behalen.

edit:
las link net pas later.. thx voor de link Lekkere Kwal

[Remus]

SETI kreeg extra geld, maar SETI != SETI@home

[Ploink]

Dit verbaast me niks. Een paar jaar geleden schreeft ik een geoptimaliseerde FFT in i386 assemly in een delphi unit. Toen ik dit vergeleek met de FFT snelheid van de seti client was mijn conclusie dat dit programma zeker 10x zo snel zou kunnen. De manager van s@h antwoordde op mijn email dat ze geen interesse hadden omdat ze hun code in C schreven. Vervolgens hoorde ik van anderen geruchten dat ze al moeite hadden met het aanleveren van de work units en dat daarom de software zo traag is.
Net als elk bedrijf gaat het bij seti en s@h om winst. Als ze hun zoek capaciteit echt zo hoog maakten zouden ze alleen maar bewijzen dat ze niks vinden...
[edit][quote]
SETI != SETI@home
[/quote] ....gewijzigd.

[High Quality king]

//offtopic weet je ook waar je die versie van seti kan vinden die recources wel effectief gebruikt ?

//ontopic
kan het niet zo zijn dat de 32 bit modus van de x86-64 gewoon sneller is als de 64 bit, omdat ie dan 2x 32 bit tegelijk kan verwerken ofzo. En dat 64 bit alleen handig is om te ondersteunen.

Zou kunnen zijn dat ik gewoon aan het ijlen ben n00b ben

[Elephtera]

als ik het goed begrijp kan het dus zo zijn dat die seti@home clients allemaal veel sneller zouden moeten kunnen werken? waarom doen ze dat niet dan?

[bierings]

om de theoretische kans van verschillende uitkomsten door verschillende code buiten de deur te houden.

[VisionMaster]

Lezen is kunst

Een verklaring hiervoor noemt de schrijver van het artikel de mogelijkheid dat SETI@Home geen SIMD-instructies gebruikt. De schrijver durft zelfs te stellen dat SETI@Home waarschijnlijk zeer weinig veranderingen heeft toegepast in de code ten opzichte van de i386-versie.

[Elephtera]

ik bedoel dus dat als ze die SIMD instructies wel zouden gebruiken seti sneller zou moeten kunnen. of vergis ik me daar dus in?

[Verwijderd]

De schrijver durft zelfs te stellen dat SETI@Home waarschijnlijk zeer weinig veranderingen heeft toegepast in de code ten opzichte van de i386-versie.

Laten we hopen dat de schrijver gelijk heeft, anders is dit wel ongoochelend .
Maareuh ... gaat het om een 64bits SuSE (dus gecompiled met 64bit optimalisaties) of gewoon een standaard 32bits? Dat zou ook wel eens een verschil kunnen maken. Of vergis ik me?

[arjankoole]

Maareuh ... gaat het om een 64bits SuSE (dus gecompiled met 64bit optimalisaties) of gewoon een standaard 32bits? Dat zou ook wel eens een verschil kunnen maken. Of vergis ik me?

het gaat om een volledig 64-bits SuSE, en om een Seti die niet echt verder gaat dan 32bits code.

het OS kan zo goed zijn als je het maakt, maar als de applicatie dan gewoon in 32bit mode draait ga je het verschil goed merken.

maar ik kan het SETI moeilijk kwalijk nemen dat ze niet teveel af willen wijken van de code., een altijd identieke uitkomst is heel belangerijk.

[Verwijderd]

Op een MSI K8D Master-F moederbord wordt een AMD Opteron 244 (1,6GHz) geprikt

Euh.. een opteron 244 is toch echt een 1.8GHz hoor?

[Sir_Killalot]

Klopt

http://www.tweakers.net/nieuws/26630

De 240 = 1.4 GHz en de 242 = 1.6 GHz.

[Jeldert]

Als ze echt de CPU wouden testen konden ze beter het programma van Distributed.net ( ) kunnen gebruiken. Aangezien die bijna geen geheugen nodig heeft, en de snelheid van SETI@Home veel meer van het geheugen afhankelijk is.
En als je dan de benchmark functie van de gebruikt op verschillende CPU's (vergelijkingsmateriaal genoeg) dan heb je een veel beter beeld van de kracht van de CPU.

[mcB]

Ik ben het niet met je eens.
De koe van Distributed.net gebruikt voor RC5 de block-rotate instructie op een processor.
AMD's (bijv XP) hebben deze functie in de hardware ingebakken zitten. Intel daarentegen heeft deze instructie niet in de CPU ingebakkan (P4), maar doet het softwarematig.

Resultaat: de AMD XP's zijn veel sneller dan de Intel p4's.
Om hieruit te concluderen dat de AMD in zn geheel sneller is dan de Intel,.... Dat gaat er bij mij niet in.

[lucid]

Een kleine verklaring staat al in de tekst. De resultaten zijn beter op elkaar af te stemmen.
Algorithmes , 32/64 bit. Kan me voorstellen dat ze daar even over moeten puzzelen

Overigens apart om een processor zo aan de tand te voelen, zelf het artikel neemt het niet helemaal serieus.

Er zijn vast meer E.T. out there dan je kunt vermoeden. Kijk maar eens om je heen in de tram

[Verwijderd]

Die opteron kon toch full-speed 32-bit code draaien? Dan zou die dus, geoptimaliseerd voor 64-bit of niet, altijd beter moeten werken.

Kan iemand dit uitleggen?

[GoBieN-Be]

Zo is het altijd met benchmarks, denk aan de tests van Apple G5 , waar ze beweerden nu de snelste te zijn.

- Welk OS wordt er gebruikt ?
- In welke taal werd de benchmark software geschreven ?
- Welke Compiler voor de benchmark software ?

enzv ...

Als je cross platform wil benchen moet je met veel rekening houden.

Het enige zinvolle van deze test kon geweest zijn om Opteron vs Xeon vs Itanium te doen. Dan kon je misschien het verschil zien in native 32 bit kunnen draaien en 32 bit moeten emuleren.

[d-motion]

Eerlijk gezegt ben ik benieuwd wat de performance wordt!