AWS : une biblioth`eque de vol de travail adaptatif

Le probl`eme est que beaucoup de tˆaches ainsi cr´e´ees ne seront jamais vol´ees. Ces tˆaches

ont un cout de cr´eation et de maintien, et mˆeme si leWork First Principleest appliqu´e, cette

d´ecoupe r´ecursive cr´ee un surcout compar´e `a l’ex´ecution s´equentielle pure d’une boucle

for. La solution `a ce probl`eme dans TBB est d’utiliser unauto partitionneurqui fait une

d´ecoupe intelligente en fonction du nombre de processeurs et des ´ev`enements de vol.

Le second exemple est la fonctionparallel scan, qui calcule le pr´efixe des ´el´ements

d’une plage. Apr`es avoir coup´e la plage des ´el´ements `a traiter en deux moiti´es et calcul´e

le pr´efixe sur chaque moiti´e, elle doit faire une op´eration suppl´ementaire pour calculer

le r´esultat final : multiplier tous les ´el´ements de la seconde moiti´e par pr´efixe du dernier

´el´ement de la premi`ere moiti´e. Nicolau et Wang [WNySS96] ont montr´e qu’une borne

inf´erieure pour le temps de calcul des pr´efixes surp processeurs est _p²+1ⁿ o `un est le

nom-bre d’´el´ements de la plage. Un algorithme na¨ıf bas´e sur une d´ecoupe r´ecursive calculerait le

r´esultat en 2n

p op´erations, ce qui n’est pas optimal. Ceci est la cons´equence d’op´erations

ad-ditionnelles dues `a la parall´elisation. TBB adresse ce probl`eme en ´evitant ce surcout lorsque

la seconde moiti´e n’a pas ´et´e vol´ee.

Ces exemples montrent que le probl`eme de la d´ecoupe des donn´ees est crucial vis-`a-vis

des performances d’un syst`eme de vol de travail.

Enfin, le vol de travail bas´e sur les deques doit faire face au probl`eme de la granularit´e :

si les tˆaches sont `a grain fin, i.e. que les fonctions parall`eles sont courtes, le surcout li´e `a la

gestion et l’ordonnancement entre tˆache est ´elev´e ; mais si les tˆaches sont `a gros grain, cela

limite potentiellement le parall´elisme.

3.2.1 Une solution : le vol de travail adaptatif

Une solution pour conserver un parall´elisme entre donn´ees efficace et adresser le

probl`eme de la granularit´e est d’utiliser le vol de travail adaptatif. Ce dernier est bas´e sur

le couplage de deux algorithmes : un algorithme s´equentiel ex´ecut´e par un processeur, qui

consiste `a faire desextractions s´equentiellesd’une partie du travail total et `a ex´ecuter ce

tra-vail localement ; un algorithme parall`ele permettant de remettre en cause le calcul s´equentiel

avec une extraction parall`ele du travail.

Une impl´ementation logicielle efficace d’un sch´ema de vol de travail adaptatif suit le

Work First Principle qui est la combinaison de deux r´esultats : premi`erement, l’algorithme

parall`ele ex´ecut´e s´equentiellement (comme dans Cilk) est remplac´e par un algorithme

s´equentiel optimis´e [DGK+

05] ; deuxi`emement, l’introduction d’une boucle pour contr ˆoler

le surcout d ˆu `a la parall´elisation [DGG+

07]. En suivant ce principe, une impl´ementation

sans deque est prouv´ee optimale, `a la fois en th´eorie et en pratique, pour une large

gamme d’algorithmes de la STL [TRM+

08]. Une autre impl´ementation, `a laquelle nous

al-lons nous int´eresser par la suite a ´et´e prouv´ee optimale pour les calculs sur des flux de

donn´ees [BRT08].

3.3 AWS : une biblioth`eque de vol de travail adaptatif

La biblioth`eque de vol de travail constitue une part importante de l’´ecriture d’un

algo-rithme parall`ele. Cette section vise `a pr´esenter la biblioth`eque AWS (pour Adaptive Work

Stealing), qui est une impl´ementation du vol de travail adaptatif, ´ecrite en vue de tourner

sur des syst`emes embarqu´es. Nous nous int´eressons `a cette biblioth`eque dans le but de tirer

parti des avantages du vol de travail dans notre contexte architectural.

Chapitre 3 ´Etat de l’art sur le support mat´eriel au vol de travail

3.3.1 Philosophie d’AWS

Une contrainte majeure dans les syst`emes embarqu´es et les MPSoCs est que l’espace

m´emoire doit ˆetre statiquement born´e. En cons´equence, cette sp´ecification du vol de travail

n’alloue pas de m´emoire suppl´ementaire durant l’ex´ecution. Par ailleurs, elle ne requiert pas

