Author:
Markus Levy is voorzitter van EEMBC, een organisatie die benchmarks opstelt voor embedded processoren.
Reading time: 3 minutes
’Multicore programmeren is een eitje. We doen het al twintig jaar met multiprocessorsystemen.‘ Geloof het alstublieft niet als iemand dit beweert. Niet dat ik u wil afschrikken bij het overstappen naar multicore, maar er zijn aanzienlijke verschillen tussen programmeren voor multicore en multiprocessing. Gelukkig werkt de industrie ijverig aan het oplossen van deze problemen.
Voor we ingaan op de details van de meer fascinerende problemen is het goed om een stapje terug te doen en naar het grote geheel te kijken. Ten eerste is het duidelijk dat C en C++ de dominante programmeertalen zullen blijven in de nabije toekomst (de komende vijf tot acht jaar), vanwege ervaring, legacy-code of bestaande tools. En C heeft geen parallellismeconstructies of programmeerconcepten in de taal zelf.
Ten tweede zitten de meeste problemen met multicore programmeren bij het migreren van bestaande code. Laten we wel wezen, er zijn megamiljoenen coderegels en maar weinig mensen die dit willen herschrijven. Maar deze code is – behalve dat ze vaak gebrekkig becommentarieerd is – soms zo gevoelig dat zelfs een kleine verandering de hele boel in het honderd schopt. Ik heb een programmeur van telecomsystemen zelfs wel eens horen zeggen dat ’het hele systeem stopt als ik zelfs maar een printf-statement verander.‘ Gelukkig zijn zij, die applicaties vers mogen schrijven.
Multicore heeft vele gezichten. Heterogeen, homogeen, SMP en AMP is een greep uit de verschillende multicoresmaken en elk van hen kan andere programmeerstructuren vereisen. Bovendien bepaalt de functionaliteit van de processorkernen hoe de code moet worden opgedeeld. Een homogene multicoreprocessor zal bijvoorbeeld een relatief onafhankelijke opdeling ondersteunen. Een heterogene systeemchip gebruikt processoren met verschillende architecturen, doorgaans in de vorm van gespecialiseerde hardware die goedkoper en zuiniger is voor een specifieke taak. Deze kunnen een heel andere opdelingsstrategie vereisen.
Ongeacht het type moet de load balancing genoeg aandacht krijgen. Alhoewel de systeemscheduler dit kan afhandelen, heeft de manier waarop u uw parallelle code schrijft een belangrijke invloed. Daarnaast is de specifieke architectuur van belang.
Er zijn verschillende aanpakken om de rekenkracht van meerdere kernen te gebruiken afhankelijk van taak, de verwachte invoer en de onderliggende architectuur. Dit vereist een begrip van de impact die hardware-latency heeft (cache-coherentie of de overhead van message passing) en wordt uiteindelijk beïnvloed door de locatie van uw code in het geheugen.
Een andere belangrijke factor vormen data-afhankelijkheden. Bij seriële uitvoering worden de functies gegarandeerd aangeroepen in de volgorde waarin ze zijn opgeschreven. In de parallelle wereld bepaalt het thread scheduling-mechanisme dit. De eerste honderd keer dat de code draait kan dit best goed werken, maar dat garandeert niet dat het ’veilig‘ is. Dit is een van de wrange realiteiten van het omzetten van seriële naar parallelle code. Daarnaast schrijft de mate van data-afhankelijkheid uiteindelijk de te behalen hoeveelheid parallellisme voor.
De lijst met overwegingen is bijna eindeloos, maar ik wil nog een erg belangrijke factor noemen en dat is debuggen. Vanzelfsprekend moet u debuggen in het achterhoofd houden tijdens het schrijven van uw code, maar dat is makkelijker gezegd dan gedaan. Neem de nodige stappen om dataraces, deadlocks en andere multicorerampen te vermijden of in ieder geval de kans erop te verminderen.
Al deze uitdagingen en meer bediscussiëren we nu in de Multicore Association-werkgroep voor Multicore Programming Practices. Zelfs als u uw expertise niet wilt delen, denk ik dat het voor u interessant is om deze vergaderingen bij te wonen en te leren van anderen. Het vereist een teaminspanning om de kunst van multicore programmeren te beheersen en het makkelijker te maken om meer dan twintig jaar aan legacycode en programmeergewoontes te migreren.
