De nieuwste desktop-cpu's getest onder Linux

Uit welke componenten bestaat het ultieme Linux-werkstation? Op deze vraag probeert de reviewer bij Anandtech een antwoord te vinden, waarbij de nadruk ligt op het zoeken naar de juiste processor. Zowel AMD als Intel zijn met drie processors vertegenwoordigd. Naast deze zes processors, twee soorten geheugen en twee verschillende moederborden wordt er getest met SuSE 9.1 Professional. De configuraties zullen in de tests kernel 2.6.5-7.108 de sporen gaan geven. Voor de meeste benchmarks is HyperThreading uitgeschakeld omdat de meeste desktop-applicaties hier niet voor gemaakt zijn. Er zijn zowel 32-bits tests als 64-bits tests uitgevoerd, waarbij de laatsten draaiden op de twee 64-bits Athlons.

AMD Athlon 64 3500+ (Winchester, klein) Er worden veel verschillende tests gedraaid: onder andere met databases, rendersoftware, schaakprogramma's en encryptie. Daarnaast wordt er gekeken naar de resultaten met compilerende en synthetische benchmarks en de prestaties van de processors bij intensieve bewerkingen zoals bijvoorbeeld het zippen van bestanden. Aan het eind van de review wordt er nog even gekeken naar de verschillen tussen DDR1 en DDR2. In de verschillende tests blijkt er onder Linux weinig verschil tussen de twee soorten geheugen. De reviewer kan geen van beiden aanbevelen maar wijst wel op de prijsverschillen en de eventuele geschiktheid van het moederbord.

Suse Linux 9.1 In de meeste gevallen blijken de 64-bits applicaties beter te presteren dan de 32-bits tegenhangers. Net zoals bij het geheugen is er geen duidelijke keuze te maken bij de processors. Een aanschaf van één van de geteste processoren kan vooral gebeuren op basis van de aanschafprijs. Een duurder exemplaar heeft bijvoorbeeld meer nut als er gedacht wordt aan overklokken. De Pentium 4 560 en de Athlon 64 3500+ zijn de beste twee CPU's van deze review, waarbij de Athlon een goede verhouding laat zien tussen prijs en prestatie. Ook de 64-bits mogelijkheden van de Athlon zou deze processor een goede keuze maken, op deze manier is het mogelijk om de 64-bit versie van SuSE naast de 32-bits variant te draaien.

Reacties (44)

Metal Baron 20 september 2004 23:12

Wel jammer dat ze Apple's powermac G5 niet meegenomen hebben. Hoewel deze natuurlijk op een andere gebruikersgroep is gericht zou het leuk zijn te kijken hoe dezelfde software (dus ook OS) op verschillende CPU architecturen presteert.

My-life @Metal Baron • 20 september 2004 23:24

Ik denk niet dat de eigenaren van een G5 deze OS gaan draaien.

Verwijderd @My-life • 20 september 2004 23:56

al mijn collegas die een Apple hebben (G5/Powerbooks etc) draaien dual boot OSX/Linux (dan wel Yellow Dog dan wel Gentoo) dus ik denk dat dat wel degelijk interesant is...

arjankoole @Verwijderd • 21 september 2004 10:37

al mijn collegas die een Apple hebben (G5/Powerbooks etc) draaien dual boot OSX/Linux (dan wel Yellow Dog dan wel Gentoo) dus ik denk dat dat wel degelijk interesant is...

niet als je bekijkt dat dat zelden voorkomt (toegegeven, het zal meer en meer gebeuren). Een distro als Gentoo is nou niet iets wat je aan de gemiddelde gebruiker voert, een Mac gebruiker zal ik niet over 1 kam scheren met een windows gebruiker, maar 't blijft een gebruiker. En voor het instaleren van gentoo heb je toch wel wat meer clue nodig.

