Eerste dual Athlon Linux benchmarks

NewsForge heeft als eerste benchmarks gescoord van een dual Athlon systeem. Op de LinuxWorld stand van MandrakeSoft zagen zij kans om twee Linux 2.4.0ac12 kernel compiles los te laten op een Mandrake 7.2 bak met Tyan 760MP mobo, twee 1200MHz Athlon CPU's en 256MB PC2100 SDRAM. Om onverklaarbare reden was de kernel compile met dual processor support meer dan twee keer zo snel als de default make config waarbij één CPU wordt gebruikt:

While the results for the single-CPU compile were good results, what we are really looking at are the dual results. The kernel compile with both processors performed an impressive 142% faster than the single-processor system, showing that adding another CPU doesn't necessarily mean just a 100% boost in performance. Although a two-minute 2.4.0ac12 compile is definately impressive.

Single Dual 2.4.0ac12 compile tijd (m:s) 4:51 2:00

Reacties (62)

[Verwijderd]

Die extra performance is makkelijk te verklaren. Open eens een TOP ofzo, en kijk naar het CPU gebruik van de compiler. Meestal ligt die maar rond de 60% en wordt 40% van de tijd gewoon gewacht op IO. Als je op een single-CPU systeem de optie "-j3" (max 3 simultane compiles) geeft, wordt de performance ook al beter, omdat dan de CPU 100% voro compilen wordt gebruikt (terwijl de ene op IO wacht kan de ander de cpu volledig benutten).

De verklaring voor de 142% boost is dus flauw, gewoon 99% van de extra CPU (minus 1% overhead) en 43% winst door de simultaan mode.

[Verwijderd]

Hallo!! Het gaat hier om een dual Athlon Linux test. Toch niet over dit mobo?

Wat ik nou niet snap is dat het dual systeem meer dan 2x zo snel is. Hoe kan dat nou? Ik dacht dat je altijd wat verlies leed als je een dual systeempje had (dus niet twee keer zo snel (maar bijv. 1,9) als een single systeem). Kan iemand dit uitleggen?

[roytanck|IA]

Stel dat het OS 40% van processorkracht gebruikt. Bij 1 cpu heb je dan dus 60% over voor het compileren.. Bij 2 cpu's heb je dan dus "160% over"? Da's meer dan 2,5 keer zo veel.

Natuurlijk is er overhead en zo, maar in principe kan, onder een goed smp-os, er in 1 applicatie wel degelijk meer dan 100% winst zijn... (man dit is een gave setup voor BeOS.... )

[Eastern]

Even zo dan: Je hebt het over een fictief getal van 40% overhead? Volgens mij is dat niet zo. Als ik NT draai, en verder niks doe dan is het CPU gebruik 0-2% maximaal. Onder Linux is dat (als het goed is) nog minder. Dus dan zou je nooit zo hoog kunnen komen.

[mr_a]

Daar heb je geen gelijk in want de situatie waar de benchmark over gaat (compileren) is niet te vergelijken met een "idle state".
Bijvoorbeeld als het systeem aaan het swappen bent en tegelijkertijd data van en naar de schijf aan het kopieren bent (I/O), dan kan zelfs bij de modernste ultra-DMA systemen het processorgebruik oplopen tot 40%.

[Verwijderd]

Dat komt misschien omdat de 2 procs. op dit mobo gebruikmaken van elk een aparte bus. En niet zo als op Intel mobo'tjes 2 procs. op een bus.

[musiman]

Uhhh, wat dacht je van:
een geoptimaliseerde compile?

Kijk, als je alle troep eruit gooit en een mooie schone compile maakt, dan werkt je systeem ogenschijnlijk sneller (hij hoeft minder aan die andere, onnodige, processen te werken).

[Verwijderd]

