AMD publiceert Xeon Woodcrest-benchmarks

Door Wouter Tinus, woensdag 6 september 2006 04:35, 38 reacties • Feedback
Bron: SPEC

Het lijkt erop dat AMD in zijn labs druk aan het testen is met de Xeon Woodcrest, mogelijk om zwakke punten te ontdekken of te evalueren welke features van het ontwerp interessant zijn om in de eigen architectuur op te nemen. Hoewel het natuurlijk dom zou zijn om de ogen te sluiten voor de producten van de concurrentie (Intel speelt op zijn beurt bijvoorbeeld ook met Opterons), komt het niet vaak voor dat de resultaten van zulke tests ook daadwerkelijk gepubliceerd worden. In dit geval lijkt AMD echter een reden te hebben gevonden om dat wel te doen: het stuurde zijn bevindingen in SPECjbb2005 op voor publicatie zodat iedereen voor zichzelf kan zien wat er aan de hand is.

Het euvel dat AMD wereldkundig wil maken zit in de agressieve prefetchers van Woodcrest, die in tegenstelling tot wat Intel beweert helemaal niet zo 'veilig' zijn om te gebruiken. Het valt achteraf gezien wel op dat de beste SPECjbb2005-scores (van onder andere Fujitsu, IBM en Dell) zonder prefetchers zijn gedaan, maar daarmee was nog niet duidelijk wat de score zou zijn met de standaardinstelling - waarbij de prefetchers zijn ingeschakeld. De test van AMD laat zien dat Woodcrest een prestatieverlies van 14% incasseert als de prefetchers worden ingeschakeld, een niet verwaarloosbaar verschil. Helaas voor AMD is de 3,0GHz Woodcrest zelfs met prefetchers ingeschakeld nog 24% sneller in deze test dan de 2,8GHz Opteron.


SPECjbb2005

IBM	Xeon	3,0GHz		114941

Dell	Xeon	3,0GHz		102099

Fujitsu	Xeon	3,0GHz		100590

AMD	Xeon	3,0GHz		99068

AMD	Xeon	3,0GHz		84968

AMD	Opteron	2,8GHz	-	68533

Mogelijk is SPECjbb2005 een uitzondering, maar het zou evengoed zo kunnen zijn dat het prefetchen net als HyperThreading een feature is die met enig beleid ingezet moet worden, in plaats van deze blind ingeschakeld te laten staan.

Reacties (38)

0 Ron.IT
6 september 2006 06:02

Had liever gezien dat AMD meer personeel op het K8L project had geplaatst, zodat we sneller een daadkrachtig antwoord kunnen verwachten.

Ik wordt wel een beetje moe van deze specifieke testen, en AMD is daar echt niet de enigste in. Vanuit een marketings standpunt begrijp ik het wel, en gelukkig is er voor ons als Tweaker zijnde genoeg onafhankelijke websites die wat realistischer testen, maar het wordt er allemaal niet gemakkelijker op. En de tijd tussen fabrieks benchmarks en die van sites zoals AnandTech, HardOCP en Tweakers.net zelf is vaak veel te lang.

Toepassingen worden ook steeds specifieker, mijn eigen doelgroep is vaak veel meer geïntereseerd in video-bewerking snelheid, waarbij de MPEG4 prestaties van benchmarks een redelijke indicatie zijn. En voor bedrijven zal de SPECjbb2005 wel een redelijke indicatie zijn voor hun programma's, maar ik zie dat dan toch persoonlijk liever in combinatie met een goede SQL test. Probleem is dan inderdaad dat veel meer systeem componenten een invloed op de prestatie hebben, dus de SPEC testen blijven een goede CPU indicatie, maar moeten dan wel in een groter geheel geplaatst worden en niet altijd zo uniek in één enkele test om er marketingtechnisch beter voor te staan.

Auteur +3

Wouter Tinus
@Ron.IT • 6 september 2006 06:54

SPEC testen blijven een goede CPU indicatie, maar moeten dan wel in een groter geheel geplaatst worden en niet altijd zo uniek in één enkele test om er marketingtechnisch beter voor te staan.

Ik zou niet weten op welke manier het goed zou zijn voor de marketing om te laten zien hoe een goedkopere, zuinigere Xeon met sub-optimale instellingen nog steeds een ruime overwinning haalt op je eigen topmodel. Dit lijkt me meer iets wat technici onder elkaar willen delen om het nadeel van (te) agressieve prefetchers te laten zien.