Dus, het draaien van Linux op een G5 is derhalve niet mainstream, heeft een dusdanig laag marktaandeel, dat het nog niet intressant is om een dergelijke analyse uit te voeren. Toegeven: de G5 zal waarschijnlijk wel redelijk wat ASS kicken

wica @My-life • 20 september 2004 23:52

/off-topic
Maar waarm denk jij dat? Omdat men OSX heeft?

Persoonlijk denk ik dat er wel een x aantal zijn die linux draaien. Net zoals bij de WinTel machine.

1 van de redenen is. dat OSX nog geen 64bit ondersteuning heeft voor de G5.

Verwijderd @My-life • 21 september 2004 10:23

Apple eigenaren hebben toch al een besturingssysteem dat goed werkt. Waarom zou je dan nog andere OS'en gaan proberen?

rtgo 21 september 2004 10:46

Wat ik mis bij linux benchmarks is Fourrier transformatie. Dat is iets dat in de wetenschap (en dat zijn zeer actieve linux gebruikers) veel gebruikt wordt. En dan niet 1 keer maar duizenden keren achter elkaar. En als een programma een lange tijd (soms meerdere dagen) loopt is optimalisatie van de processorkeuze toch leuk meegenomen.

Verwijderd @rtgo • 21 september 2004 13:17

seti@home is ook een goede "benchmark", kan je meteen ook met andere operating systems en architecturen vergelijken waar dit programma voor bestaat.

ZEN 20 september 2004 23:28

Wel jammer dat ze zich zo richten op processoren. Dat is juist iets wat ik wel allemaal best vind, neem aan dat daarin niet al te grote verschillen zijn tussen linux en windows. Misschien iets mbt kernel optimalisatie of zo. Ze hadden misschien beter met gentoo kunnen testen en dan compileren voor een specifieke proc..

Waar ik juist interesse zou hebben in een review over hardwaren en linux desktop apps, is bijv. beste videokaart die goed onder linux werkt en waar je makkelijk een aantal tftjes aan kan hangen, beste dvd brander, beste webcam, beste etc.. dingen die je onder een windows desktop/workstation gebruikt en die je goed/beter wilt kunnen gebruiken onder linux...

Graag ook met verschillende distro's debian, suse, gentoo bijv..

LogiForce 20 september 2004 23:23

Waarom SUSE

Als je echt een goed vergelijk wil hebben moet je Gentoo nemen. Dan kan je tenminste alles uit de kast halen

Wat zonder Gentoo

heb je geen ULTIEME (zoals boven vermeld) linux werkstation.
En ik denk dat heel wat Tweakers het met me eens zullen zijn

Jack Flushell

@LogiForce • 20 september 2004 23:51

Ik vind je reactie echt zwaar overdreve, zeker met 4 van die

. Gentoo kan je inderdaad meer optimaliseren, maar het is allang gebleken dat het niet veel uitmaakt.

Bovendien is SUSE een goede algmene veel gebruikte linux-distrubutie.

Soultaker

@Jack Flushell • 21 september 2004 00:04

De verschillen tussen verschillende Pentiums is niet zo groot, maar optimalisatie voor de 64-bits instructieset van AMD maakt nu net wél een relevant verschil, omdat er een belangrijk aantal nieuwe all-purpose registers beschikbaar komen.

Verder is de relevantie van architectuur-specifieke optimalisatie afhankelijk van de toepassing die je test. Multi-media libraries als Xine en MPlayer hebben aparte codepaths voor verschillende architecturen. Als zo'n library gecompileert is om compatible te zijn met een 386 en dus geen MMX- of SSE-instructies kan gebruiken, dan merk je het verschil met geoptimaliseerde code op (bijvoorbeeld) een machine met P4 instructieset wel.

Dat optimaliseren voor een specifieke architectuur 'niet veel uitmaakt' is dus erg kort door de bocht.

deadinspace @Soultaker • 21 september 2004 20:53

De verschillen tussen verschillende Pentiums is niet zo groot, maar optimalisatie voor de 64-bits instructieset van AMD maakt nu net wél een relevant verschil, omdat er een belangrijk aantal nieuwe all-purpose registers beschikbaar komen.

