Multicore is moeilijk

Processorfabrikanten Intel, AMD en Sun hebben hun kaarten gezet op manycore processoren. In de toekomst hebben we processoren met misschien wel honderden of zelfs duizenden kernen. Belangrijke vraag is echter of onze software daar ook iets aan heeft.

Al meer dan veertig jaar voorspelt de Wet van Moore een exponentiële groei van het aantal transistoren op een chip. Dat aantal verdubbelt elke twee jaar. Of het inderdaad een wet is of inmiddels een self fulfilling prophecy is onduidelijk. Wel is zeker dat chipfabrikanten enorme inspanningen moeten leveren om met hun ontwerpen en productieprocessen de Wet van Moore bij te houden.

Daarbij zijn niet alleen grote technische problemen te overwinnen. Naast natuurkundige komen ook economische grenzen steeds meer in zicht. Het ontwerpen van processoren en het bouwen van de chipfabrieken wordt steeds duurder.

Verminderde meeropbrengst

Wat de Wet van Moore zegt over het aantal transistoren op een chip, geldt natuurlijk niet noodzakelijk voor de prestaties van een processor. Het benutten van die extra transistoren is een hele ingewikkelde klus. En hoewel ook het prestatieniveau op softwarevlak exponentieel groeit, gaat dat lang zo snel niet.

In het algemeen is het zo dat de versnelling van nieuwe technologie afneemt naarmate je deze opschaalt of uitontwikkelt (de wet van de verminderde meeropbrengst). Zo kun je de kloksnelheid wel blijven verhogen, maar daarmee vergroot je ook het gat tussen de processor en de geheugenhiërarchie. Dat betekent dat die hoog-geklokte processor steeds meer van zijn cycles ‘bezig’ is met wachten op het geheugen.

Een ander belangrijk probleem is het stroomverbruik. Met het verkleinen van de fabricagetechnologie neemt de statische lekkage enorm toe. Een deel daarvan wordt gecompenseerd door het lagere dynamische verbruik. Bij een fijnere technologie kan men immers met een lager voltage toe. Om de schakelsnelheid te verhogen, zou het voltage weer moeten worden verhoogd, met een sterke (kwadratische) toename van het energieverbruik tot gevolg.

Manycore

Intel en andere processorfabrikanten denken de oplossing voor deze problemen te hebben gevonden in de multicore architecturen. AMD levert inmiddels Phenom quadcore procesoren waarbij daadwerkelijk vier volledige kernen naast elkaar op deze chip zitten. Intel is wat dat betreft iets minder ver en levert quadcore processoren die bestaan uit twee dualcore chips samengebracht in één behuizing. High-end gebruikers (lees: gamers) kunnen deze quadcore processoren straks zelfs in dualprocessor configuraties kopen. Intel en AMD werken aan systemen met in totaal acht kernen onder de respectievelijke namen Skulltrail en FASN8.

Sun is het verst in zijn ontwikkelingen op gebied van multicore voor algemeen gebruik. De UltraSparc T1 (Niagara) heeft acht kernen en ondersteunt vier threads per kern. Dat komt neer op een totaal van 32 threads. Zijn opvolger, de T2, verwerkt al acht maal acht is 64 threads. Bij deze processoren spreekt je dus niet meer van multicore maar van manycore.

Tera-scale

In de toekomst zullen ook Intel en AMD hun processoren in manycore varianten uitbrengen. Belangrijkste ontwikkeling op dit gebied is Intels onderzoeksproject Tera-scale. Onderdeel daarvan is de Larrabee/Polaris-processor met tachtig kernen.

Tot die tijd krijgen we niet alleen meer kernen op de general-purpose processoren – de Nehalem van Intel zal acht kernen bevatten, de Bulldozer processor van AMD acht of zestien – maar ook verschillende soorten kernen. De Fusion processor van AMD wordt voorzien van een geïntegreerde grafische rekenchip (GPU). Daarnaast is er in AMD’s Torrenza-architectuur ook ruimte voor accelerators van derden. Denk daarbij aan hardware specifiek voor encryptie, multimedia en en High-Performance Computing (HPC). Intel werkt aan vergelijkbare technieken.

Bottleneck

Wil deze parallele strategie van de processorfabrikanten inderdaad slagen, dan zijn drastische wijzigingen in de software vereist. Op dit moment is er eigenlijk maar één toepassing die direct op een manycore systeem kan draaien en dat is virtualisatie. Gevirtualiseerde systemen zijn immers volledig onafhankelijk van elkaar en alle virtuele machines en hun processen kunnen zonder verdere synchronisatie op hun eigen thread uitgevoerd worden.

Diezelfde onafhankelijkheid brengt echter met zich mee dat zich een bottleneck vormt op de bus naar het geheugen. Geheugenpagina’s die normaal door processen gedeeld worden – typisch die van het besturingssysteem en de softwarebibliotheken – moeten nu voor elke virtuele machine apart worden geladen. VMware probeert daar met Transparant Page Sharing wat aan te doen. Dat kan echter niet veel meer doen dan simpelweg verschillende geheugenpagina’s met elkaar vergelijken en op elkaar mappen als ze hetzelfde blijken te zijn.