Er staat dat het COMPILEREN meer dan twee keer zo snel was, beter gezegd minder dan de helft van de tijd kostte. De performance was een factor 1,42 zoals in de quote staat (en helaas niet de 1,9 zoals je zelf noemt). Dat de compile minder tijd kost kan toch? Eigenlijk kun je de twee compiles niet goed met elkaar vergelijken, want het zijn eigenlijk twee verschillende "programma's" die je compileert

[.oisyn]

nee dat lees je verkeerd. Er staat 142% FASTER, wat dus niet betekent dat ie 1.42 zo snel is, maar dat ie 142% sneller is

0% sneller is net zo snel
100 % sneller is 2x zo snel
dus 142% sneller is 2.42x zo snel

(zelfde als met winst. Als je 130% winst hebt betekent dat dat je iets voor 2.3x zoveel hebt verkocht dan dat je het hebt gekocht)

als je het uitrekent zie je dat het klopt
4:51 = 291 seconde
291 / 2.42 ~ 120.2479 seconde ~ 2 minuten

[Robo]

Zou het kunnen zijn dat in dit geval de caching van Linux veel I/O overhead goed maakt? Normaal gesproken is de I/O-overhead toch wel de remmende factor bij een kernel compile.

Wat natuurlijk ook verschil uitmaakt is de'-j3' optie voor de dual processor compile. Juist omdat de I/O-overhead relatief groot is kan het uitmaken om meer dan 1 job te doen. Test maar eens uit met een kernel compile op een single processor systeem en 'top' in een andere term. Zal je zien dat de processor toch niet 100% bezig is met compileren.

[Exirion]

Volgens mij is de enige plausibele verklaring waarom het compileren met 2 CPU's meer dan 2 keer zo snel is, dat de effectieve cache-size met twee CPU's twee keer zo groot is. Amdahl's Law (een wet in het parallel programmeren) beweert dat een speed-up factor altijd kleiner dan 1 is omdat paralelle verwerking overhead veroorzaakt. De praktijk laat zien dat dit niet altijd zo is, en als reden daarvoor wordt de toegenomen effectieve cache size genoemd.

[Verwijderd]

Nog een reden voor superlineaire scaling kan zijn dat je in multiprocessormode effectief meer geheugenbandbreedte hebt.

Ik denk echter dat bovenstaande test niet echt iets zegt, omdat er teveel factoren van invloed op het resultaat zijn die niet direct iets met SMP te maken hebben (met name de -j optie en diskcaching).

Zijn er eigenlijk wel goede SMP compilers voor linux?

[Exirion]

Bedoel je om programma's voor SMP mee te compileren of een compiler die zelf voor SMP bedoeld is? Ik neem aan dat je de compiler zelf bedoelt, en dat weet ik dus niet. Maar ik denk dat als je de -j optie gebruikt bij gcc, dat ie dan op een SMP systeem ook de threads verdeelt over de CPU's. Maar echt geoptimaliseerd is dat dan waarschijnlijk niet.

[Verwijderd]

wel, gcc compileren onder een smp optimized compiler

[N8w8]

Nee, zo werkt -j niet. Je geeft -j2 mee aan make, en die zorgt er dan voor dat iedere CPU altijd iets te doen heeft (in een ideale situatie dan). Er worden dus gewoon 2 make-threads gestart. Verder nix.

Of bedoelde je dat ook?

[NightBird]