Maar daar heb je Gentoo helemaal niet voor nodig, aangezien de distributies met x86-64 support daar een aparte versie voor hebben die in zijn geheel voor x86-64 CPU's gecompiled zijn.

Dus SuSE x86-64 of Debian x86-64 maakt net zo goed gebruik van die extra registers en 64 bit integers als Gentoo.

Verder is de relevantie van architectuur-specifieke optimalisatie afhankelijk van de toepassing die je test. Multi-media libraries als Xine en MPlayer hebben aparte codepaths voor verschillende architecturen. Als zo'n library gecompileert is om compatible te zijn met een 386 en dus geen MMX- of SSE-instructies kan gebruiken, dan merk je het verschil met geoptimaliseerde code op (bijvoorbeeld) een machine met P4 instructieset wel.

Ja, maar beide van je voorbeelden (Xine en Mplayer) hebben run-time detectie voor features als MMX en SSE, en gebruiken run-time andere codepaths als deze aanwezig zijn, zodat dezelfde MMX- en SSE-ondersteunende binary op zowel een 80386 als een Pentium 4 werkt.

Ook hier heb je dus Gentoo niet nodig om MMX/SSE te gebruiken in Xine of Mplayer.

Overigens, in het geval dat het _wel_ uitmaakte of je Xine/Mplayer van source compilede... Programma's zijn ook van source te compilen in andere distributies dan Gentoo. Voor één of twee programma's ook niet echt de moeite.

Dat optimaliseren voor een specifieke architectuur 'niet veel uitmaakt' is dus erg kort door de bocht.

Hij had het over optimaliseren binnen dezelfde architectuur, dus voor verschillende i386 CPU's (80386, Pentium Classic, Athlon XP, Pentium 4, etc). En daar maakt het inderdaad erg weinig uit.

Verwijderd @LogiForce • 21 september 2004 09:36

Voordat je dat ultieme werkstation hebt, heb je zowat al grijze haren.

Voordat je alles uit de kast hebt gehaald moet je zekers met stage1 beginnen en een paar keer experimenteren met de FLAGS.

Al dit gedoe kost een boel tijd, kun je beter besteden dan naar de compilatie van je programma's kijken.

Gentoo kan leuk zijn, als je flink wat tijd over hebt.

BTW, de 10 fps die ik waarschijnlijk met ut2k4 zal hebben is mij deze moeite niet waard.

voormalig gentoo gebruiker op x86 en alpha

Verwijderd 20 september 2004 23:06

Snap hier weer helemaal niets van !!!

Waarom hypertrading uit geschakeld ?
Er zijn wel degelijk apps. die dit onder steunen onder Linux en zo niet heb je er geen last van als deze optie aan blijft staan.

En in Prijs kwaliteid verhouding liggen de CPU's niet ver uit elkaar.

Lijkt er op dat Tweakers wel erg graag de AMD boven aan wil zien staan.

Verwijderd @Verwijderd • 20 september 2004 23:27

Komt nog bij, dat als je de test zou lezen, dat ze bij de páár apps die het wél ondersteunen het ook wel eventjes aangezet hebben. Lees voor de gein het artikel eens.

Weer zo'n iemand die denkt dat alle info van tweakers komt. Meestal verwijst tweakers alleen naar de info. Goeie site, maar je moet weten hoe je het moet lezen. (NFI!)

Jamaicaman @Verwijderd • 20 september 2004 23:10

Tweakers heeft die tests niet gedaan hoor...

twiFight @Verwijderd • 20 september 2004 23:10

Cool, ik wist niet dat Anantech van tweakers.net was

Go Tweakers!

Fairy @Verwijderd • 20 september 2004 23:14

Voor je begint te flamen, doe dan eerst eens wat aan de "kwaliteid" van je spelling ofzo

Verwijderd 20 september 2004 23:28

