Software maakt vandaag zelden optimaal gebruik van de multicoreprocessoren die je nu zelfs in de goedkoopste desktops aantreft. Een probleem dat al jaren geleden voorspeld is. En nog steeds is er geen makkelijke en eenduidige oplossing.

Het idee is simpel en efficiënt: als je het verwerkingsvermogen van een processor niet verder kan opdrijven door bijvoorbeeld een hogere kloksnelheid, dan stop je gewoon meer dan één verwerkingskern in die chip. Zeker als je hiervoor toch over genoeg tran-sistors per ‘die’ (het stukje silicon in een chip) beschikt. Het probleem is evenwel dat de meeste software tot vandaag qua verwerking inherent sequentieel is en ontwikkelaars heel wat moeite hebben om software op te splitsen in stukken code die efficiënt parallel (of ‘concurrent’) met elkaar in die verschillende kernen kunnen draaien. De toepassingen op de client-systemen lijken daar overigens nog meer onder te lijden dan deze op de back-end systemen. De toepassingen op die centrale systemen zijn niet zelden geconcipieerd om op geclusterde systemen te draaien, terwijl de verwerking vaak ook processen betreft die makkelijker parallelliseerbaar zijn (bijvoorbeeld in databases). Een complete rampspoed is dat natuurlijk niet. Er wordt ook al een hele poos aan het probleem gesleuteld en een expert als Brian Goetz, senior staff engineer bij Sun Microsystems en lid van de expertengroep rond de Java JSR166/’concurrency utilities’, heeft daar een goede kijk op.

Over het probleem van parallelisme/concurrency zijn de meningen verdeeld. De enen zeggen van ‘we staan nog maar aan het begin, er moet nog research worden gepleegd’, anderen stellen ‘we weten genoeg, d’r zijn oplossingen’.

BRIAN GOETZ: Mijn kijk op de zaak is dat Java vanaf de eerste dag was voorzien van ondersteuning voor ‘concurrency’ en ‘multithreading’. Het heeft de multiprocessoren of ‘multicores’ zien aankomen en ‘threading’ en ‘concurrency’ werden er dan ook niet op een later ogenblik aan vastgeplakt. Dat in tegenstelling met C en C++ waar met ‘libraries’ wordt gewerkt. De hardware biedt nu steeds meer mogelijkheden, ook inzake virtualisering, maar uiteindelijk is parallellisme niet makkelijk en is het ook niet echt bedoeld om makkelijk te zijn. Het Java-platform maakt het gewoon mogelijk om aan parallellisme te doen.

Hoe kan het dan toegankelijk worden gemaakt voor de doorsnee ontwikkelaars?

BRIAN GOETZ: De beste aanpak is nog steeds die welke al jaren wordt toegepast. Zorg ervoor dat de gewone ontwikkelaar er niet wordt aan blootgesteld. In Java EE werd het ‘concurrency’ aspect van 1996 tot 2000 weggestopt en dat maakte het succesvol, want je moest er geen ‘rocket scientist’ voor zijn. In Java 5 hebben we dan elementen in het concurrency pakket gestopt om tegemoet te komen aan de meest voorkomende problemen, die dan met ‘off the shelf’ componenten kunnen worden aangepakt. In Java 7 zullen we nog een stap verder gaan door het aanbieden van een ‘for-join’ library, goed voor ‘parallelle decompositie’-mogelijkheden over verschillende aantallen van verwerkingskernen.

Hoe breng je dat op een toegankelijke manier aan de man?

BRIAN GOETZ: Daar hebben we geen pasklaar antwoord op.

Dat ook vandaag in studentenopleidingen nog niet wordt gesproken over parallellisering, is volgens sommigen ‘misdadig’?

BRIAN GOETZ: Ik ben het eens met die opmerking. Je hebt vandaag immers al multicores in de goedkoopste consumentensystemen. Ja, het is onverantwoord er niet over te spreken.

Eigenlijk is ook nog niet geweten voor welke toepassingen parallellisme nu echt geschikt en mogelijk is?

BRIAN GOETZ: Parallellisme vormt een van de elementen in je toolbox, en soms is het zinvol om er gebruik van te maken maar soms ook niet. Weten wanneer het zinvol is, dat moet je aangeleerd worden, zodat je het ziet. Dan kan je je toepassing goed opsplitsen, zodat je sneller resultaten boekt.

In wezen vereist dat een inzicht in mogelijke problemen die voortvloeien uit de ‘overhead’ die het gevolg is van een parallellisering en dat is een klassiek ingenieursprobleem: een kosten/baten analyse maken. Maar omdat ontwikkelaars niet gewoon zijn zo te denken, moet hen dat worden aangeleerd!