Kijk je een niveau hoger naar de manier waarop processen met het besturingssysteem interacteren, dan zien we daar een vergelijkbare bottleneck. Alle processen op een machine delen immers de kritieke secties (code en datastructuren) van het besturingssysteem. Dat beperkt het aantal programma’s dat op een enkel systeem kan draaien, en dus het aantal threads dat aan het werk wordt gehouden.

Threads

Hoewel er vast nog wel geoptimaliseerd kan worden in de huidige kernels, moet de prestatieverbetering die de manycores ons in het verschiet stellen, toch echt komen uit het parallel maken van de applicaties zelf. Dus het splitsen van programmaonderdelen in delen die onafhankelijk van elkaar verwerkt worden. Dat betekent dat programmeurs hun software moeten omschrijven naar code die zo veel mogelijk gebruik maakt van threads.

Of dat inderdaad op afzienbare termijn gaat gebeuren, is zeer de vraag. Waar parallelle algoritmen vanzelfsprekend en natuurlijk zijn in de wereld van High-Performance Computing en visualisatie, is dat voor algemene en zakelijke toepassingen geenszins het geval. Het prestatieniveau is daar zelden een nijpend probleem. Het is goedkoper om er extra hardware tegenaan te gooien dan grote investeringen te doen in het parallelliseren van moeilijk parallelliseerbare code.

Programmeertalen

Bovendien worden juist dit soort toepassingen tegenwoordig niet meer bottom-up ontwikkeld maar van bovenaf met behulp van een GUI builder in elkaar geklikt. Afgelopen weken hebben we in de media kunnen lezen hoe Java wel geschikt is als productietaal voor general-purpose toepassingen, maar niet als software op specifieke hardware is afgestemd (mapping).

Maar net als Java zijn ook C en C++ niet geschikt om de manycore architecturen te kunnen benutten. Programmeurs willen – en mogen – echt niet de hele dag bezig zijn om zo veel mogelijk parallelliteit uit hun algoritmen te peuren om die in threads vast te leggen. Bovendien is het ondoenlijk om daarbij al rekening te houden met de processoren van de toekomst. Nu zitten er vier of acht kernen in een systeem. Straks zijn dat er tientallen. En als we Intel mogen geloven, worden dat er op termijn vele honderden en misschien wel duizenden.

Wat je wilt is een taal waarin parallelliteit ingebakken wordt op een hoger abstractieniveau dan de huidige thread-libraries dat doen. Op die manier kan het daadwerkelijk parallelliseren en de mapping op de hardware verplaatst worden naar de compiler. Bjarne Stroustrup, de bedenker van C++, deed onlangs dan ook een oproep om te komen tot een nieuwe taal. Deze moet programmeurs betere faciliteiten voor parallellisme geven.

Throughput computing

Interessant is dat Intel als onderdeel van project Tera-scale inderdaad ook een nieuwe programmeertaal heeft ontwikkeld. Ct (C/C++ for Throughput Computing) werkt met zogenaamde throughput vectors (TVEC’s) die niet alleen bekende instructiesets (arrays) kunnen bevatten maar ook andere vormen van parallelle data. Denk aan geavanceerde programmeermiddelen als sparse matrices en associatieve arrays. Intel noemt dit "collections".

De bedenkers introduceren naast taken ook "futures". Dat zijn functies die uitgevoerd kunnen worden zodra hun parameters bekend zijn. Op die manier ontstaat een hele boom van onderling afhankelijke threads. De administratie hiervan doet erg denken aan de manier waarop scoreboards de afhankelijkheden van instructies binnen processoren bijhouden. Dat laat weer duidelijk zien hoe manycores complexiteit van de hardware naar de software verplaatsen.

Voor de uitvoering van Ct-programma’s wordt gebruik gemaakt van een compiler/run-time combinatie vergelijkbaar met die voor Java. De code wordt vertaald naar een variant van x86-code waarbij de vector-instructies (de SSE-uitbreidingen) eerst nog in een generieke vorm worden gecodeerd. Pas bij uitvoering zorgt een JIT-compiler (just in time) voor de mapping van threads en vectorinstructies naar de onderliggende hardware. Op die manier wil Intel zorgen dat programmatuur die nu geschreven of onder handen genomen wordt, in de toekomst opschaalt naar veel grotere manycores.

Beproefd middel

Hoewel er de komende jaren veel onderzoek op dit gebied zal plaatsvinden, is het nog maar de vraag of manycore processoren inderdaad voor algemene toepassingen uitgenut kunnen worden. Het risico bestaat dat de manycores voor dergelijke applicaties praktisch niet bruikbaar blijken te zijn. Het is destijds immers ook lastig gebleken de extra investeringen te rechtvaardigen voor 4-way en later 8-way SMP x86-systemen.

Feit is dat universiteiten cursussen, programmeertalen, compilertechnologie en onderzoek moeten ontwikkelen op het gebied van parallelle architecturen. Komt daar niet uit wat een bedrijf als Intel voor ogen heeft, dan is het waarschijnlijk dat we op termijn toch weer moeten teruggrijpen op het beproefde middel van de hogere kloksnelheid.