waarom HT uitgeschakeld? als je wil kijken welke de beste cpu is, moet je toch niet functionaliteit van de ene gaan uitschakelen? als een programma niet HT is, is er geen voordeel, indien wel, is een Pentium sneller,.
64 bit van athlon wordt toch ook niet uitgeschakeld omdat veel programa's nog in 32 bit werken?

Verwijderd @Verwijderd • 20 september 2004 23:37

stoofke_melle, ik zei het al tegen Briandw:

Als je de test zou lezen, zou je zien dat ze het bij een paar apps die het ondersteunen, hebben aangezet. Helaas heeft het níet echt veel effect.

mjtdevries @Verwijderd • 21 september 2004 12:23

Voor HT heb je geen support van een programma nodig.

Het enig wat er nodig is is dat er meerdere threads lopen. En nou zullen linux programma's wel niet zo vaak multithreaded zijn, maar het OS zelf is dat hopelijk wel. En daar kan je dat net wat winst pakken met HT.

In ieder geval is het een slechte test als je het soms aan zet en soms niet.
Dan moet je gewoon alle tests 2x uitvoeren. Eén maal met HT en één maal zonder HT.

Verwijderd @Verwijderd • 20 september 2004 23:39

In een aantal gevallen is HTT juist langzamer.

edit: dit is ook te zien in de benchmark resultaten bij anandtech.

SirBlade 21 september 2004 01:04

/off-topic
Zippen van bestanden? Doet iemand dit tegenwoordig nog regelmatig? En zo ja, waarom?

Ik doe het zelf wel eens als een een kleine hoeveelheid data inclusief directorystructuur aan iemand wil sturen. Maar dat zijn altijd relatief kleine zipfiles (<5MB). Als het een grote hoeveelheid data is maak ik er een iso van die ik op een cd brandt.

En dan zie de reviews van de nieuwe zip-versies, "comprimeert nog beter". Dat had ik nodig toen ik een harddisk had van 40MB niet nu een entry-level-pc al een 40GB drive heeft.

Of mis ik iets?

MadEgg @SirBlade • 21 september 2004 01:38

Snelheid en handelbaarheid zijn voor mij redenen.

Nou gebruik ik daarvoor op Linux geen zip maar tar/gz(en geen bzip2 want dat duurt weer veel langer met comprimeren). Een homedirectory backuppen doe ik door eerst de hele boel in te pakken en daarna het bestand in een keer te kopieren naar een andere schijf. Doordat het bestand uit een stuk bestaat en ook nog een stuk kleiner is dan de homedir gaat dit veel sneller.

Waarom geen iso, dat lijkt me duidelijk, m'n homedir is groter dan 700MB en een dvd-brander heb ik niet.

Verder vind ik het nogal zinloos dat ze HT uitgeschakeld hebben. Het is imo een van de beste features van de P4, mede de reden dat ik die heb gekocht ipv Athlon64, naast die stomme NX-bit van Athlon64 natuurlijk. Het geeft je compleet het gevoel alsof je op een dual-proc systeempje zit voor een fractie van de prijs van een echt dual-proc systeem.

jcvw @MadEgg • 21 september 2004 08:13

Verder vind ik het nogal zinloos dat ze HT uitgeschakeld hebben. Het is imo een van de beste features van de P4

Je moet je heel goed realiseren bij het gebruik dat het niet extreem veel oplevert. Eigen benchmarks hebben opgeleverd: op een HT CPU twee integer CPU-bound processen draaien gaat 10% sneller dan zonder HT. Twee floating-point CPU-bound processen draaien gaat 40% sneller, en een mix van een integer en een floating point gaat 60% sneller. Daar merk je het dus...
Maar er is ook een prijs die je betaalt: Onder Linux moet je dan de SMP kernel gaan draaien, en dat kost meteen weer zo'n 15% (eigen benchmarks).
Kortom: als je op een single-CPU HT aanzet, levert het alleen wat op als je ook flink wat float berekeningen doet. Voor de gemiddelde server die mail/http/.... services doet is dat nauwelijks het geval. Als je al een Meer-CPU machine hebt (bijv dual xeon), dan heb je al een SMP kernel, en heb je de 15% al betaald. Dan levert de HT aanzetten alleen maar winst op. Maar ook dan geldt dat die extra "spook" CPUs die je krijgt niet meer dan 10-50% extra opleveren.