Vandaag wordt over code nog te veel gedacht in functie van wat die doet. Nu moet meer worden bekeken welke data erbij betrokken zijn en hoe die over de verschillende verwerkingselementen moeten worden verdeeld. Je moet hiervoor opgeleid zijn. Wie tien jaar geleden leerde programmeren, heeft nu te maken met een onderliggende hardware die compleet is veranderd. (Nvdr: een reden te meer om iedereen, inclusief eindgebruikers, wat meer aandacht te laten besteden aan wat zich onder de ‘motorkap’ van een computer bevindt en gebeurt. Dat zou al heel wat problemen voorkomen)

Zijn de tools al van voldoende niveau om te helpen bij de parallellisering van toepassingen?

BRIAN GOETZ: Tja, als de hardware verandert, duurt het vaak jaren eer de tools hun inhaalbeweging hebben gemaakt en multicores worden nu pas serieus genomen. Ik hoop wel dat er in de eerstvolgende jaren tools komen die nagaan hoe efficiënt de hardware wordt benut, of er ‘hard lock’ problemen zijn, waar er ‘verkeersproblemen’ zijn op de geheugenbus en dies meer. Er is nood aan betere analysetools. Vandaag bevinden we ons hiervoor min of meer op hetzelfde niveau als de ‘profiling tools’ ca. 10 à 15 jaar geleden. Iedereen zag de nood eraan wel in, maar de tools waren gewoon nog niet goed genoeg om de performantie van een systeem te meten.

Is het niet beter tools te hebben die meteen een goed parallelliserend gebruik van hardware garanderen?

BRIAN GOETZ: Je kan goede houtbewerkingtools hebben, maar daar niet noodzakelijk goed werk mee afleveren.

Het is met visualiseringstools dat je leert inschatten wat het correcte gedrag van een stuk code is. En die tools kan je ook aanwenden in het onderwijs, om de mensen een praktijkgerichte kijk bij te brengen. De tools die aantonen wat er gebeurt in een systeem zijn ook de tools waarmee je de juiste denkwijzen over dit alles kan aanleren.

Het ontbreekt ook niet aan suggesties om een en ander sneller op te lossen, zoals bijvoorbeeld ‘transactioneel geheugen’?

BRIAN GOETZ: Ik heb gemengde gevoelens bij ‘transactioneel geheugen’. Er wordt al lang aan gewerkt, het lijkt veelbelovend, maar telkens blijkt het toch nog een kwestie van ‘binnenkort’ te zijn. Het probleem [het ten volle gebruiken van de mogelijkheden van een multicore nvdr.] is zo acuut dat mensen haast eender welke oplossing willen omarmen, en dan is transactioneel geheugen niet een oplossing omdat ze die willen, maar een om van het probleem af te geraken. Het resultaat zal allicht even gecompliceerd zijn als met ‘locks’ en het creëert een nieuw gebied van complexiteit. Bovendien zijn er nog heel wat onbeantwoorde vragen en is de performantie nog

niet goed. Het blijft dus veeleer een theoretische mogelijkheid. Ja het is een oplossing, het is een simpeler programmeermodel, maar nee, het is niet snel genoeg en het is geen volledige oplossing.

Zijn andere programmeertalen een oplossing? Bijvoorbeeld functionele talen?

BRIAN GOETZ: Scala is een interessante benadering. Maar een taal als Erlang is interessanter. Die heeft helemaal geen ‘shared state’, geen ‘mutable state’ en dus geen ‘shared mutable state’, en dat laatste is de bron van veel problemen. Het is een eleganter model, maar toch hou ik niet van Erlang. Ik heb hogere verwachtingen van een aanpak à la Scala.

Ik heb zes jaar geleden al een project gedaan voor een gedistribueerde toepassing. Als je je aan een aantal regels houdt, zoals het gebruik van ‘messages’, geen ‘shared state’ etc, zit je goed. Het was een erg succesvol project, zonder ‘concurrency’ problemen, ook al omdat we het programmeermodel hadden vereenvoudigd.

Eigenlijk is er niet echt een nieuwe taal nodig. Het gaat om de juiste denkwijze. Al te vaak volgt een ontwikkelaar in het gebruik van een taal de weg van de minste weerstand. Het is dan ook vaak

een kwestie van meer discipline om de mogelijkheden van een taal zinvol aan te wenden.

Heeft het zin om programmeertalen uit te breiden met het oog op concurrency?

