Pieter Edelman
29 March 2013

Met de release van de Multicore Task Api zet de Multicore Association zijn derde en laatste pijler neer voor softwareontwikkeling op meerkernige embedded systemen, maar introduceert ze weer een nieuwe aanpak voor parallel programmeren. Urs Gleim van de werkgroep en Markus Levy van de industrie-associatie leggen uit waarom dat nodig is.

Zo‘n beetje het eerste dat de piepjonge Multicore Association in 2005 deed, was identificeren wat er nodig is om embedded multicore systemen goed te kunnen programmeren. De industriegroep kwam uit op drie pijlers: een communicatiemechanisme tussen cores, threads en dergelijke, een manier om de beschikbare hardwarebronnen te reguleren en een methode om een rekentaak op te delen in kleine brokjes die op verschillende rekenkernen zoals CPU‘s, DSP‘s en GPU‘s in het systeem kunnen worden verwerkt. Vijf jaar geleden zette de Multicore Association de eerste stap met de Multicore Communications Api (MCapi). In 2011 volgde MRapi, voor het beheren van de resources binnen een systeem. Met MTApi, voor taakbeheer, is nu de laatste van de drie fundamenten gelegd.

MTapi laat zich vergelijken met OpenCL, OpenMP of PThreads – een set C-functies en -datatypes waarmee een programmeur zijn software makkelijk in afzonderlijke taken kan opdelen. Weer een nieuwe aanpak voor multicoreprogrammeren dus, naast de lange lijst bestaande methodes; behalve de drie hierboven bevat het keuzemenu nog OpenACC, Threading Building Blocks, Cilk (Plus), Cuda, Renderscript, Grand Central Dispatch en nog een bonte verzameling reguliere en exotische aanpakken. De grote vraag is dus: waarom nog een standaard?

RTEmagicC_MTapi 1.jpg
Centraal in MTapi staat de job (verwerk een netwerkpakket), waarvan elke instantie wordt beheerd als aparte task (verwerk dit specifieke netwerkpakket). Verschillende actions bevatten de implementaties voor verschillende hardwarearchitecturen.

Het antwoord bestaat uit verschillende onderdelen. Allereerst zijn alle bestaande Api‘s voortgekomen uit de desktopwereld en dat is te merken in embedded toepassingen, legt Urs Gleim uit. Als hoofd van de Parallel Systems-onderzoeksgroep bij Siemens zat hij de afgelopen jaren de MTapi-commissie voor. ’Ze voldoen niet aan de eisen van de echte embedded-markten, zoals lage latency en klein geheugengebruik. Om een voorbeeld te noemen: dergelijke standaarden houden rekening met het idee van een gedistribueerd systeem waaruit componenten tijdens het draaien kunnen wegvallen. Er zitten dus mechanismen in om steeds te valideren of de hardware nog wel aanwezig is. Dat introduceert extra latency. MCapi en MTapi gaan ervan uit dat de hardware van een draaiend systeem niet verandert.‘

Ook zijn de bestaande aanpakken vrij specifiek, bijvoorbeeld voor een architectuur, terwijl MTapi juist een overkoepelende standaard wil zijn. Zo is de specificatie bedoeld voor een brede reeks processortypes: CPU‘s, DSP‘s, vectorinstructies, GPU‘s en wat er in de toekomst nog uitgevonden mag worden. Daarnaast, of misschien wel daardoor, moet de standaard de verschillende manieren van parallellisme accommoderen. Verschillende taken kunnen naast elkaar op verschillende delen van het systeem worden uitgevoerd (taakparallellisme), op de afzonderlijke rekenkernen kan dezelfde bewerking op verschillende delen van de data worden uitgevoerd (dataparallellisme). Bij stream processing moeten verschillende datastromen onafhankelijk van elkaar een pijplijn van bewerkingen ondergaan.

 advertorial 

System engineering @ ASML, practices and challenges

During the first online session of the System Architecting Conference, on 25 January, Frank de Lange and Tom Castenmiller (ASML) will address the role of systems engineering and discuss the essences of the roadmapping process, the holistic system design and the product generation process. Register now for free.

Een enkel netwerkpakket

De schrijvers van MTapi – chipmakers zoals Freescale, TI en Qualcomm, OS-leveranciers als Wind River en Enea, applicatiebedrijven als Ericsson en Siemens, en de universiteit van Houston voor de theoretische achtergrond – stonden dus voor een formidabele opgave: een uniforme standaard die alle bedrijfseigen aanpakken van chipmakers voor elke eigen architectuur aan de kant kan schuiven. Een enkel paradigma moet de bouwblokken bieden om elk type processor of versneller aan te sturen met elk type parallellisme. En o ja, het moet ook nog eens het geheugenbeheer in goede banen leiden.

MTapi 2
Verschillende typen hardware betekenen verschillende typen parallellisme.