Maar de Athlong 64 levert omdat ie in 64-bit mode veel meer registers heeft dan een P4, ook zo'n 20% winst op t.o.v. dezelfde processor in 32-bits (dus "P4") mode.

mede de reden dat ik die heb gekocht ipv Athlon64, naast die stomme NX-bit van Athlon64 natuurlijk

Ik denk juist dat die NX-bit van de Athlon een uitkomst is. Echte processoren (mainframes en zo) hadden altijd al een NX-bit in de page tables of segment descriptors zitten. Het werd hoog tijd dat ze kwamen. Met NX bit wordt het voor exploit-schrijvers een stuk lastiger: Een buffer overflow kan nog steeds, maar er kan geen executeerbare code meer de buffer in gepompt worden die daarna uitgevoerd wordt...

Niet voor niets komt de P4 ook met een NX bit...

ritsjoena @jcvw • 21 september 2004 11:42

Exploit-preventie hoort niét thuis in de processor. De processor moet doen wat hem wordt opgedragen. Ook als hem opgedragen wordt data te executen

Mee eens, maar naar wat ik begrepen heb gebeurd dit ook niet. Wat wel gebeurd is dat er een parameter aan het geheugen wordt toegevoegd die zegt wat voor gegevens er in dat stuk geheugen staat. Dit heeft het OS nodig om te kunnen beslissen of iets geexecuteerd moet worden of niet.

Er is dus alleen ondersteuning voor dit systeem en niet een daadwerkelijke afhandeling ervan.

MadEgg @jcvw • 21 september 2004 11:24

[....]
Ik draai Gentoo, en toen ik mijn nieuwe processor met HT heb gekocht heb ik het hele systeem opnieuw compileerd. Met support voor HTT natuurlijk.
Op m'n vorige P4 2,4 GHz was ie 4 dagen zoet op alles(inclusief KDE, Gnome, Firefox, OpenOffice etc), met deze was dat gereduceerd tot zo'n 1,5 dag. Lijkt me toch sterk dat een snelheidswinst van meer dan 150% niet te wijten is aan 800 MHz extra. Ik geef toe, niet de meest betrouwbare benchmark, maar voor mijn gevoel is het ziekelijk veel sneller gegaan dan ik verwacht had.

[....]

Exploit-preventie hoort niét thuis in de processor. De processor moet doen wat hem wordt opgedragen. Ook als hem opgedragen wordt data te executen.

Dit is een reactie op de slechte beveiliging van MS, de processorboeren denken, lossen zij het niet op dan doen wij het wel. Foute instelling natuurlijk. Jammer dat Intel hier ook mee aan gaat doen(of al doet met de Itaniums natuurlijk).

Verwijderd @jcvw • 22 september 2004 13:18

Execution prevention hoort echt wel thuis in de processor (dat het nu nog niet zo is, is een flinke misser van Intel's kant) dat is namelijk de enigste plek waar je dat af kan dwingen.

ritsjoena @SirBlade • 21 september 2004 09:22

Zippen van bestanden? Doet iemand dit tegenwoordig nog regelmatig? En zo ja, waarom?

Ik niet, maar kom ze regelmatig tegen. Zippen (of een andere compressie) heeft 2 voordelen:
1) Kleiner
2) Archivering, een heleboel bestanden in 1 bestand, wat de collectie als 1 geheel handelbaarder maakt.

Bestanden gezipt opslaan doe je inderdaad alleen als je veel data hebt en het daarvoor uitmaakt.