BRIAN GOETZ: Hier is heel wat werk rond gedaan, in het bijzonder in C++ met ‘atomic lmocks’ en dies meer. Dat is een hulp om mensen naar de juiste oplossing te voeren, want dan leren ze kijken naar de mogelijkheden die een taal biedt. Inzake een library-gesteunde aanpak, ben ik meer sceptisch of die wel voldoende is. Het is een meer onnatuurlijke programmeeraanpak. Eigenlijk moet worden bestudeerd wat echt werkt en dan vervolgens de taal zelf worden aangepast. Maar dat wordt moeilijker naarmate de taal ouder is. Neem bijvoorbeeld ‘generics’ in Java, dat was al moeilijk. En kijk naar de huidige moeilijkheden rond ‘closures’. Het is ook een kwestie van terugwaartse compatibiliteit. Een tools of libraries-gesteunde aanpak levert dus wel sneller resultaten op, maar toch is het beter om wat men eruit leert aan te wenden om de taal aan te passen.

Kunnen aanpassingen in de hardware helpen? Intel, Sun en anderen doen pogingen in die zin.

BRIAN GOETZ: Ja, Intel heeft veel geïnvesteerd in ‘transactioneel geheugen’, en dat zowel in hardware als software. Zo heeft het voorzieningen voor transactioneel geheugen ingebouwd in zijn processoren en ook Sun’s multicoreprocessor ‘Rock’ biedt hiervoor een rudimentaire ondersteuning. Als transactioneel geheugen echt performant wil zijn, zal het zo’n hardwareondersteuning nodig hebben. Maar staat onze kennis daarvan al voldoende ver? Of zijn we nog aan het gissen? Want zowel de hardware als de compiler en dies meer moeten worden aangepast, en dat neemt tijd.

Kan dan beter voor een puur ‘model driven development’ worden geopteerd?

BRIAN GOETZ: Dat zal de oplossing zijn om die miljoenen ontwikkelaars aan concurrency en parallelism te laten doen. Verberg de complexiteit! En hoe? Dwing hen om een meer restrictief programmeermodel te volgen. Laat hen niet zo-maar doen wat ze willen, maar dwing een stijl af die beter mapt op parallellisme. Als iedereen zou kunnen worden gedwongen zo te programmeren, zouden er minder problemen zijn. Maar hoe dat aantrekkelijk maken voor die ontwikkelaars? Met een taal als Erlang? Zij willen liever JavaScript!

Wat dan met de kritiek van diegenen die zeggen dat dynamische talen het probleem nog erger maken?

BRIAN GOETZ: Die hebben overschot van gelijk! Er staat de Ruby-gemeenschap bijvoorbeeld nog een verrassing te wachten Ze tonen hoe productief ze wel zijn en hoe ze alles naar hartewens kunnen aanpassen. Ze zijn euforisch en zetten een hoge borst op tegen C, Java en andere talen. Maar Ruby heeft wel nog geen verhaal over concurrency, geen formeel ‘memory model’. Dynamische talen zijn producten die de problemen van gisteren oplossen en niet de problemen van vandaag of morgen.

Concurrency lijkt overigens minder een probleem voor de toepassingen op de centrale systemen, die al vaker voor clustersystemen werden geconcipieerd, dan die op de client-systemen.

BRIAN GOETZ: Dat klopt. De ‘server side’ ontwikkelaar heeft al veel langer een betere kijk op dit probleem, en hij schrijft ook al veel langer voor multiprocessor-systemen. Het is bij de veel grotere groep van client-gerichte ontwikkelaars dat het probleem zich nu aandient.

In wezen is dit een probleem bovenop andere bestaande problemen. Zou niet beter eerst het probleem van security moeten worden aangepakt?

BRIAN GOETZ: Dat argument zou ik aanvaarden, als dan ook echt aandacht aan security zou worden besteed. Maar in de hele discussie wordt security evenzeer genegeerd. De aandacht blijft maar uitgaan naar steeds meer ‘features’, terwijl niemand wil betalen voor security of kwaliteit. Ik geef toe dat security een groot probleem is, maar niemand doet er wat aan. Overigens hebben security en concurrency wel veel gemeenschappelijk. In beide gevallen is het immers geen expertise waarvoor je snel een gerichte cursus kan gaan volgen, zoals dat bijvoorbeeld rond XML of een specifieke database kan. Security en concurrency hebben te maken met hoe je over het probleem nadenkt. Allebei zijn het ook kwesties die in de opleidingswereld moeten worden aangepakt. Bij nieuwe studenten, maar ook bij mensen die tien jaar geleden afstudeerden. Security en concurrency, je moet je er echt op toeleggen.

Guy Kindermans