de gestion de la concurrence entre les threads puisque `a chaque instant, seul un calcul est en

cours sur chaque unit´e d’ex´ecution qui n’est pas en attente.

En effet, plut ˆot que de g´erer sur chaque unit´e un ensemble de tˆaches prˆetes, AWS suit

l’id´ee de l’algorithme de vol de travail sans deque propos´e dans [TRM+

08] qui est bas´e sur

la cr´eation paresseuse des tˆaches. Un processeur actifjeffectue le calcul de la tˆache qui lui

est assign´ee ; quand une requˆete de vol venant du processeur iarrive surj, une nouvelle

tˆache est cr´e´ee et correspond `a une partie du travail restant surjprˆete `a ˆetre calcul´ee. Cette

tˆache est alors assign´ee au processeuriqui peut continuer son ex´ecution.

Dans la suite, l’op´eration qui construit la description d’une tˆache publique est

ap-pel´ee extract par() et celle qui construit la description d’une tˆache priv´ee est appel´ee

extract seq(). Ces op´erations sont impl´ement´ees au niveau de l’application. Ainsi, la

cr´eation effective des tˆaches est d´el´egu´ee `a l’application ; AWS ne g`ere que les requˆetes de

vol sur les processeurs en attente et l’ex´ecution locale du travail sur les processeurs actifs.

Ces deux op´erations sont ind´ependantes : un vol qui se termine avec succ`es m`ene `a un

extract par()sur la victime, ce qui modifie le travail restant. Cette synchronisation entre

les requˆetes de vol et l’ex´ecution locale est g´er´ee au niveau de la biblioth`eque de vol de

tra-vail. Le travail local sur un processeur actif est effectu´e sous la forme d’un bloc d’op´erations,

et est d´efini au niveau de l’application : la fonctionextract seq()est appel´ee de mani`ere

it´erative sur le travail local jusqu’`a sa compl´etion.

3.3.2 Avantages et contraintes du mod`ele de programmation li´e `a AWS

Cette section discute de l’impact des caract´eristiques et des choix fait dans AWS sur

plusieurs points. Premi`erement, un des avantages d’AWS est de laisser `a l’utilisateur la

pos-sibilit´e de descendre `a grain fin tout en n’impliquant qu’un surcout tr`es faible. En effet,

la quantit´e de travail vol´ee et la taille des tˆaches extraites s’adapte `a la quantit´e de travail

restante.

Par ailleurs, l’ordonnancement des tˆaches prˆetes est connu pour avoir un impact sur

les performances. Ainsi, la d´el´egation au niveau applicatif des op´erationsextract par()

etextract seq()supprime ce surcout au niveau de l’application. L’inconv´enient que cela

pose est qu’il faut arriver `a ´ecrire son programme sous la forme de ces deux fonctions, plus

celle pour le traitement des ´el´ements.

Ensuite, il est `a noter que le couplage de deux algorithmes, un s´equentiel - pour les

op´erationsextract seq()- et un parall`ele - pour les op´erationsextract par()- n’empˆeche

pas le parall´elisme r´ecursif : il est possible d’imaginer la gestion d’une collection de tˆaches

prˆetes `a ˆetre vol´ees `a l’int´erieur du travail local. Bien s ˆur, cela d´elaisse alors les contraintes

m´emoire au niveau applicatif. Dans le mˆeme ordre d’id´ee, il est imaginable d’utiliser

une biblioth`eque de plus haut niveau au-dessus d’AWS pour g´erer des synchronisations

suppl´ementaires.

L’inconv´enient principal de l’approche propos´ee est que pour une application complexe,

toutes les synchronisations inter-tˆaches (comme dans le cas de l’exemple pr´ec´edent avec le

parall´elisme r´ecursif) doivent ˆetre g´er´ees dans le code de l’application. En effet, AWS ne g`ere

pas la d´ependance entre tˆaches de par son mod`ele, et n’est donc pas tr`es adapt´e `a toutes les

classes d’applications. Cela n’est cependant pas n´ecessairement un probl`eme, puisque les

applications de traitement de donn´ees ne requi`erent pas de telles synchronisations.

3.3 AWS : une biblioth`eque de vol de travail adaptatif

3.3.3 Impl´ementation d’AWS

Comme nous avons dans nos travaux utilis´e et modifi´e la biblioth`eque AWS, il est

n´ecessaire de d´ecrire son impl´ementation. N´eanmoins, comme nous sommes repartis d’une

biblioth`eque existante, nous la pr´esentons dans cette section. Nous rappellons que notre

objectif ici est d’´etudier l’int´erˆet d’un support mat´eriel ad-hoc en vue d’am´eliorer les

perfor-mances de l’impl´ementation.

3.3.3.1 Comportement g´en´eral

Bas´e sur les choix de conception pr´ec´edents, ce paragraphe pr´esente la fac¸on dont la

biblioth`eque d’AWS est construite, ainsi que son API.

Le comportement g´en´eral est le suivant. Au d´emarrage, chaque processeur est actif et

