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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 49 reacties

For your convenience, an English translation of this article is available.

Niagara aankondigingRuim 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.

Gefrustreerde man achter laptopNiet 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.

Merom / Conroe / Woodcrest die (500px)
Intels Core 2-processor: meer logica dan cache



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 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