[linux] Re: 64-/32-bits comp, geen benchmarks voor?

Huub Reuver h_reuver op mantell.xs4all.nl
Di Nov 6 20:37:41 CET 2007


On Tue, Nov 06, 2007 at 09:17:22AM +0100, Daniel von Asmuth wrote:
> On Tue, Nov 06, 2007 at 09:03:12AM +0100, Julien Michielsen wrote:
> > Velen van ons zullen een 64-bits processor hebben. Getuige een aantal 
> > reacties voor nop, want - zegt men - 32-bits gaat net zo snel, en is 
> > beter uitontwikkelde technologie.
> > Klinkt best overtuigend, maar toch vind ik het jammer dat ik die AMD-64 
> > (waar ik best wel trots op was en ben) voor joker gekocht zou hebben. 
..
> > Kun je gelijk mooi kijken hoe jouw processor het doet met een 32- en hoe 
> > met een 64-bits linux versie.
> 
> De belangrijkste benchmark is de SPEC suite en die komt in de vorm van
> broncode om op alle belangrijke computers te kunnen worden gebruikt. 
> 
> Het c't Magazine is een van de organisaties die gecertificeerd zijn om 
> hem te mogen gebruiken. Resultaten worden op diverse plaatsen op het Web
> gepubliceerd. 
> 
> De informele Linux benchmark (ook geschikt voor thuisgebruikers): meet
> de tijd die je computer nodig heeft om een kernel te compileren. Ik heb
> zo'n vergelijking al eens gedaan en merkte dat compileren van x86_64
> code een stuk trager ging dan i686 code. Op andere taken liggen de
> snelheden dichter bij elkaar. 

Volgens mij test je met het compileren van een kernel iets heel anders:
Ik compileer kernels voor mijn 32-bit terminals altijd op de 64-bit AMD.
Niet vanwege de 64-bit, maar puur vanwege de kloksnelheid en andere
optimaliseringen van de AMD64X2 t.o.v. een C3.

Eerste probleem waar je tegenaan loopt is dat de compiler standaard 
compileert voor de architectuur tenzij je ARCH=i386 exporteert.
Dam vraag ik me af of een gcc-compiler op een AMD64 werkt als een 64-bit
computer tijdens het compileren van 32-bit code. Ik zou me kunnen 
voorstellen dat tijdens het compileren gcc werkt met 'halve' data.

Vergelijken van compileren van 32-bit en 64-bit code is irrelevant.
In het ergste geval compileert de pc compleet andere code (#define..).
Ik ben geen programmeur, maar eh...

Waarvoor zou je 64-bits willen gebruiken?
Voor geheugentoegang? 32-bits is voldoende.
Voor sneller doorvoer in de processor? Er zijn andere manieren om meer
data door de processor te wurgen, maar 64-bit data kan met name erg
leuk zijn. Als een 64-bit pc geoptimaliseerd is voor encryptie of 
videobewerking moet je toch vaak rauwe data doorvoeren.

Eind van het verhaal blijft volgens mij toch dat je een stukje rauwe
snelheid gebruikt en dat de rest afhangt van optimalisatie van de 
programmatuur.

Ik meen me een voorbeeld te herinneren van een benchmark die overgeslagen 
werd omdat de code door de compiler werd geoptimaliseerd. Erg vervelend
dat die moeizaam geprogrammeerde lus werd weggeoptimaliseerd.

Blijft het gevoel van snelheid dat toch weer afhankelijk is van de 
gebruiker. Is de processor en code voor hem optimaal en is hij een
tragere pc gewend.

Ik denk dat bij een benchmark voor mijzelf archiveren en uitpakken
een van de onderdelen is die ik zou testen. Daarnaast zal processor-
belasting tijdens de tests belangrijk zijn. Belangrijker dan snelheid 
is vaak op responsie van het systeem onder zware belasting. Is het nuttig 
om dat verkeerde proces te killen of reageert het systeem toch niet
tot het commando klaar is?

Met vriendelijke groet,
Huub Reuver 




More information about the Linux mailing list