Introductie: problemen van moderne cores
For your convenience, an
English translation of this article is available.
Ruim drie jaar geleden kwam Sun voor het eerst met informatie naar buiten over een eigenwijs nieuw concept voor serverprocessors. Het idee was om niet langer te proberen om één taak snel uit te voeren, maar in plaats daarvan met heel veel taken tegelijk bezig te zijn, om netto toch goede prestaties neer te zetten. Het eerste resultaat van deze drastische koerswijziging is de UltraSparc T1 'Niagara', die eind vorig jaar werd geïntroduceerd. In dit artikel wordt de visie achter deze processor ontleed, gekeken naar de servers die Sun er omheen heeft gebouwd en bovenal testen in hoeverre dit nieuwe concept bruikbaar is voor een websitedatabase als die van Tweakers.net. Een 'traditionele' server met twee dualcore Opterons dient als vergelijkingsmateriaal. We maken ook meteen van de gelegenheid gebruik om te kijken naar de verschillen aan de softwarekant, zoals tussen MySQL en PostgreSQL, en Solaris tegen Linux.
Achtergrond: het probleem
De motivatie van Sun om aan het ontwerpen van Niagara en zijn opvolgers te beginnen was dat het steeds moeilijker wordt om conventionele cores sneller te maken: het toevoegen van extra spierkracht in de vorm van gigaflops is kinderspel, maar ervoor zorgen dat die kracht ook nuttig gebruikt kan worden, is een uitdaging waar duizenden slimme mensen zich dagelijks het hoofd over breken. Omdat andere hardware zich lang niet zo snel ontwikkelt als processors duurt het - vanuit de core gezien - bijvoorbeeld steeds langer voor data uit het geheugen beschikbaar is. Er is (en wordt) heel veel onderzoek gedaan naar technieken om de gemiddelde toegangstijd te minimaliseren en/of deze op een of andere manier nuttig te gebruiken in plaats van domweg te wachten, maar desondanks wordt het gat groter.
Niet alleen het geheugen vormt een bottleneck: ook de code zelf werkt vaak stug tegen. Instructies zijn vrijwel altijd op een of andere manier van elkaar afhankelijk, in de zin dat de uitkomst van de ene nodig is als invoer voor de andere. Iedere moderne core kan tussen de drie en acht instructies tegelijk uitvoeren, maar gemiddeld mag men al van geluk spreken als er twee gevonden kunnen worden die volledig los van elkaar staan. Veel vaker is het er maar één, en het komt ook regelmatig voor dat er helemaal geen opdrachten gevonden kunnen worden die op dat moment veilig de pipeline ingestuurd kunnen worden. Met de hand geoptimaliseerde code zal in veel gevallen wel beter presteren, maar niet alles kan opgelost worden door betere software: voor de meeste algoritmes zijn er harde praktische en theoretische limieten.
Het domweg opdrijven van de kloksnelheid door steeds kleinere transistors te gebruiken is ook geen optie meer, nu klanten zich steeds bewuster worden van het energieverbruik van hun servers. De diepe pipelines die ervoor nodig zijn om hoog te klokken maken het bovendien nog moeilijker om de beschikbare rekenkracht optimaal te benutten, waardoor het zelfs met een riant vermogensbudget niet bepaald een simpele klus is om een 'racemonster' te bouwen dat daadwerkelijk meerwaarde biedt op het gebied van prestaties. Kortom: de makkelijkste trucs om de prestaties van een core te verbeteren zijn al lang en breed op, en dus moeten er steeds grotere investeringen in complexiteit worden gedaan om relatief kleine winsten te boeken.
Complexiteitsexplosie
Bijna alle moderne processors hebben als gevolg van de genoemde problemen tientallen tot honderden miljoenen transistors aan boord die eigenlijk helemaal niets bijdragen aan de functionaliteit van de chip, maar puur en alleen nodig zijn om bottlenecks in de rest van het systeem te verzachten. We hebben het dan niet alleen over cache, maar bijvoorbeeld ook over functionaliteit om instructies in een andere volgorde uit te voeren dan de ontwikkelaar heeft gespecificeerd, of om te gokken dat de code bij een tweesprong een bepaalde kant op gaat. Fouten maken is uiteraard geen optie, en dus moeten er letterlijk honderden instructies - inclusief hun onderlinge afhankelijkheden - tegelijk gevolgd kunnen worden om de correcte executie van de code zelfs in de meest onwaarschijnlijke samenloop van omstandigheden te kunnen garanderen.
Intel, AMD en IBM doen nog steeds hun best om deze problemen het hoofd te bieden met hun nieuwste generaties x86- en Power-processors. Deze bedrijven pompen dan ook veel geld in het ontwerpen en verbeteren van hun cores, terwijl ze vechten tegen toename in complexiteit. Ondertussen wordt er ook een alternatief pad bewandeld: in de Itanium-serie is een hoop van de genoemde logica uit de hardware gehaald en afgeschoven op de compiler. Het idee hierachter is dat het ontwikkelen van krachtige cores op langere termijn steeds makkelijker zal worden vergeleken met andere architecturen, terwijl de software naar verloop van tijd steeds slimmer wordt. Compilers hebben immers zeeën van tijd om parallellisme te vinden, vergeleken met een processor die in een fractie van een microseconde moet kunnen beslissen. In de praktijk zijn er natuurlijk een hoop extra afwegingen die het succes van de Itanium-aanpak zullen bepalen, maar dat is meer iets voor een later artikel.
Intels Core 2-processor: meer logica dan cache
De UltraSparc T1 'Niagara'
Terug naar Sun: de processors van het bedrijf waren tijdens de dotcom-hype helemaal hip: er was bijna geen betere manier om indruk te maken op investeerders dan een 19"-rack goed gevuld met Enterprise- of Fire-servers. De laatste jaren moeten de Sparcs het echter steeds vaker afleggen tegen hun concurrenten, en dat heeft zich vertaald naar consequent dalende verkoopcijfers. In 2001 verkocht het bedrijf voor 6,9 miljard dollar Sparc-hardware, goed voor een aandeel van 13,7% in de totale servermarkt. In 2005 was bijna een derde van de omzet verdampt, ondanks het feit dat de pijn de laatste jaren iets is verzacht door de verkoop van x86-servers, waaronder de begin 2004 geïntroduceerde Opteron-lijn.
Sun was en is natuurlijk niet blij met deze trend, maar leek echter ook geen hoop meer te hebben om het rappe tempo waarmee anderen hun cores verbeteren bij te houden. Met het annuleren van de UltraSparc V - de evolutionaire opvolger van de huidige UltraSparc IV+ - werd de handdoek in de ring gegooid voor wat betreft singlethread prestaties. Deze radicale stap hield in dat Sun zijn toekomst als processorbakker inzette op Niagara, de codenaam van een ontwerp dat het in 2002 had verkregen tijdens de overname van Afara Websystems. Oorspronkelijk bedoeld om als netwerkprocessor te worden gebruikt, leunt dit product niet op een snelle core maar op een combinatie van CMT en CMP - Chip Multi-Threading en Chip Multi-Processing. Men noemt dit concept 'Throughput Computing' of tegenwoordig officieel 'CoolThreads Technology'. Om dit voor leken te illusteren gebruikt Sun de volgende analogie:
Waarbij het antwoord natuurlijk afhankelijk is van het aantal mensen dat mee moet.
Natuurlijk hebben andere processorbakkers dezelfde trends gezien als Sun. De komst van multicores was dan ook al lang en breed voorspeld - en zelfs al deels uitgevoerd - voor Sun met zijn strategie de openbaarheid zocht. Het verschil is echter dat de rest het allemaal niet zo radicaal aanpakt: de concurrentie probeert nog steeds een middenweg te vinden tussen geavanceerde cores met goede singlethread prestaties, gekoppeld met een bescheiden duplicatie daarvan. Op dit moment zijn de meeste bedrijven het er over eens dat twee cores per socket voor het hier en nu wel prima is, hoewel de eerste quadcores ook al in zicht zijn. Sun heeft er echter geen gras over laten groeien, en is met het eerste product in de serie direct naar acht cores gesprongen.
De cores van de Niagara zijn relatief eenvoudig: op multithreading na wordt er op conceptueel niveau niet veel meer gedaan dan in een 486: er wordt maximaal één instructie per kloktik uitgevoerd en alles gebeurt precies in de volgorde waarop het binnenkomt. De multithreading is ook niet bijster geavanceerd: er wordt simpelweg iedere kloktik overgeschakeld naar de volgende van de maximaal vier actieve threads. Dit is een stuk eenvoudiger dan bijvoorbeeld HyperThreading (SMT), waarbij instructies uit meerdere threads tegelijk de pipeline in kunnen gaan. Door het ontwerp van de cores simpel te houden kunnen er echter wel acht stuks samen met een quad channel geheugencontroller én een gedeelde FPU op een chip worden geïntegreerd, zonder het stroomverbruik door het dak te jagen. De volledige specificaties, vergeleken met die van de Opteron, zijn als volgt:
| | Sun UltraSparc T1 | AMD Opteron (Revisie E) |
|---|
| Cores | 8 | 2 |
| Threads per core | 4 | 1 |
| | |
| Procédé | 90nm | 90nm |
| Kloksnelheid | 1,0 - 1,2GHz | 2,2 - 2,6GHz |
| Aantal transistors | 300 miljoen | 233 miljoen |
| Grootte | 380mm² | 194mm² |
| | |
| Pipeline ontwerp | In-order | Out-of-order |
| Pipeline lengte (integer) | 6 stappen | 12 stappen |
| Pipeline lengte (float) | N.v.t. | 17 stappen |
| Max. instructies per klok | 1 | 3 |
| L1-cache (per core) | 8KB data, 16KB instructie | 64KB data, 64KB instructie |
| L2-cache | 3MB (gedeeld) | 2MB (1MB per core) |
| | |
| Geheugencontroller | 4x DDR2-533 (34,1GB/s) | 2x DDR400 (12,8GB/s) |
| Onderlinge communicatie | Interne crossbar (134GB/s) | HyperTransport (24GB/s) |
| Aantal pinnen socket | 1933 | 940 |
| TDP | 79W | 95W |
Als we een paar - veel te oppervlakkige, maar desondanks illustrerende - rekensommen doen komen we op de volgende statistieken uit: de Niagara-processor heeft per core 48mm², 38 miljoen transistors en 10 watt nodig, terwijl de Opteron 97mm², 117 miljoen transistors en 48 watt per core opeist. Sun heeft dus echt een uniek ontwerp neergezet dat nauwelijks lijkt op zijn concurrenten. Het is zelfs de vraag of er nog wel van concurrenten gesproken kan worden: de T1 heeft een aantal eigenschappen die hem per definitie buitensluiten van een groot deel van de markt. Door een tekort aan FPU-kracht, de onmogelijkheid om meer dan één chip per moederbord te installeren en slechte singlethread prestaties vormt hij op veel gebieden geen bedreiging voor Intel, IBM of AMD. Wel zijn er een aantal specifieke gebieden waar de Niaraga uitblinkt, zoals Sun graag laat zien op zijn website. Ook legt het bedrijf veel nadruk op de prestaties per watt. Hoogste tijd dus om dit type server eens onder de loep te nemen, en te kijken hoe deze zich verhoudt tot een 'traditionele' Opteron-configuratie.
Testkandidaten: T2000 en X4200
Voor deze test zijn twee machines van Sun gebruikt: een T2000 en een X4200. Beide zijn 2U rackmounted servers, met als belangrijkste verschil de processors: het hart van de T2000 is een UltraSparc T1 met acht cores op 1GHz, terwijl de X4200 is uitgerust met twee dualcore Opteron 280-processors op 2,4GHz. Beide machines hadden twee 73GB SAS-schijven van Fujitsu (2,5", 10.000rpm), aangesloten op een LSI RAID-controller. Er zijn nog wel andere verschillen: zo had de UltraSparc 16GB DDR2-533-geheugen aan boord, terwijl de Opteron het met 8GB DDR400 moest doen. Onze tests hebben aangetoond dat de stap van 4 naar 8GB geheugen al nauwelijks winst oplevert voor onze benchmark, dus we geloven niet dat de T2000 met zijn zestien gigabytes een oneerlijk voordeel heeft gehad.
Een ander klein punt is dat de SAS-controller bij de T2000 werd meegeleverd als een losse insteekkaart, terwijl hij bij de X4200 op het moederbord gesoldeerd zat. Verdere verschillen zijn er vooral in de bouw van de machines: hoewel beide erg netjes ogen en bovendien solide lijken te zijn, heeft Sun voor de ene toch net iets andere keuzes gemaakt dan voor de andere. De dubbele Opteron heeft met zijn 190W TDP bijvoorbeeld dikkere koeling nodig dan de UltraSparc T1 van 79W. Het ontwerp van de koeling is wel hetzelfde: koele lucht wordt aan de voorkant aangezogen en recht over de processors en het geheugen heengeblazen. Het deksel van de kast is zo ontworpen dat de heetste onderdelen de meeste airflow krijgen.
T2000
X4200
Beheer op afstand met ILOM en ALOM
Voor servers is beheer op afstand vaak een absolute vereiste, en veel features bieden op dat vlak is dus een goede manier voor fabrikanten om zich van elkaar te onderscheiden. Sun heeft op dit moment twee verschillende systemen in gebruik: ALOM en ILOM. Met beide systemen kan een hoop gegevens over de hardware worden uitgelezen en is het mogelijk om waarschuwingen te laten versturen als er dingen fout (dreigen te) gaan. Ook kan de console van Linux of Solaris worden overgenomen en in geval van nood is er nog de optie voor een harde reset.
Het verschil tussen de twee systemen is vooral de manier waarop deze functies toegankelijk zijn: ALOM is alleen via telnet (onbeveiligd), ssh (beveiligd) of een seriële kabel toegankelijk, en wordt dus via een command line bediend. ILOM daarentegen kan ook via een ingebouwde https-server benaderd worden, waarbij een gebruiksvriendelijke grafische interface beschikbaar is die een stuk sneller te doorgronden valt.
Helaas is alleen de X4200 (Opteron) voorzien van ILOM; de T2000 moet het voorlopig doen met ALOM. Er is niet omheen te komen: de UltraSparc-server heeft geen aansluiting voor een monitor, en om een nieuw besturingssysteem te installeren (of de standaard aanwezige pre-installatie van Solaris 10 af te maken) moet er via een andere machine gewerkt worden. Ook staat de netwerkinterface standaard uitgeschakeld, wat een beheerder verplicht om op zijn minst één keer met een seriële kabel aan de slag te gaan. Sun heeft overigens aangeven dat dit laatste punt in de toekomst verbeterd zal worden. Over het installeren van de X4200 hebben we geen klachten: dit kan gewoon via een monitor of de standaard ingeschakelde netwerkverbinding, zonder verder gekke dingen te doen.
ALOM
ILOM
MySQL-optimalisaties
Het testen van de UltraSparc T1 was geen makkelijke taak: we zijn ruim drie maanden bezig geweest om de optimale configuratie te vinden voor onze test, waarbij er door ons is samengewerkt met mensen van Sun, die op hun beurt weer met mensen van MySQL aan de slag zijn gegaan. In totaal zijn er ruim twee miljard queries gedraaid, verdeeld over ruim 3500 runs, die in serie meer dan 19 dagen zouden duren. Tijdens ons onderzoek hebben we zeer uiteenlopende resultaten gezien, wat ons leert dat deze machine niet makkelijk te temmen is. Wie het onderste uit de kan wil halen moet zorgen voor de juiste combinatie van software en instellingen, iets wat veel geduld kan vereisen. We zijn er nu redelijk van overtuigd dat we het beste hebben gedaan van wat we tot op dit moment hebben kunnen doen, maar Sun heeft onze benchmark op dit moment nog steeds in onderzoek, omdat het bedrijf gelooft dat het beter moet kunnen. Naar aanleiding van de problemen die wij ondervonden heeft men een verbetering bedacht voor de Sun Studio-compiler die later mogelijk een behoorlijke winst kan opleveren, maar we wilden daarop niet meer wachten met het publiceren van onze bevindingen.
Ten opzichte van het vorige artikel zijn er een aantal dingen veranderd aan de testmethode. Het meest zichtbare is dat we voor de resultaten over zijn gestapt van 'queries per seconde' naar 'requests per seconde'. Hierdoor kunnen verschillende databases beter met elkaar vergeleken worden, omdat de een meer queries nodig kan hebben om dezelfde pagina op te bouwen dan de ander. Een voorbeeld hiervan is MySQL 4.x, dat niet echt optimaal omgaat met subqueries en daardoor sneller is met een groter aantal simpelere opdrachten. Dit terwijl een alternatief als PostgreSQL zijn beste kant juist laat zien met ingewikkelde queries, waar er ook minder van nodig zijn.
Verder hebben we nu standaard twee cliëntmachines gebruikt om belasting op de database te genereren, omdat in onze vorige review - helaas pas tegen het einde van de test - bleek dat dit structureel betere resultaten opleverde. Ook hebben we functionaliteit ingebouwd die ons in staat stelt om cores en/of threads uit te schakelen, zodat we het schaalgedrag van de servers beter kunnen bestuderen.
Om het grote effect dat een paar kleine veranderingen kunnen hebben te demonstreren, staat hieronder een grafiek met verschillende MySQL 5.x-resultaten die we tijdens ons onderzoek hebben verkregen. Er is steeds een gelijk aantal cores en evenveel geheugen gebruikt, maar desondanks lopen de scores tussen verschillende versies van MySQL wild uiteen. Ook de instellingen kunnen een wereld van verschil maken: een door Sun onder handen genomen 5.0.18-versie was bijvoorbeeld behoorlijk sneller dan onze oorspronkelijke configuratie, terwijl er eigenlijk maar één parameter was aangepast.
MySQL-schaalgedrag
In ons eerdere artikel moesten we al concluderen dat MySQL 4.x nou niet bepaald goed schaalt met meerdere cores/threads, maar omdat het (nog) wel de versie is waar onze site en vele andere op draaien, wilden we toch kijken hoe deze software zich zou houden op de UltraSparc T1. De eerste twee stappen naar respectievelijk twee en vier cores verlopen nog soepel, maar de volgende, van vier naar zes, stelt al enigszins teleur. De laatste stap naar acht cores blijkt zelfs nauwelijks merkbaar te zijn in de prestaties. Onder de zwaardere belastingen (tien en hoger) levert de eerste verdubbeling van het aantal cores 112% prestatiewinst op, de tweede 78% en de laatste nog maar 18%.
In MySQL 5.0 zijn een hoop problemen met betrekking tot de schaalbaarheid opgelost, wat zich vertaalt naar duidelijk hogere prestatiepieken. Desondanks valt er met acht cores nog steeds weinig winst te halen, en bovendien is er een vrij dramatisch nieuw gedrag geïntroduceerd. Bij zwaardere belasting (meer dan 40 gelijktijdige gebruikers) zakken de prestaties als een plumpudding in elkaar. Erger nog: hoe hoger de piek, hoe dieper het dal. Waar we bij 25 gelijktijdige gebruikers nog logische resultaten terugkrijgen, komen er bij 50 en hoger bizarre situaties naar voren waarin 1 core sneller is dan 8 cores. De reden hiervoor is niet duidelijk: noch onze ervaren systeembeheerders, noch de experts bij Sun en MySQL konden voor een oplossing zorgen. Ook experimenten met verschillende (bèta)versies leverden geen enkele verbetering op, waardoor we voor nu gewoon moeten accepteren dat het zo is.
MySQL vs. PostgreSQL
Hoewel MySQL waarschijnlijk de bekendste naam heeft van alle opensourcedatabases, zijn er een aantal zeer goede alternatieven te verkrijgen. Een daarvan is PostgreSQL, waarvan de ontwikkeling in 1986 van start ging. Het doel van het project was in eerste instantie om een opvolger van een andere database genaamd Ingres te ontwerpen. Vandaar ook de naam van het pakket: 'post-Ingres' is langzaam verbasterd naar Postgres en later dus PostgreSQL. De database is inmiddels al bij versie 8.1 beland en wordt beschouwd als zijnde minstens even goed als MySQL, zo niet beter. Omdat de discussie over 'de beste' database een gevoelige en langdradige is wordt deze in dit artikel vermeden, maar het is toch wel interessant om eens te onderzoeken hoe goed of slecht Tweakers.net zou draaien op PostgreSQL.
We kozen ervoor om een cvs-snapshot van PostgreSQL 8.2 (alpha) te compileren, omdat deze naar verluidt beter zou kunnen schalen dan de huidige officiële releases. Omdat er ook een bèta van MySQL 5.1 is geprobeerd vonden we dat PostgreSQL dezelfde kans verdiende. Toen bleek dat de 8.2-versie ondanks zijn experimentele status probleemloos en erg snel werkte, zagen we geen reden meer om terug te vallen op de laatste release.
In tegenstelling tot alle versies van MySQL die we hebben geprobeerd vertoont PostgreSQL bijna perfect schaalgedrag. Onder belasting van tien gelijktijdige gebruikers of meer levert de stap van één naar twee cores gemiddeld 114% betere prestaties op, de stap naar vier cores 96%, en vervolgens naar acht cores nog eens 77%. Dit betekent dat acht cores in totaal 7,4 keer de prestaties leveren van één core. Wat verder een verademing is ten opzichte van MySQL, is dat de prestaties stabiel blijven nadat ze hun maximum hebben bereikt. De server met meer werk opzadelen dan hij eigenlijk aankan zorgt dus niet voor de instorteffecten die we eerder zagen. Wanneer we alleen kijken naar de zware belastingen aan het einde van de grafiek zien we dat de lijnen ongeveer plat worden, waardoor de schaalcijfers nog beter zijn: de winsten van de coreverdubbelingen naar 2, 4 en 8 zijn boven de 40 gelijktijdige gebruikers respectievelijk 122%, 104% en 98%, wat betekent dat het prestatieverschil tussen één en acht cores gemiddeld een factor 9 is.
PostgreSQL zou zo een schoolvoorbeeld kunnen worden voor een goede implementatie van multithreading, en is daardoor precies het soort applicatie waar de UltraSparc T1 zijn tanden in kan zetten. Zolang niet te veel rekenkracht nodig is, maar de software wel in staat is om zich probleemloos op te splitsen in onafhankelijke delen is de T2000 volledig in zijn element. De hieronder weergegeven grafiek van MySQL 5.0.20a (dezelfde als die op de vorige pagina, maar met aangepaste schaal) laat nog eens zien hoe groot het contrast is, en dus hoe belangrijk het is om niet zomaar multithreading in de software te hebben, maar ook een goed schalende implementatie ervan.
Het heeft behoorlijk wat voeten in de aarde gehad om onze benchmark geschikt te maken voor PostgreSQL: de normale code van Tweakers.net is namelijk sterk geoptimaliseerd om de unieke 'persoonlijkheid' van MySQL 4.0 te bevredigen. Een directe kopie van de database en queries leverde dramatisch slechte resultaten op, dus om PostgreSQL een eerlijke kans te geven zijn indices verplaatst, subqueries toegepast en bepaalde joins omgeschreven. Deze optimalisaties zorgden voor een factor vier betere prestaties. Toch is er lang niet zoveel moeite in gestoken als in de MySQL-optimalisaties die letterlijk in de loop der jaren zijn gevonden, waardoor we vermoeden dat er nog wel meer uit te slepen valt.
Sun UltraSparc T1 vs. AMD Opteron
We hebben nu gezien dat de Sun UltraSparc T1 - mits voorzien van de juiste software - goed kan opschalen. Dit gegeven is op zich wel leuk om ermee te demonstreren wat de achterliggende filosofie is, maar zonder vergelijkingsmateriaal zegt het natuurlijk weinig over de potentie van de processor. Zijn 32 trage threads snel genoeg om twee of vier snelle cores te verslaan? Om die vraag te beantwoorden bestelden we naast de T2000 ook een X4200, voorzien van twee 2,4GHz dualcore Opterons. Om het besturingssysteem uit de vergelijking te halen werd op de X4200 ook Solaris 10 gebruikt. Wel had de Opteron 'maar' 8GB geheugen (in plaats van 16GB voor de T2000), maar zoals al eerder werd aangegeven heeft alles boven de 4GB weinig invloed op de prestaties in deze benchmark.
Wat we onmiddellijk zien is dat de Opteron-server niet alleen duidelijk beter presteert dan de UltraSparc T1, maar ook dat deze eerder zijn piek bereikt. De X4200 toont zijn volle kracht al vanaf ongeveer 10 gelijktijdige gebruikers, terwijl de T2000 pas rond de 40 zijn volledige potentieel bereikt. Wanneer we naar beneden schalen zien we dat twee Opteron-cores geen enkele moeite hebben om vier Niagara-cores te verslaan. We hebben dit zowel bevestigd door van beide Opterons één core uit te schakelen, als door gewoon een van de processors volledig uit te schakelen. Het verschil in prestaties was daarbij minimaal.
In MySQL komt hetzelfde beeld terug, behalve dan dat het er voor de T2000 nog minder goed uitziet vanwege het slechte schaalgedrag. Opvallend genoeg heeft de Opteron geen last van de diepe val die de prestaties onder hoge belasting maken bij de UltraSparc T1, hoewel het er na een bepaald punt zeker niet beter op wordt. Hoe dan ook zijn in MySQL de twee Opteron-cores in alle gevallen sneller dan acht Niagara-cores. Het vrij bedroevende beeld in MySQL maakt niet bepaald reclame voor de filosofie om cores te versimpelen om er dan zoveel mogelijk op een chip te kunnen plakken. Er zijn echter mensen die wél succes hebben gehad om MySQL te laten vliegen op de UltraSparc T1, maar kennelijk is ons belastingspatroon er simpelweg niet geschikt voor.
Solaris vs. Linux
De enige factor die niet in de vergelijking op de vorige pagina is meegewogen is die van het besturingssysteem. De UltraSparc T1-server is in deze review getest met de nieuwste versie van Suns eigen Solaris 10. Om de vergelijking eerlijk te houden werd op de Opteron-machine hetzelfde geïnstalleerd, maar nieuwsgierig als we zijn wilden we natuurlijk ook wel eens weten wat precies het verschil in prestaties tussen Solaris en Linux. We kozen voor Ubuntu server edition, maar slaagden er niet in om dit aan de praat te krijgen op de T2000. Vandaar dat we alleen resultaten voor de Opteron hebben, maar die vertellen op zich al een duidelijk verhaal: bij concurrencies van 15 en hoger was Solaris gemiddeld 6% en 14% sneller dan Linux in respectievelijk PostgreSQL en MySQL. Opvallend is wel dat laatstgenoemde wel een hogere prestatiepiek vertoont onder Linux.
Voor de volledigheid dient hierbij wel even vermeld te worden dat het ons niet gelukt is om de geïntegreerde SAS-controller van de X4200 onder Linux aan de praat te krijgen, en daarom hebben we in plaats daarvan een losse Areca 1120-kaart met een paar Raptors ingezet. Volgens onze schijfexpert Femme zou die opstelling wel beter presteren, maar omdat er geen RAID is gebruikt en het systeem 8GB geheugen had (terwijl de schijfactiviteit met 4GB al extreem laag was), geloven we dat de invloed hiervan minimaal is geweest.
Stroomverbruik, prijzen en conclusie
We kunnen helaas niets anders dan teleurgesteld zijn in de prestaties van de UltraSparc T1: zelfs met het perfect opschalende PostgreSQL wordt de machine keihard voorbijgestreefd door een middenmoot Opteron-server die voor net iets meer dan de helft van de prijs te koop is. Het is te hopen dat de T2000 zich in andere situaties beter houdt en de prestatiewinsten dan ook groot genoeg zijn om het prijsverschil te verantwoorden, want anders zou de chip met zijn radicale ontwerp wel eens onder de voet gelopen kunnen worden door concurrenten die de overstap naar multicore geleidelijker en conserveratiever aanpakken. Een pluspunt van de T2000 is wel dat de processor erg zuinig is: gemeten aan het stopcontact heeft het apparaat onder volle belasting slechts 232 watt nodig, terwijl de Opteron-server tijdens het uitvoeren van dezelfde taken bijna de helft meer verstookt. Gekeken naar de prestaties per watt in PostgreSQL komen we uit op een piek van 1,17 requests per seconde per watt voor de Opteron en 1,34 requests per seconde per watt voor de T2000, een verschil van ongeveer 15% in het voordeel van de Niagara. Sun zelfs wil in zijn zelfbedachte SWaP-maatstaaf ook nog de hoogte van de server meerekenen, maar aangezien beide 2U waren verandert dat in dit geval het beeld niet.
 |
 | Stroomverbruik | |
|
| Sun X4200 (4 cores, 2,4GHz) - load |    341 | |
|
| Sun X4200 (4 cores, 2,4GHz) - idle | 274 | |
|
| Sun T2000 (8 cores, 1GHz) - load |    232 | |
|
| Sun T2000 (8 cores, 1GHz) - idle | 223 | |
|
|
| Prijzen in euro's (bron: Sun.nl, 16-7) | |
|
| X4200 (4-core, 2,4GHz, 8GB) | 6800 | |
|
| T2000 (4-core, 1GHz, 8GB) | 8300 | |
|
| T2000 (6-core, 1GHz, 8GB) | 10900 | |
|
| T2000 (8-core, 1GHz, 8GB) | 13400 | |
|
Belangrijk om hier in de gaten te houden is dat we hier maar één applicatie hebben getest, namelijk de database van Tweakers.net. Dat de T2000 voor die toepassing geen goede keuze zou zijn betekent niet dat de machine direct afgeschreven moet worden: wellicht is hij bijvoorbeeld wel interessant als webserver. Sun heeft verschillende records gebroken met de T2000 en er zijn dus toepassingen te bedenken waar de processor beter in zijn element is. De belangrijkste conclusie die we kunnen trekken is dat kopers van deze server heel erg goed op moeten passen waar ze hem voor willen gebruiken, want als een applicatie toevallig net niet in het straatje van de UltraSparc T1 past kan het een dure miskoop zijn. Zulke risico's zijn bij servers met gewone Opterons of Xeons een heel stuk kleiner. Gelukkig begrijpt Sun dit zelf ook, en is het bedrijf erg behulpzaam voor mensen die de T2000 een keer willen uitproberen.
De toekomst
De UltraSparc T1 is slechts de eerste van Suns nieuwe lijn processors. Als we de roadmap mogen geloven dan zal volgend jaar de op 65nm gebakken Niagara II verschijnen. Volgens de geruchten zal deze twee keer zoveel threads tegelijk kunnen verwerken, iets hoger klokken (maximaal 1,4GHz) en voor iedere core een eigen FPU hebben, in plaats van één gedeelde. Verder zou er in plaats van directe ondersteuning voor DDR2 overgestapt worden op FB-DIMM. In 2008 zou vervolgens Rock verschijnen, die vooral betere singlethread prestaties zou moeten bieden. Sun heeft volgens de geruchten een erg interessante manier bedacht om multithreading op een flexibele manier aan te pakken. In principe zouden zestien 'cores' ieder aan twee threads gaan werken, maar het cache zou worden gedeeld door groepjes van vier: ieder kwart van de processor zou 64KB L1 en 2MB L2 krijgen. Naar verluidt kunnen de cores echter niet alleen hun caches met elkaar delen, maar ook ongebruikte rekenkracht. Er zou dus ook wel gesproken kunnen worden over vier 'supercores' die ieder acht threads afhandelen.
Hoewel Sun een hoop innovatieve ideeën heeft voor toekomstige processors, heeft het wel een groot risico genomen door dit pad te bewandelen: de chip is lang niet zo breed inzetbaar als zijn x86-concurrenten en kan ook niet meedoen in de hogere marktsegmenten waar Power en Itanium leven. Uiteraard heeft het ontwerp wel zijn unieke sterke punten, maar hij zal op die gebieden erg goed moeten gaan verkopen om het wegvallen van de rest te compenseren. Op dit moment bewaakt de UltraSparc IV+ het fort nog, maar met het annuleren van diens opvolger zal de Niagara-lijn zich uiteindelijk helemaal zelf moeten gaan redden. Tot nu toe is nog niet gebleken dat de verkoopcijfers spectaculair zijn: in de presentatie over zijn meest recente kwartaalcijfers liet Sun wel weten dat ten opzichte van vorig jaar iets meer servers had verkocht, maar uit een nog veel sterkere stijging van de - pas geleden weer versterkte - Opteron-machines - kunnen we concluderen dat de Sparc-verkopen nog steeds dalende zijn. Op dit moment is Niagara goed voor 100 miljoen dollar omzet per kwartaal, op een totale serveromzet van 1,3 miljard.
Sun zal het ontwerp flink onder handen moeten nemen om het breder inzetbaar te maken, maar lijkt de laatste tijd alleen maar aan het bezuinigen te zijn op zijn de processorafdeling. Met het annuleren van de UltraSparc V raakten vijfhonderd man hun baan kwijt; later zijn er nog zestig naar AMD gegaan en recent zijn er weer tweehonderd ontslagen, onder andere mensen die bezig waren met co-processors voor Rock. Na het aftreden van Scott McNealy heeft de nieuwe CEO Jonathan Schwartz aangekondigd dat er nog eens vier- tot vijfduizend banen gaan verdwijnen bij Sun. Onduidelijk is in hoeverre de chipafdeling hierdoor wordt getroffen. Als Niagara en opvolgers geen succes worden zal het voor Sun waarschijnlijk geen grote ramp zijn: sinds vorig jaar heeft het een deal met Fujitsu om servers met diens Sparc64-processors te verkopen. Ook zou x86 een deel op zich kunnen nemen: Transitive (bekend van de PowerPC-emulator die Apple gebruikt voor zijn Intel-Macs) heeft zijn software pas geleden uitgebreid om ook Sparc te kunnen draaien.
Het is te hopen dat de Niagara een groot genoeg deel van de markt weet te veroveren om de toekomstige ontwikkeling te blijven rechtvaardigen. Diversiteit op de markt is namelijk goed voor de consument, en Sun zou met deze chips een van de weinige bedrijven kunnen worden die met succes het gevecht tegen de x86-bierkaai aangaat. We vragen ons echter hardop af of hoe ver Sun bereid is om hiermee te gaan: zal het er koste wat kost een succes van proberen te maken, of zal het hele concept slachtoffer worden van bezuinigingen als het niet snel genoeg geld in het laatje begint te brengen? Volgens Sun zelf is het bedrijf in ieder geval vastberaden om door te zetten: de roadmap loopt tot voorbij 2010.
Dankwoord
Tweakers.net wil graag de volgende mensen bedanken; Bart Muyzer en Hans Nijbacker (Sun Nederland) voor hun medewerking aan dit artikel en hun voortdurende inspanningen om de benchmarkresultaten te verbeteren; Jochem van Dieten (databaseconsultant en vaste GoT-bezoeker) voor zijn hulp met PostgreSQL; en natuurlijk ACM en moto-moi voor het uitvoeren van de tests en de hulp bij het verwerken en interpreteren van de resultaten.
/i/1247490657.png?f=fpa)
/u/2425/LOGO2S.JPG?f=community){kind=small}
/u/1830/acm.png?f=community){kind=small}
:strip_icc():strip_exif()/u/81722/bacardi.jpg?f=community){kind=small}
:strip_exif()/u/43775/ajunne.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/29534/moto-icon.jpg?f=community){kind=icon}
Ik ben met je eens dat Solaris erg lekker werkt, al voelt het in eerste instantie wel wat spartaans aan voor een GNU/Linux admin/u/70160/herko-icon.png?f=community){kind=icon}
/u/89535/crop56f4e5c063de4.png?f=community){kind=small}
/u/1/femme.png?f=community){kind=small}
:strip_icc():strip_exif()/u/49652/HomerInBlack2.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/36378/crop5a3f931ecfec0_cropped.jpeg?f=community){kind=small}
:strip_exif()/u/818/we33ee45.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/6511/icoon%2520t.net.jpg?f=community){kind=small}
/u/8/oog3.png?f=community){kind=small}