kahm-jai
@Ron.IT • 6 september 2006 08:42

"Had liever gezien dat AMD meer personeel op het K8L project had geplaatst, zodat we sneller een daadkrachtig antwoord kunnen verwachten."

Beetje nonesense, hoeveel mensen heb je nodig om 1 bench te draaien...

Ik denk dat met de K8L in het achterhoofd dat ze gaan kijken wat aggressieve prefetchers voor hun zouden betekenen.

Het is beter om te weten wat de effecten zijn van alle veranderingen en dan alleen de beste veranderingen te implementeren. imho

+2 r.koppelman
@Ron.IT • 6 september 2006 08:52

Ik ben hier ander zeer blij mee. Als je onderste uit de kan wil hebben moet je ook de zwaktes van een architectuur kennen. En specifieke zwaktes zal Intel ons niet vertellen. Dus lang leve de concurentie.

+1 Zamman
@r.koppelman • 6 september 2006 10:25

Die waren er anders wel uitgerold via andere technici van bijv IBM, DELL enz, via techsites of via medetweakers. AMD doet gewoon onderzoek om te kijken wat de Xeon snel maakt en of zij iets soortgelijks kunnen implementeren om een zelfde resultaat te behalen.

Als je dan over iets struikelt dat niet goed blijkt te zijn bij de concurrent, wat je wellicht als slecht kan afschilderen, is dat helemaal leuk. Je zegt dat intel slechte prefetchers heeft, en de mensen onthouden intel en slecht, want prefetchers is zo'n moeilijk woord.

Ik heb zelfs ten tijde van de Pentium 2 nog mensen horen zeggen dat ze liever geen intel hadden i.v.m. de FPU bug.

Nu denk ik niet dat dit zo'n dramatisch effect zal hebben als de FPU bug, zeker omdat de prefetchers ook uit te schakelen zijn en het geen consumenten procs betreft.

+2 KRIS FRANSSENS
6 september 2006 09:40

Heel veel fantalk weer hierboven.....
AMD werkt aan dit moment koortsachtig om de K8L tijdig klaar te krijgen.
Waarom zouden ze zelf gaan testen of agressieve prefetchers zoden aan de dijk brengen als Intel al een cpu heeft dat die techniek toepast.
AMD publiceert nu dit en kan dan achteraf makkelijk zeggen : "uit testen is reeds gebleken dat het niet de moeite loont de chip complexer te maken".
En gelijk hebben ze wel. Agressieve prefetchers is iets wat zijn tijd vooruit is. Net als HT destijds. Beide fabrikanten hebben de overstap op multicore cpu's gemaakt en weldra zullen we de nodige ondersteuning zien in de vorm van multithreading apps. Met een Pentium 4 met HT kon je deze best uit laten staan als je niet met 3DS max, photoshop of iets anders van die categorie werkte. HT was toen dus voor veel gebruikers meer een gadget dan een werkelijke verbetering (in vele gevallen gingen de prestaties er zelfs op achteruit als HT ingeschakeld stond). Beetje hetzelfde verhaal met agressieve prefetchers. Maar Intel kan er nu wel ervaring mee opdoen en software ontwikkelaars kunnen code schrijven die nog meer uit de CPU's kan halen zonder dat het voor de gebruikers noodzakelijk is nu reeds er effectief gebruik van te maken.

Luxx
@KRIS FRANSSENS • 6 september 2006 11:05

Waarom zouden ze zelf gaan testen of agressieve prefetchers zoden aan de dijk brengen als Intel al een cpu heeft dat die techniek toepast.
AMD publiceert nu dit en kan dan achteraf makkelijk zeggen : "uit testen is reeds gebleken dat het niet de moeite loont de chip complexer te maken".

Bedenk je wel dat de ene agresssieve prefetcher de andere niet is. Een andere implementatie ervan zou zomaar veel betere(of slechtere) resultaten kunnen geven.

mieJas
@KRIS FRANSSENS • 6 september 2006 10:12

Omdat het bij Intel niet optimaal werkt, wil niet zeggen dat de architectuur van AMD er geen profijt van kan hebben (64bit, dualcore,...). Kan ook zijn het weer zo'n haastklus was om nog iets extra te hebben om mee naar buiten te komen.