Maar wat dacht je van versturen over internet? 700MB of 500MB is dan een groot verschil. Zeker over de wat minder snelle verbindingen.

greensocks @ritsjoena • 21 september 2004 09:38

Zippen van bestanden? Doet iemand dit tegenwoordig nog regelmatig? En zo ja, waarom?

Wat dacht je van virusscanners bij bedrijven die executables uit de mail filteren. Het zippen helpt dan deze exe's toch binnen te krijgen.

RobT @greensocks • 21 september 2004 11:39

Ehm, je kunt gewoon de .exe extensie hernoemen naar iets anders, en dan komt je mailtje meestal gewoon door..

mjtdevries @greensocks • 21 september 2004 12:26

Een beetje virusscanner scant ook in zipbestanden.

Dan moet je er ook een wachtwoord op zetten, anders wordt je executable alsnog verwijderd.

Mathijs @SirBlade • 23 september 2004 00:55

Dat doen mensen nog regelmatig ja, om binaries te posten bijvoorbeeld. Het heeft niet alleen met schijfruimte te maken maar vooral met bandbreedte. Zelfde met mail, sommigen hebben er nu eenmaal last van dat hun provider geen grote attachements ondersteunt.
Maar vooral snelheid met uitpakken vind ikzelf belangrijk, als er iets gedownload is wil ik het ook kunnen gebruiken.

Verwijderd 21 september 2004 09:43

hm:

"Ook de 64-bits mogelijkheden van de Athlon zou deze processor een goede keuze maken, op deze manier is het mogelijk om de 64-bit versie van SuSE naast de 32-bits variant te draaien."

weet iemand een reden waarom ik 32-bits suse nog zou willen draaien als ik een athlon 64 bezit?

ritsjoena @Verwijderd • 21 september 2004 10:08

weet iemand een reden waarom ik 32-bits suse nog zou willen draaien als ik een athlon 64 bezit?

Om de systemen te vergelijken en te achterhalen wat je er echt mee wint?

Maar wat belangrijker is: Soms kun je een 32-bit gecompileerd programma tegenkomen die niet goed wil werken onder het 64-bit systeem.

Hierbij ga ik ervan uit dat SuSe 64bit 32bit programma's kan draaien. Anders is de reden om 32bit SuSe te willen kunnen draaien veel sterker.

Verwijderd @ritsjoena • 21 september 2004 10:13

Op newsservers staat alles gezipt.dus ja ik gebruik het nog dagelijks.

JF_ @Verwijderd • 21 september 2004 11:20

Bijvoorbeeld omdat er voor videokaarten van bepaalde fabrikanten geen 64bits drivers zijn onder Linux?

Olaf van der Spek 21 september 2004 11:30

http://www.anandtech.com/linux/showdoc.aspx?i=2213&p=7

32-bit lame
encoding time times play time, more are better

Deze snap ik niet.
Een lagere encoding time is toch juist beter?
En play time is toch gelijk voor alle CPUs?

The 64-binaries are encoding 25 times faster than if we were to play them, i.e. in one second the Athlon FX-53 encodes ~25 seconds worth of playtime!

Moet het dan niet zijn play time / encoding time?

ATS 20 september 2004 22:59

Jammer dat er geen videokaarten getest zijn. Juist daarvoor heb je te maken met driversupport (of het gebrek daar aan) en kan je misschien écht andere resultaten verwachten dan onder Windows. Van de ruwe CPU en geheugen capaciteit mag je denk ik verwachten dat Linux die redelijk goed kan uitbuiten, net als windows (de laatste op het 64 bit gebeuren na dan.)

Verwijderd @ATS • 20 september 2004 23:53

video tests onder linux zijn niet echt interesant... ATI is crap met stukjes, en nVidia heeft het redelijk goed voor elkaar... dat is bij iedereen die met linux te maken heeft wel bekent

Op dit item kan niet meer gereageerd worden.

Lees meer

Reacties (44)

Sorteer op:

Weergave: