Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 46 reacties, 88.393 views •

Conclusie

Hoewel dit artikel zeker niet bedoeld is om het laatste en volledige antwoord te geven op de vraag wat nou de beste databasesoftware en -hardware is, willen we met deze test wel een fundering leggen voor een serie van toekomstige artikelen die over hetzelfde onderwerp gaan. Er staat een aantal interessante nieuwe ontwikkelingen te gebeuren dit jaar, waaronder de introductie van Intels Xeon 'Dempsey', de Socket F Opteron van AMD met DDR2-geheugen en natuurlijk ook Intels Woodcrest.

Hoewel we van AMD dit jaar geen grote verbeteringen meer verwachten, ligt de lat voor Intel hoger - het bedrijf heeft dan ook aardig wat achterstand om in te halen. De roadmaps geven aan dat de situatie zoals die er nu ligt aan het einde van het jaar drastisch anders zal zijn: een van de redenen waarom de dualcore Xeon in deze test niet harder wilde gaan dan zijn singlecore broertje is zijn beperkte bandbreedte: met vier cores op één 6,4GB/s bus werken is duidelijk geen pretje. Binnenkort verschijnt er echter een nieuwe chipset met een dubbele FSB en vier kanalen FB-DIMM, waardoor de beschikbare bandbreedte meer dan verdubbelt naar 17GB/s. De 65nm Xeon-processors die daarbij horen laten zich bovendien een heel stuk hoger klokken: we hebben hier een 2,8GHz Paxville onder de loep genomen, maar Dempsey zal beschikbaar zijn tot en met 3,73GHz.

Dual core Xeon DP Dempsey

Binnen een half jaar na Dempsey verschijnt Woodcrest, die de bandbreedte nog eens extra opvoert naar 21,3GB/s. Bovendien is deze chip gebaseerd op de volledig nieuwe architectuur die ook in Conroe en Merom terug te vinden zal zijn. Eén van de belangrijkste dingen die hiermee wordt aangepakt is het stroomverbruik van de Xeons: Dempsey krijgt nog een TDP van 150 watt mee, wat vergeleken met de 95 watt Opterons erg veel is. Woodcrest zal het verbruik naar verluidt bijna halveren (naar 80 watt), terwijl het tegelijkertijd betere prestaties belooft. Dat Intel ons aan het einde van het jaar een veel beter product zal kunnen bieden dat we nu getest hebben lijkt zo ongeveer vast te staan, maar de grote vraag is natuurlijk hoeveel beter, en of het ook genoeg is om de Opteron van de troon te stoten. Merom en Conroe mogen in vroege tests dan wel indrukwekkende resultaten neerzetten tegenover de Athlon 64 X2, maar een serverconfiguratie waarin twee processors moeten samenwerken is toch andere koek dan de een chip die op zichzelf goed werkt.

Omdat we hier feitelijk maar één soort toepassing hebben getest kunnen we in dit artikel geen definitieve conclusies trekken over welke processor of databasepakket nou 'het beste' is, maar we zijn duidelijk onder de indruk van de prestaties van de dualcore Opteron, en ook MySQL 5.0 was voor ons een positieve verrassing. Intels Xeons zouden het in andere taken misschien beter kunnen doen, maar in ons geval stellen ze teleur: vooral de dualcore-versie lijkt zijn geld niet waard te zijn. Hoewel dat later in het jaar weer helemaal kan veranderen, moeten we op dit moment concluderen dat we nog steeds liever voor AMD gaan.

* Dankwoord

Tweakers.net wil Robin Kuepers (Dell), Alex Vellinga (Melrow), Matty Bakkeren (Intel) en Winnie Silvertand (Whizpr / AMD) bedanken voor hun medewerking aan dit artikel. Verder dank aan onze eigen Femme, Kees, ACM en moto-moi voor het opzetten en uitvoeren van de tests en hun waardevolle inzichten voor het schrijven van dit artikel.


Reacties (46)

Reactiefilter:-146044+142+26+30
Moderatie-faq Wijzig weergave
vraag me hier dus wel heel erg af, wat de geintergreerde geheugen controler voor de nieuwe Amd64 x2 chipjes zal opleveren, zou in ieder gevaal zeer benieuwd zijn naar een zelfde soort onderzoek tegen die tijd.

eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.

wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking)
is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
vraag me hier dus wel heel erg af, wat de geintergreerde geheugen controler voor de nieuwe Amd64 x2 chipjes zal opleveren, zou in ieder gevaal zeer benieuwd zijn naar een zelfde soort onderzoek tegen die tijd.
Het is zeker de bedoeling om dit vaker te gaan doen, dus wie weet :).
eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.
Het probleem daarbij is dat de code van Tweakers.net zwaar geoptimaliseerd is voor MySQL en zich dus niet zo makkelijk laat overzetten naar een andere database. Zelfs als het in een keer zou werken zou je weer hele andere trucs moeten gaan toepassen om de optimale prestaties te krijgen, en dat kost veel tijd. Nu dat gezegd is kan ik verklappen dat we hebben geprobeerd om Tweakers.net op PostgreSQL te testen, maar dat is om verschillende redenen fout gelopen en het resultaat daarvan hebben we dus achterwege gelaten. Wellicht komt dat echter nog terug in een toekomstig artikel.
wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking) is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
Heel de frontpage van de site draait op één database. Query cache staat automatisch aan voor alle tabellen, maar degene waarin veel geschreven wordt profiteren er minder van.
Het probleem daarbij is dat de code van Tweakers.net zwaar geoptimaliseerd is voor MySQL en zich dus niet zo makkelijk laat overzetten naar een andere database.
Puur uit interesse, wat valt er aan MySQL zo specifiek zwaar te optimaliseren waardoor het dan ook nog eens voor SQL code zorgt die niet meer portabel is naar andere engines ?

Op die manier vervalt heel het voordeel van SQL als 'structured query language' IMHO...
Pas sinds 4.1 en nog meer 5.0 doet MySQL moeite om ook daadwerkelijk compatible met SQL te zijn. Daarvoor was het vrij gebruikelijk dat er zaken in zaten die niet in andere databases werken. Er zijn diverse voorbeelden, maar het lijkt me voor deze discussie niet heel handig ze allemaal te noemen.
Om je toch niet met een kluitje in het riet te sturen:
MySQL kan pas subqueries sinds 4.1, dus daarvoor moest je truckjes uithalen om hetzelfde effect te bereiken door de queries niet erg optimaal te herschrijven of door ze op te splitsen en de resultaten van "sub"queries eerst apart te verwerken in je applicatie.
MySQL gebruikte tot voor 4.1 de functie "concat" om iets vergelijkbaars als || te doen, maar niet het helemaal hetzelfde. Evenzo voor diverse andere functies, ze zijn/waren vaak net anders genoemd en/of werkten net even anders dan de standaardfunctionaliteit.
MySQL laat het toe dat je een langere select list hebt dan je group by list en dan heb ik het niet over de aggregations in de SL.

En zo zijn er nog heel wat meer. Veel van de queries konden overigens met redelijk beperkte aanpassingen toch werken in PostgreSQL. Maar aangezien PostgreSQL relatief tov MySQL slecht presteert met hele lichte queries was het nuttig en bijna noodzakelijk om met name die opsplitsingen van queries terug te draaien.
Ondanks die "terugdraaiingen" zijn er nog zat andere stukken code die kunnen profiteren van het opnieuw doordenken van de structuur en/of de queries.
eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.
Op zich heb je gelijk dat dat interessant is. Zoals Wouter al zegt, we hebben wel PostgreSQL in eerste instantie ook gebenchmarked. In de optimalisatie van de queries ging echter behoorlijk wat tijd zitten en juist daardoor gingen we enerzijds meer fouten introduceren en werden anderzijds de resultaten minder goed vergelijkbaar. Een redelijk belangrijke conclusie die ik je er nog wel over kan geven is dat ondanks de niet vergelijkbare resultaten (met mysql), gaven de cijfers ook bij PostgreSQL hetzelfde beeld als MySQL doet. Zowel voor HT als de dual-coreoplossingen
wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking)
is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
Nee, dat gaat niet zo maar. Veel van de queries combineren diverse tabellen weer met elkaar (bijvoorbeeld de username bij de reacties). Sterker nog, in de praktijk zijn er maar een paar waar relatief veel in geschreven wordt en een vrij groot aantal waar relatief weinig in geschreven wordt. Maar zelfs voor de reactietabel moet je niet vergeten dat er hooguit een paar nieuwe reacties per minuut bijkomen, terwijl er in dezelfde tijd misschien wel 10x zoveel views op reacties zijn geweest.
Het is daarom ook "minder effectief" niet gelijk totaal zinloos bij de meeste van onze queries :)
eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.
Dit artikel heeft een beperkte strekking, namelijk die van een webdatabase-server. MySQL wordt vanwege de lage kosten, afdoende mogelijkheden en goede prestaties veel gebruikt voor webdatabases. Oracle wordt gebruikt voor hele andere toepassingen waarvoor wij geen simulatie voorhanden hebben die is gebaseerd op omgeving uit de echte wereld.

MS SQL zou wel een mooie toevoeging zijn omdat het veel wordt gebruikt voor websites die op Windows-systemen draaien.
wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking)
is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
Over het algemeen geldt dat alle tabellen in de Tweakers.net-database een hoge verhouding reads hebben ten opzichte van writes, behalve de tabellen waar vrijwel uitsluitend in geschreven wordt (met name statistieken). Dit zal voor veel webdatabases het geval zijn. Ik denk dat wij zelfs aan de hoge kant wat betreft writes zitten ivm de veelvuldig voorkomende mutaties in de Pricewatch, de reactietabellen en user/sessietabellen door het toevoegen of wijzigen van prijzen en user moderaties. Desondanks worden er toch veel meer views gedaan dan mutaties.

Op de statstabellen heeft de query cache weinig overhead omdat er nauwelijks SELECT's op die tabellen gedaan worden en er dus ook weinig in de cache getrashed kan worden.
Ik ben benieuwd hoe de getallen zijn als je meer gaat schrijven in de DB
Mooie test!! hier hou ik wel van!!

In deze test worden de pagina dus 'niet echt' gegenereerd?!
Ik zat namelijk vandaag te knoeien om de resultaten van een querie netjes op het scherm te drukken maar de opbouw van de pagina heeft ook nog eens veel impact op de totale load
De pagina's werden wel echt gegenereerd maar dat gebeurde op een apart systeem. De databasemachines hielden zich dus puur en alleen bezig met het verwerken van de queries, niet met de verdere opbouw van de pagina.
Ze worden niet 'echt' gegenereerd. Als je ze zou zien zou je een hoop getallen zien, niet alsof je naar de frontpage zou kijken.

Het genereren van de pagaina, de opbouw e.d. kost inderdaad veel rekenkracht ook, en de webservers hebben het daar ook wel zwaar mee, maar dat is niet aan de database gerelateerde load, dus die konden we voor deze test weglaten. Als we webserversoftware zouden testen dan was het inderdaad een kwestie van de pagina compleet genereren en 'laten zien', maar nu het puur om de queries gaat is dat niet gebeurd.
De opmaak van je site zou niet uit mogen maken. Wat jij denk ik bedoeld is dat er bij sommige opmaken meer html en dus webserver load bij komt kijken.