+1 KRIS FRANSSENS
@mieJas • 6 september 2006 11:09

Aan je reactie te zien lijkt het me dat je geen idee hebt waarover het eigenlijk gaat.... die agressieve prefetchers.
Ik zou een google aanspreken. Dan vind je na even zoeken terug dat het prefetchen van data een vrij complex iets is wat voor problemen zorgt als de data die het softwarepakket door de processor niet genoeg intelligentie bevat wat betreft het prefetchen van data.
Ik weet de link niet meer precies maar er is een artikel van Johan De Gelas terug te vinden over de noodzaak aan een combinatie tussen hard- en software prefetchen. Intel heeft in Woodcrest een algoritme ingebouwd dat op een lager niveau dan voorheen gaat filteren. Echter de data die naar de CPU komt is niet gestructureerd genoeg om deze handelingen snel en efficiënt uit te voeren. Dat leidt dus tot meer vertragingen dan het prefetchen op een hoger niveau (dus minder filteren).
Het gaat in feite erom dat men het verkeer tussen de CPU en het geheugen wil filteren zodat er alleen te verwerken data naar het geheugen en terug moet waardoor de effectieve bandbreedte (dus het deel van de theoretische dat voor berekeningen gebruikt wordt) groter wordt. Momenteel gaat er nog veel te veel nietszeggende data van de cpu naar het geheugen en terug.

0 sneakers
6 september 2006 08:39

Leuke benchmarks hoor (draai zelf ook 4 xeon woodcrests), maar was dit niet 2/3 dagen geleden ook al bewezen op tweakers.net zelf?

AMD vist een beetje achter het net door de concurrent beter te bewijzen en dat ook nog eens openbaar te maken aan iedere computer freak op aarde

Kennen ze het woord m-a-r-k-e-t-i-n-g bij AMD niet ofzo?

+3 humbug
@sneakers • 6 september 2006 09:04

de review op tweakers ging over databases (MySQL en PostgreSQL) en dus niet over J2EE oplossingen. Daarnaast werd er in die review wel geexperimenteerd met Hyperthreading maar niet met de prefetchers. Dus het is wel degelijk nieuws dat sleutelen aan de prefetchers snelheidswinst kan opleveren.

Aan de andere kant heeft Intel ook de mogelijkheden daarvoor ingebouwd, dus echt verrassend is het nu ook weer niet

0 MMORPG-addict
6 september 2006 06:53

Wie gelooft er tegenwoordig nog in Bench-marks?

Ze zijn zo belangrijk voor de MArketing geworden dat alles geoorloofd is.

Auteur +2

Wouter Tinus
@MMORPG-addict • 6 september 2006 06:58

Alle SPEC-tests moeten voldoen aan een stricte set regels waarvan de naleving door een onafhankelijke commissie wordt beoordeeld. Betrapt worden op bedrog zou dodelijk zijn voor de reputatie van een fabrikant, omdat klanten ze dan niet meer kunnen vertrouwen. Het is dus niet alsof je zomaar iets kunt verzinnen.

+1 twixxie
@MMORPG-addict • 6 september 2006 07:31

AMD laat toch ook netjes zien dat de woodcrest wel beter is dan de opteron
denk jij dat ze beetje valse benchmark resultaten publiceren.
dan krijgen ze rechtzaken en zoals wouter tinus zegt vinden je klanten dat ook niet echt leuk

sus
6 september 2006 08:46

Raar dat AMD deze test naar buiten brengt? Juist niet! Ze tonen nu aan dat die Xeon's helemaal niet zo goed zijn als Intel beweerd, immers ze presteren standaard 14% minder goed.

Dat heet dus marketing, omdat AMD dit nu in zijn opteron beter kan doen, en daar ook mee kan adverteren. Nu is slechts het bewijs alvast naar buiten gebracht

Shaidar
@sus • 6 september 2006 08:51

ze tonen aan dat die Xeons helemaal niet zo goed zijn als intel beweerd ... en dan nog zijn ze sneller dan AMDs topmodel.

Als dat marketing is ... dan is dat héle slechte marketing.

bat266
@Shaidar • 6 september 2006 09:48