Het gouden ei kwam van Siemens. Gleim was een van de toehoorders bij een presentatie van Markus Levy waarin de Multicore Association-oprichter uiteenzette wat er nodig is. Na afloop stapte hij op Levy af met de mededeling dat Siemens voor interne projecten een C-bibliotheek gebruikt die al een heel eind aan die eisen tegemoetkwam.

De oplossing is om elke taak op te delen in kleine brokjes. ’Deze tasks zijn vergelijkbaar met een klassieke thread, maar dan veel fijnmaziger‘, legt Gleim uit. ’Een taak kan bijvoorbeeld zijn om een enkel netwerkpakket te verwerken, of een stukje van een foto.‘ Een kleine runtime beslist waar en wanneer de taken worden uitgevoerd. Ze kunnen elkaar dus simpelweg sequentieel opvolgen, maar ze kunnen net zo goed uitzwermen over verschillende processorcores. De specificatie is daar flexibel in: de beslissing kan van tevoren worden vastgelegd of tijdens de uitvoer worden genomen, hoewel de specificatie van de beschikbare hardware wel altijd tijdens het compileren bekend moet zijn. Ook zijn er verschillende mogelijkheden om de stromen van taken in banen te leiden. ’Om met afhankelijkheden om te gaan, zijn er verschillende opties om taken op elkaar te laten wachten of bijvoorbeeld om een wachtrij te gebruiken‘, vertelt Gleim.

Met deze aanpak kunnen eigenlijk alle typen parallellisme worden gemaakt, meent de werkgroep. ’Het is een funderings-Api, dus soms zal het logischer zijn om hier een applicatiespecifieke Api bovenop te leggen, bijvoorbeeld voor beeldverwerkingsalgoritmes‘, zegt Gleim. ’Het voordeel is dat je die bibliotheek vervolgens op elk platform kunt gebruiken waarvoor MTapi beschikbaar is.‘

Eigen geheugen

In een programmeermodel als OpenCL of Cuda worden de delen die op de GPU moeten draaien apart geschreven in een beperkte subset van de C-taal – de GPU is simpelweg niet berekend op complexe logische bewerkingen. Ook in het MTapi-model ontkomt de programmeur er niet aan een specifieke applicatie voor elk processortype. Een charmant verschil is echter dat het mogelijk is om voor elk processortype een andere implementatie van een specifieke taak mee te nemen in de binary. In een extreem geval zou de runtime dus kunnen beslissen om een berekening te verhuizen van de GPU naar de CPU als het systeem staat te zwoegen op een grafische taak. In de praktijk zal het er echter vooral om gaan dat de ontwikkelaar makkelijk kan uitproberen wat er gebeurt als werk verhuist naar een andere versneller.

Het platform houdt verder een beetje in de gaten wat er moet gebeuren voor het geheugenbeheer. Want een processorcore moet wel van de juiste data worden voorzien wanneer die een taak krijgt toegewezen. In klassieke multicore processoren delen de rekenkernen doorgaans hetzelfde geheugen en kunnen ze direct met de juiste data aan de slag. Hardwareversnellers beschikken doorgaans echter over hun eigen geheugen, waarvoor een kopie zal moeten worden gemaakt en de resultaten zullen moeten worden teruggestuurd.

MTapi specificeert hoe een applicatie kan worden opgedeeld.

De Api is daartoe voorzien van functies om de benodigde data binnen te hengelen, waar de programmeur zijn taak meestal mee zal beginnen. De MTapi-runtime zal bij de uitvoer uitvogelen of er een kopie moet worden gemaakt en hoe dan wel. ’Hiervoor kan de programmeur overigens ook weer MCapi gebruiken‘, vertelt Levy. ’Elk van de drie Api‘s kunnen alleenstaand of in combinatie met elkaar worden benut.‘

Als kers op de taart is er voor threadgebaseerde toepassingen al een natuurlijke weg naar de overstap MTapi. Threads kunnen namelijk een op een worden omgezet naar tasks, en vandaar kan de ontwikkelaar gaan schaven.

Maar daar zullen ze nog even mee moeten wachten. De specificatie ligt er nu, net als een referentie-implementatie, maar toolbouwers, chipbedrijven en leveranciers van besturingssystemen moeten nu aan de slag om de software voor hun eigen producten te implementeren. ’Zoals elke standaard duurt het een tijdje voordat bedrijven er een businessmodel omheen kunnen bouwen. Met MCapi hadden we in het begin vooral academische gebruikers, maar je ziet nu dat er commerciële aanbieders de kop opsteken. Vanochtend aan het ontbijt in mijn hotel ontmoette ik weer iemand van een nieuw bedrijf dat het ondersteunt‘, vertelt Levy. Waarschijnlijk zullen de academici echter vooroplopen. ’Universiteiten hoeven zich niet aan een strikt businessmodel te houden‘, weet Levy, ’dus vaak zijn dat de early adopters.‘