De database server maakt het niet veel uit hoe en wanneer hij queries ontvangt!
Waarom niet de 1120 op alle hardwareplatformen getest?
In eerste instantie wilden we het juist allemaal met die 1130 doen, maar die bleek bij de 2e server (die 1U Dell op de foto) al niet te passen, waardoor we uiteindelijk maar de 1120 zijn blijven gebruiken.
De dual 3.8 Ghz hing tegen die tijd echter al in ons rack en konden we niet meer opnieuw testen. Voor de performance maakte het verder geloof ik niks uit en anders een heel klein beetje. De oplettende bezoeker zal misschien herkend hebben dat de 3.8Ghz configuratie precies overeenkomt met die van de forum-searchserver Aphrodite en de 3.4Ghz met de fileserver Atlas ;)
Ik denk (maar misschien kan iemand anders die zich daadwerkelijk met het testen bezig heeft gehouden me corrigeren ;)) dat de singlecore Xeon simpelweg als eerste is getest en dat het niet de moeite waard was om die later nog een keer opnieuw te doen (gezien de lage I/O-activiteit).
Kun je na het hele verhaal over de raidcontrollers constateren hd performance niet belangrijk is voor een databaseserver? Zou een gewone SATA schijf ook voldoen?
Disk performance is zeker niet onbelangrijk voor database-servers. Dit artikel is gericht op de prestaties van serverplatformen, dwz de combinatie processor/chipset/geheugen. Om te voorkomen dat de storage een grote invloed heeft op de prestaties is de dataset kleiner gehouden dan het geheugen van de servers. De data kan daardoor goed gecached worden. In de echte wereld zal er vaak gewerkt worden met datasets die (soms velen malen) groter zijn dan het RAM in de server. Als er ook nog eens een groot gedeelte van de dataset frequent wordt gebruikt ontstaat er vanzelf meer disk I/O.
dus als de dataset kleiner blijft dan je werkgeheugen zit je goed met een wat mindere disk(array).
is misschien goed om te weten voor degenen met een relatief kleine dataset dat zou de keuze voor een grote array of meer ram makkelijker kunnen maken(als er een compromis gemaakt moet worden, en we blijven natuurlijk nederlanders he).
Dat is een te simpele conclusie. Je zit dan altijd nog met writes die altijd naar disk doorgestuurd moeten worden, etc.

In deze test wordt daarnaast minder in de database geschreven dan in onze productieomgeving. Dat zorgt er dus voor dat de data in de caches van de database en de diskcache van het OS minder snel verouderen en er dus ook om die reden minder diskactiviteit nodig is.

Maar ik denk dat je doorgaans met meer ram meer bereikt dan een versnelde I/O. Met name omdat ram tot op zekere hoogte relatief goedkoop is, terwijl I/O al vrij snel behoorlijk prijzig kan worden.
Desalniettemin moet je natuurlijk ook weer uitkijken met een onderbemeten I/O-systeem, want dan kan het zijn dat het wachten op writes zo lang duurt dat je alsnog daar problemen door ondervindt. :)
In veel gevallen kun je beter je geld in meer geheugen en snellere disks steken, dan snellere cpu's overigens. Tenzij je een kleine actieve dataset hebt (die dus volledig in het geheugen past) en je daar veel rekenintensieve queries op los wilt laten, uiteraard.
Er stond 600 kb/s dus het ligt dus duidelijk niet aan de harde schijven dan zou zelfs een eeuwenoude harddisk uit 1995 genoeg zijn die haalde ook al makelijk 4MB/s.

Maar een buffer is natuurlijk wel handig om wat sneller te zijn. En met een Raidset heb je meerdere schijfbuffers die veel sneller werken als het echte schijfoppervlak.

edit: - En wat hierboven al staat er zit ook nog RAM geheugen voor dus is de RAID-set niet echt nodig.
Er stond 600 kb/s dus het ligt dus duidelijk niet aan de harde schijven dan zou zelfs een eeuwenoude harddisk uit 1995 genoeg zijn die haalde ook al makelijk 4MB/s.
Transfer rate is (zeker in dit geval) niet de juiste manier om te meten hoe druk een HDD het heeft. Helaas geven alle/veel niet aan welk gedeelte van de tijd een HDD bezig of idle is.
Mooie timing voor dit artikel :) Vlak voor de start van de verwachtte inhaalrace van Intel, om daar op de eerste rij verslag van te doen (ook al is het vanuit een beperkt perspectief). Hopen natuurlijk wel, dat bij elke 'major' platform/cpu release van een van de beide fabrikanten deze traditie voortgezet wordt.

