Extension of ACETONE C code generator for multi-core architectures

Dit artikel introduceert een uitbreiding van de ACETONE C-codegenerator om parallelle code voor multi-core architecturen te genereren, waarbij het processor-toewijzingsprobleem formeel wordt gedefinieerd en de staat van de kunst wordt onderzocht.

Yanis Aït-Aïssa (IRIT-TRACES), Thomas Carle (IRIT-TRACES), Sergei Chichin, Benjamin Lesage, Claire Pagetti

Gepubliceerd Wed, 11 Ma
📖 5 min leestijd🧠 Diepgaand

Each language version is independently generated for its own context, not a direct translation.

De ACETONE-uitbreiding: Van eenzame kok naar een goed georganiseerd restaurant

Stel je voor dat je een heel groot, complex recept moet bereiden voor een vliegtuig. Dit recept is een Neuraal Netwerk (een soort slimme computerhersenen die dingen leert te herkennen, zoals een landingsbaan op een foto).

Vroeger deed dit alles één enkele kok (een single-core processor). Die kok deed alles: van het snijden van groenten tot het bakken van de vis. Het probleem? Als het recept te groot wordt, duurt het te lang. En in de luchtvaart is tijd alles; als de computer te lang nadenkt, kan het vliegtuig niet veilig landen.

De auteurs van dit paper hebben een oplossing bedacht voor het ACETONE-systeem. Ze hebben een manier gevonden om dit "recept" niet meer door één kok te laten doen, maar door een team van koks (meerdere processorkernen) die samenwerken.

Hier is hoe ze dat doen, vertaald in alledaags taal:

1. Het probleem: De eenzame kok

Het oude ACETONE-systeem was fantastisch omdat het code schreef die voorspelbaar was. Je wist precies hoe lang het zou duren. Maar het was alsof je één kok in een enorme keuken zette. Als je een complex gerecht (een groot neuraal netwerk) moest maken, zat die kok de hele dag in de keuken. Het vliegtuig kon niet wachten.

2. De oplossing: Een goed georganiseerd team

De auteurs hebben ACETONE uitgebreid zodat het werk opgesplitst kan worden over meerdere koks (meerdere processorkernen). Maar het is niet zo simpel als "iedereen doet maar wat". Je moet het werk heel slim verdelen.

Ze zien het neuraal netwerk als een stroomdiagram (een DAG). Stel je voor dat het een reeks stappen is:

  • Stap A moet klaar zijn voordat Stap B kan beginnen.
  • Stap C kan tegelijkertijd met Stap B gebeuren.

De uitdaging is: Wie doet wat, en wanneer?

3. De slimme plannenmaker (De DAG-scheduler)

Om dit te regelen, hebben de auteurs een "plannenmaker" bedacht. Deze kijkt naar het recept en zegt:

  • "Kok 1, jij doet de eerste drie stappen."
  • "Kok 2, jij begint pas als Kok 1 klaar is met stap 3, maar jij kunt wel stap 4 doen terwijl Kok 1 stap 5 doet."

Ze hebben twee manieren gebruikt om dit plan te maken:

  • De snelle methode (ISH): Dit is als een ervaren chef die snel een plan schetst. Het is niet perfect, maar het is snel en werkt goed.
  • De perfecte methode (DSH & ILP): Dit is als een super-rekenmachine die alle mogelijke combinaties uitprobeert om het beste plan te vinden. Dit duurt langer om te berekenen, maar levert vaak een snellere uitvoering op.

4. De communicatie: Het dienblad en de bel

Nu komt het lastige deel. Als Kok 1 een ingrediënt (data) heeft bereid voor Kok 2, hoe geeft hij dat door?
In een vliegtuigcomputer kunnen de koks niet gewoon tegen elkaar praten. Ze moeten een gemeenschappelijk aanrecht (het gedeelde geheugen) gebruiken.

De auteurs hebben een veilig systeem bedacht:

  • Het rode vlaggetje (De synchronisatie): Kok 1 legt het bord neer en steekt een rood vlaggetje omhoog.
  • De wachtende kok: Kok 2 kijkt naar het vlaggetje. Zolang het niet omhoog staat, wacht hij. Zodra het omhoog staat, pakt hij het bord en zet hij het vlaggetje weer neer.

Dit zorgt ervoor dat Kok 2 nooit een bord pakt dat nog niet klaar is, en dat Kok 1 geen nieuw bord legt op een bord dat Kok 2 nog niet heeft opgehaald. Dit klinkt simpel, maar in de wereld van computers is dit cruciaal om te voorkomen dat alles in de war raakt.

5. Het resultaat: Sneller, maar met een kleine prijs

Hoe werkt het in de praktijk?

  • Ze hebben dit getest op een echte computerchip (een Texas Instruments KeyStone).
  • Het goede nieuws: Het team van koks was inderdaad sneller dan de eenzame kok. Voor het deel van het werk dat goed verdeeld kon worden, waren ze 31% sneller.
  • De beperking: Het totale resultaat was slechts 8% sneller. Waarom? Omdat sommige stappen in het recept (zoals het berekenen van convoluties) gewoonweg te groot zijn om te verdelen. Die stappen moeten nog steeds door één kok worden gedaan, en die houden het hele team tegen.

Conclusie

Dit paper laat zien dat we neuraal netwerken in vliegtuigen veiliger en sneller kunnen maken door ze op meerdere processoren te draaien. Ze hebben een systeem gebouwd dat:

  1. Het werk slim verdeelt over meerdere kernen.
  2. Zorgt voor perfecte communicatie tussen die kernen (zonder dat er fouten ontstaan).
  3. Garandeert dat we precies weten hoe lang het duurt (cruciaal voor veiligheid).

Het is alsof je van een solist in een orkest bent gegaan naar een heel orkest. Het klinkt luider en krachtiger, maar je hebt een goede dirigent nodig (de scheduler) en een strakke regie (de synchronisatie) om ervoor te zorgen dat het niet een chaos wordt. Voor de luchtvaart is dit een belangrijke stap om slimme AI-toepassingen veilig in de cockpit te krijgen.