AMD laat door deze test te publiceren zien dat de prefetchers (voolopig) niet werken. AMD ontkracht zo de functionaliteiten van de xeon. De xeon heeft nu dus geen voorsprong meer (in deze test) door het gebruik van prefetchers die AMD niet gebruikt. Zo kan Intel deze functionaliteit minder gebruiken voor promotie.

Ik denk dus dat het redelijk to goede marketing is. AMD heeft nu op dit moment een achterstand, daar is (voorlopig) niks aan te doen.

0 JJKiers
@Shaidar • 6 september 2006 18:30

Elke aandacht is goede aandacht, zolang je naam maar goed gespeld is.

+1 MadNeo
6 september 2006 08:43

Lijkt me nu niet echt slim van AMD.
Op deze manier gooien ze hun eigen ramen in

Hiermee tonen ze duidelijk aan dat een intel processor (met dezelfde chipsnelheid) duidelijk beter is.
Sterker nog, als ik als klant zou moeten kiezen tussen AMD en INTEL, zou ik na het zien van deze resultaten zeker intel kiezen.

maratropa
@MadNeo • 6 september 2006 10:07

Bedrijven kiezen voor hardware op basis van applicatie snelheid. Voordat een beetje bedrijf een flinke hoop servers koopt, testen ze eerst flink.

Idereen weet onderhand wel dat de woodcrest erg snel is, dat mag ook wel voor een chip die jaren jonger is dan de opteron. In dat licht doet de opteron het nog heel erg goed.

Zelf nu zijn er nog applicaties die gewoon beter draaien op een opteron systeem.

0 humbug
@maratropa • 6 september 2006 10:24

Het idee dat een "jaren jongere" chip in 1 keer beter presteert dan zijn concurrenten is niet helemaal juist. Die concurrenten zijn in verschillende revisies geoptimaliseerd terwijl er bij een nieuwe chip misschien meer groeipotentieel is maar dat potentieel zeker niet direct beschikbaar hoeft te zijn.

Zo hadden de Pentium Pro, Athlon, P4 en de Athlon64 allemaal moeite om in het begin een duidelijke voorsprong te nemen op de oudere ontwerpen. Eigenlijk is deze Core 2 Duo de eerste chip sinds lange tijd die vanaf zijn introductie zowel op prijs/prestatie als de pure performance een flinke afstand neemt.

Ik ben benieuwd of de dan 2 jaar jongere K8L in 2008 (?) er in slaagt Intel net zo'n hoofdpijn te geven als dit ontwerp AMD nu geeft. Maar ik reken er niet op.

Trouwens, welke applicaties draaien beter op opteron systemen? Ik ken ze namelijk niet. Maar net zoals er nu nog steeds applicaties zijn die beter presteren op Xeons/P4s dan op Athlon 64s en Opterons zullen ze er vast wel zijn.

maratropa
@humbug • 6 september 2006 11:06

performance-wise is er toch niet zo heel veel gereviseerd aan de opteron. Netburst suckte gewoon

Iig doen bijvoorbeeld wetenschappelijk simulaties het soms erg goed op opterons.

Cookie
@humbug • 6 september 2006 19:47

Trouwens, welke applicaties draaien beter op opteron systemen? Ik ken ze namelijk niet.

Sciencemark is zo ongeveer hét programmaatje dat de K7/K8-chips helemaal op het lijf geschreven lijkt. De ontwerper ervan is daarna bij AMD mogen komen werken, wat hier en daar wenkbrauwen deed fronsen, maar die carrière move schijnt absoluut niet met het eerstgenoemde te maken te hebben, dus ik wil hier ook niet suggereren dat die twee dingen wel met elkaar te maken hebben. Anywho, iedere AMD-minnende reviewer draait graag Sciencemark

Auteur +2

Wouter Tinus
@aval0ne • 6 september 2006 12:36

vergeet te vermelden dat de op het AMD systeem meerdere instances van JVM draaien en op het intel systeem maar 1

Meerdere instanties draaien wordt zoals pyotr al zegt gedaan om de prestaties te verhogen, in het geval van de Opteron om optimaal gebruik te maken van NUMA. Het is dus geen nadeel, eerder een voordeel.

Iemand die gezien heeft dat de Opteron wel hogere scores (125011 bijvoorbeeld) haalt dan de Xeon maar dat die resultaten toevallig weer niet vermeld worden?