Het zou interessant zijn wat meer uitgebreide artikelen op tweakers te zien.

Bijvoorbeeld de invloed van caches op integer en fp prestaties. M.b.v. van de SPEC suite. Ook al is er op www.spec.org (SPECmine) veel data te vinden, vaak worden daar verschillende compilers e.d. gebruikt wat toch zorgt voor beperkte vergelijkings mogelijkheden.

Voorbeeld:
Een identieke (compiler) set up voor elke geteste CPU. Te denken is dan bijvoorbeeld aan de volgende CPU's (met gelijk getrokken FSB's en kloksnelheden etc. voor gelijke CPU's):

K7 - 64 KB L2 Cache ('Applebred')
K7 - 256 KB L2 Cache ('Thoroughbred')
K7 - 512 KB L2 Cache (' Barton')

Northwood Celeron - 128 KB L2 Cache
Northwood - 512 KB L2 Cache
Northwood Xeon - 512 KB L2 + 1 MB L3 Cache
Northwood Xeon ('EE') - 512 KB L2 + 2 MB L3 Cache
Northwood Xeon - 512 KB L2 + 4 MB L3 Cache

K8 - 128 KB L2 Cache
K8 - 256 KB L2 Cache
K8 - 512 KB L2 Cache
K8 - 1 MB L2 Cache

Prescott 'Celeron D' - 256 KB L2 Cache
Prescott - 1 MB L2 Cache
Prescott - 2 MB L2 Cache
Prescott 'Xeon' - 1 MB L2 + 4 MB L3 Cache
Prescott 'Xeon' - 1 MB L2 + 8 MB L3 Cache

Dothan 'Celeron M' ULV - 512KB L2 Cache
Dothan 'Celeron M' - 1 MB L2 Cache
Dothan - 2 MB L2 Cache

Eventueel aangevuld met een test welke de invloed van een paar generatie compilers (ICC 7 t/m 9 o.i.d.) op Integer en FP prestaties laat zien.

En hoe vertaald zich een eventueel aangetoonde prestatiewinst, in pure int of fp, naar 'real world' applicaties?

Je ziet op allerlei plaatsen (talloze messageboards etc.) altijd weer de 'cache size' discussie opduiken in relatie tot prestaties. Een uitgebreid artikel daarover zou mooi als referentiepunt kunnen dienen.
@EAS:

Ik denk niet dat je op de juiste manier bezig bent als je de FSB en clockspeeds gelijk trekt, gezien de IPC van de CPUs niet gelijk is is dat geen eerlijke vergelijking. (Daarnaast heeft de K8 gelukkig geen FSB)

Daarnaast ga je iets te kort door de bocht wanneer je het hebt over K8, er zit behoorlijk meer verschil tussen de verschillende K8 cores als alleen de cache grootte. We hebben het ook over het aantal Hypertransport links, de snelheid en breedte daarvan, het aantal ondersteunde instructies (denk aan SSE3), verbeteringen in de cache van de verschillende cores (betere prefetch en dat soort zaken).

