Manycore probleem voor programmeurs

12 februari 2010

De meest gebruikte programmeertalen van dit moment, Java, C/C++ en C#, maken allemaal gebruik van hetzelfde threadmodel. Voor ontwikkelaars is dat dé methode om de parallelle rekenkracht van multicoreprocessors uit te nutten. Dat doen zij door meerdere executiestromen naast elkaar op te starten. Volgens Paul Klint, hoofd van de onderzoeksafdeling Software Engineering bij het Centrum Wiskunde & Informatica (CWI), voldoet dit model in de praktijk echter niet. Het gaat mis bij de synchronisatie van de threads, daar waar die verschillende executiestromen weer bij elkaar moeten komen. “Als je op safe speelt, dan werkt het niet. Doe je dat niet, dan gaat het fout. Dit soort modellen waarin programmeurs expliciet hun parallelle code moeten specificeren, zijn een doodlopende weg; ze zijn te moeilijk.”

Hetzelfde geldt volgens Klint voor het geheugenmodel van Java. “Dat houdt weliswaar rekening met meerdere parallelle processen, maar dat heeft allerlei ingewikkelde consequenties. Het model is te complex, waardoor zelfs hele simpele programmaatjes al voor verrassingen voor de programmeur kunnen zorgen.”

Het belang van goede parallelle programmeermodellen is echter nooit zo groot geweest als op dit moment. Processorfabrikanten zijn zonder uitzondering afgestapt van de trend naar steeds hogere kloksnelheden. Dat betekent dat de caches minder groot hoeven te zijn en steeds meer transistoren beschikbaar zijn voor extra rekenkernen. Intel heeft bijvoorbeeld de ambitie uitgesproken om op termijn tientallen, honderden of misschien wel duizenden kernen op zijn chips te willen zetten.

Daarmee hebben de fabrikanten de softwareontwikkelaars wel voor een enorme uitdaging gesteld. Allereerst omdat er fundamentele beperkingen zijn aan de parallelliseerbaarheid van algoritmen (de Wet van Amdahl). “Er zullen altijd applicaties zijn waarvan verschillende onderdelen sequentieel uitgevoerd moeten worden”, aldus Klint. Maar zelfs als dit niet speelt, blijft het heel moeilijk om algoritmen zo veel mogelijk en zo veel mogelijk geautomatiseerd te parallelliseren. Sterker nog, daar zijn we al decennia lang mee bezig, zonder dat dat heeft geleid tot een algemene oplossing voor dit probleem. Klint noemt het zelfs de heilige graal van de informatica. “Je kunt wel zeggen dat die zoektocht is mislukt. Daarom kijken we nu minder naar het algemene probleem en meer naar deelgebieden waar we wel wat mee kunnen.” Daarbij noemt hij Fourier-transformaties als voorbeeld.

En dat sluit weer aan bij de manier waarop een onderzoeker bij Intel de problematiek eerder kenschetste: Op het hoogste niveau, bijvoorbeeld in de gebruikersinterface, is expliciet parallelliseren met behulp van threads geen probleem. Op het laagste niveau ook niet. Daar worden parallelle libraries, bijvoorbeeld voor Fourier-transformaties, onder andere door de processorfabrikanten zelf beschikbaar gesteld. Het is juist de bulk ertussenin die zo veel problemen oplevert.

Inmiddels heeft men zijn hoop gevestigd op nieuwe programmeertalen met ondersteuning voor impliciet parallellisme. Daarbij worden programmeurs gedwongen hun software zo te formuleren dat het voor de compiler veel makkelijker wordt om daar parallelle executables uit te genereren. Dat heeft geleid tot hernieuwde belangstelling voor een oudere taal als Erlang. Maar ook tot hele nieuwe programmeertalen en uitbreidingen op bestaande talen. Voorbeelden daarvan zijn X10 (IBM), Fortress (Sun), Go (Google) en Ct (Intel).

Bij het CWI heeft Klint zelf met Rascal een taal ontwikkeld voor metaprogramming. Daarmee kunnen onder andere refactorings (herschrijvingen) op programmacode worden uitgevoerd. Op die manier kan bestaande software worden verbeterd. Belangrijkste argument voor deze aanpak is dat de meeste code helemaal niet opnieuw geschreven wordt. Het leeuwendeel van de programmatuur die straks op de manycore hardware draait, is bestaande code. Slechts een klein deel wordt specifiek voor deze nieuwe architectuur ontwikkeld. “Rascal is gebaseerd op relationele calculus,” vertelt Klint. Je wilt weten wie precies wie aanroept in een programma. Die relaties kunnen gebruikt worden om slimme compilers mee te bouwen en automatisch code te genereren. De gebruiker merkt daar niets van; die intelligentie zit onder de motorkap.” Daarnaast kan Rascal worden gebruikt om analyses te maken en transformaties te doen. “Threads kunnen bijvoorbeeld worden onderzocht op het gebruik van gemeenschappelijke resources en het optreden van deadlocks.”

Rascal is geen objectgeoriënteerde taal maar lijkt wel op Java en is daarmee goed te integreren. Er is een open-sourceplugin voor Eclipse beschikbaar. Daarbij hoort een grammatica voor het inlezen en verwerken van Java-broncode. Op die manier kunnen bijvoorbeeld metrieken over de onderhoudbaarheid en complexiteit van de software worden verkregen. Daarnaast zullen refactorings kunnen worden uitgevoerd. “We willen systematisch en elegant een aantal veelgebruikte refactorings implementeren,” aldus Klint. “Het is bemoedigend dat IBM en de Eclipse-gemeenschap enthousiast zijn over onze oplossing.”

Daarmee ligt de focus van Klints werk dus niet op de problematiek van nieuwe parallelle code maar op de transformatie van de installed base. “Parallellisme is daar een onderdeel van. Wij gaan die heilige graal niet vinden. Wij kijken naar de analyse en transformatie van bestaande software. Daarbij maken we vooral gebruik van onze ervaring op het gebied van talen. Parallellisme doen we erbij.”

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!