Heb je ook gezien dat dat met vier processors is gehaald is in plaats van met twee? Als we zo gaan beginnen kan ik er ook een quad Xeon MP-score bij betrekken (178201 bijvoorbeeld).

AMD heeft helemaal niets gepubliceerd

Ze hebben het naar SPEC opgestuurd voor publicatie. Dat het niet op AMD.com staat wil niet zeggen dat zij niet degenen zijn die het wereldkundig hebben gemaakt, het is immers niet verplicht om die cijfers openbaar te maken. Dat ze identieke configuraties zowel met als zonder prefetching hebben opgestuurd lijkt me een duidelijke indicatie dat men dáár de aandacht op wilde vestigen, want normaalgesproken sturen fabrikanten alleen de beste resultaten die ze kunnen krijgen op. Het is natuurlijk niet de aandacht van het grote publiek die ze hiermee krijgen, maar wel die van technisch onderlegde mensen.

Een artikel van WT dat Intel 10% van zijn personeel gaat ontslaan kunnen we niet verwachten natuurlijk. Bad Intel PR.

nieuws: Bevestiging: Intel schrapt 10.500 banen - dat had iemand anders dus al gedaan. En hoe goed is de "PR" voor Intel trouwens dat hun stoere nieuwe prefetchers 14% lagere prestaties opleveren in deze test? Ik begrijp dat het leven van een AMD-fanboy vandaag de dag moeilijk is, maar jij ziet echt spoken.

+1 pyotr

@aval0ne • 6 september 2006 12:08

Niet helemaal vergelijkbaar, die hogere Opteron scores werden gehaald met 4 cpu's (8 cores). Dat is natuurlijk wel een voordeel van de Opteron t.o.v. de Woodcrest, AMD ondersteunt tot 16 cores in 1 server, de Woodcrest gaat (bij mijn weten) maar tot 4 cores.

Aan de andere kant, echt brute perfomance op de J2EE benchmark wordt gehaald door gewoon een heel rack (blade)servers neer te zetten

Meerdere instances van de JVM draaien wordt over het algemeen gedaan om de performance te verbeteren, bijvoorbeeld omdat de gebruikte (32bit) JVM maar max. 4GB kan adresseren en er (veel) meer geheugen in je machine zit.

Cookie
@aval0ne • 6 september 2006 13:07

Een artikel van WT dat Intel 10% van zijn personeel gaat ontslaan kunnen we niet verwachten natuurlijk. Bad Intel PR

Waarom zou WT dubbelposts schrijven? De Tweakers.net-redactie besteedt ruimschoots aandacht aan de reorganisatieberichten rond Intel:

nieuws: 'Reorganisatie Intel kan 16.000 medewerkers treffen'
nieuws: Intel plant ontslag duizend managers
nieuws: Intel verkoopt afdeling 'Media and Signaling Business'
nieuws: Bevestiging: Intel schrapt 10.500 banen

Als je daarnaast ietsiepietsie verder kijkt dan de neus lang is zou je zien dat WT ook 'AMD-PR-berichten' schrijft:

nieuws: Energiemeting van Core 2 Duo en Energy Efficient Athlon
nieuws: AMD verovert meer dan een kwart van de servermarkt
nieuws: AMD bouwt 3,2 miljard dollar kostende fabriek in New York
nieuws: AMD gooit dubbel socket in de strijd tegen Core 2

en last but not least:
reviews: AMD productietechniek: wie niet sterk is moet slim zijn

Dutch_Razor
6 september 2006 08:05

Dit klinkt gewoon weird

AMD publiceert Xeon Woodcrest-benchmarks

Edit: Als je erbij nadenkt is t net zoals:

Vice-president EA zegt dat Xbox 360 in prijs verlaagd wordt

+1 M600873
6 september 2006 08:21

Inderdaad, het is maar net wat je er mee gaat doen.
Een Bench-marks kan geheel anders uitvallen als je gaat monteren.
Laat het hele zooitje draaien met zware grafische progjes,
dan kan het weer anders zijn.

nAFutro
6 september 2006 08:23

Intel lacht zich rot nu, zelfs door AMD gebenchmarked met de minst snelste instelling voor die benchmark zijn ze nog koploper...

1 2 Volgende

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

AMD publiceert Xeon Woodcrest-benchmarks

Lees meer over

Gerelateerde content

Sorteer op:

Weergave:

Reacties (38)