commence un calcul, d´etermin´e par son identifiant processeur. Quand un processeur va en

attente, il devient un voleur. Il s´electionne une victime de mani`ere cyclique jusqu’`a trouver

du travail `a voler.

3.3.3.2 Structures utilis´ees pour le travail

Chaque processeur g`ere deux structureswork t qui repr´esentent une partie du travail

total. `A chaque instant, toute donn´ee ne peut ˆetre contenue que dans au plus une structure

work tdu syst`eme. La premi`ere structurework test publique et visible de tous les autres

processeurs. Elle est initialis´ee avec une certaine quantit´e de travail, g´en´eralement la mˆeme

pour tous les processeurs. La seconde structurework t est une structure priv´ee qui n’est

visible que pour le processeur qui la poss`ede et qui contient le travail `a faire localement.

3.3.3.3 Cœur de l’algorithme

Le cœur de l’algorithme de vol de travail adaptatif (fonctionloop core adaptive) est

pr´esent´e figure3.1. Apr`es une requˆete de vol se soldant par un succ`es, un processeur

ob-tient du travailw et ex´ecute une boucle locale : lalocal-loop. Dans cette boucle, le

pro-cesseur ex´ecute une fonction appel´eeextract seq()qui extrait une petite partie du travail

duwork t public vers lework t priv´e l. Le processeur traite ensuite ce travaill avec une

fonction appel´eelocal run(): ce traitement est fait de mani`ere s´equentielle et ne peut ˆetre

pr´eempt´e. Quand la structurework tpubliquewest vide, le processeur devient un voleur et

sort de lalocal-loop. Il scanne alors toutes les structureswork tpubliques jusqu’`a en

trou-ver une non-vide et ex´ecute alors la fonctionextract par()qui extrait une partie du travail

de la victime dans sa propre structure publiquew. Le processeur entre ensuite `a nouveau

dans lalocal-loop. Quand toutes les structureswork tpubliques sont vides, la totalit´e du

travail a ´et´e trait´ee.

3.3.3.4 Nature des structureswork t

Les structureswork tne contiennent en g´en´eral pas le travail lui-mˆeme, mais plut ˆot une

description du travail, tels que des indexes d´efinissant le d´ebut et la fin d’une zone `a traiter.

Pour le cas o `u les donn´ees d’entr´ees sont un tableau, la figure 3.2 illustre la structure

d’un nœud, qui contient deux structureswork tpointant respectivement vers le premier et

le dernier ´el´ement du travail en cours de traitement pour ce nœud, et le premier et dernier

´el´ement du travail restant, qui lui peut ˆetre vol´e.

Chapitre 3 ´Etat de l’art sur le support mat´eriel au vol de travail

1 / * node mutex : v e r r o u p r o t ´e g e a n t l e t r a v a i l p a r t a g ´e

2 ( i . e . p o u v a n t ˆe t r e v o l ´e ) du noeud c o u r a n t * /

3 l o c k ( node mutex ) ;

4 h a s l o c a l w o r k = t r u e;

5 h a s g l o b a l w o r k = t r u e;

6 while ( h a s g l o b a l w o r k ) { / * s t e a l−l o o p * /

7 while ( h a s l o c a l w o r k ) { / * l o c a l−l o o p * /

8 s t a t u s = e x t r a c t s e q ( ) ; / * e x t r a i t du t r a v a i l l o c a l l de w * /

9 i f ( s t a t u s == STATUS OK ) {

10 unlock ( node mutex ) ;

11 l o c a l r u n ( ) ; / * t r a i t e l o c a l e m e n t l * /

12 l o c k ( node mutex ) ;

13 } e l s e

14 h a s l o c a l w o r k = f a l s e;

15 } / * f i n de l a l o c a l−l o o p * /

16 / * t r y s t e a l * /

17 unlock ( node mutex ) ;

18 s t a t u s = s t e a l ( ) ; / * r ´ecup`e r e du t r a v a i l p a r t a g ´e : w * /

19 l o c k ( node mutex ) ;

20

21 i f ( s t a t u s == STATUS OK )

22 h a s l o c a l w o r k = t r u e;

23 e l s e

24 h a s g l o b a l w o r k = f a l s e;

25 } / * f i n de l a s t e a l−l o o p * /

26 aws unlock ( node mutex ) ;

FIG. 3.1 – Cœur de l’algorithme AWS (fonctionloop core adaptive)

. . . . . .

Travail déjà traité ou appartenant à un autre noeud

données courantes pour le noeud

Noeud contenant les deux structures work_t

données d'entrée

Travail correspondant au work_t local (en cours de traitement)

Travail correspondant au work_t partagé (peut être volé)

Dans le document Étude de deux solutions pour le support matériel de la programmation parallèle dans les multiprocesseurs intégrés : vol de travail et mémoires transactionnelles (Page 36-40)