Daarnaast krijg je ook superlineaire speedup (dus meer dan verdubbeling van de snelheid, bij verdubbeling van de cpu's) bij zoekalgoritmen. Stel je moet een array met 100 getallen doorzoeken naar een bepaald getal, en dat getal zit op plaats 75 van de array.
Bij 2 cpu's nemen ze beide een halve array, en zal de 2e cpu het getal al na 25 getallen vinden.
Zodoende ben je dus al 3x zo snel, in plaats van 2x.

[Exirion]

Dan moet de code wel zodanig zijn geoptimaliseerd dat de data wordt verdeeld over de processen. Dat is hier niet het geval, want de compiler code is alleen in threads opgedeeld. Dat betekent dat de code verdeeld is, maar de data niet. Jouw voorbeeld is een heel bekend voorbeeld van speedup bij search algoritmen, maar hier niet van toepassing. De memoization- en prediction-tables kunnen uiteraard wel op die manier verdeeld worden over de CPU's, maar dan krijg je weer het probleem dat delen van de tabellen voor de andere CPU's remote zijn zodat je weer meer communication overhead krijgt bij een query op een remote deel van zo'n tabel. Een oplossing daarvoor is dan weer data-replication, maar of je dan nog een superlineaire versnelling overhoudt dat betwijfel ik.

[Verwijderd]

Exerion je hebt helemaal gelijk

Paraselsius dit is idd geen realistische test, ik weet niet hoever de kennis van possix compat. systeem reikt bij hun, maar ik vraag me ten 1e af of ze een indentieke kernel compilatie hebben uitgevoerd, dwz. maak de tree eerst helemaal schoon (arch dist clean en een mrproper om dep op z'n plaats te houden) in die situatie wordt er evenveel gecompileerd. Als je dit niet doet komt het altijd voor dat er al een aantal zaken al gecompileerd zijn dus de 2e keer duurt het minder lang. Ok, volgende punt is int belasting. Er zijn talloze discussies (waardevol en minder waardevol) geweest over het verschil IDE<->SCSI. Het komt erop neer dat IDE (io programming/ poort aansturing) veel en veel meer interrupts vreet dan SCSI (dma transfers, bus topologie). Omdat IDE zo ontzettend veel ints vreet kan de cpu op dat moment niets anders doen, terwijl met SCSI de proc gewoon doorgaat. Wat gebeurd er nu bij een 2 of meer procs systeem? De ints kunnen verdeeld worden over de procs als het os die ondersteunt. Resultaat is dat IDE nog steeds belachelijk veel ints genereerd, maar dat het over 2 procs verdeeld wordt waardoor je een veel hogere HD performance haalt EN nog meer beschikbare proc kracht. Dit is allemaal niet alleen gebaseerd op theorie, maar ook op praktische ervaring. (Ik prog smp en doe aan kernel hacking)

[Verwijderd]

En betere int afhandeling door dual proc systeem betekend betere hd/proc performance waardoor het compileren dus sneller zal verlopen. Sneller dan die procentuele kracht die je erbij gedacht te hebben..

Snurk, vandaag ga ik wel naar bed ;-)

[Verwijderd]

Zoals Robo al zegt: de compile optie "-j 3" zorgt voor een fikse vooruitgang. Maar er is meer dan dat. Newsforge zegt dat ze de single-CPU test deden met ``make bzImage'' en de dual CPU-test met ``make clean; make -j3 bzImage''.

De optie ``make clean'' suggereert dat er al eerder een kernel is gebakken op hetzelfde systeem. Oftewel: de schrijver suggereert, dat de zogenaamde ``single processor'' test in feite een van de processoren op een dual processor moederbord is geweest. How's that for a benchmark?

Daarbij: een kernel compile behoort te beginnen met ``make dep''. Aangezien dat commando door de newsforge niet gebruikt is, wil het zeggen dat de single-CPU compile eerst een tijd ``make dep'' staat te doen. Echter, ``make clean'' overschrijft niet de dependencies, dus de zogenaamde dual CPU-test meet een snelheidswinst van iets dat 'ie niet hoeft te doen.

Een beter methode was ongeveer als volgt gegaan:

1. bouw twee kernels. Een met dual CPU-support, een zonder.
2. Start Linux met de single-CPU-kernel; pak een kernel uit; tik achtereenvolgens ``make menuconfig'', sla de kernelopties zonder iets te wijzigen op, en typ nu ``cp .config Testkernel''. Je hebt nu de ``standaard''-kernelopties opgeslagen.
Nu tik je ``make dep''.
Vervolgens de test, ``time make bzImage''.

Nu doe je datzelfde met make -j2 op het single-processor-systeem. Om de benchmark netjes te laten verlopen typ je:
make mrproper (d.i. wis alle instellingen, sources, dependencies!)
cp Testkernel .config (om de standaardconfig terug te zetten)
make oldconfig (om de standaardconfig te activeren)
make dep
... en weer ``time -j2 bzImage''.

Hetzelfde kun je eventueel nog voor -j3 doen.

Nu kun je diezelfde opties proberen met de Linux gestart met de voor dual processing gecompileerde kernel. En pas dan kun je de getallen enigszins vergelijken.

De huidige vergelijking is totaal onzinnig, en zegt vooral iets over de gebrekkige Linux-kennis van de schrijver bij Newsforge.

[WHiZZi]

Leuke plank. Jammer dat er SCSI op zit. Ik vind persoonlijk een RAID-ATA100 controller fijner..

[McCormick]

Hmmmjah, en ik zou ook bijna gaan denken dat een pizzaboxSERVERmobotje is, (form factor, schuin geplaatste dimms onboard vga, dual nic), vandaar dus ook scsi.

Zie ook http://athena.tweakers.net/nieuws.dsp?ID=15533

[ACM]

Euhm...
de titel was "Linux benchmarks"!
En zoals iedereen ondertussen zou moeten weten, is het installeren van linux op ide-raid lang niet zo makkelijk/fijn als op een scsi systeem.
(Maar de promise controllers worden ondertussen wel redelijk ondersteund)

[4of9]

Het ging hier over het compilen van een linux kernel niet over het instaleren van linux op ide-raid systeem

[Daniel]

Tja, ik ook (prijs-kwaliteit verhouding) maar dit is een serverplank, geen huis, tuin en keukending

Logisch dus dat er SCSI op zit

[Contagion]

Ik kan me een speedup van meer dan 2 ook nauwelijks voorstellen zeker omdat het zo'n groot verschil is. Heel erg vreemd. Ergens hierboven wordt gesteld dat er bijv 40% voor je OS is en 60% over blijft maar zo veel overhead is er niet.

Het enige wat ik kan verzinnen is dat ze de test als volgt hebben gedaan:

1. installeer linux met std. 386 2.2.x kernel
2. compileer een smp kernel (2.4.x) en meet hoe lang het duurt.
3. start op met deze nieuwe kernel en laat m zichzelf nog eens compilen

Zo kan ik het ook ja

[Robo]

Je hoeft niet te verzinnen hoe ze de test gedaan hebben, want dat staat netjes beschreven in het artikel. Je had daar kunnen zien dat ze twee keer exact dezelfde kernel (inclusief opties) hebben gecompileerd. Enige verschil is de commandline parameter bij 'make'.

[Verwijderd]

Waarschijnlijk komt het doordat met 2 procs de caches ook verdubbelt zijn, en bij AMD krijgen ze netjes elk een 100 mhz ddr bus, zodat ze elkaar niet in de weg zitten zoals bij alle andere systemen (ik heb het over PC's).

[Damusic2me]

Nou ben ik absoluut geen linux expert maar ik denk toch uit logisch redeneren dat roytanck wel eens een aardig eind in de richting kan zitten:
je compiler draait, je os draait en je gooit er een extra cpu bij en je hebt meer dan 100% performance winst.
als je nou 2x een os draaait en 2x een compiler.. tja dan zou je er niet boven uit kunnen komen maar las ik ook iets over een caching overhead en wordt dat nu ook verdeelt over 2 processoren ??? zou ook lekker kunnen schelen
Maar conclusie: is een lekker rete snel systeempje.. Ik denk dat ik maar vast ga sparen

[Verwijderd]

moeilijk... net zoiets, ik heb 2 auto's, in de ene auto rij ik altijd, dus hou ik .75 auto over, en de andere auto heb ik ernaast staan, maar daar doe ik nooit iets mee.. dus heb ik ten opzichte van de .75 die ik gebruik er een 1.00 bij! jah, vast... hele vage verklaring... misschien is dit verkeerd omschreven, maar ik bedoel het goed....

[Jis]

is wel een goed voorbeeld ja. Als je 1 auto hebt, heb je 3 plaatsen over. Je zou verwachten dat je bij 2 auto's dus 6 plaatsen over zou houden.
Maarrr als je die nou in je eentje bestuurd(dual-car/aanhanger), hou je er dus 7 over.
Dus heb je 2.16 zoveel lege zitplaatsen.

[Verwijderd]

Hoeveel performance bonus zou je dan krijgen met een quad-processor setup? (zie VirtuHammer newspost)

Een extra 127,5%?
Dan is het eigenlijk 5 halen 4 betalen :-)

[packman]

nenee, dat moet zijn 5 halen, 10 betalen, zo'n SMP mobo is echt niet gratis hoor...

[Verwijderd]

dual athlon? ik vind bi-athlon toch wat leuker klinken

[Verwijderd]

moet je in frankrijk gaan wonen daar hebben ze geen dual systemen, uitsluitend bi syteempjes

[Laurent]

Ziet er goed uit, alleen wat zit er nou naast die 4de DIMM slot

[Verwijderd]

Dat witte zijn de klemmetjes van het DIMM-slot, omdat de DIMM-sloten schuin zijn geplaatst.

[actieman]

maar hoezo zijn ze schuin geplaatst dan

niet voor de ruimte waarschijnlijk, want dan kom je in de knoei met je proc. koeling....

[edit]
ik bedoel je kunt hem wel in een "pizzabox" douwen, maar hoe krijg je dan die hitte van de proc's weg? Een beetje koeler wil nog al hoog zijn en het heeft ook geen nu als je proc fan tegen het dak staat te blazen...

[Femme]

512MB en 1GB DIMMs willen nog wel eens erg hoog zijn, dat kan een probleem zijn als je een plank met normale 90° gekantelde DIMM slots wilt gebruiken in een 1U rackmount. Door de slots schuin te plaatsen is er ook plek voor hoge DIMMs.

[actieman]

ja dat begrijp ik, maar hoe zit het dan met je proc koeling?

je kunt een dual athlon wel in een 1U kasje duwen, maar een socket a koeler is al gauw 5cm hoog en moet dan ook nog z'n lucht naar boven kwijt kunnen...

of zitten er in een 1U kastje (netzoals die 3com switches & hubs fan's aan de zijkant, waardoor je dus met een simpele heatsink voldoende koeling zou hebben

[Verwijderd]

of zitten er in een 1U kastje [...] fan's aan de zijkant, waardoor je dus met een simpele heatsink voldoende koeling zou hebben

Nee, de zijkant van een rackmounted unit is natuurlijk niet echt interessant voor (actieve) koeling, die wordt immers nogal afgedekt door het rack waarin het systeempje wordt opgehangen. Ventilatiesleuven komen soms wel voor in de zijkant, maar dan alleen als lucht-toevoer, fans zie je alleen vóór en achter in/op het kastje.

Overigens: een dual Athlon in een 1U rackmount moet imho wel kunnen, 't lukt tenslotte ook met een dual Alpha, en dat zijn in die zin net zulke bakbeesten. Zie http://www.alpha-processor.com/pressreleases/pr 110600a.shtml : dual Alpha 833MHz in een 1U rackje!

[Laurent]

Aha zo, schuin. Ik d8 dat degene aan de rand geen hendeltje ofzow had en dan iets anders moest voorstellen, we moeten nog afwachten op echte close-ups

[BrammeS]

Damn dat ik veel eerder moeten hebben dan kwam ik tenminste niet in de knoei met mn hardeschijfen die in de weg zitten voor het bijprikken van extra geheugen!...... Bytheway at bord ziet er echt way cool uit. Een Dual Athlon 1200..... niet normaal meer!

[NuKeFaCe]

Je hebt ook klemmetjes als de dimmsloten rechtop staan !!!!!!!

[Femme]

De onderste 2xIDE, boven flop en SCSI?