Uiteindelijk is het zo goed als onmogelijk om precies te weten hoe snel een CPU is en om dat te vergelijken. Je kunt het beste zelf een praktijk test uitvoeren zoals hier gedaan is om te kijken wat in jouw unieke situatie het beste is. Ook kun je op basis van andere tests een voorspelling doen, maar hou altijd in gedachte dat een voorspelling geen waarheid hoeft te zijn.
Ik denk niet dat je op de juiste manier bezig bent als je de FSB en clockspeeds gelijk trekt, gezien de IPC van de CPUs niet gelijk is is dat geen eerlijke vergelijking. (Daarnaast heeft de K8 gelukkig geen FSB)
Thorchar, daarom schreef ik ook "voor gelijke CPU's". Ik wil niet zien of een Prescott sneller is dan een K7 met identieke kloksnelheid e.d., maar ik bedoel dat als je een K7 pakt, dat je dan elke K7 test met een identiek geklokte FSB, met daarop identiek getimed geheugen en een identieke kloksnelheid. Een K7 'Applebred' Duron komt natuurlijk fabriek-af met andere FSB eisen dan een K7 'Thoroughbred' XP. Of dit dan onder- of overklokken inhoud van een van de beide K7 varianten, is aan de reviewers. Idem voor Celeron varianten (en ook Xeon). Vaak lagere FSB snelheden t.o.v. de desktop versies, geen mogelijkheden tot het (omhoog) veranderen van de multiplier, dus dan maar "naar elkaar toe klokken".
Opgesomd:
Voor elke K7: een gelijke klok/fsb/geheugen snelheid -> alleen de verschillen in cache blijven over.
Voor elke Northwood: een gelijke klok/fsb/geheugen snelheid -> alleen de verschillen in cache blijven over.
Voor elke K8: een gelijke klok/HT/geheugen snelheid -> alleen de verschillen in cache blijven over.
Voor elke Prescott: een gelijke klok/fsb/geheugen snelheid -> alleen de verschillen in cache blijven over.
Voor elke Dothan: een gelijke klok/fsb/geheugen snelheid -> alleen de verschillen in cache blijven over.
En niet: klok/fsb/geheugen snelheid K7 setup == klok/fsb/geheugen snelheid Prescott setup == klok/fsb/geheugen snelheid Northwood setup etc. etc. Mocht het laatste toch onverhoopt het geval zijn: leuk, maar niet relevant voor deze test.
Daarnaast ga je iets te kort door de bocht wanneer je het hebt over K8, er zit behoorlijk meer verschil tussen de verschillende K8 cores als alleen de cache grootte. We hebben het ook over het aantal Hypertransport links, de snelheid en breedte daarvan, het aantal ondersteunde instructies (denk aan SSE3), verbeteringen in de cache van de verschillende cores (betere prefetch en dat soort zaken.
Zoals ook vermeld achter K7 -> identieke steppings. Voor elke familie van processoren dus een identieke stepping (voor zover de Xeon hierbij niet in de weg staat). Elimineert gelijk zaken als extra instructies, betere prefetching, grotere TLB's etc.
Wat betreft K8; de niet aanwezige FSB en het aantal HT-links: Het is een test bedoeld voor uniprocessor systemen. De 2 extra aanwezige cHT links in de K8 Opteron variant worden hierbij dus niet belast. Maar dat komt zowiezo al niet tersprake, omdat alle cache configuraties voor de K8 in een socket 939 jasje beschikbaar zijn -> hebben we maar met één HT link van doen, welke we dan gelijk houden/klokken voor alle cache varianten (800 of 1000 MHz of ???? MHz al naar gelang wat beter uitkomt). Voor de geheugen configuratie bij de 'weg met alle communicatie over een FSB' K8: Beetje letten op geheugen multipliers. Moet lijkt me dan prima te doen zijn :).
Je kunt het beste zelf een praktijk test uitvoeren zoals hier gedaan is om te kijken wat in jouw unieke situatie het beste is.
Absoluut mee eens. Maar de test die ik voor ogen heb, moet antwoord geven op de vraag: Wat is de invloed van cache's op integer en fp prestaties. Meer een algemene (aantonende?) test dus.
Dat dit dan eventueel kan verschillen tussen de verschillende processor families (microarchitectuur, cache configuraties etc.), kan bijv. ook een observatie zijn. Maar er zal in ieder geval een antwoord uitrollen :)
Jup ik ben het met je eens het is echt een bijna onmogelijke test. Er zijn zoveel parameters die je test kunnen beinvloeden dat het testen van enkel de cache invloed eigenlijk zo goed als onmogelijk is.

Daarnaast denk ik altijd zo:

Als je kunt kiezen tussen een iets lager clocksnelheid met meer cache of een iets hogere clocksnelheid met minder cache kies dan altijd voor meer cache. De kloksnelheid kun je zelf wel bijwerken. :Y)

Het hangt echt enorm veel van de software en omstandigheden in de software af hoeveel een bepaalde hoeveelheid cache aan invloed heeft. Zit je bijvoorbeeld net in een ongunstige situatie waarbij de branch predictor veel fouten maakt dan ga je dat met minder cache veel zwaarder merken als met meer cache. Die omstandigheden zijn alleen bijna niet te testen. Ook kan het radicaal anders zijn per revisie en core type.

En als je dan al die tijd geld en moeite in de perfecte test hebt gestopt en je eindelijk het antwoord hebt dan komt de fabrikant met een nieuwe core of de software fabrikant met een nieuwe versie... |:(

Je moet het dus altijd een beetje gokken ben ik bang.
In het verlengde van de spec-rate zou ik zeer geinteresseerd zijn in LAPACK en FFT prestaties op verschillende systemen. De meeste benchmarks die op het internet te vinden zijn gaan over 'supercomputers': data over de schootcomputer zijn meestal sterk verouderd.

Zo kun je denken aan:
gcc + MKL (Intel)
gcc + ACML + FFTW (AMD)
gcc + ATLAS + FFTW (Intel en AMD)
ifc/icc + MKL (Intel)
ifc/icc + ATLAS + FFTW (Intel)

en kijken hoe schaalbaar dit is bij het gebruik van 1, 2, 4, ... cores.

Mijn ervaring is dat geheugenintensieve berekeningen (zoals BLAS-3) op een Athlon sneller gaan dan op een Xeon, maar rekenintensieve zijn weer veel sneller op de Xeon. Opterons heb ik nooit kunnen testen...
Als jullie dit nog eens doen is het misschien een idee om de kleuren van de verschillende data-sets wat contrasterender te maken. Vooral op de zesde pagina vond ik het af en toe wat slecht uit elkaar te houden.
Ik heb gekozen voor gelijke kleuren met verschillen lijnstijlen voor dezelfde cpu's zodat snel is te zien hoe de resultaten van dezelfde cpu (met/zonder HyperThreading, single- of multi-client) zich tot elkaar verhouden).
Wat op zich opvalt is dat de idletime niet echt zwaar onderuit gaat. dat wijst op een andere bottlenek. Kan het daardoor niet zo zijn dat het gewoon aan het moederbord c.q. chipset i.p.v. de processoren ?
Er blijft inderdaad maar weinig over als de Cpu's idle zijn en de i/o lang niet vol zit. Maar of het dat dan ook geweest is?

Ik hou het op een combinatie van factoren, want ook bij de relatief snelle bus (tov aantal cpu's en snelheid ervan) bij de Dual Opteron 254 zaten de cpu's niet vol.
Mooie test alleen ik vind het grafiek type niet handig gekozen. Doordat de afstand tussen de stappen tussen de Concurrency overal even groot zijn krijg je een rare lijnen en stijgingspercentages.
Een "rare" lijn (parabolische vorm) krijg je ook wel als de schaal op de x-as lineair is. Het detail in het gebied waar het 't meest om doet (concurrency van 10 of lager) is dan alleen wat kleiner. Voor de vergelijking maakt het weinig uit, ook omdat het belangrijkste gebied optisch het meeste overwicht heeft. Extreem hoge concurrencies komen in de praktijk doorgaans minder vaak voor dat gematigde concurrencies.
Zeer interessant artikel. Kan iemand nog wat meer vertellen over de "ramp-up run"? Is dit gedaan om de caches en buffers te vullen voordat de "echte" test begon?
Precies om die reden ja. Het was overigens gewoon een testrun, zonder naar de resultaten te kijken. ;)
Mooie test zeg!
Ik vind het deel van mySql 4.x en 5.0 erg interessant.

Hebben jullie bij de test gebruik gemaakt van een PHP script?
Daar heb je op dit moment namelijk ook het verschil van de mysql en mysqli library.

De mysqli staat voor mysql Improved en zou veiligheid en snelheids verbeteringen met zich mee moeten brengen.
Hebben jullie hier al wat mee getest toevallig? Voor- en/of na-delen van gevonden?

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True