INFORMATIQUE Ordonnancement d'un DAG avec transfert des ... · Ordonnancement d'un DAG avec transfert des données sur une plateforme NUMA multicore Présentée par Slimane Mohammed

THÉSE

Pour l'obtention du

Diplome de Doctorat en Sciences

INFORMATIQUE

Ordonnancement d'un DAG avec transfert des données

sur une plateforme NUMA multicore

Présentée par

Slimane Mohammed

soutenue devant le jury composé de :

Mr. Kadour Mejdi Professeur, Univ. Oran1 Président

Mr. Sekhri Larbi Professeur, Univ. Oran1 Directeur de thèse

Mr. Benmohamed Mohamed Professeur, Univ. Constantine 2 Examinateur

Mr. Allaoua Chaoui Professeur, Univ. Constantine 2 Examinateur

Mr. Djebbar Bachir Professeur, USTOMB Examinateur

Mme.Taghezout Noria MCA, Univ. Oran1 Examinatrice

�A�C �l`�� w�¤� �§@��¤ �kn� �wn�� §@�� ¢l�� r§

�y\`�� ¢l�� d}

º�d¡�

�wl�C �� An`� �w�A� �§@�� Tb�¯� �� ¨��

¨�� ¤ ¨�� ¤C ¨��

«r�O�� ¨t�� ¤C ¨��

�h�¯� �f�§ �� ¤d�§¯¤ w�A`§ �§@�� AVrs�� YRr� �� ¨��

�m`�� @¡ ©d¡�

Abstract

Scheduling of DAG with data placement on multicore NUMAplatform

Directed acyclic graphs (DAG) based scheduling algorithms in traditional com-puting paradigms focus more on computational tasks and less than on the data placementduring scheduling mapping. In the hierarchical memories context, this behavior will havenegative impact on performance of system. With the introduction of non-uniform mem-ory access (NUMA) multicore architectures, simultaneous optimization of computationand data placement in DAG based scheduling and mapping become the most challengingtopics in scheduling related research. Such architecture exposes multilevel hierarchicalmemories with di�erent characteristics which make the cost of the communication dif-ferent in each level. From the other side, some interdependent tasks are communicationintensive tasks that need to load and store their data frequently from the memory de-pending on data location, the performance of such system and its scheduler depends notonly on its threads scheduling decision but also on its data locality decision (the mappingof the thread data).

In this thesis, we tackle the problem of the scheduling parallel applications de-scribed by DAG in target platforms by exploring case where not just computation andcommunication are considered in scheduling decision but also data placement on hierar-chical memories platforms. The current scheduling and mapping policies try to reducethe overall penalties of the remote access by taking into account the data locality in thescheduling decisions. But most of the work done is for independent tasks context withstatic initialization. To do this for DAG application execution on the hierarchical plat-forms, it is necessary to �nd a way to combine both policies to get the most appropriatedecision about when and where to schedule thread and where to place its data. In thiswork, we will:

1. Include the platform topology information (supplied by run-time environmentat start time of application).

2. Use the application pattern (application structure provided by developers).

3. Divide the tasks set to a number of disjoint sets based on this structure andon task state.

4. Wide the tasks visibility by exploring a large horizon in order to gather moreinformation about the state of current process running DAG.

5. Balance the load using distance based work stealing strategy at run-time.

These are the main ideas of the proposed scheduling and mapping policy of thiswork integrated as heuristics in this process to guide it and to reduce the impact of NUMApenalties on the completion total time of the DAG and preserve the system performance.

Key words : Task graph, DAG based scheduling, mapping, data locality, Mul-ticore machines, NUMA architectures, Hierarchical platforms, Execution Horizon, Workstealing, Load balancing.

Résumé

Ordonnancement d'un DAG avec transfert des données sur uneplateforme NUMA multicore

Les algorithmes d'ordonnancement des graphes de tâches (DAG) selon l'approcheclassique se concentrent davantage sur les tâches de calcul et leurs dépendances ( communi-cation ) et donnent moins d'importance au placement des données lors de l'allocation.Dans le contexte des plateformes hiérarchiques, ne pas placer les données des threads defaçon appropriée impacte les performances du système. Avec l'introduction des architecturesd'accès non uniforme à la mémoire (NUMA), l'optimisation simultanée du placement desthreads et des données d'un DAG est devenue cruciale. Une telle architecture possede unsystème de mémoire hiérarchique multi niveaux avec des caractéristiques di�érentes quirend le coût de la communication di�érent dans chaque niveau. Une bonne partie du tempsdes tâches dépendantes orientées données se consomme en chargeant ou sauvegardantses données de la mémoire en fonction du placement initial. Les performances d'un telsystème et son ordonnanceur dépendent non seulement de sa décision d'a�ectation desthreads mais aussi de sa décision du placement des données.

Dans cette thèse, nous abordons le problème de l'ordonnancement d'applicationsparallèles décrites par un DAG sur la plateforme cible en explorant le cas où non seulementle calcul et la communication sont considérés, mais aussi le placement de données sur lesplateformes hiérarchiques. Les politiques courantes de l'ordonnancement et l'allocation dela mémoire tentent d'atténuer l'e�et NUMA en réduisant la pénalité d'accès distant à lamémoire en tenant en compte la localité des données lors de la décision de l'ordonnancement.Ce travail propose de :

1. Inclure l'information sur la topologie (fournie par l'environnement runtime au débutde l'exécution de l'application) de la plateforme.

2. Utiliser le motif de l'application (sa classe information fournie par le développeur del'application) à exécuter.

3. Regrouper les tâches dans des classes disjointes en se basant sur cette structure etl'état de la tâche.

4. Elargir le champs de visibilité des tâches en explorant un large horizon a�n de collecterplus d'informations sur l'état courant du processus d'éxecution de DAG.

5. Equilibrer la charge au temps d'exécution en utilisant la stratégie de vol de travailbasée sur la distance.

Comme idées de bases, ces propositions seront integrées comme heuristiques dansla politique de l'ordonnancement des threads et le placement des données pour guider ceprocessus et l'aider à réduire l'e�et NUMA sur le temps total d'exécution d'un DAG etde préserver les performances du système.

Mots-clés : Graphe de tâches, Ordonnancement DAG, Placement, Localité dedonnées, Machines multic÷urs, Architectures NUMA, Caches hiérarchiques, Horizon d'éxecution,Vol de travail, Equilibrage de charge.

P�l�

�wn�� d`tm�� NUMA Tyn� Yl� �AyW`m�� Rwm� �� DAG T�¤d�

¨� Tlm`tsm�� DAG Tyql�®�� Th�wm�� AWW�m�� Yl� Tm¶Aq�� T�¤d�� Ay�ECw�

�Rwm� �� r�� Ty�As�� Amhm�� Yl� A¡zy�r� �� O� T§dylqt�� TbFw�� CAV�

�@¡ ,y�rt�� Tlslstm�� r��@�� AyF ¨� .�Rwmt�� ¤ T�¤d�� Tylm� �®� �AyW`m��

d`tm�� Ynb�� d�tF� �� .�k� �A\n�� Ty�A`� ¤ º� � Yl� ¨blF r�� ¢� wk§ Xmn��

��A-T�¤d�� A�§� A� (NUMA) �w�w�� rZAnt� ry� ¤ Tl�Amt� ¯ r��Ð ��Ð ¤ �wn��

Cw�¯� �� d`§ DAG XW�� Rwm� ¤ T�¤d� T��sm� d��¤ � ¨� �yl��¯� �Rwmt�� ¤

Yn� .T�¤d�� ¶Asm� QA�� ¨ml`�� b�� Ay� � ¨� A§d�� kK� ¨t�� TyO`tsm��

r�¯� ,Tflt�� P¶AO�� A§wtsm�� d`t� ¤ y�rt�� Tlslst� ��r�Ð |r`� £@h�

�Ahm�� {`� «r�� Th� �� ¤ Th� �� «wts� �� ¨� Tn§Abt� �AO�¯� Tflk� �`�§ ©@��

r��@�� Y�� ¤ �� Ah�AyW`� ^f�� ¤ �m�� A� Ab�A� rbt`� ¨lO�� A� Ah� TW��rtm��

Yl� Xq� dmt`§ ¯ T�¤d�� ¤ �A\n�� @¡ º� � .ry�¯� £@¡ �Rwmt� Tql`t� �C�r�

.Ah�AyW`m� QA�� Rwmt�� C�r� Yl� AS§� �k� ¤ Tff�m�� @yfnt�� Aylm� T�¤d�

þ� Ahn� rb`m�� T§E�wtm�� AqybWt�� T�¤d� T��s� �� Y�� Y`s� T�¤rV¯� £@¡ ¨�

TbFw�� Xq� Hy� ¨t�� T�A�� AKktF� �®� �� Ð ¤ T�dhtsm�� Ynb�� Yl� DAG�AyW`m�� Rwm� AS§� �k� ¤ T�¤d�� C�r� ÐA�� ®� CAbt�¯� �y`� �@��§ �AO�¯� ¤

�ylqt�� Y�� Y`s� Ty�A�� Rwmt�� ¤ T�¤d�� AFAyF � .rZAnt�®�� Ynb�� r�Ð Yl�

C�r� ¨� �AyW`m�� Rwm� Abs��A� A¡@�� dy`b�� w�w�� w`m� �A`�� ry��t�� d� ��

Yl� ��Ð �ybWt� .Tlqtsm�� Amhm�� AyF ¨� �A� Tq�As�� A��¯� �\`� �k� .T�¤d��

A�§� ©C¤rS�� ,y�rt�� Tlslstm�� Ynb�� Yl� DAG þ� Ahn� rb`m�� AqybWt�� @yfn�

�¤d�� §� ¤ Yt� �w� s�¯� C�rq�� Y�� }wtl� �ytFAys�� Atl� �y� �zml� �ybF

: þ� �wq� �wF ,�m`�� @¡ ¨� .Ah�AyW`� �S� �§� ¤ @yfnt�� Aylm�

ºd� �®� @yfnt�� Tl�r� T·y� �� T�dqm��) @yfnt�� Yn� Ay�w�wbV T�wl`� ��C � .(1)

.(�ybWt��

.(��rbm�� rV �� AW`� �ybWt�� Tyn�)�ybWt�� Xm� ��d�tF� .(2)

�� d� Yl� �Amhm�� T�wm�� ºz�� wF ,�Amhm�� T�A� ¤ Tynb�� £@¡ Yl� �ºAn� .(3)

.TlOfnm�� A�wm�m��

�w� r�� A�wl`� �m�� Ð ¤ �F¤� �� AKktFA� �Amhm�� T§¦C �A�� yFw� .(4)

.DAG @yfn� Tylm`� Tn¡�r�� T�A��

@yfnt�� Tl�r� �®� �m`�� T�rF Ty�y��rtF� ��d�tFA� Tynb�� Yl� ºb`�� E�w� ^f� .(5)

T�Asm�� Yl� Tm¶Aq��

T�Cdm�� m`�� @h� �Rwmt�� ¤ T�¤d�� AFAys� T�rtqm�� Tysy¶r�� CAk�¯� ¨¡ £@¡

¨lk�� ºAht�¯� ��E Yl� �A�w`m�� r�� ylqtl� ¤ A¡ AJC¯ Tylm`�� £@¡ ¨� HkytFC��

.�A\n�� º� � ^f�� ¤

,�AyW`m�� T§C�w� ,�AyW`m�� Rwm� ,DAG T�¤d� ,�Ahm�� XW�� : �Atfm-�Aml�

T�rF ,@yfnt�� ,�Cdtm�� ¨nyb�� §z�t�� ,NUMA Yn� ,�wn�� d`t� ��A`m� yF�w�

.ºb`�� §Ew� ,�m`��

Remerciement

Je remercie ALLAH le tout puissant la source de toutes les grâces qui nousentourent de nous avoir donné la force et le courage à accomplir ce travail .

Je remercie mon directeur de thèse, le Professeur Sekhri Larbi pour avoiraccepté de superviser et diriger ce travail pendant ces années, pour sa contribution activedans l'accomplissement de ce travail, et pour ses conseils et son aide. Son expérience, sescritiques et ses encouragements ont été très béné�ques et surtout sa patience de m'avoirencadré.

Je tiens tout d'abord à remercier le Professeur Kadour Mejdi pour l'honneurqu'il me fait en acceptant de présider le jury de cette thèse .

J'exprime toute ma gratitude aux professeurs BenmohamedMohamed, AllaouaChaoui et Djebbar Bachir , le Docteur Taghezout Noria pour avoir consacré deleur temps pour la lecture de ce manuscrit. Je leur suis vivement reconnaissant d'avoiraccepté de participer au jury.

Je dis aussi un grand merci à ma femme qui s'est fortement impliquée dans lesaspects, pas toujours agréables, de correction des fautes d'orthographe et de la logistique decette thèse. Ainsi que ma s÷ur, mes deux frères et mes amis pour le soutien, l'encouragementet l'aide si nécéssaire pour accomplir un tel travail.

A Vous tous, Que vous trouverez ici mes remerciements et ma gratitude les plusprofonds.

Table des matières

1 Introduction 11.1 Problématique et motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objectifs de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Plan et Organisation de la thèse . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Production scienti�que . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Paradigmes architecturaux des plateformes Multic÷urs-UMA/NUMA 5

2.1 Processeurs monoc÷ur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.1 Puissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Pipeline ILP( Instruction Level Parallelism) . . . . . . . . . . . . . 8

2.2 Processeurs Multic÷urs (Multicore) . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Contrôleur de mémoire intégré . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 Hiérarchie de la mémoire [TG13] . . . . . . . . . . . . . . . . . . . 9

2.2.3 Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 Cohérence de Cache . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Systèmes SMP/UMA (uniform memory access) . . . . . . . . . . . . . . . 12

2.3.1 Mesure de l'accélération (speedup γ) . . . . . . . . . . . . . . . . . 13

2.3.2 Passage à l'échelle (scalability ζ) . . . . . . . . . . . . . . . . . . . 14

2.4 Systèmes NUMA Non Uniform memory Access . . . . . . . . . . . . . . . . 15

2.4.1 Architecture NUMA . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.2 Caractéristiques NUMA . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 Localité des données et Politiques de Placement . . . . . . . . . . . . . . . 20

2.5.1 Principe de la localité . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5.2 Politiques de Placement . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5.3 Attâchement d'un Thread (Thread Binding) . . . . . . . . . . . . . 23

2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Graphes de tâches 26

3.1 Application parallèle décrite par DAG . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Graphe de tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Modèle DAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.1 Concepts et dé�nitions . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.2 Exécution d'un DAG . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3

3.3 Modèle d'ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.1 Modèle Just-in-Time JIT . . . . . . . . . . . . . . . . . . . . . . . . 363.3.2 Horizon d'exécution pour les multicoeurs [Pla15] . . . . . . . . . . . 36

3.3.3 Ordonnancement par liste . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.4 Par clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.5 Duplication des tâches . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3.6 Basés les Metaheuristiques . . . . . . . . . . . . . . . . . . . . . . . 39

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Etat de l'art de l'ordonnancement et le placement sur MC-NUMA 41

4.1 Caractéristiques des approches . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 Caractéristiques principales . . . . . . . . . . . . . . . . . . . . . . 43

4.1.2 Caractéristiques du placement de données . . . . . . . . . . . . . . 43

4.1.3 Caractéristiques des mécanismes d'ordonnancement . . . . . . . . . 44

4.2 Ordonnancement des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.1 Principe de la réutilisation de l'ordonnancement . . . . . . . . . . . 44

4.2.2 Ordonnancement du parallélisme non structuré . . . . . . . . . . . 45

4.3 Placement des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.1 A�nity on touch AoT . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.2 CARREFOUR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3.3 Interface memory a�nity MAI . . . . . . . . . . . . . . . . . . . . . 49

4.3.4 MINAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.5 Placement de pages orienté feedback FBoPP . . . . . . . . . . . . . 52

4.4 Ordonnancement et placement combinés . . . . . . . . . . . . . . . . . . . 53

4.4.1 FORESTGOMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.4.2 LAWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.5 Stratégies d'équilibrage de charge dans NUMA . . . . . . . . . . . . . . . . 58

4.5.1 Partage du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.5.2 Vol de travail (Work stealing) . . . . . . . . . . . . . . . . . . . . . 58

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5 Horizon d'exécution étendu et Vol de travail adaptatif 62

5.1 Schémas des stratégies d'ordonnancement et placement . . . . . . . . . . . 62

5.2 Ordonnancement et placement des tâches indépendantes . . . . . . . . . . 65

5.2.1 Combinaison des politiques d'ordonnancement/placement classiques 65

5.2.2 Politiques d'ordonnancement classique . . . . . . . . . . . . . . . . 65

5.2.3 Politiques de placement classique . . . . . . . . . . . . . . . . . . . 66

5.3 Ordonnancement et placement d'un graphe de tâches . . . . . . . . . . . . 67

5.3.1 Heuristique Horizon d'exécution Etendu X-VHFU . . . . . . . . . . 67

5.4 Equilibrage de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.4.1 Vol de travail basé sur distance et adaptatif . . . . . . . . . . . . . 75

5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6 Simulation et Analyse des résultats 79

4

6.1 Simulateur NUMA (HLSMN) . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.1.1 Etat de l'art des simulateurs Multicoeurs NUMA . . . . . . . . . . 806.1.2 Architecture et Conception du simulateur HLSMN . . . . . . . . . 80

6.2 Expérimentation tâches indépendantes . . . . . . . . . . . . . . . . . . . . 84

6.2.1 Con�guration de la simulation . . . . . . . . . . . . . . . . . . . . . 84

6.2.2 Expérimentation des scénarios . . . . . . . . . . . . . . . . . . . . . 84

6.2.3 Analyse des Résultats . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.3 Expérimentation tâches dépendantes DAG . . . . . . . . . . . . . . . . . . 86




6.4 Expérimentation Equilibrage de charge . . . . . . . . . . . . . . . . . . . . 94




6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7 Conclusion et perspectives 98

7.1 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.2 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

References 101

Table des �gures

2.1 Evolution des fréquences maximales de processeurs [HP17] . . . . . . . . . 7

2.2 Ecart de la vitesse entre le processeur et la mémoire [McK04] . . . . . . . . 7

2.3 Architecture du processeur d'Intel Multicore i7 [HP17] . . . . . . . . . . . 8

2.4 Hiérarchie de la mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Scalabilité linéaire, SMP et Cluster [HP17] . . . . . . . . . . . . . . . . . . 15

2.6 Carte mère NUMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Architecture NUMA (a) Plusieurs n÷uds (b) à deux n÷uds . . . . . . . . 16

2.8 Accès mémoire locaux et distants sur NUMA . . . . . . . . . . . . . . . . . 182.9 Code OPENMP parallélisant une boucle sur NUMA . . . . . . . . . . . . . 18

2.10 Exemples de placement des données du code OpenMP sur NUMA . . . . . 22

3.1 Exemple d'un code OpenMP parallèle et son DAG équivalent . . . . . . . . 27

3.2 DAG de l'application résolution d'un système d'équations [Dre15] . . . . . 31

3.3 Ordonnancement du DAG rand0000.stg sur des plateformes UMAs . . . . . 35

4.1 Ordonnancement d'un DAG sur des plateformes UMA/NUMA . . . . . . . 42

4.2 MINAS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3 Principe de FORESTGOMP Framework . . . . . . . . . . . . . . . . . . . 55

5.1 DAG avec plusieurs niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2 Resultat de la partition d'un DAG . . . . . . . . . . . . . . . . . . . . . . 69

5.3 Graphe de transformation des niveaux de visibilité . . . . . . . . . . . . . . 73

5.4 DAG avec plusieurs niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.5 Plateforme NUMA et stratégie de vol de travail . . . . . . . . . . . . . . . 74

6.1 NUMA object model structure a- interne b- Arborescence de la topologie . 81

6.2 Architecture du simulateur HLSMN . . . . . . . . . . . . . . . . . . . . . . 816.3 Temps total d'exécution pour chaque scénario (a) 50 tâches (b) 200 tâches 86

6.4 Trace des acces mémoire distants (a) 50 tâches (b) 200 tâches . . . . . . . 86

6.5 Diagramme GANT résultat de l'exécution d'un scénario . . . . . . . . . . . 89

6.6 Scénario d'expérimentation pour mesurer Cmax . . . . . . . . . . . . . . . . 89

6.7 Temps total d'exécution mesuré pour le scénario joué . . . . . . . . . . . . 90

6.8 Pénalité NUMA mesuré pour scénario joué . . . . . . . . . . . . . . . . . . 93

6.9 Charge instantanée des n÷uds avec/sans vol de travail adapté NUMA . . . 95

6.10 Charge moyenne de la plateforme NUMA 4 noeuds . . . . . . . . . . . . . 95

Liste des tableaux

2.1 Augmentation de la puissance de 1990 à 2004 [HP17] . . . . . . . . . . . . 6

2.2 Finesse de la gravure de 1978 à 2028 src : [Gue16] . . . . . . . . . . . . . . 6

2.3 Caractéristiques de la hiérarchie mémoire : [HP17] . . . . . . . . . . . . . . 9

2.4 Coût des accès mémoire en cycles processeur et la bande passante . . . . . 18

2.5 Coût des accès mémoire mesuré en temps d'accès pour l'exemple �gure 2.9 18

2.6 Fonctionnalités NUMA implémentées dans les systèmes d'exploitation courants 24

4.1 Caractéristiques de l'approche réutilisation de l'ordonnancement . . . . . . 45

4.2 Caractéristiques de l'Ordonnancement du parallélisme non structuré . . . . 46

4.3 Caractéristiques de l'A�nity on Touch . . . . . . . . . . . . . . . . . . . . 47

4.4 Caractéristiques de l'approche CARREFOUR . . . . . . . . . . . . . . . . 49

4.5 Caractéristiques de l'approche MAI . . . . . . . . . . . . . . . . . . . . . . 50

4.6 Caractéristiques de l'approche MINAS . . . . . . . . . . . . . . . . . . . . 52

4.7 Caractéristiques de l'approche FBoPP . . . . . . . . . . . . . . . . . . . . 52

4.8 Caractéristiques de l'approche FORESTGOMP . . . . . . . . . . . . . . . 54

4.9 Caractéristiques de l'approche LAWS . . . . . . . . . . . . . . . . . . . . . 56

4.10 Caractéristiques des approches et du placement de données associes . . . . 57

4.11 Caractéristiques de l'ordonnancement des approches vues . . . . . . . . . . 57

6.1 Temps total d'exécution de chaque scénario 50/250 tâches . . . . . . . . . 85

6.2 Ligne tâche dans le �chier DAG au format STG étendu . . . . . . . . . . . 87

6.3 Pénalité NUMA pour chaque instance DAG sans XH-VHFU . . . . . . . . 92

6.4 Pénalité NUMA pour chaque instance DAG avec XH-VHFU . . . . . . . . 92

Liste des Algorithmes

1 Résolution systeme d'équations . . . . . . . . . . . . . . . . . . . . . . . . . 29

2 Ordonnancement par liste statique . . . . . . . . . . . . . . . . . . . . . . . 38

3 Algorithme générique d'ordonnancement des taches . . . . . . . . . . . . . . 63

4 Algorithme générique de placement des données des taches . . . . . . . . . . 64

5 Partitionnement d'un DAG en sous DAGs . . . . . . . . . . . . . . . . . . . 686 Préférence d'exécution des sous DAGs . . . . . . . . . . . . . . . . . . . . . 707 Algorithme Horizon d'exécution étendu XH-VHFU . . . . . . . . . . . . . . 72

8 Vol de travail adaptatif basé sur la distance . . . . . . . . . . . . . . . . . . 76

Liste des Abréviations

Abrev English FrançaisAoXT A�nity on First Next Touch A�nité d'acces Premiere fois SuivantBC Cache Bloc Bloc CacheBM Memory Bloc Bloc MémoireCPU Central Processing Unit (processor) Unité centrale du traitement (processeur)DAG Direct acyclic graph Graphe acyclique derigéDRAM Dynamic Random Access Memory Mémoire à acces aleatoire dynamiqueFBoPP FeedBack oriented Page Placement Retroaction orientée placement de PageFP Fireplane interconnect SunMS Fireplane interconnect SunMSHLSMN High Level Simulator of MC NUMA Simulateur de Haut niveau MC NUMAHT HyperTransport (AMD) HyperTransport (AMD)ICN InterConnect Network Réseau D'interConnexionILP Instruction Level Parallelism Parallelisme au niveau des instructionsIMC Integrated Memory Controller Controlleur Mémoire integréJIT Just In Time (Compiler) Juste au temps (Compilateur)L1/2/3 L1/2/3 Cache (Level 1/2/3) Cache Niveau 1/2/3LAWS Locality-Aware Work-Stealing Vol de travail basé sur la LocalitéLFU Least Frequently used Moins Utilisé FréquementLRU Least Recently used Moins Utilisé RécementMAI Memory A�nity Interface Interface d'A�ity MémoireMC MultiCore Processor Processeur MultcoeursMIMD Multiple Instructions Multiple Data Plusieurs Instructions Plusieurs donnéesMINAS Memory A�nity Management FW Framework de Gestion A�nité MémoireMISD Multiple Instructions Single Data Plusieurs Instructions Une seule donnéeMPO Memory Placement Optimisation Optimisation du Placement MémoireMRV Most Recent Value Valeur la plus recenteMSNoC MultiSocket Network on Chip MultiSocket réseau sur PuceNUMA Non Uniform Memory Architecture Architecture à Mémoire non uniformeQPI Quick Path Interconnect (Intel) Quick Path Interconnect (Intel)SDN SubDagNode Noeud d'un sous DAGSIMD Single Instruction Multiple Data Un Flux d'Instructions données multiplesSIMD Single Instruction Multiple Data Un Flux d'Instructions Une seule donnéesSMP Symetric MultiProcessors Multiprocesseurs SymmetriqueSMT Simultaneous MultiThreading MultiThreading SimultanéSRAM Static Random Access Memory Mémoire à acces aleatoire statiqueUMA Uniform Memory Architecture Architecture à Mémoire uniformeWP Write Policy Politique de Modi�cationWS Work Stealing (LoadBalancing) Vol de travail (Equilibtrage de charge)XH-VHFU eXecution Horizon Heuristic Heuristique Horizon d'execution

Chapitre 1

Introduction

Au début des années deux mille, l'industrie des microprocesseurs a atteint sa limiteavec sa version initiale des monoprocesseurs en se heurtant aux 3 murs qui ont freinéla loi de Moore [Moo+65] après 50 ans de prédiction. Par conséquent, l'industrie a optépour des architectures multic÷urs intégrant plusieurs c÷urs (core ou unités de calcul)sur une même puce où chaque c÷ur dispose de sa propre mémoire cache ou partagée avecles autres c÷urs, d'une mémoire principale commune constituée de plusieurs bancs demémoires le tout par son organisation physique forme une hiérarchie de mémoire deplusieurs niveaux, ainsi le système dispose de su�samment de ressources pour traiteren parallèle les applications multitâches. L'évolution de l'informatique a pris uneautre direction plus spectaculaire, une autre aventure commence l'informatique parallèlegrand publique ou le coût des ressources de calcul devient abordable et l'exécutionparallèle des applications n'est plus un luxe (s'est démocratisée). Cette évolution n'étaitpas suivie par une conception des modèles de programmation parallèle et des outilslogiciels adaptés à ces ressources (les systèmes de hautes performances d'aujourd'huisont composés de centaines de c÷urs et les systèmes futurs en intègreront des milliers- systèmes massivement parallèles). Les architectures parallèles récentes ne cessent pas dese complexi�er, des plateformes multic÷urs multi-socket intégrant plusieurs n÷udsde calcul sur une même carte mère ou puce (multic÷urs multisocket or multisocketNetwork on Chip MSNoC) [MER] ont été conçues comme solution aux problèmes dubus partagé (congestion) dans les architectures symétriques (SMP) [HP17]. A�n defournir une bande passante mémoire su�sante dans ces systèmes, la mémoire vive estdistribuée physiquement sur plusieurs contrôleurs mémoire associe à un n÷ud avecun accès non-uniforme à la mémoire (NUMA) [HP17].

1.1 Problématique et motivation

En raison de la complexité de ce dernier type d'architectures parallèles, les coûtsd'accès mémoire peuvent varier en fonction de la distance entre le processeur et le bancmémoire accédé. Ce fait a introduit une pénalité sur le temps d'exécution total desapplications parallèles qui s'exécutent sur les n÷uds de cette plateforme [HP17]. D'unautre coté, vu que le nombre de c÷urs est devenu très élevé dans les architectures modernes(manycore), telles machines entraînant des accès mémoire concurrents qui conduisent àdes ponts chauds sur des bancs mémoire, générant des problèmes d'équilibrage de

1

charge, de contention mémoire et d'accès distants [HP17]. Des travaux de rechercherécents ont identi�é les modèles de programmation à base de tâches indépendantesà granularité �ne comme une approche clé pour exploiter la puissance de calcul desarchitectures généralistes massivement parallèles [HP17].

Toutefois, peu de recherches ont été conduites sur l'optimisation dynamique desprogrammes parallèles à base de tâches dépendante a�n de réduire l'impact négatifsur les performances résultant de l'e�et NUMA.

Les plates-formes multic÷urs avec un accès mémoire non uniforme (MC-NUMA) sontdevenues des ressources usuelles de calcul haute performance.

Par conséquent, les principaux dé�s sur les plates-formes NUMA pour ordonnan-cer une application parallèle décrite par un graphe de tâches dépendantes acyclique(DAG) sont :

1- Réaliser la bonne allocation tâche/thread-n÷ud (Trouver l'ordre optimal ouproche pour exécuter les tâches de ce DAG sur les n÷uds de la plate-forme).

2- Réaliser le bon placement donnée-thread/mémoire-n÷ud (Mapper les don-nées de telle façon de réduire la latence des accès mémoire et de maximiser la bandepassante).

3- Equilibrer la charge entre les c÷urs/n÷uds de calculs.

4- Garder certaine proximité spatiale et temporelle entre les tâches dépendanteslors de l'exécution a�n de préserver la localité des données.

1.2 Objectifs de la thèse

Le but de cette thèse est de :

1- Déterminer les enjeux et les opportunités concernant l'exploitation e�cace demachines multic÷urs NUMA par des applications parallèle à base de tâches dépendantesdécrite par un DAG, en optimisant son ordonnancement .

2- Proposer des mécanismes e�caces pour le placement de tâches et de données,améliorant la localité des accès à la mémoire ainsi que les performances systèmes, enoptimisant le placement des données associes aux tâches .

Les décisions de placement sont basées sur l'exploitation des informations sur lesdépendances entre tâches disponibles via des annotations et d'autre technique fourniespar les langages de programmation parallèle à base de tâches et les supports exécutifsmodernes (runtime).

2

1.3 Contributions

Dans ce contexte, l'objectif principal de cette thèse est d'assurer un ordonnancemente�cace des tâches d'un DAG sur des machines NUMA multic÷urs en contrôlant leplacement des données associes aux tâches en exécutions en favorisant la proximité spatialeet temporelle (a�nité mémoire).

La contribution majeure de cette thèse consiste à concevoir une approche d'ordonnance-ment d'un DAG dans le contexte NUMA qui favorisent l'a�nité mémoire tâche/donnée etla proximité de voisinage tâche/tâche en minimisant la métrique classique d'un problèmed'ordonnancement qui est le temps total d'exécution des tâches. Nos contributions :

1- Réalisation d'un simulateur NUMA dont les principaux aspects des plateformesNUMA ont été implémenté dans d'un simulateur que nous avons utilisé pour les évaluationsprésentées dans ce travail.

2- Etude et comparaison de l'impact des politiques d'ordonnancement des tâches /placement des données sur les performances des applications sur les plateformes NUMAdont les tâches sont indépendantes (pas de communication ou partage des données entreles tâches).

3- Conception d'un algorithme d'ordonnancement basé sur l'heuristique Horizond'exécution adapté NUMA qui consiste à partitionner l'ensemble des tâches en plusieursclasses disjointes en fonction de l'état courant d'exécution des tâches et sélectionner cellequi va élargir cet horizon.

4- Equilibrage de charge dynamique entre les n÷ud/c÷urs de la plateforme enutilisant une stratégie de vol de travail adapté pour NUMA basé sur la matrice distancede la plateforme.

1.4 Plan et Organisation de la thèse

Ce document s'organise de la façon suivante :

1- Le présent chapitre introduit le contexte, la motivation et la contribution denotre étude.

2- Le deuxième chapitre est consacré à la présentation de l'évolution de la technologiedes microprocesseurs, des architectures parallèles et en particulier SMP-UMA et la platefor-me NUMA. Nous exposons les concepts clés qui ont une relation directe sur l'exécutiondes applications parallèles.

3- Le troisième chapitre présente le modèle de la description des applicationsparallèles à base de tâches et en particulier le modèle du graphe de tâches (DAG) quiest le sujet de notre étude. La terminologie associée à ce contexte est expliquée danscette partie en commençant par le processus de la description, ensuite le processus del'exécution et à la �n les algorithmes utilisés.

3

4- Le quatrième chapitre présente l'état de l'art des algorithmes d'ordonnancementplacement dans le contexte des Multic÷urs et de NUMA en dressant un panorama despolitiques d'ordonnancement/placement existants

5- Dans le cinquième chapitre, nous introduisons nos heuristiques pour améliorerles algorithmes existants d'ordonnancement NUMA et équilibrer la charge des supportsexécutifs.

6- Le sixième chapitre est consacré à l'introduction du simulateur réalisé ainsi quela simulation des algorithmes donnés dans le chapitre précédents suivi par une analysedes résultats des di�érents scenarios expérimentés.

7- Le dernier chapitre comme conclusion de ce travail, il récapitule nos principalescontributions. Il présente également les pistes de recherche futures à explorer et l'extensionde nos travaux à d'autres champs d'application (NUMA clusters ou autre).

1.5 Production scienti�que

Ce travail a mené à la publication deux articles acceptés dans les revues EEA etIJIST ainsi qu'une version initiale présentée dans la conférence LAPECI.

� Mohamed Slimane et Larbi Sekhri. Modeling the Scheduling Problem of Identi-calParallel Machines with Load Balancing by Time Petri Nets. In, International Journalof Intelligent Systems Technologies and Applications, déc. 2014, p. 42-48. [SS14a]

� Mohamed SLIMANE et Larbi SEKHRI. HLSMNHigh level Multicore NUMA Simulator.In : Electrotehnica, Electronica, Automatica, vol. 65, no. 3, pp. 170-175 (2017). url :http ://www.eea-journal.ro/ro/d/5/p/EEA65325. [SS17]

� Mohamed SLIMANE, Larbi SEKHRI, 'Parallel Pipelined Implementation of DESCryptographic Algorithm on Multicore Machines', 1éres journées Scienti�-ques duLaboratoire d'Architectures Parallèles, Embarquées et du Calcul intensif (LAPECI)28 et 29 septembre 2014, Oran, Algérie.[SS14b]

4

Chapitre 2

Paradigmes architecturaux desplateformes Multic÷urs-UMA/NUMA

Dans ce chapitre, nous introduisons les concepts concernant les supports matérielsresponsables de l'exécution des applications parallèles. L'objectif est de présenter lesparticularités techniques et les spéci�cités architecturales des di�érents types de plateformesparallèles. Pour concevoir des ordonnanceurs e�caces qui puissent tirer parti e�cacement(et si possible facilement) des architectures parallèles, il faut exploiter certaines caractéristi-ques liées à la spéci�cité du type ciblé. En e�et, pour obtenir de bonnes performances, lesapplications parallèles doivent exploiter les avantages de l'architecture sous-jacente et lesservices proposés par le support exécutif (runtime). Les ordinateurs actuels disposent deplusieurs niveaux de parallélisme matériel. Ils peuvent disposer de plusieurs processeursconnectés par un réseau d'interconnexion, qui eux-mêmes sont composés de plusieursc÷urs, et ces c÷urs disposent d'unités de calcul vectoriel.

Dans la section 2.1, nous décrivons tout d'abord les architectures des processeursmonocoeurs. Nous détaillerons les di�érentes limitations physiques qui régissent ces archite-ctures. Puis, dans la section 2.2, nous considérons un autre type de plateforme qui sera lesuccesseur du monoprocesseur, les multic÷urs, nous nous intéressons à cette architectureet à ses caractéristiques. La section 2.3 expose le premier type des plateformes multiproce-sseurs UMA/SMP. La plateforme NUMA, qui sera l'objet de notre étude, est présentéedans la section 2.4. En�n, la section 2.5 présente le problème du placement des donnéesen introduisant le concept de la localité des données ainsi que la terminologie associéedans ce contexte.

2.1 Processeurs monoc÷ur

Depuis son invention en 1969 et sa première commercialisation en 1971, le micro-processeur a suivi une évolution phénoménale en doublant sa capacité de traitementtous les deux ans comme il a prédit le cofondateur d'Intel Mr G. Moore dans son articlede 1965 que le nombre des transistors sur les puces semi-conducteurs va doubler chaque18 mois. Ce nombre est déterminé par l'évolution de la �nesse de gravure dont ladiminution permet d'augmenter ce nombre par puce et aussi sa fréquence [Moo+65].Durant cette évolution, les processeurs ont connu une succession de transformation dansses versions (single cycle processor, Pipelined , Deep-Pilepline, Superscalar, Out-of Order)[HP17].

5

Jusqu'au début des années deux mille, Les performances des processeurs construitssur le modèle de von Neumann ont continué d'augmenter de façon exponentielle. Aucours des années, les processeurs sont devenus de plus en plus petits. Cette diminutiona�ecte directement, en termes de fréquence, leurs performances. Ces dernières années,Cette augmentation amorce un fort ralentissement (Table 2.1 donne la tendance del'augmentation de la puissance par date).

Année 1990 2000 2004

Augmentation de puissance 60% 40% 20%

Table 2.1: Augmentation de la puissance de 1990 à 2004 [HP17]

Les contraintes qui ont freiné cette évolution sont exprimées par le terme "Patter-sonthree walls" [Berkeley's David Patterson succinctly summarized INTEL's problem in"Patterson's Three Walls" : Power Wall + Memory Wall + ILPWall = Brick Wall][Fisveb]qui désigne les barrières (murs) confrontés par les méthodes et les technologies utiliséesdans le processus de fabrication des processeurs. Alors elles ont atteint leurs limites. Lestrois mur/barrières de Patterson sont :

2.1.1 Puissance

La diminution de �nesse de gravure a permis de mettre plus de transistors par la mêmepuce qui ont besoin de plus de puissance qui va entrainer une consommation électriqueet une dissipation thermique importantes. Ce processus (�nesse de gravure) a une limitephysique que toute technologie utilisée pour cette opération est incapable d'aller au delàde cette limite. En e�et, il se heurt à des phénomènes physiques limitant les performances.La table 2.2 donne la tendance de la �nesse de gravure par date depuis 1978 jusqu'à 2015et les prévisions pour l'année 2021 et 2028 (qui sera la �n du processus de la diminutionde la taille physique de la grille des transistors à 5nm [Gue16]).

Année 1978 1985 1995 2005 2015 2021 2028

Finesse de Gravure 100nm 52nm 35nm 25nm 15nm 10nm 5nm

Table 2.2: Finesse de la gravure de 1978 à 2028 src : [Gue16]

Donc, l'augmentation de la fréquence, pour permettre celle des performances, aatteint ses limites. Ces dernières sont proportionnelles au produit du nombre de transistorspar la fréquence d'horloge. En e�et, un transistor consomme et dissipe à chaquechangement d'état. Donc, plus il y a de transistors, plus il y a de consommation électriqueet de dissipation thermique. Ce phénomène est ampli�é par la fréquence d'horloge qui vaaugmenter la fréquence des changements d'état et donc la consommation et la dissipation.La consommation électrique et la dissipation thermique ont aujourd'hui atteint des seuilscritiques avec certains processeurs ayant une consommation de plus de 100W et nécessitantd'imposants systèmes de refroidissement. Donc, Nous ne pouvons plus augmenter lafréquence des processeurs avec la conception actuelle des transistors. La �gure 2.1 donnel'évolution des fréquences maximales des processeurs durant ces derniers 40 ans.

6

Figure 2.1: Evolution des fréquences maximales de processeurs [HP17]

2.1.2 Mémoire

Une caractéristique importante du développement matériel au cours des dernièresdécennies a été l'écart croissant entre le temps de cycle de l'horloge du processeuret le temps d'accès à la mémoire principale. La mémoire principale est construite sur labase de la mémoire DRAM (Dynamic Random Access Memory) qui est trop lentepar rapport au cycle d'horloge du CPU. Les calculs impliquant uniquement le registre duprocesseur peuvent être e�ectués rapidement, mais lors d'un accès à la mémoire principale,le processeur se bloque pendant de nombreux cycles en attendant les données de lamémoire avant de pouvoir reprendre l'exécution et cela limite fortement ses performances.Durant cette opération, beaucoup de cycles sont perdus à attendre que des données enmémoire soient mises dans les registres. Cet écart (de la vitesse entre le processeur et lamémoire) est devenu très grand ce qui rend inutile de continuer cette course qui n'est passuivie par la mémoire. En e�et, la di�érence entre la fréquence du processeur et celle dela mémoire est telle que tout accès mémoire devient extrêmement coûteux (memory wall[McK04]). La �gure 2.2 donne l'écart de la vitesse entre le processeur et la mémoire.

Figure 2.2: Ecart de la vitesse entre le processeur et la mémoire [McK04]

7

2.1.3 Pipeline ILP( Instruction Level Parallelism)

Le parallélisme matériel a atteint sa limite de 40 étages au delà il y a peu deparallélisme avec un coût important (Extraction du parallélisme au niveau des instructionsà partir d'un �ot séquentiel bas niveau).

"L'industrie a été stupéfaite lorsque Intel a annulé non pas un, mais deux modèles deprocesseurs de premier plan en mai 2004. Intel Tejas (le mono remplaçant de Pentium4) a dissipé 150 watts à 2,8 GHz avec un pipeline de 40 étages et un socket 1000pins. Lorsque les microprocesseurs sont trop chauds, ils cessent de fonctionner et parfoisexplosent." Suite à cet évènement, l'expression "Intel's Tejas hits the walls - hard" aexprimé la situation de l'industrie des microprocesseurs, en marquant la �n de la périodedes monoprocesseurs . Ainsi, Intel a rapidement changé de direction, et a annoncé lepremier double c÷ur processeur en lançant la révolution des multic÷urs. [Fisvea]

2.2 Processeurs Multic÷urs (Multicore)

Le processeur multic÷urs est un processeur intégrant plusieurs unités de calculen les dupliquant sur la même puce. On appelle chaque unité un c÷ur (core) qui estcapable de faire un traitement, d'accéder à la mémoire, d'exécuter des entrées/sorties, quiest superscalaire, out-of-order et dispose d'un certain nombre d'unités de calcul vectoriel(Single Instruction Multiple Data ou SIMD). L'ensemble des c÷urs fonctionne en parallèleen réalisant les tâches a�ectées (calcule, communication RAM - I/O).

Figure 2.3: Architecture du processeur d'Intel Multicore i7 [HP17]

La �gure 2.3 montre un exemple d'un processeur multic÷urs le processeur Intel Corei7, il dispose de quatre c÷urs regroupés par 2. Chaque c÷ur a son +propre cache de niveau1 et 2 (L1, L2) et Ils ont un cache de niveau 3 (L3) partagé. D'un point de vue de calculparallèle, les di�érences majeures entre les processeurs multic÷urs disponibles sont :

2.2.1 Contrôleur de mémoire intégré

Les fournisseurs des processeurs ont intégré un contrôleur de mémoire et un busdans la CPU MC pour connecter la mémoire du système à pleine vitesse à ces c÷urs. Ceconnecteur (le bus qui relie les c÷urs à l'IMC) est généralement partagé entre tous lesc÷urs du processeur.

8

2.2.2 Hiérarchie de la mémoire [TG13]

Vu que le système de mémoire est très lent par rapport au processeur et pour utilisere�cacement les cycles de ce dernier et réduire la pénalité de l'accès mémoire (Une puceDRAM a un temps d'accès mémoire entre 20 et 70 ns et un processeur à 3 GHz defréquence, a un temps de cycle de 0.33 ns, un accès mémoire est équivalent à 60�200cycles processeurs). Une hiérarchie de mémoire est généralement utilisée, composée deplusieurs niveaux de mémoires de tailles et de vitesses d'accès di�érentes. La �gure 2.4schématise cette hiérarchie avec ses di�érents composants et 2.3 donne les valeurs associéesaux métriques quantitatives mesurant ses caractéristiques, seule la mémoire principale ausommet de la hiérarchie est construite à partir de DRAM (Dynamic Random AccessMemory), les autres niveaux utilisent SRAM (Static Random Access Memory).L'objectif dans la hiérarchie mémoire est d'avoir un temps d'accès mémoire moyen faibleen favorisant l' accès aux données à partir d'une mémoire rapide, et qui contient seulementune partie des données de la mémoire principale lente. Sa conception peut avoir une grandein�uence sur le temps d'exécution des programmes parallèles.

Figure 2.4: Hiérarchie de la mémoire

Level Register Cache L1 Cache L2 Cache L3 Memory Disk

Technology Gate SRAM SRAM SRAM DRAM Flash/Magnetic

Data Word Line (Bloc) Line Line Page File

Capacity 1Kbit 64KB 256KB 2-4MB 1-16GB 1-16TB

Latency 30ps 1ns 3-10ns 10-20ns 50-100ns 5-10ms

Table 2.3: Caractéristiques de la hiérarchie mémoire : [HP17]

2.2.3 Caches

Tous les processeurs modernes sont équipés d'une mémoire de petite capacité (allantde quelques Ko à quelques Mo) mais très rapide (0.5-2.5 ns comparé au DRAM 50-70ns )appelée cache SRAM qui stockent des données (une partie des données de la mémoire) sur

9

lesquelles le processeur travaille temporairement et qui masquent la latence d'accès àla mémoire principale lente. L'emplacement physique de la mémoire cache est très prochedes c÷urs a�n de réduire les coûts de communication.

Dans une con�guration typique, un CPU comprend plusieurs caches, formant unehiérarchie de cache Les caches peuvent être une autre ressource partagée sur lesprocesseurs.

Le cache de premier L1 est local pour chaque c÷ur de petite taille, comprise entre8 et 128 kilo-octets, mais assez rapide.

Le cache du deuxième niveau L2 peut être local pour chaque c÷ur ou partagéentre les c÷urs moins rapide que L1 et mais de taille supérieure, L1 et L2 sont partagésentre les threads matériels.

Le cache de troisième niveau L3, cependant, est partagé entre tous les c÷urs duprocesseur de grande taille mais lent

Les caches stockent les blocs de données des niveaux supérieur sous la forme delignes de cache = bloc : un bloc contigu d'octets. La taille est �xe, dépend del'architecture, typiquement elles sont de 32 octets sur certains processeurs de l'architectureARM [Lim07], ou 64 octets sur les processeurs x86 de l'architecture Netburst d'Intel

Grace à un contrôleur de cache séparé, le contrôle du cache est découplé duprocesseur et exécuté par ce dernier. Pendant l'exécution du programme, le processeurspéci�e les adresses mémoire (indépendamment de l'organisation du système de mémoire,sans connaître l'architecture) à lire ou à écrire comme données par les opérations dechargement/stockage. il les transmet à ce système et attend que les valeurs correspondantessoient renvoyées ou écrites. Après avoir reçu une requête d'accès mémoire du processeur,le contrôleur de cache véri�e si l'adresse mémoire spéci�ée correspond à une ligne de cachequi est actuellement stockée dans le cache. Si c'est le cas, une mise en cache cache-hitse produit et la donnée demandée est transmise au processeur à partir du cache. Sinonun cache manqué cache-miss se produit et la ligne de cache est d'abord copiée dela mémoire dans le cache (un bloc de mémoire entier est amené dans le cache, dit unremplacement cache) avant que la donnée demandée ne soit délivrée au processeur. Letemps de retard correspondant est appelé pénalité du cache-miss. Étant donné que letemps d'accès à la mémoire est signi�cativement plus grand que le temps d'accès au cache,un cache-miss entraîne un retard de remise d'opérande au processeur. Par conséquent, ilest souhaitable de réduire autant que possible le nombre des cache-miss. Le temps d'accèsd'un cache dépend de sa taille, la taille du bloc-cache et sa méthode d'adressage, Toutefois,l'utilisation d'un cache plus grand entraîne un plus petit nombre de remplacements parrapport un cache plus petit, car davantage de blocs de cache peuvent être conservés dansle cache. L'utilisation de blocs plus grands réduit le nombre de blocs qui s'intègrent dansle cache lors de l'utilisation de la même taille de cache. Par conséquent, les blocs onttendance à être remplacés plus tôt par rapport aux blocs plus petits.

Étant donné que le cache est nettement plus petit que la mémoire principale, tousles blocs de mémoire ne peuvent pas être stockés dans le cache en même temps. Parconséquent, un algorithme d'association doit être utilisé pour dé�nir la relation entreles blocs cache/mémoire (BC/BM) et détermine comment un bloc stocké est localisé etextrait du cache. Pour l'association, l'accès associatif clé(tag)/valeur(contenu du BM)sera utilisé pour déterminer pour un bloc-mémoire les positions des blocs-cache ou il peutêtre stocké/sa position dans le cache pour une mise à jour ou une lecture, s'il est déjà

10

chargé dans le cache. [HRR07]

Méthodes de Remplacement des blocs

Lorsqu'un cache-miss se produit, un nouveau bloc de mémoire doit être chargé dansle cache. Dans ce cas, il faut choisir la position dans le cache pour stocker le nouveau blocmémoire alors il faut décharger le bloc occupant cette position. Le bloc à remplacer estsélectionné en utilisant une méthode de remplacement.

- Le moins récemment utilisé (Least recently used LRU) qui remplace le blocd'un ensemble qui n'a pas été utilisé depuis un certain temps. le matériel doit garder unetrace pour chaque bloc d'un ensemble lorsque ce dernier a été utilisé récemment et sontemps d'accès correspondant doit être mise à jour à chaque utilisation.

- Le moins fréquemment utilisé (Least frequently used LFU) qui remplacele bloc d'un ensemble qui est le moins référencé (peu d'accès à ce bloc). pour chaquebloc un compteur doit être maintenu par LFU qui doit être mis à jour pour chaque accèsmémoire.

Politique de modi�cation (Write Policy)

Lorsque le processeur émet un accès en écriture à un bloc de mémoire actuellementstocké dans le cache, le bloc référencé est dé�nitivement mis à jour dans le cache, carl'accès en lecture suivant doit renvoyer la valeur la plus récente (most recent value MRV).Quand le bloc mémoire correspondant dans la mémoire principale est-il mis à jour ? Lastratégie qui prend cette décision est appelé politique d'écriture ou de modi�cation.Les politiques les plus utilisées sont :

- Modi�cation immédiate (Write-Through) la mise à jour de la mémoire estfaite immédiatement âpres la modi�cation du BC ce qui permet de garder la mémoireet le cache dans un état consistant. son inconvenant est que chaque modi�cation cachedéclenche un accès mémoire.

-Modi�cation retardée (Write-back) Une opération d'écriture d'un bloc de mémoireactuellement réside dans le cache est e�ectuée uniquement dans le cache ; l'entrée demémoire correspondante n'est pas mise à jour immédiatement. Ainsi, le cache peut contenirdes valeurs plus récentes que la mémoire principale.

2.2.4 Cohérence de Cache

Pour les systèmes multiprocesseurs-multic÷urs où chaque processeur/c÷ur utilise uncache local séparé, nous sommes confrontés au problème de conserver une vue cohérentedes données partagées entre tous les processeurs/c÷urs. Les données partagées stockées àdes niveaux di�érents dans la hiérarchie de la mémoire peuvent conduire à un problèmede cohérence de cache qui peut être dé�ni lorsque les di�érents c÷urs du processeurcopient les mêmes informations de la mémoire/cache partagé, et que diverses copies desdonnées seront stockées dans le cache de chaque c÷ur, surtout si la politique write-backest utilisée. Par conséquent, chaque copie de données peut avoir une valeur distinctedes copies des 'autres c÷urs après qu'elle est traitée séparément, elle est alors appelée

11

copie incohérente (invalide). [TG13] Alors comment garder les di�érentes copies d'unedonnée mémoire consistantes et système doit assurer l'accès à la valeur mise a jourrécemment (most recent value MRV) ?

La cohérence des informations entre mémoire-cache et cache-cache est un élémentfondamental car elle garantit qu'un processeur/c÷ur a accès à la dernière valeur qui aété écrite. Pour être cohérent, le système de mémoire doit satisfaire certaines propriétésen assurant que chaque processeur a une vue cohérente et que lui même a une vueglobale cohérente. Pour réaliser cet objectif, un protocole de cohérence de cache basésur le matériel est utilisé. De nombreux protocoles peuvent être identi�és, y compris lesprotocoles de surveillance et les protocoles basés sur les répertoires.

Protocole de surveillance

Ce protocole repose sur la propriété que tous les accès mémoire sont e�ectués via unsupport partagé de di�usion (un bus) de sorte que chaque contrôleur de cache puisseobserver tous les accès en écriture pour e�ectuer des mises à jour ou des invalidations.Ainsi, toutes les entrées peuvent être observées par les contrôleurs de cache de chaqueprocesseur. Lorsque le contrôleur de cache observe une écriture dans un emplacementde mémoire actuellement détenu dans le cache local, il déclenche un mécanisme pourpréserver la cohérence. il a deux techniques :

protocoles basés sur des mises à jour : Les contrôleurs de cache e�ectuentdirectement une mise à jour du cache en copiant la nouvelle valeur à partir du bus.Ainsi, les caches locaux contiennent toujours les valeurs écrites les plus récentes desemplacements de mémoire.

protocoles basés sur l'invalidation : Dans ce cas, le bloc de cache correspondantà un bloc de mémoire est invalidé de sorte que l'accès en lecture suivant doit d'aborde�ectuer une mise à jour à partir de la mémoire principale. [TS02]

Protocole basé sur l'annuaire

Ce protocole est une alternative au protocole de surveillance, au lieu d'utiliser unsupport de di�usion, il utilise un répertoire central pour stocker l'état des blocs demémoire qui peuvent être conservés dans le cache. un contrôleur de cache peut obtenirl'état d'un bloc de mémoire par une recherche dans le répertoire. Ce répertoire peut êtrepartagé ou réparti entre di�érents processeurs pour éviter les con�its d'accès. [CSG99]

Un répertoire central est maintenu pour sauvegarder l'état de chaque bloc mémoirequi est déjà copié dans un cache. Ce répertoire peut être partagé. Le contrôleur de cachedétermine l'état d'un bloc en accédant et en consultant ce répertoire.

2.3 Systèmes SMP/UMA (uniform memory access)

Ils sont des multiprocesseurs à mémoire partagée via un bus commun, comportent unpetit nombre de processeurs, généralement huit ou moins souvent appelés Multiproce-sseurs symétriques (à mémoire partagée) (SMP) . Vue leurs conception architecturale,Les SMP et les MC ont en commun une contrainte qui limite leurs performances, la

12

mémoire centrale partagée et l'accès à un espace d'adressage commun pour toutes lesunités de traitement (soit processeurs ou c÷urs). Toutes ces unités ont un temps d'accèségal à cette mémoire (un temps d'accès à la mémoire uniforme pour tout le monde UMA),d'où le terme symétrique ou l'uniformité.

Un algorithme séquentiel As parallélisé (Ap) pour être exécuté sur une architectureUMA peut ne pas atteindre les performances espérées préalablement (gain en rapiditéet la réduction signi�cative du temps total d'exécution Cmax) pour plusieurs raisonsqui peuvent être liées à sa nature, à la méthode de la décomposition parallèle ou auxcontraintes des architectures cibles. Avant d'exposer ces facteurs, nous présentons lesmétriques qui permettent de mesurer le gain de l'exécution parallèle sur une architecturecible par rapport son exécution séquentielle.

2.3.1 Mesure de l'accélération (speedup γ)

Dé�nition : Accélération d'un programme parallèle.

En donnant un algorithme séquentiel Ap dont le temps d'exécution séquentielle sur unprocesseur est T1 , Soit Ap sa version parallèle et Tp son temps total d'exécution surl'architecture parallèle cible H. L'accélération de Ap représente le gain en rapiditéd'exécution obtenu par son exécution sur H qui est égale au rapport entre le tempsd'exécution du programme séquentiel et le temps d'exécution parallèle en fonction dunombre des ressources parallèles dans la plateforme (processeurs).

γ(n) =T1Tp

Si ce rapport est constant alors l'accélération est linéaire dans ce cas elle représente unparallélisme optimal (idéal). Mais s'il est variable sa courbe représente une accélérationsub-linéaire (au dessous de la ligne y = x) alors ce ralentissement dû au overhead duparallélisme causé par la communication et la synchronisation.

La décomposition d'un programme parallèle in�uence sur ce facteur. Et puisque cettedécomposition est fonction degré intrinsèque de parallélisation de l'algorithme séquen-tiel( L'existence d'une partie purement séquentielle Ts et d'une partie parallélisable Tp telque T1 = Ts + Tp avec un taux de parallélisation αp = Tp/T1) . La loi d'Amdahl ra�nel'expression de gamma en fonction de cette décomposition et le nombre des processeursp de la plateforme parallèle, par la formule suivante [TG13] :

γ =T1

Ts + Tp/p=

1

(1− αp) + αp/p

On remarque que si limp→∞ γ = 1/(1− αp) alors cette accélération est limitée par lapartie non parallélisable de A. Et si limαp→1 γ = p ça donne une accélération linéaire (unparallélisme optimal).

Cette mesure γ exprime une valeur théorique qui ne prend pas en compte l'in�uencedes opérations de la communication et la synchronisation entre les parties parallèles entreelles-mêmes ou avec la hiérarchie mémoire d'une part et l'impact de l'architecture dela plateforme parallèle (ses caractéristiques, sa topologie, ) avec son support d'exécution

13

(runtime, ordonnanceur, mapper, ...) d'autre part. Ces deux facteurs ajoutent un overheadnon négligeable aux processus de la parallélisation. Bien que les caches, la préextraction(pre-fetching) et les canaux de communication améliorent considérablement les performancessi elles sont exploitées e�cacement, pas tous les accès à la mémoire principale peuvent êtreéliminés et ou les communications entre les parties parallèles l'amélioration de la latenced'accès DRAM et la minimisation de l'impact de la communication/synchronisation resteune préoccupation majeure pour les performances.

Dans le contexte des architectures SMP/multic÷ur, un système parallèle de p unitésde traitement (processeur/c÷ur), chaque unité supplémentaire augmente potentielle-mentle nombre total de demandes à la mémoire principale par unité de temps t et le nombredes opérations communication/synchronisation QM(p, t) et augmente ainsi la pression surle contrôleur de mémoire et sur bus partagé en réduisant la bande passante et augmentantla latence d'accès à la DRAM LM(p, t).

QM(p, t) ≤ QM(p+ 1, t)⇒ LM(p, t) > LM(p+ 1, t)

Pour p0 su�samment grand LM(p0, t) >> devient important. Une fois la bandepassante du contrôleur saturée, la latence des accès à la DRAM augmente et les accèsmémoire deviennent rapidement un goulot d'étranglement pour les performances quiaugmentent le temps des communications et par conséquent le temps total d'exécutionCmax .

2.3.2 Passage à l'échelle (scalability ζ)

Dé�nition : Accélération d'un programme parallèle.

La scalabilité (ζ) d'un programme parallèle désigne l'augmentation des performances(Φ) obtenues lorsque l'on ajoute des processeurs p :

ζp = ∆(p) = Φ(q + p)/Φ(q)

La scalabilité mesure l'évolutivité qui est le degré auquel le débit de charge de travailW béné�cie de la disponibilité de processeurs supplémentaires ou la faculté d'un systèmede maintenir un niveau de performance stable Φc. Il est généralement exprimé comme lequotient du débit de la charge de travail Wp sur un multiprocesseur divisé par le débitsur un monoprocesseur comparable W1 : ζp = Wp/W1. Dans leurs travaux Gunther .alpropose un modèle pour quanti�er la scalabilité de façon générale. Le modèle proposé USL(Universal scalabilité law) [GSP17] combine les e�ets suivants en dé�nissant un modèlede scalabilité uni�ée dont le coe�cient de scalabilité C(N) :

C(N) =N

1 + α(N − 1) + βN(N − 1)

Les termes du dénominateur expriment les aspects suivants (les niveaux 3Cs) :- Concurrence : (parallelism ideal) : basically, linear scaling (Computation) .- Contention : due aux �les d'attente des ressources partagées(Communication α)- Cohérence : due au retard de la mise à jour des données dans la hiérarchie mémoire

14

(rendre les données consistantes et cohérentes) (β).

Dans le contexte des machines parallèles récentes, nous pouvons inclure les facteursignorés dans la loi d'Amdahl en dé�nissant un speedup γ étendu exprimé en fonctiondu parallélisme intrinsèque de la l'algorithme séquentiel (la partie parallélisable) et sonoverhead de la communication/synchronisation βc généré par son exécution parallèle surla plateforme cible (la con�guration de la plateforme c.-à-d. sa topologie, sa hiérarchiemémoire, son réseau d'interconnexion,).

γ(n) =1

(1− αp) + αp/p+ βc= h(algorithme_parallèle , plateforme_con�guration)

La �gure 2.5 présente la scalabilité de certaines plateformes informatiques. Elle donne la

Figure 2.5: Scalabilité linéaire, SMP et Cluster [HP17]

mesure de l'accélération résultant du processus de la parallélisation d'une application surune plateforme parallèle constituée de plusieurs processeurs.

L'expérimentation a démontré que les charges de travail réelles ne s'adaptent pasparfaitement à un système SMP à partir de certain seuil. Dans ce contexte, les principauxfacteurs qui empêchent une scalabilité parfaite sont les suivants :- La contention bus/mémoire augmente (toute la mémoire est partagée par tous les proces-seurs)- L'augmentation du coût/nombre des échecs caches (ratés)- Le cache invalidation des caches distants (lire un cache distant pour maintenir lacohérence du cache)- Augmentation du coût / nombre des instructions de synchronisation / verrouillage -déverrouillage / attente de verrous utilisés par le système d'exploitation et applications .

Tous ces facteurs contribuent négativement à achever un niveau de scalabilité acceptablesur SMP pour des charges de travail moyennes ou importantes. C'est di�cile dans cesconditions (SMP-mémoire partagée avec un bus d'accès unique) de préserver un niveaustable des performances en ajoutant d'autre processeurs à partir de certain seuil p0 parcontre toute augmentation va avoir un e�et négatif sur la performance (Problème descalabilité : ∀p > p0, ζp ≤ ζp−1)

2.4 Systèmes NUMA Non Uniform memory Access

NUMA est une solution pour surmonter les problèmes de la scalabilité des architec-tures SMP [Pan11], basée sur le principe d'une mémoire distribuée et partagée ou les

15

processeurs accèdent à tout l'espace mémoire disponibles. Chaque processeur est directem-ent connecté à une partie de la mémoire physique (un banc mémoire). Un exempled'une carte mère NUMA à quatre n÷uds constitués d'un microprocesseur et d'un bancmémoire est donné dans la �gure 2.6. La deuxième �gure 2.7 montre l'architecture typiqued'une plateforme NUMA deux variantes présentées à deux n÷uds et à plusieurs n÷udsrespectivement.

Figure 2.6: Carte mère NUMA

Figure 2.7: Architecture NUMA (a) Plusieurs n÷uds (b) à deux n÷uds

2.4.1 Architecture NUMA

Son architecture est constituée de composants suivants :

N÷ud (Node, Socket)

Un n÷ud peut être un processeur multic÷urs ou un SMP constitué de plusieursprocesseurs multic÷urs qui se caractérise par l'uniformité de l'accès à la mémoire detous ces composants (UMA).

16

Réseaux d'interconnexion (Interconnexion network ICN)

Un réseau de liens de communication de haut débit et de faible latence, les échangessont établis via une connexion sur ce réseau (déterminer le chemin entre deux communicants,un routage). Ce réseau est caractérisé par sa topologie déterminée par la façon de connecterles n÷uds des plateformes. Deux classes de topologies existent :

A- Topologie point-a-point (entièrement maillé) : permet de connecter tous lesn÷uds en direct (un seul saut) Ce type de topologie dégrade les performances lors dupassage à l'échelle pour un réseau moyen ou important de processeurs connectés vu quele nombre des liens requis est quadratique O(n2).

B- Topologie spéci�que avec un mécanisme de routage : Elle peut être un arbreou anneau ou autre avec des caractéristiques géométriques spéci�ques qui permettentde déterminer la longueur du chemin pour relier deux processeurs communicants. Lesprocesseurs distants sont accessibles par plus d'un saut en plusieurs étapes intermédiairesà travers d'autres processeurs. Le mécanisme de routage permet de déterminer le cheminmenant au processeur cible à partir de la source ensuite acheminer les requêtes distantesaux processeurs cibles pour lire ou écrire une information dans sa mémoire locale à lademande du processeur source.

Parmi les ICNs implémentés sur les plateformes NUMAs modernes, nous pouvons citer[Mul13] :-a- QPI : QuickPath Interconnect (QPI) Intel [Int09]-b- HT : HyperTransport AMD [Amd]-c- FP : Fireplane interconnect Sun Microsystems [Cha a].

Mémoire distribuée-partagée

Le système de mémoire est hybride, une mémoire distribuée-partagée, physiquementdistribuée sur les n÷uds et partagée entre es c÷urs de même n÷ud. L'espace d'adressageest global et partagé, n'importe quelle unité de calcul peut accéder à n'importe quelleadresse mémoire. Dans ce contexte, nous distinguons deux types de mémoire :a - Mémoire locale : des bancs de mémoire associée à chaque processeur et directementconnectés caractérisés par un accès local en écriture en lecture aux données situées danssa mémoire locale qui est assez rapid. La �gure 2.8 schématise les accès mémoire sur uneplateforme NUMA et coût correspond en fonction des cycles processeur. Pour les accèslocaux, Elle donne 38 cycles pour le cache local et 190 cycles pour la mémoire locale.b - Mémoire distante : qui, du point de vue d'un CPU, est connectée à un CPUdi�érent, caractérisée par un accès distant en écriture ou en lecture aux données situéesdans une mémoire distante qui assez lent. Sur la �gure 2.8, Pour les accès distants, Lesvaleurs données sont 186 cycles pour le cache distant et 310 cycles pour la mémoiredistante. La �gure 2.9 présente un exemple d'un code OPENMP qui s'exécute sur NUMAen parallélisant une boucle dont les données sont deux vecteurs A et B. Chaque itérationva lire une valeur de A (A[i]) et modi�e une valeur de B (A[i]). La parallélisation de laboucle crée un ensemble de tâches (thread) pour exécuter un nombre spéci�é d'itérations.Donc chaque tâche nécessite d'accéder à la plage a�ectée des valeurs de A et B pour faireson calcul. Si les vecteurs A et B sont distribués sur les mémoires de la plateforme (lecas présenté par la �gure), et la plage des éléments de A et B utilisés par la tâche T eststockée dans la mémoire du n÷ud N sur lequel T s'exécute, alors les T n'aura que des

17

Figure 2.8: Accès mémoire locaux et distants sur NUMA

Figure 2.9: Code OPENMP parallélisant une boucle sur NUMA

accès locaux. Par contre si une partie de ces éléments sont stockés sur une autre mémoirealors Certain nombre d'accès mémoire de T seront distant et cela va prolonger l'exécutionde T . Les tables 2.4 et 2.5 donnent le coût en cycle processeur, temps d'accès (local, voisinet voisin distant) et bande passante/latence respectivement des accès mémoire en fonctionde leurs nature et emplacement. Ca donne une idée de l'impact du type d'accès sur ledéroulement de l'exécution des tâches (en réduisant/augmentant le nombre de cyclesprocesseur ou temps d'accès ou latence/BP).

CACHE MEMORY BANDWIDTH

LOCAL 38 cycles 190 cycles 10.1 GB/s

REMOTE 186 cycles 310 cycles 6.3 GB/s

Table 2.4: Coût des accès mémoire en cycles processeur et la bande passante

LOCAL NODE NEIGHBOR NODE OPPOSITE NODE

READ 83 ns 98 ns 117 ns

WRITE 142 ns 177 ns 208 ns

Table 2.5: Coût des accès mémoire mesuré en temps d'accès pour l'exemple �gure 2.9

18

2.4.2 Caractéristiques NUMA

Pénalité NUMA (ratio)

Comparé à un accès local, l'accès distant est caractérisé par un débit faible et latenceimportante. En se basant sur cette réalité dans les plateformes NUMA, nous pouvonsdé�nir une métrique qui évalue l'e�cacité des politiques des gestions des ressources NUMAen fonction des ces deux types d'accès. Cette métrique est appelée ratio NUMA (distance,NUMA rate, factor). La pénalité NUMA α est le rapport du nombre d'accès local ALsur le nombre des accès distant AR pour le programme P en court d'exécution sur uneplateforme NUMA spéci�que. Cette métrique est pour quanti�er l'overhead généré par lacommunication entre les n÷uds de la plateforme lors de cette exécution [Mul13]

α(P ) =ALAR

Distance NUMA (sauts NUMA))

Les architectures à base de NUMA introduisent une notion de distance entre lescomposants du système (ie : n÷uds, processeurs, mémoire, bus d'E/S, etc.). La métriqueutilisée pour déterminer une distance(saut) entre les n÷uds NUMA varie avec la latenceet la bande passante.

Cohérence de Cache NUMA (ccNUMA)

La mémoire globale est partagée et chaque processeur peut accéder à n'importe quelélément de données, bien qu'avec des performances réduites si l'élément de données estsitué sur une banque de mémoire qui n'est pas directement connectée. Cependant, lamémoire cache interne non partagée de chaque processeur (ou de chaque n÷ud pour lesprocesseurs multi-n÷uds) n'est pas accessible depuis d'autres processeurs. Un processeurne sait donc pas si l'état d'un élément de données dans la mémoire principale est dansun état actuel ou si un état plus mis à jour existe dans un cache d'un autre processeur.Ainsi, les plates-formes NUMA utilisent un mécanisme pour appliquer la cohérence ducache à travers la mémoire partagée adapté NUMA.

La plupart des systèmes NUMA sont cependant cohérents avec le cache et sonto�ciellement appelés plateformes ccNUMA. Les plates-formes ccNUMA utilisent un maté-riel spécial qui permet la communication entre processeurs et les contrôleurs de cachebasé généralement sur la technique du répertoire. Pour chaque cache-manqué (lecture ouécriture), chaque processeur doit communiquer avec tous les autres processeurs a�n des'assurer que le prochain chargement de la mémoire principale est dans un état actuelet non stocké dans un autre cache. Cette communication a un surcoût signi�catif. A�nde réduire cette surcharge, nous devons éviter l'accès à la même zone de mémoire parplusieurs processeurs.

19

Exemple

IBM R© Power 750 Express R© [cor13] , est un système NUMA. Il est équipé de quatrecartes processeurs, et chacune contient huit c÷urs et huit emplacements mémoire (considé-rées locales). Le système contient 32 c÷urs et 256 Go mémoire et quatre n÷uds NUMAchacun avec 8 c÷urs et 64 Go mémoire locale. Avec le mode SMT4 (Simultaneous Multith-reading) activé, les systèmes d'exploitation voit 128 (32*4) processeurs logiques avec 32sur chaque n÷ud. Le listing suivant donne le résultat de l'exécution de la commandenumactl hardware [Lin] sur ce système .

numactl hardware

available: 4 nodes (0-3)

node 0 cpus: 012 3 4 5 6 7 8 9 10 11 12 13 14 .... 25 26 27 28 29 30 31

node 0 size: 61184 MB

node 0 free: 59734 MB

node 1 cpus: 32 33 34 35 36 37 38 39 40 41 42 .... 57 58 59 60 61 62 63



node 2 cpus: 64 65 66 67 68 69 70 71 72 73 74 .... 89 90 91 92 93 94 95



node 3 cpus: 96 97 98 99 100 101 102 103 104 .... 123 124 125 126 127



node distances:

node 0 1 2 3

0: 10 20 20 20

1: 20 10 20 20

2: 20 20 10 20

3: 20 20 20 10

2.5 Localité des données et Politiques de Placement

2.5.1 Principe de la localité

Le principe de localité est une propriété de programme en exécution qui établie que : lesprogrammes ont tendance à réutiliser les données et instructions qu'ils ont utiliséesrécemment. (Un programme consacre 90% de son temps d'exécution à seulement 10%du code). Ce principe permet de prédire quelles instructions et données un programmeutilisera dans un avenir proche en fonction de ses accès dans un passé récent. Il s'appliqueaux accès aux données et code. Il existe des types communs de localité de référence utilisés

20

dans les architectures informatiques. La localité spatiale et temporelle peut être distinguéecomme suit :

Localité spatiale

Les accès mémoire d'un programme ont une grande localisation spatiale, si le programmeaccède souvent à des emplacements de mémoire avec des adresses voisines à des momentssuccessifs pendant l'exécution du programme. Ainsi, pour les programmes avec une grandelocalisation spatiale, il arrive souvent qu'après un accès à un emplacement de mémoire,un ou plusieurs emplacements de mémoire de la même ligne de cache soient égalementaccédés peu de temps après. Dans de telles situations, après le chargement d'un bloc decache, plusieurs des emplacements de mémoire suivants peuvent être chargés à partir dece bloc de cache, évitant ainsi des erreurs de cache coûteuses. L'utilisation de blocs decache comprenant plusieurs mots de mémoire repose sur l'hypothèse que la plupart desprogrammes présentent une localité spatiale. [KA02]

Localité temporelle

Les accès mémoire d'un programme ont une forte localisation temporelle, s'il arrivesouvent que le même emplacement mémoire soit accédé plusieurs fois à des momentssuccessifs au cours de l'exécution du programme. Ainsi, pour les programmes avec unehaute localisation temporelle, il arrive souvent qu'après avoir chargé un bloc de cachedans le cache, les mots de mémoire du bloc de cache soient accédés plusieurs fois avantque le bloc de cache soit à nouveau remplacé. [KA02]

2.5.2 Politiques de Placement

L'a�nité des processus et des données est cruciale pour gérer les problèmescausés par l'e�et NUMA, ce principe consiste à préserver la proximité de threads etleurs données en en allouant aux données l'espace mémoire associées au n÷ud sur lequelle thread s'exécute. Si un thread accède à la mémoire distante, le thread peut changer sona�nité CPU à exécuter localement à la mémoire ou la mémoire peut migrer vers le threadd'accès. Ces problèmes NUMA peuvent être réduits en maintenant ou en améliorant laproximité de threads et leurs données les plus fréquemment utilisées. A�n d'optimiserexplicitement une application pour une architecture NUMA multic÷urs. Ce but est réaliséen sélectionnant une politique de placement appropriée qui place les threads et données enrespectant leurs a�nités. Cette politique essaye de trouver un compromis entre a�ectationdes processeurs aux threads et l'allocation de la mémoire aux données accédées par cesthreads. La �gure 2.10 montre deux façons de distribuer les données (les éléments desdeux vecteurs A et B) des tâches qui représentent chacune un lot d'itérations sur uneplage constitue d'éléments de A en lecture et B en écriture. La proximité des threadsà leurs données est cruciale pour la performance. Ceci est déterminé par les stratégiesde placement du système d'exploitation et les modèles de programmation parallèle. Cesderniers souvent n'o�rent aucun support explicite pour in�uencer le placement de lamémoire pour le programmeur.

Pour une mémoire partagée entre les processeurs à travers la plateforme avec des

21

Figure 2.10: Exemples de placement des données du code OpenMP sur NUMA

accès non uniformes, une distribution appropriée des données est nécessaire a�n d'éviterles accès distants à la mémoire non locale. Les approches de la distribution des donnéessont :

Round Robin

En distribuant les données à tour de rôle entre les mémoires des n÷uds. Elle estpeu e�cace et peut contribuer à ampli�er l'e�et NUMA en plaçant les données desthreads sur des n÷uds distants (aucune information n'est exploitée pour respecter l'a�nitéthreads/données)

Politique A�nity-on-First-Touch (AoFT)

La plupart des plateformes NUMA implémentent cette première règle. Si un threaddemande un fragment de mémoire, le mappeur(qui exécute la politique de placement desdonnées) s'assure que le fragment de mémoire est alloué à partir du segment de mémoirele plus proche à ce thread. La page mémoire contenant cette donnée est mappée dansle domaine local du processeur qui l'écrit en premier (c.-à-d. exécutant le thread qui aaccédé à cette donnée). [Asc+11] Solaris, Linux et Windows utilisent la stratégie dite decette politique par défaut. Cela signi�e qu'une page est placée dans la mémoire à côtédu processeur à partir duquel le premier accès à la page se produit. Cette stratégie peutêtre exploitée dans une application en initialisant les données en parallèle dans le mêmeschéma que celui auquel nous accédons pendant le calcul.

Politique A�nity-on-Next-Touch (AoNT)

L'a�nité next-touch est une autre approche pour réduire l'e�et NUMA et maximi-ser l'a�nité thread/données. Lorsque l'ordonnanceur de système d'exploitation détectequ'un processus accède à un bloc de mémoire qui ne se trouve pas dans le même n÷ud,Il marque ce morceau de mémoire prêt à être déplacé. Il essayera alors de trouver unmoment approprié pour déplacer le morceau de mémoire vers le segment de mémoire

22

approprié, qui est le plus proche du processus en cours. Selon Lankes et al. [Pan11] lesystème d'exploitation Sun / Oracle Solaris utilise la politique de distribution a�nity-on-next-touch, alors que Linux n'a toujours pas cette fonctionnalité.

Solaris : Solaris propose l'appel système madvise via le MPO (optimisation duplacement de la mémoire) installation, en prenant une plage d'adresses et un indicateurde modèle d'accès en tant qu'arguments. L'indicateur MADV ACCESS LWP indique aunoyau que le prochain thread touchera la plage d'adresses spéci�ée y accédera le plusfortement et pour déplacer les pages vers le noyau du thread accédant ou NUMA n÷ud,respectivement.

Linux : Linux a un appel système supplémentaire sys-move-pages qui a été rendudisponible pour o�rir des facilités de migration de page. En utilisant cette fonction, vouspouvez déplacer manuellement les pages d'un processeur à un autre. Mais l'application esttoujours nécessaire pour savoir quel jeu de pages doit être déplacé vers quel processeur.En plus de cet appel système, l'outil numactl [Lin] peut être utilisé pour autoriserl'allocation de mémoire uniquement à partir d'un ensemble spéci�é de n÷uds NUMA, oupour dé�nir une politique d'entrelacement de mémoire. La mémoire sera ensuite allouéeà l'aide d'une stratégie round-robin, qui peut améliorer les performances de l'applicationavec des modèles d'accès mémoire aléatoires. [Dre15].

Löf et Holmgren [HEN000] ont évalué une implémentation AFFINITY-ON-NEXT-TOUCH dans le mode utilisateur de sur un domaine isolé de 8 n÷uds d'un Système SunFire 15000. En utilisant AFFINITY-ON-NEXT-TOUCH, la performance est amélioréejusqu'à 166%, ce qui montre ce placement de données peut avoir un impact énorme surles performances des applications.

Goglin et Furmento [GF09a] ont implémenté AFFINITY-ON-NEXT-TOUCH pour lenoyau Linux et ont comparé les performances à une implémentation de l'espace utilisateur.L'implémentation basée sur le noyau est environ 30% plus rapide sur un système AMDOpteron 8347HE à quatre n÷uds et a�che un surdébit signi�cativement moins importantque l'implémentation dans l'espace utilisateur pour les petites régions de mémoire. Cepen-dant, les auteurs concluent qu'une implémentation dans l'espace utilisateur fonctionnemieux dans les cas où des zones mémoire plus importantes utilisées par l'applicationdoivent être migrées. L'implémentation mode noyau migre ces zones page par page, tandisqu'une implémentation mode utilisateur peut migrer chacune de ces zones en une seuleopération avec une surcharge plus faible.

2.5.3 Attâchement d'un Thread (Thread Binding)

le système d'exploitation peut décider de déplacer un thread de son emplacementinitial(migration). Cela peut entraîner une pénalité de performance, car les donnéesdu cache ainsi que la localité mémoire sont perdues. L'opération de la migration estcoûteuse. Pour éviter cette migration, il est possible de lier un thread à un c÷urdonné ou à un sous-ensemble donné des c÷urs d'un système. Solaris propose l'appelsystème processor-bind() pour lier un thread ou un ensemble de threads à un c÷urspéci�é. La fonction sched-seta�nity() de l'appel système Linux et l'appel de lafonction SetThreadA�nityMask() sur Windows s'attendent à ce qu'un masque debits représentant les c÷urs autorisés à l'exécution d'un thread spéci�que. Une autreapproche pour appliquer la liaison de thread est via des commandes spéci�ques au système

23

d'exploitation, par exemple. en utilisant la commande taskset ou les outils numactl sousLinux ou en appelant un programme avec start /a�nity surWindows. En utilisant cesoutils, un processus peut être restreint à un sous-ensemble donné de c÷urs de processeurset tout thread créé par ce processus obéira à ces restrictions. La table 2.6 montre les

Operating System AIX7.2 FreeBSD11 HP/UX Linux Arch4.1 Solaris Win10

Pin Thread + + + + + +

Logical CPU/Node + + + + + +

Mode distance - - - + - -

Table 2.6: Fonctionnalités NUMA implémentées dans les systèmes d'exploitationcourants

fonctionnalités NUMA implémentées dans les systèmes d'exploitation courants.

24

2.6 Conclusion

Comme il n'était pas possible de continuer la course des fréquences pour les processeursmonocoeurs d'une part et les multiprocesseurs basés sur ces processeurs n'étaient pasassez puissants et soufrent de plusieurs limitations, alors multic÷urs étaient une nouvelledirection pour continuer à exploiter les puissances des ordinateurs. Dans ce premierchapitre nous avons exposé les motivations de la révolution des multic÷urs au débutdes années deux milles. En suite, nous avons présenté leurs caractéristiques et l'impactsur l'industrie logicielle (en adaptant les systèmes d'exploitation et les applications).Cette mutation a accéléré l'adoption des applications massivement parallèles par un grandnombre d'usager (développeur, scienti�que,..). Les systèmes multiprocesseurs ont gagnéde puissance en utilisant cette technologie, mais ils étaient pénalisés par un nombre defacteurs qui étaient intrinsèquement liés à leurs méthodes de conception classiques quiconsistent à assembler les processeurs autours d'une mémoire partagée en utilisant un buscommun pour assurer l'équité de l'utilisation des ressources entre les processeurs (créantune symétrie et uniformité d'accès à la mémoire SMP/UMA). Cette utilisation intensea rapidement montré que nous ne pouvons pas continuer à concevoir les architecturesparallèles avec un esprit classique (MC-SMP-UMA) vu qu'elle a exhibé des limites endonnant un niveau de performance loin de l'espéré. Un système de mémoire hiérarchiquecompliqué couplé à un système de communication utilisant un support partagé ont étaientles principaux facteurs responsables de la dégradation des performances (l'accès au buspartagé créant la contention de communication et limitant le passage à l'échelle, unemémoire assez lente par rapport le processeur). Le remplacement des bus par des réseauxde communication avec des mécanismes de routage d'une part et la distribution de lamémoire centrale entre les processeurs ont donné naissance à cette nouvelle conceptiondes plateformes parallèles NUMA qui ne sont ni symétrique ni uniforme mais o�rent plusd'avantages à ces applications massivement parallèles (passage à l'échelle).

Dans la partie consacrée à NUMA, nous avons décrit cette architecture en donnantces principaux composants et comment elle contribue à surmonter le problème de passageà l'échelle des UMA. Par la suite nous avons parlé des spéci�cités/contraintes NUMAqui impactent grandement les politiques classiques d'ordonnancement des applicationsparallèles qui ne sont plus adaptées à ce contexte vu qu'elles ne sont pas concernéespar la localité et le placement des données sur une mémoire distribuées et un espaced'adressage partagé. Alors nous avons présenté les modi�cations qui a été faite au systèmed'exploitation pour être adapté à NUMA (NUMA aware), en implémentant les politiquesde placements des données standardisées ainsi que l'a�nité des threads en les attachantsà une unité d'exécution ou à un groupe d'unités.

Dans le chapitre suivant, nous allons parler des applications parallèles en générale etles applications parallèles décrites par un graphe de tâches en particulier.

25

Chapitre 3

Graphes de tâches

Dans ce chapitre, nous introduisons les concepts concernant la description des applica-tions parallèles à base de tâches en particulier les graphes de tâches, le modèle DAG et lesmodèles d'ordonnancement. Son objectif est de présenter les particularités structurellesde cette classe d'applications ainsi que son aspect fonctionnel lors de son ordonnancementet son exécution sur une plateforme multiprocesseurs.

Dans la section 3.1, nous décrivons tout d'abord les applications à base de tâches ainsique le graphe de tâches comme outils pour cette description. Ensuite dans la section 3.2,nous considérons le modèle DAG et nous présentons les concepts et la terminologie quiont relation avec ce type de graphe. L'aspect dynamique résultant de son exécution sur uneplateforme parallèle sera décrit en détail dans cette section. Les modèles d'ordonnancementainsi que les algorithmes de résolution sont présentés dans la section 3.3. En�n la section3.4 conclue ce chapitre.

3.1 Application parallèle décrite par DAG

La parallélisation e�cace d'une application nécessite une connaissance approfondiede la structure du programme. Il existe plusieurs méthodes pour déclarer la structureparallèle du programme à partir de sa version séquentielle en spéci�ant les blocs (sections)séquentiels et leurs relations, souvent faite manuellement par le programmeur, Ces métho-des sont appelées les modèles de la programmation parallèle. Comme exemples deces modèles, on peut citer Fork-Join pattern [ABB00], les MPI (passage de messages)[GLS99], map-reduce pattern [DG04]. Ces modèles di�èrent dans leur API, dans leurgranularité et leur fonctionnalité, ils partagent tous un objectif commun : partitionnerle programme séquentiel et exécuter les blocs séquentiels résultants dans un ordre quipréserve leurs dépendances mutuelles sur la plateforme parallèle cible sur laquelle onexécute l'application (appelé environnement d'exécution). La deuxième partie de ceprocessus (trouver cet ordre) s'appelle l'ordonnancement. Les blocs séquentiels représen-tent des parties du code séquentiel du programme sont appelés les tâches. L'environnementd'exécution matériel et logiciel où un algorithme ou l'application parallèle s'exécutent estappelé le modèle de système.

26

Figure 3.1: Exemple d'un code OpenMP parallèle et son DAG équivalent

3.1.1 Graphe de tâches

Les dépendances entre les tâches représentent la relation fonctionnelle causale ouun partage de ressources ou de données (qui nécessitent d'être placées et transferées)entre les tâches concernées. Les données utilisées par les tâches précédentes après leursexécutions doivent être mises à jour et préparées pour les tâches suivantes. Ces relationsde dépendance entre les tâches peuvent être modélisées en tant que graphe, et donc toutesles dépendances représentent une causalité de précédence temporelle ce qui empêchel'existence de tout cycle dans ce graphe (retour vers des tâches déjà exécutées) Ainsi, cemodèle s'appelle Graphe acyclique dirigé (DAG). La �gure 3.1 montre un exempled'un code OpenMP parallèle et son DAG équivalent. Le problème de l'ordonnancementdes programmes parallèles décrits par un DAG consiste à trouver l'ordre d'exécution(ressources temporelles) des tâches constituantes le programmes et sa projection sur laplateforme parallèle (ressources spatiales) de façon consistante qui respecte le principede la causalité. Ullmann et al ont montré que le problème de l'ordonnancementd'un DAG sur une machine multiprocesseur est un problème NP-complet soussa forme générale [Ull75]. Les techniques d'ordonnancement les plus populaires ne tententpas de trouver nécessairement un ordre optimal. Au lieu de cela, ils tentent d'en trouverun qui respecte leurs dépendances mutuelles et est en corrélation avec une métriqued'importance spéci�ée qui favorise les tâches les plus importantes et les plus critiquespour l'exécution globale de l'application [KA99]. La tâche de l'ordonnanceur ne dépendpas seulement de l'application parallèle à ordonnancer mais aussi de l'environnementde l'exécution. Les techniques d'ordonnancement (algorithmes, politiques, stratégies) secaractérisent par la quantité d'informations et les détails à-propos du DAG exploitées pourréaliser son objectif. Certains algorithmes utilisent peu d'informations sur la structure duprogramme dans ce processus (Certes une connaissance plus complète de la structuredu programme, sa prise de décision peut devenir plus raisonnable et plus e�cace, Maisen réalité beaucoup de ces informations ne sont pas disponibles lors de la conception

27

(désigne-time) mais au moment d'exécution du programme (runtime)), Au lieu de cela, ilsessaient d'utiliser des modèles qui donnent à un ordonnanceur une connaissance restreintede la structure du programme lui permettant d'améliorer les performances dans unenvironnement d'exécution donné ce qui les rend plus rapides (atteindre une meilleureperformance en ne connaissant qu'une partie de la structure du programme) [HL14].

Les propriétés de l'environnement où l'ordonnanceur agit ont une in�uence majeuresur la structure de l'algorithme d'ordonnancement. Selon que les processeurs soient ounon homogènes, quelle est la topologie de la plateforme, les informations sur le programme,etc., l'algorithme peut prendre ses décisions en considérant des informations très di�érentes.L'aspect principal est de savoir comment les propriétés de l'ordonnancement résultantdépendent de l'exhaustivité des informations disponibles pour l'algorithme. Le modèle desystème se compose de trois composants :- modèle plateforme- modèle interconnexion- modèle ordonnancement

- Le modèle plateforme : décrit les propriétés des plateformes (processeurs, n÷udde calcul, ..), qui exécutent un programme parallèle et l'ordonnanceur lui-même. Lesprocesseurs d'une plateforme peuvent être homogènes ou hétérogènes.

- Le modèle interconnexion : décrit les propriétés des liens de communication quiconnectent les processeurs et leur topologie. Les liens de communication peuvent êtreune ressource partagée qui nécessitent une concurrence pour l'utiliser alors il faut gérer lecon�it de ce partage dans ce contexte (avec con�it with-contention) ou être sans contention(contention-free). (Contestation-free, une fois qu'une opération de communication démarre,elle ne subit aucune perturbation par rapport à d'autres opérations de communication,Cela signi�e qu'une opération de communication occupe exclusivement le canal entre lesdeux processeurs et ne peut pas être interrompue).

- Le modèle ordonnancement : décrit les informations disponibles pour un ordonnan-ceur et la manière dont son algorithme peut fonctionner avec ces informations disponibles.

Les algorithmes manipulant les graphes de tâche et générant les ordonnancementcorrespondants à une application décrite par ce modèle peuvent être divisés en deuxclasses suivantes :

1- Algorithmes just-in-time (JIT-algorithmes)

Ces algorithmes ont très peu d'informations sur le programme pour lequel ils tententde trouver un ordre d'exécution. Leurs décisions sont prises en runtime. Et la minimisationdes coûts d'ordonnancement est souvent un objectif important pour eux.

2- Algorithmes complets

Ces algorithmes connaissent la structure complexe du programme. Ils font chaquedécision d'ordonnancement en tenant compte des répercussions possibles de l'avenir. Toutcela permet de réaliser toutes les actions nécessaires avant l'exécution de l'application, entemps de compilation (design-time).

28

3.2 Modèle DAG

L'exécution de programme parallèle se compose des tâches (code séquentiel), quiont des dépendances de données entre elles. Une telle structure peut être modéliséeselon un graphe dirigé acyclique (DAG), où les n÷uds représentent des tâches (partiesséquentielles) et des arcs (arêtes) représentent des dépendances de données. Divers paramè-tres du programme peuvent être modélisés soit comme attributs des n÷uds, des arcs oudu graphe lui-même.

3.2.1 Concepts et dé�nitions

A�n de montrer le processus de la description d'un code parallèle par un DAG, nousallons dé�nir les concepts de base pour cette transformation et les notations utilisées par lasuite. Nous commençons par la présentation d'un exemple de code séquentiel d'algorithmepour un problème classique du calcule numérique 'résolution d'un système d'équationsdont la matrice est triangulaire' qui va servir de modèle.

Soit le problème de la résolution d'un système d'équation suivant : A · x = b

� A ∈MTIn(R) Matrice triangulaire inferieure donnée� b ∈ Rn vecteur constant

L'algorithme AL001 suivant calcule la solution de ce système : Cet algorithme est

Algorithme 1 : Résolution systeme d'équations

for i = 1 to n doTask Ti,i : xi ← bi

ai,i

for j = i+ 1 to n doTask Ti,j : bj ← bj − ai,jxi

séquentiel, la totalité du calcule est faite par les blocs de code (Tâche Tij) de l'algorithmeou l'exécution de ces blocs suit un ordre total dé�nit par la structure séquentielle ducode.

Dé�nition : Calculer Avant <seq.

On dé�nit la relation d'ordre total sur AL001 calculer avant <seq :

T <seq T′ =⇒ T est calculée / exécutée avant T ′

On a l'ordre suivant pour les tâches de AL001 : T1,1 <seq T1,2 <seq T1,3 <seq · · · <seq

T1,n <seq T2,2 <seq · · · <seq Tn,n

La logique de l'exécution des Ti,j est la suivante :- T1,1 est la première tâche et calcule x1,- T1,2 et T1,3 utilisent x1, elle doit attendre la �n de T1,1 (calcul de x1).- T1,2 met à jour b2 et T1;,3 met à jour b3. T1,2 et T1,3 sont indépendantes et peuvent êtreexécutées dans n'importe quel ordre.

29

On caractérise la Tâche T par :- In(T ) : l'ensemble des variables lues par la tâche T .- Out(T ) : l'ensemble des variables écrites par la tâche T .

Dé�nition : Variables partagées.

On dé�nit l'ensemble SV des variables partagées entre T et T ′ l'ensemble desvariables qui peuvent être modi�ées par les deux tâches ou une des tâches et lues parl'autre au cours de l'exécution.

SV (T, T ′) = ((Out(T ) ∩Out(T ′)) ∪ (Out(T ) ∩ In(T ′)) ∪ (Out(T ′) ∩ In(T ))

Dé�nition : Bernstein conditions.

T et T ′ sont dépendantes, si et seulement si elles partagent certaines variables àmodi�er T⊥T ′.

T⊥T ′ ⇐⇒ SV (T, T ′) 6= ∅

Dans l'exemple donné, on a Out(T1,1) ∩ In(T1,2) = {x1} alors T1,1⊥T1,2 et Out(T1,3) ∩Out(T2,3) = {b3} alors T1,3⊥T2,3.

Si T⊥T ′ alors elles doivent être ordonnées selon l'ordre de l'exécution séquentielle.

Dé�nition : Relation de Précédence ≺.

T précède T ′ si et seulement que T et T ′ partagent certaines variables et T doit êtreexécuter avant T ′ T ≺ T ′.

T ≺ T ′ ⇐⇒ (T⊥T ′)&T ≤seq T ′

≺ : est un ordre partial (consistant avec <seq) : <= (<seq ∩⊥)+

Dans l'exemple, on a : T2,4 et T4,4 : T2,4 modi�e b4 et T4,4 lit b4 =⇒ T2,4⊥T4,4;T2,3 <T4,4

T4,4 et T4,5 : T4,4 modi�e x4 et T4,( modi�e x4 =⇒ T4,4⊥T4,5;T4,4 < T4,5

T2,4 et T4,5 : T2,4 et T4,5 sont indépendantes

Représentation par un graphe dirigé G = (V,E)V = ensemble de tâches.e = (T, T ′) ∈ E ⇐⇒ T < T ′ relation de précédence T est prédécesseur de T ′ La �gure3.2 montre le DAG correspondant au programme donné en exemple.

Cette représentation donne un graphe dirigé et sans cycle appelé graphe de précéden-ce ou de tâches (DAG direct acyclic graph) dont les n÷uds sont des tâches (calcul) etles arcs représentent les dépendances entre les tâches (communication). Souvent cettedescription peut être complétée par les informations d'exécution (la durée de chaquetâche w, le volume des données échangées entre deux tâches communicantes c si ellessont disponibles) dans certains cas DAG(T, <, w, c). Le coût de ce calcul et de cette

30

Figure 3.2: DAG de l'application résolution d'un système d'équations [Dre15]

communication ne dépend pas seulement de la durée des tâches et du volume échangé entreles tâches communicantes mais aussi des caractéristiques la plateforme sur laquelle elless'exécutent. C'est pourquoi il est important de caractériser et modéliser cette plateformepour quanti�er correctement les performances des politiques gérant l'exécution des applica-tions parallèles sur ces plateformes. La modélisation la plus simple est de représenterl'architecture cible par l'ensemble de ressources d'exécution (processeurs, c÷urs, n÷uds,ou autre) P = {Pi}i∈I en donnant leurs caractéristiques.

Par la suite on va utiliser les fonctions suivantes :- δ/(vi) : fonction prédécesseur renvoie une liste des tâches qui précèdent la tâche vi(les tâches mères (n÷uds parents prédécesseurs)).- δ.(vi) : fonction successeur renvoie une liste des tâches dont l'exécution dépend de latâche (du n÷ud) vi (tâches �lles (successeurs)).- w(vi) : coût de calcul du travail vi.- c(eij) : coût de communication eij le volume des données échangées entre deux tâches.

Si les tâches vi et vj sont programmées pour le même processeur, alors c(eij) = 0.Sans perte de généralité, supposons qu'un DAG ait un seul n÷ud d'entrée et qu'un seuln÷ud de sortie. Tous les n÷uds, à l'exception des n÷uds d'entrée et de sortie, (initiauxet terminaux) ont des poids positifs w(vi) > 0.

Le niveau statique sl d'un n÷ud vi est la longueur du chemin le plus long du n÷udvi au n÷ud de sortie, y compris le poids de vi. S-level ne considère pas les coûts decommunication, donc il ne dépend pas d'un ordonnancement particulier.

sl(vi) = if(δ.(vi) = ∅, 0, maxvj∈δ.(vi)

{sl(vj)}+ w(vi)

Le niveau statique supérieur (top) stl d'un n÷ud vi est la longueur du chemin leplus long du n÷ud d'entrée vers un n÷ud vi, à l'exclusion du poids de vi. Le niveaustatique supérieur inclut tous les coûts de communication et calculé avant l'établissementde l'ordonnancement. Ainsi, le calcul à un niveau ne considère pas la possibilité d'annuler

31

les coûts de communication, lorsque des tâches dépendantes s'exécutent sur le mêmeprocesseur.

stl(vi) = if(δ/(vi) = ∅, 0, maxvj∈δ/(vi)

{stl(vj) + w(eji) + w(vj)}

Le niveau statique inférieur (bottom) sbl d'un n÷ud vi est la longueur du cheminle plus long du n÷ud vi au n÷ud de sortie, y compris le poids de vi. Le calcul du niveaub statique inclut les coûts de communication de la même manière qu'avec le niveau t.

sbl(vi) = if(δ.(vi) = ∅, 0, maxvj∈δ.(vi)

{sbl(vj) + w(eij)}+ w(vi)

Le travail total (W) est la poids totale de toutes les tâches dans le DAG. Si toutes lestâches sont programmées sur le même processeur, la durée de l'ordonnancement résultantest égale au travail total. La formule pour calculer le travail total est la suivante :

W =∑vi∈V

w(vi)

Le chemin critique (CP) désigne la longueur du chemin le plus long du n÷ud d'entréeau n÷ud de sortie. Un DAG peut avoir plusieurs chemins critiques de même longueur. Lalongueur de chemin critique équivaut au niveau s d'un n÷ud d'entrée. Le chemin critiqueest un paramètre important d'un DAG, car il montre la limite inférieure de toute longueurde programme possible : Même avec une quantité illimitée d'exécution de processeurs nepeut pas prendre moins que l'exécution du chemin critique requiert. Le chemin critiquepeut également inclure les coûts de communication existant entre les n÷uds dans le chemincritique.

Les paramètres mentionnés ci-dessus ne dépendent pas d'un ordonnancement particulierqui peut a�ecter des tâches aux processeurs de manière di�érente. Ces paramèt-res sontappelés statiques.

3.2.2 Exécution d'un DAG

Soit le DAG G(V,E,w, c) qui décrit la structure d'une application parallèle que nousallons l'exécuter sur la plateforme de m processeurs P = {Pi}i∈[1..m]

Dé�nition : Principe de causalité.

L'ordonnancement d'un DAG G(V,E,w, c) est la fonction θ qui associe à chaquetâche sa date début :

θ : V → Rvi 7→ si = θ(vi).

Véri�ant la relation (principe de causalité) :

∀(vi, vj) ∈ E, θ(vi) + w(vi) < θ(vj)

Apres avoir déterminé un ordre chronologique de l'exécution des tâches d'un DAG, nous

32

allons dé�nir une fonction qui assure la projection des tâches sur les processeurs de laplateforme cible.

Dé�nition : Principe de non chevauchement

L'allocation d'un processeur à une tâche d'un DAG est la fonction π qui associe àchaque tâche un processeur sur lequel elle va être exécuté (renvoie un processeuralloué à la tâche vi) :

π : V → Pvi 7→ pj = π(vi).

Véri�ant la relation (principe de non chevauchement) :

∀(vi, vj) ∈ V 2, π(vi) = π(vj) ≡ (θ(vi) + w(vi) < θ(vj))or(θ(vj) + w(vj) < θ(vi))

Un algorithme d'ordonnancement détermine le début d'exécution et le processeuralloué d'une tâche.

En donnant un ordonnancement particulier θk, on peut déterminer les paramètresdynamiques suivants :

Le temps de début d'une tâche dans un ordonnancement particulier est désigné parST (vi) = si.

Le temps de la �n d'une tâche dans un ordonnancement particulier est désignéecomme ET (vi) = ei. Entre le début et la �n d'une tâche, on la relation suivante :

ET (vi) = ST (vi) + w(vi)

Le temps total d'exécution (completion time, Makespan) indique le temps de �nde la tâche de sortie. Aussi appelée durée de l'ordonnancement. note Cmax(Ok)

Le niveau dynamique supérieur top d'une tâche vi sur un processeur Pj est lalongueur du chemin le plus long de la tâche d'entrée vers la tâche vi, à l'exclusion du poidsde vi. Ce niveau indique le temps de début le plus tôt possible d'une tâche vi, lorsque lestâches antécédentes de vi est déjà ordonnancées.

tl(vi) = if(δ/(vi) = ∅, 0, maxvj∈δ/(vi)

{FT (vj) + w(eji)}

Le niveau t dynamique ne considère pas la disponibilité d'un processeur prêt pour exécutiondu n÷ud vi, donc le temps réel le plus tôt possible peut être plus grand.

Le niveau dynamique inférieur bottom d'une tâche vi sur un processeur pj est lalongueur du chemin le plus long de vi à la sortie, y compris le poids de vi. Ce niveau estcalculé comme suit.

bl(vi) = if(δ.(vi) = ∅, 0, maxvj∈δ.(vi)

{bl(vj) + w(eij)}+ w(vi)

Le temps prêt RT (vi, pj) est le temps le plus tôt possible lorsque le processeur pj peutexécuter la tâche vi.

Le temps début au plus tôt EST (vi, pj) fait référence au temps d'exécution le plus

33

tôt possible de la tâche vi sur un processeur pj.

EST (vi, pj) = max{tl(vi), R(vi, pj)}

Le premier temps de �nition EFT (vi; pj) se rapporte au temps de �nition le plus tôtpossible d'un n÷ud vi sur un processeur pj. Entre EST et EFT suivant relation tient.

EFT (vi, pj) = EST (vi, pj) + w(vi)

Le temps de la �n réelle (AFT) est le moment où la tâche achève son travail dans unordonnancement particulier.

Le Temps début au plus tard (ALAP) est une métrique qui indique combien ledébut d'une tâche peut être retardé sans augmenter le makespan. L'ALAP des tâches duchemin critique est égal à leur niveau t.

En donnant un DAG et un environnement d'exécution ENV et O soit l'ensemble detous les ordonnancements possible de DAG sur ENV .

Un problème d'ordonnancement Π(O|DAG,ENV ) consiste à déterminer l'ordon-nancement optimal O∗ de l'exécution de DAG sur ENV dont Cmax est le minimum.

O∗ = arg minOi∈O{Cmax(Oi())}

Comme nous avons cité dans la section 3.1.1, que Ullmann et al ont montré que leproblème de l'ordonnancement d'un DAG sur une machine multiprocesseur estun problème NP-complet sous sa forme générale [Ull75]. Trouver O∗ généralement n'estassez facile. C'est pourquoi on cherche une bonne solution qui proche à la solution optimaleavec un coût acceptable. Le listing suivant donne le contenu du �cher random000.stg selonle format StandardTaskGraph (STG) d'un DAG générique de 50 tâches et les �guressuivantes 3.3 montre son ordonnancement sur les plateformes UMA de 4 c÷urs et 8c÷urs respectivement.

#StandardTaskGraphSetProject

#RandomTaskGraph50//tmp/50/rand0000.stg

50

0 0 0

1 9 1 0

2 4 1 0

3 3 1 0

4 6 1 0

5 4 1 1

6 3 1 5

7 3 1 0

8 8 1 6

9 9 1 0

10 2 3 2 6 8

11 1 1 9

.............

48 2 5 23 28 29 40 41

49 9 4 30 39 46 47

34

Figure 3.3: Ordonnancement du DAG rand0000.stg sur des plateformes UMAs

50 10 3 20 32 46

51 0 11 3 17 31 34 38 42 43 45 48 49 50

35

3.3 Modèle d'ordonnancement

Le modèle du système détermine la variété des algorithmes qui peuvent être utilisés.L'applicabilité du modèle est déterminée par les propriétés requises de l'environne-mentd'exécution. Des facteurs tels que les garanties de performance, la robustesse, la �abilité etd'autres déterminent un modèle de système optimal et un algorithme d'ordonnancementoptimal. Cette section présente des principes généraux d'ordonnancem-ent et des paradig-mes dans les modèles de système.

3.3.1 Modèle Just-in-Time JIT

Le modèle Just-in-Time (JIT) ne prend pas en compte la structure du programme. Lesordonnanceur de ce modèle ne peuvent se permettre aucun ordre statique. On supposequ'à chaque moment, un ordonnanceur connaît des informations très restreintes, maiscette information est à jour. Pour cette raison, les décisions de l'ordonnanceur doiventêtre prises immédiatement avant leur mise en ÷uvre,

Dans le modèle just-in-time, les algorithmes d'ordonnancement des tâches DAG apparai-ssent pour l'ordonnanceur uniquement lorsqu'elles sont prêtes, i. e. toutes leurs dépendancessont satisfaites. Une tâche qui est en cours d'exécution sur un processeur est dite active.Si l'exécution d'une tâche dépend d'une autre tâche, alors la premiere est appelée unetâche-�lle de la deuxième la tâche mère.

Une queue globale et unique qui représente la �le d'attente de tâches prêtes (dontl'état est prêt) est utilisée dans ce modèle. La tâche prête qui est en entête de cette queueest a�ectée au processeur qui devient libre.

Dans ce contexte, la contention pour le bus système peut diminuer drastiquement lalatence et le débit du système [ALL89] d'une part. D'autre part, L'in�uence de la localitédes données sur le nombre de pertes de mémoire cache CPU [HL14] et les défauts de page[Blu+96] participent à aggraver la situation. Cela augmente le tra�c et la contenance dubus mémoire partagé et entraîne des pénalités de performance signi�catives.

Si les tâches �lles restent sur le même processeur que les tâches-mères, les pénalités deperformance se développent plus lentement avec un nombre accru de processeurs [SL93].

3.3.2 Horizon d'exécution pour les multicoeurs [Pla15]

L'ordonnancement est e�ectué en plani�ant les tâches sur les processeurs disponib-lesdans un ordre qui respecte les dépendances de données du DAG. Puisque initialement justeune information partielle sur l'application est disponible au support d'exécution, alors Laprise de décision se fait seulement au moment d'exécution de façon dynamique. Lorsqu'uneapplication démarre, l'ordonnanceur découvre un certain nombre de tâches, à une certaineprofondeur en fonction des tâches déjà traitées (soit complète, en exécution ou prête) cequi constitue l'horizon d'exécution vu par l'ordonnanceur à ce moment. Certaines tâchessont prêtes à être exécutées juste après la �n de certaines tâches en exécution. Une foisqu'une tâche �nit, l'ordonnanceur découvre ses descendants à une certaine profondeur etmis à jour l'horizon courant. Dans cet aspect, le modèle d'horizon est similaire au modèleJIT. Mais contrairement à ce dernier, l'ordonnanceur dans le modèle de l'horizon découvre

36

plus d'informations après chaque étape d'exécution. Plus d'informations sur la structurede programme parallèle permettent à l'ordonnanceur qui permet de prendre une meilleuredécision d'ordonnancement à chaque étape de l'exécution.

Pour rendre cette information disponible, l'ordonnanceur peut utiliser les outils d'analy-se de code statique initialement pour extraction de certain aspect statique de l'application(sa structure, nombre des tâches,...) comme il peut utiliser les outils d'instru-mentationde l'exécution pour collecter les statistiques et les valeurs de certains paramètres aprèschaque événement d'exécution (la �n/début d'exécution d'une tâche, communication).

Les outils d'analyse de code statique devraient pouvoir reconnaître la structure del'application (les parties séquentielles du programme et les dépendances entre eux). Leprogrammeur peut fournir certaines indications à ces outils en annotant le code sourceavec des directives dont l'interprétation par le compilateur permet de renseigner le supportexécutif de certaines détails. En outre, l'outil d'analyse de code statique devrait pouvoirannoter l'image binaire du programme avec les informations sur ces parties séquentielles.Ces annotations devraient être reconnues par une partie dynamique d'un système parallèle,qui fournit un ordonnanceur avec une connaissance de l'horizon. L'ordon-nanceur devraitpouvoir récupérer ces informations et l'utiliser pour prendre des décisions d'ordonnancement.

3.3.3 Ordonnancement par liste

Cette section décrit les détails de mise en ÷uvre qui sont souvent communs à tousces modèles. Les algorithmes basés sur les heuristiques ne donnent pas une solutionoptimale, mais une solution proche de l'optimale. L'heuristique typique de l'algorithme del'ordonnancement est appelée list scheduling [KA99]. Le but des algorithmes de l'ordon-nancement de liste est de minimiser (ou maximiser) certains paramètres d'un programmerésultant : makespan, équité, e�cacité énergétique, il construit une liste de priorité detoutes les tâches dans le DAG en fonction de certaines métriques. Ensuite, l'ordonnanceure�ectue une a�ectation des tâches aux processeurs dans l'ordre des priorités des tâches.Lorsqu'une tâche est a�ectée à un processeur, elle est supprimée de la liste des priorités.L'a�ectation peut avoir lieu soit de manière statique (avant l'exécution de l'exécution duprogramme), soit dynamiquement (pendant que le programme est en cours d'exécution).Si l'a�ectation a lieu pendant l'exécution, il peut se produire la situation suivante. Suppo-sons qu'un processeur est disponible pour l'exécution et que certaines tâches de la listedes priorités sont prêtes, mais la tâche la plus prioritaire n'est pas prête, car certainesdépendan-ces ne sont pas encore satisfaites. Cela peut se produire si la tâche supérieure dela �le d'attente prioritaire dépend d'une tâche en cours d'exécution sur un processeur. Il ya deux solutions pour cette situation. Dans le premier, l'ordonnanceur attend que la tâchesupérieure soit prête. Dans l'autre, l'ordonnanceur prend les tâches les plus prioritairesparmi les tâches prêtes.

Statique

Les algorithmes de l'ordonnancement de listes statiques sont souvent combinés avecd'autres heuristiques de l'ordonnancement. L'algorithme de l'ordonnancement organised'abord les tâches dans la liste des tâches. Cette liste a des tâches classées selon unecertaine priorité. Le choix de la priorité dépend de l'algorithme et sa complexité de calcul

37

varie, mais il est important de choisir la priorité de façon à ce que les tâches de la listesoient typologiquement triées. Si cette condition est remplie et si la �le d'attente destâches qui doivent encore être ordonnancées contient au moins une tâche prête, la tâcheprête la plus prioritaire sera au sommet. Après la création d'une �le d'attente de prioritédes tâches, l'algorithme de l'ordonnancement se compose de deux étapes [KA99] :

1. Supprimer la tâche supérieure de la �le d'attente de l'ordonnancement ;

2. Allouer la tâche à un processeur qui permet de l'exécuter le plus tôt possible.

L'hypothèse initiale est que les tâches sont ordonnancées de manière à ce que chaquenouvelle tâche apparaisse à la �n de l'ordonnancement local d'un processeur. Il est simpleà implémenter, mais peut être amélioré par insertion d'autres heuristiques [Kru88].

Algorithme 2 : Ordonnancement par liste statiqueinput : DAG G(Tasks,Edges) ; TopologyGraph TG(Nodes,Processors,Links)output : A schedule of G on TG

TasksList← sortTasksByPriority(Tasks) ;for each task ∈ TasksList do

processor ← selectAvailableProcessor(task, Processors) ;schedule(task, processor);

Dynamique

Les algorithmes de l'ordonnancement de liste dynamique sont l'extension des algorith-mes de l'ordonnancement de listes statiques. Ils peuvent modi�er la �le d'attente prioritairedes travaux lors de sa construction. Cela se produit parce qu'après l'ajout d'une nouvelletâche, la métrique utilisée pour a�ecter les priorités doit être recalculée pour toutes lestâches qui sont déjà dans la �le d'attente prioritaire. Ainsi, un algorithme de l'ordonnance-ment de liste statique obtient une étape supplémentaire dans une construction de �led'attente prioritaire [KA99] :1. Déterminer les nouvelles priorités de toutes les tâches non ordonnancées2. Sélectionner la tâche la priorité la plus élevée pour l'ordonnancement3. Allouez la tâche au processeur qui autorise le plus tôt possible le début.

L'ordonnancement dynamique a le potentiel de générer un meilleur ordonnancementque celui statique, mais comme inconvénient, il nécessite de recalculer en continu despriorités pour la �le d'attente des tâches, augmentant ainsi la complexité temporelle del'algorithme.

3.3.4 Par clustering

Les heuristiques de clustering [Sin+08] supposent que le nombre de processeurs este�ectivement illimité. Ainsi, l'objectif de minimiser le makespan est réduit au problèmede l'optimisation des coûts de communication. Au début, Ces algorithmes attribuent àchaque tâche un processeur distinct. Dans le processus de recherche du meilleur ordonnan-cement un algorithme regroupe les clusters. La fusion des clusters signi�e l'a�ectation destâches de di�érents clusters au même processeur. Lorsque deux tâches, qui dépendent

38

directement l'une de l'autre, sont mises sur le même cluster, les coûts de communicationentre ces travaux deviennent nuls. Lorsqu'il y a un nombre de processeurs physiquessupérieur au nombre de clusters, l'attribution de processeurs au cluster ne constitue pasun problème. Mais lorsque le nombre de clusters est supérieur au nombre de processeurs,une étape supplémentaire appelée mappage est nécessaire pour accomplir le processus del'ordonnancement. Au cours de cette étape, un ordonnanceur doit mapper les clusters enprocesseurs physiques [KA99].

3.3.5 Duplication des tâches

L'heuristique de duplication a été présentée par Kruatrachue [Kru88]. La duplicationde tâches tente à réduire les frais de communication en clonant la tâche qui introduitune grande partie des coûts de communication. Ces tâches sont réparties entre plusieursprocesseurs, de sorte que plus de communication se produit localement. Ainsi, l'heuristiquede duplication de tâches tire parti du parallélisme et réduit les délais de communicationen même temps.

3.3.6 Basés les Metaheuristiques

Les algorithmes déterministes ont un déséquilibre d'e�cacité pour di�érentes con�gura-tions de work�ow d'application parallèle. Avec très peu de chance, la dégradation desperformances peut être signi�cative.

Les algorithmes basés sur les metaheuristiques tentent d'améliorer le processus de larecherche d'une solution au problème d'ordonnancement en introduisant la randomisationen écartant les solutions les moins e�caces. Di�érents types de ces algorithmes incluent :- Algorithmes génétiques [Gra99]- Recherche Tabu- Recuit simulé- Colonie de fourmis

L'idée de ces algorithmes réside dans la génération de nombreuses solutions possibles etla sélection ultérieure des meilleures. Le processus de génération et de sélection est itératif.Typiquement, Cet algorithme commence par générer une solution aléatoire. Le nombred'itérations de l'algorithme peut être volatile : l'algorithme s'exécute aussi longtemps qu'ilest possible d'apporter une amélioration sensible. Ou il peut être �xé à un certain nombreconstant. Comme pour les algorithmes déterministes, les algorithmes stochastiques dépen-dent fortement de la qualité des métriques utilisées pour comparer les solutions intermédiai-res et le processus de génération pour la prochaine génération. Parfois, un grand nombred'itérations est nécessaire pour obtenir une solution de qualité acceptable.

39

3.4 Conclusion

Dans ce chapitre, nous avons parlé du deuxième aspect concernant cette thèse à savoirl'ordonnancement d'une application parallèle à base de tâches décrite par un graphe detâches. Nous avons décrit tout d'abord les applications à base de tâches ainsi que legraphe de tâches comme outils pour cette description. Apres avoir partitionné la versionséquentielle d'une application, nous obtenons un ensemble de tâche dont la granularité(la taille des tâches) dépend du niveau du processus de la parallélisation. L'étape suivanteconsiste à déterminer les dépendances entre les tâches qui une relation de causalité dé�nitla précédence. Le graphe résultant de ce processus est un DAG qui représente la structurede l'application avec les dépendances fonctionnelles et le partage de données/ressources.Les propriétés du DAG caractérisent la façon d'exécution sur une plateforme parallèlechoisie en déterminant l'ordre temporel et spatial de cette dynamique.

Pour cette �n, des modèles d'ordonnancement sont utilisés pour trouver l'ordre quioptimise cette exécution. Des algorithmes et des heuristiques spéci�ques à chaque contextesont conçus pour aider et faciliter la prise de décision.

Dans le chapitre suivant, Nous allons présenter l'état de l'art des problèmes d'ordonnan-cement des tâches et placement des données sur NUMA.

40

Chapitre 4

Etat de l'art de l'ordonnancement et leplacement sur MC-NUMA

Dans ce chapitre, Nous allons présenter l'état de l'art des problèmes d'ordonnance-ment des tâches et placement des données dans le contexte de NUMA en exposant lesdi�érentes approches proposées durant cette décennie. Comme nous l'avons montré, laplateforme NUMA donne une solution au problème de la scalabilité de la plateforme UMAmais en contre partie elle introduit la pénalité NUMA due aux accès distants générés parle placement des données d'une tâche sur un n÷ud di�érent du n÷ud sur lequel elles'exécute. Ce facteur a un impact important sur le processus d'ordonnancement et ilcontribue à rendre le temps total d'exécution assez important pour un DAG par rapportune exécution sur une plateforme UMA. La �gure suivante 4.1 montre un ordonnancementdu mème DAG sur les plateformes UMA (un noeud de 8 coeurs N1C8) et NUMA (avec4 noueds de 2 coeurs chacun N4C2) respectivement. A�n de réaliser l'objectif principalde l'ordonnancement et placement des données dans le contexte NUMA, les approchesconçues ont été basé sur les idées qui exploitent certaines caractéristiques des architecturescibles [Dre15], dont les principales caractéristiques sont les suivantes :- Les caractéristiques des applications ciblées par l'approche (parallélisation des bouclesou application régulière, irrégulière).- L'ensemble des heuristiques (ordonnancement uniquement, placement uniquement oules deux combinés).- Le support logiciel d'implémentation (Système d'exploitation, Système d'exécution,Compilateur, Bibliothèque, Application ou une combinaison).- Les informations utilisées et comment elles sont obtenues (indications de placement,a�nités de données obtenues par pro�lage, Annotation du code source, ..).- Le modèle de programmation cible (processus indépendants, fork-join [FBD12] , OpenMP[Boa08] [Boa01] [Boa13] ou Cilk [Cil00] [FLR98]).

La programmation parallèle des tâches est une approche de plus en plus populaire pourrépondre aux attentes en matière d'évolutivité, et de productivité pour les applicationsdestinées à fonctionner sur des systèmes à plusieurs c÷urs. Les performances de l'exécutiond'un tel type de programme dépendent fortement d'un système d'exécution optimisécapable d'exploiter e�cacement le matériel sous-jacent. L'optimisation pour la hiérarchiede la mémoire, (caches et l'accès à la mémoire non uniforme), est un facteur clé dansce contexte qui peut être réalisée grâce à un ordonnance-ment optimisé des tâches surles c÷urs et à un placement optimisé des données sur les contrôleurs de mémoire. Elle

41

Figure 4.1: Ordonnancement d'un DAG sur des plateformes UMA/NUMA

doit s'adapter à l'évolution rapide des architectures (nombre croissant des unités decalcul, réseaux d'interconnexion compliqué) et réagir aux changements dynamiques ducomportement de l'application au moment de l'exécution pour équilibrer la charge. Lesapproches peuvent être divisées en trois groupes [Dre15]1- Aides à la prise de décision dont les informations sur les données pertinentes doiventêtre fournies par le programmeur.2- Automatisant la prise de décision dont les informations fournies par le programmeur.3- Automatisant la prise de décision et le recueil des informations sur les données pertinentes.

Les récents modèles de programmation parallèle à base de tâche tel que Cilk [Cil00][FLR98], OPENMP [Boa08] [Boa01] [Boa13], STARTS [Pla+09] et OPEN-STREAM[AP11] o�rent de nouvelles opportunités au système d'exécution pour obtenir des informa-tions détaillées sur les données auxquelles accède une tâche ainsi que sur les dépendancesinter-tâches. Ces modèles permettent de spéci�er les dépendances inter-tâches en tant quedépendances de données et ainsi fournir au système d'exécution des informations précisessur les accès aux données par chaque tâche et le partage de données entre les tâches.

Dans la section 4.1, Nous présentons les grandes lignes des approches proposées endonnant les aspects qui caractérisent chaque classe. Ensuite la section 4.2 expose lapremière classe dont l'objectif principal est d'ordonnancer les tâches. La deuxième classequi focalise sur le placement est présentée dans la section 4.3. La section 4.4 donne lesapproches qui combinent les deux aspects. Comme l'équilibrage de charge est importantpour préserver les performances, la section 4.5 est consacrée à détailler les stratégiesutilisées pour cette �n. En�n la section 4.6 conclue le chapitre.

42

4.1 Caractéristiques des approches

L'étude des travaux connexes montre qu'il existe de nombreuses approches pour :1- Améliorer la localisation des données par rapport à NUMA.2- Réduire les con�its sur les contrôleurs de mémoire et sur les réseaux d'interconnexion.3- Améliorer l'exploitation des caches grâce à un ordonnancement et un placement desdonnées optimisées.

Le but de cette section est de donner une synthèse des approches avant de les exposeret de mettre en évidence les di�érences entre elles. Cette synthèse est divisée en troisparties.La première : fournit un aperçu des caractéristiques générales.La deuxième : se concentre sur les fonctionnalités liées au placement de données optimiséLa troisième : résume les caractéristiques des approches basée sur l'ordonnancement

4.1.1 Caractéristiques principales

Les caractéristiques générales des approches peuvent être résumées comme suit :- La partie de la hiérarchie de mémoire optimisée par l'approche, c'est-à-dire si ellevise à améliorer les accès à la mémoire principale ou aux caches.- La couche de mise en ÷uvre de l'approche (IMP) (par exemple, une bibliothèque(LB), le système d'exploitation (OS) ou le compilateur (CP)).- L'infrastructure prise en charge pour le parallélisme (par exemple, OpenMP, threadsPOSIX ou Cilk).- La technique (TCH) sur laquelle est basée l'approche(sur un ordonnancement optimisée(S), un placement de données optimisé (P) ou si elle combine les deux techniques (C)).

4.1.2 Caractéristiques du placement de données

Les approches qui prennent en charge le placement de données di�èrent en ce quiconcerne :- Source des données pertinentes SDP : comment elles déterminent quelles donnéessont pertinentes pour améliorer le placement de données, en particulier si cela est faitautomatiquement A ou si le programmeur P doit spéci�er des structures de donnéespertinentes.- Les types de structures de données TSD : quels types de structures de donnéessont supportés (par exemple, des tableaux ou toute région mémoire contiguë).- La granularité GRN pour le placement de données (des éléments de données uniques,des pages ou des blocs représentant de grandes régions de mémoire).- Le moment de décision ToP de placement est prise (par exemple, dynamiquementau moment de l'exécution, de manière statique au moment de la compilation ou pendantle pro�lage hors ligne).

43

4.1.3 Caractéristiques des mécanismes d'ordonnancement

Pour distinguer les approches de l'ordonnancement, nous avons identi�é les caracté-ristiques suivantes :- Le type TYP (par exemple, verrouillage de thread simple THD, ordonnancement deboucle LOOP).- La source des informations SID sur lesquelles reposent les décisions (par exemple,les unités de surveillance des performances SP, les informations sur la distribution desdonnées DD établies par l'approche elle-même ou le partage des données SD entre lesthreads).- Le type d'entités d'ordonnancement ENT traitées par l'approche (par exemple,les threads du système d'exploitation, les itérations de boucle, les threads ou les tâchesOpenMP).- Le moment de décision ToS (par exemple, dynamiquement pendant l'exécutionEXE, au début de l'exécution du programme BEX ou avant une boucle parallèle BLP).

4.2 Ordonnancement des tâches

Les approches suivantes reposent sur l'ordonnancement en tant que mécanisme princi-pal pour améliorer les performances des accès mémoire.

4.2.1 Principe de la réutilisation de l'ordonnancement

1- Auteur

Nikolopoulos et al. [Nik+01].

2- Idée

Cette approche concerne la parallélisation des boucles. Elle prend en charge l'ordonnan-cement NUMA des itérations de boucle dans les applications OpenMP avec accès irrégulierà la mémoire principale. L'approche gère l'irrégularité des boucles imbriquées, où le blocde l'itération de la boucle parallèle interne dépend de l'indice d'une boucle externe, desorte que l'a�ectation des itérations de la boucle interne aux processeurs change entreitérations de la boucle externe. L'idée principale de l'approche est de distribuer d'abordles pages mémoires d'une structure de données accédée par une tâche (une boucle) surdes n÷uds utilisant une description spéci�que à l'application fournie par le programmeurpar des annotations de code et de programmer des itérations des données sur les mêmesn÷uds.

Le placement des pages est assuré par la politique �rst-touch qui place les pagesde manière appropriée (sur le n÷ud de la première itération accédant à la structure dedonnées). La localité de données est adressée en a�ectant des itérations suivantes accédantaux données aux processeurs associés aux n÷uds contenant les données.

3- Expérimentions

La plateforme de l'expérimentation : c'est un système SGI Origin 2000 avec 64 proces-seurs regroupés en 32 n÷uds.Applications :

44

1- Décomposition de LU (Application régulière), trois versions ont été comparé :- une version OpenMP non modi�ée.- une version OpenMP modi�ée avec des directives de distribution de données supportéespar le compilateur SGI.- l'approche SCHEDULE REUSE des auteurs.

2- Prévisions météorologiques (Application irrégulière) deux variantes :- Implémentés en utilisant OpenMP, avec l'approche SCHEDULE REUSE- Avec le partitionnement de données explicite et le passage de message en utilisant MPI.

4-Evaluation

L'approche de réutilisation de l'ordonnancement surpasse les deux versions d'Open-MP pour la décomposition de LU qu'elle surpasse les versions OpenMP non modi�ées del'Application de prévisions météorologiques et qu'elle o�re des performances comparablesaux Versions MPI.

5- Commentaires

La réutilisation de l'ordonnancement illustre que des informations statiques détail-léessur les accès aux données, tirées du code source de l'application, peuvent être combinéesavec une description d'une distribution de données spéci�que à l'architecture pour unemeilleure exploitation de la plateforme cible.

TCH IMP SDP TSD GRN ToP TYP SPD ENT ToSC CP+RT PRG ARY ELT EXE LOOP DD ITR EXE

Table 4.1: Caractéristiques de l'approche réutilisation de l'ordonnancement

4.2.2 Ordonnancement du parallélisme non structuré

1- Auteur

Yoo et al. dans [Yoo+13].

2- Idée

Le but de cette approche est d'optimiser les applications avec un parallélisme nonstructuré (c'est-à-dire des sections parallèles avec des tâches indépendantes qui peuventêtre ordonnancées dans n'importe quel ordre avec une possibilité de partage des données).Les auteurs se sont concentrés sur les performances du cache en exécutant des tâches quipartagent des données sur des c÷urs proches dans la hiérarchie de la mémoire.

L'approche comprend trois parties principales.- La première partie, la charge de travail est pro�lée a�n de dériver des informationssur le partage de données entre les tâches.- La deuxième partie consiste à grouper des tâches, à classer des groupes et à a�ecterles groupes à des �les d'attente de travail associées aux composants de la hiérarchie demémoire.- La troisième partie traite de l'équilibrage dynamique de la charge grâce à undétournement de tâche sensible à la localité.

Le résultat de l'exécution du pro�lage est un graphe de partage de tâches dont lessommets représentent des tâches et dont les arcs non dirigés capturent les relations de

45

partage de données entre les tâches. Le poids associé à une arête indique le nombrede lignes de cache accessibles par les deux tâches connectées par un arc. Le graphe estensuite partitionné de manière heuristique et récursive en groupes pour chaque niveau dela hiérarchie de mémoire, en commençant par le cache de dernier niveau. Chaque groupede tâches est choisi de sorte que l'ensemble de travail des tâches s'insère dans un cachedu niveau ciblé dans la hiérarchie de mémoire et de sorte que le partage de données intra-groupe soit maximisé. Le résultat est une hiérarchie de groupes de tâches qui peuventêtre ordonnancées sur les �les d'attente associées à chaque composant de la hiérarchiede mémoire, Au moment de l'exécution, les tâches sont exécutées par des threads detravail (worker) avec un thread par c÷ur. Lorsqu'un thread (worker) a �ni d'exécuterune tâche, il essaie d'abord d'obtenir une tâche de sa �le d'attente locale associée à soncache de premier niveau. Si cette �le d'attente est vide, le worker tente de prendre destâches de l'une des �les d'attente associées au cache de premier niveau de ses c÷urs voisinspar rapport au niveau suivant dans la hiérarchie de mémoire. Si ces �les d'attente sontégalement vides, le worker tente d'obtenir un groupe de tâches à partir de la �le d'attenteassociée à son cache de deuxième niveau.

3- Expérimentation

Cette approche a été appliquée sur les charges de travail générales (base de données,reconstruction d'image 3D, détection de collision, traitement d'image, multiplica-tionmatricielle et solveur pour équations aux dérivées partielles).

4- Evaluation

Le groupement de tâches, le classement et l'assignation aux �les d'attente, mais sansvol de travail sensible à la localité, peuvent accélérer l'exécution de 2 :39 sur 32 c÷urspour les tests de mémoire intensifs et jusqu'à 3 :57 sur 1024 c÷urs. Le vol de travailsensible à la localisation sur 32 c÷urs peut accélérer l'exécution de 1 :9 par rapport àun vol de travail aléatoire avec un déséquilibre de charge créé par un nombre de workersinférieur au nombre de c÷urs.

5- Commentaires

L'approche montre que l'exploitation du partage de données dans l'ordonnanceur peutconduire à des améliorations de performances signi�catives. Elle illustre également quel'a�ectation initiale des tâches peut être combinée avec une technique de vols de travailtenant compte de la localité pour l'équilibrage de charge qui réagit aux circonstances aumoment de l'exécution. L'approche du parallélisme non structuré ne fournit aucune formede placement de données explicite.

TCH IMP SDP TSD GRN ToP TYP SPD ENT ToSS RT - - - EXE TASK DS TASK SoX

Table 4.2: Caractéristiques de l'Ordonnancement du parallélisme non structuré

4.3 Placement des données

Dans cette section nous allons donner les di�érentes approches pour le placement desdonnées.

46

4.3.1 A�nity on touch AoT

1- Auteur

L. Henrik et al. [HEN000], [LH05].

2- Idée

De nombreux systèmes d'exploitation utilisent le placement AFFINITY-ON-FIRST-TOUCH (AoFT) comme stratégie de placement par défaut, dans laquelle une page demémoire physique est allouée sur le n÷ud associé à la tâche qui écrit en premier sur lapage ou lit la page. Si les c÷urs qui initialisent les structures de données et ceux qui yaccèdent se trouvent sur le même n÷ud, l'AoFT génère une forte densité d'accès mémoirelocal. Cependant, si les n÷uds d'initialisation et les n÷uds d'accès ne correspondentpas, cette stratégie peut entraîner un con�it élevé et une forte proportion d'accès àla mémoire distante. Une stratégie courante pour contourner ce problème consiste àmigrer dynamiquement les pages après l'initialisation vers les n÷uds qui e�ectuent lesaccès en écriture suivants. Cette stratégie, appelée AFFINITY-ON-NEXT-TOUCH(AoNT) ou MIGRATE-ON-NEXT-TOUCH , peut être entièrement implémentéedans l'espace utilisateur en utilisant des appels système pour la protection mémoire et lamigration de page synchrone ou dans l'espace noyau pour la migration transparente etasynchrone.

3- Expérimentation

Löf et Holmgren [HEN000] ont évalué une implémentation d'espace utilisateur deAoNT sur un domaine isolé de 8 n÷uds d'un système Sun Fire 15000 exécutant uneapplication calculant la di�usion d'ondes électromagnétiques dans un espace tridimensionnelprincipa-lement pour résoudre un ensemble d'équations en utilisant la méthode du gradientconjugué. Goglin et Furmento [GF09b] ont implémenté AoNT pour le noyau Linux surun système AMD Opteron 8347HE à quatre n÷uds.

4- Evaluation

En utilisant AoNT, la performance est améliorée jusqu'à 166%, ce qui montre que leplacement de données peut avoir un impact énorme sur les performances de l'application.Pour Goglin et Furmento [GF09b] ont comparé les performances à une implémentationd'espace utilisateur. L'implémentation basée sur le noyau est environ 30% plus rapide eta�che un sur débit signi�cativement moins important que l'implémentation de l'espaceutilisateur pour les petites régions de mémoire.

5- Commentaires

Les auteurs concluent qu'une implémentation de l'espace utilisateur est plus performan-te dans les cas où de plus grandes zones de mémoire connues par l'application doiventêtre migrées. L'implémentation d'espace noyau migre ces zones page par page, tandisqu'une implémentation d'espace utilisateur peut migrer chacune de ces zones en uneseule opération avec une surcharge plus faible. Cependant, il appartient au programmeurou à un composant logiciel de niveau supérieur de déclencher la migration de la page.

TCH IMP SDP TSD GRN ToP TYP SPD ENT ToSP OS-LB PRG-PFL - PG EXE - - - -

Table 4.3: Caractéristiques de l'A�nity on Touch

47

4.3.2 CARREFOUR

1- Auteur

Dashti et. al [Das+13].

2- Idée

C'est un mécanisme de placement de données compatible NUMA pour le noyau Linux.CARREFOUR essaie d'éviter la congestion sur les contrôleurs de mémoire et les liensd'interconnexion et considère la réduction de la latence des accès mémoire en améliorantla localisation des données uniquement comme objectif secondaire. L'approche est baséesur quatre techniques :1- La co-localisation de pages : il place une page sur le même n÷ud que le c÷uraccédant2- L'entrelacement de pages : il place les pages sur des n÷uds de manière circulaire3- La réplication de page : il réplique des pages sur plusieurs n÷uds4- Le clustering co-programme : il place les threads en fonction de leur intensité departage de données.

La combinaison de ces techniques et l'application de chaque technique dépendent ducomportement des applications exécutées sur la machine. Cela implique- des décisions globales qui activent ou désactivent des techniques individuelles globalement- des décisions page-locales qui activent ou désactivent des techniques par page.Les statistiques qui servent de base pour caractériser le comportement du programme sontdérivées des valeurs fournies par un composant de mesure qui utilise INSTRUCTION-BASED SAMPLING (IBS) [Dro07].

Les décisions globales sont prises en quatre étapes. Dans :

1- La première étape, le système décide si le placement de données est nécessaire ounon. À cette �n, CARREFOUR compare le nombre d'accès mémoire par unité de tempsdu système entier à un seuil déterminé expérimentalement de 50 accès par microseconde.Si la valeur réelle de l'application est inférieure au seuil, CARREFOUR est désactivé etaucune autre action n'est entreprise.

2- La deuxième étape consiste à décider si la réplication de page doit être activée oudésactivée. Pour éviter une charge de synchronisation élevée en raison des mises à jourfréquentes du contenu des pages, la réplication de page est uniquement utilisée pour lesapplications dont la fraction d'accès en lecture à la mémoire DRAM est supérieure à 95%.

3- La troisième étape, CARREFOUR véri�e si l'entrelacement doit être utilisé pourdistribuer les demandes à la mémoire principale à tous les contrôleurs de mémoire. Cettedécision est basée sur le déséquilibre du contrôleur de mémoire, qui est dé�ni commel'écart-type de la fréquence des accès mémoire entre les n÷uds. L'entrelacement n'estappliqué que si la valeur est supérieure à un seuil de 35%.

4- La co-localisation est activée pour les applications dont le taux d'accès local estinférieur à 80%, c'est-à-dire que la fraction des accès mémoire qui cible un n÷ud local estinférieure à 80%. Les décisions locales-locales sont prises individuellement pour chaquepage en analysant les statistiques dérivées des échantillons IBS qui appartiennent auxinstructions d'accès à la page. Une page est migrée vers un n÷ud si la migration de pageest activée globalement et si la page n'est accessible que par les c÷urs d'un seul n÷ud. Laréplication de page se déclenche si le mécanisme est autorisé globalement et si la page n'a

48

été consultée qu'en lisant les instructions. Une page accessible par des c÷urs de plusieursn÷uds en mode lecture et écriture est placée en utilisant le mécanisme d'entrelacementqui déplace la page sur le n÷ud avec le plus petit nombre d'accès mémoire par unité detemps a�n de réduire les con�its.

3- Expérimentation

L'évaluation expérimentale de CARREFOUR a été réalisée sur deux machines systèmesAMDOpteron à 16 et 24 c÷urs respectivement, regroupées en quatre n÷uds. Les applicationsutilisées pour cette évaluation sont la suite PARSEC BENCHMARK (version 2.1), lemoteur de reconnaissance faciale FACEREC (version 5.0). Les performances de CARREFOURont été comparées à la stratégie par défaut de mise en page de First-touch du noyau Linux,entrelacement sur tous les n÷uds.

5- Evaluation

CARREFOUR fonctionne nettement mieux que le placement de pages par défaut(jusqu'à 3 :63 plus rapide). Comparé à l'entrelacement sur tous les n÷uds, CARREFOURaméliore signi�cativement la performance dans la plupart des cas et limite la dégradationdes performances dans les cas où l'entrelacement entre tous les n÷uds dégrade les perform-ances par rapport au positionnement par défaut du système d'exploitation.

5- Commentaires

CARREFOUR ne parvient pas à améliorer les performances des applications avec deschangements de comportement rapides en raison de la précision d'échantillonnage limitéenécessaire pour un échantillonnage à faible débit. CARREFOUR montre que la contentionest un problème important sur les systèmes NUMA car les optimisations qui diminuentles contentions entraînent une amélioration signi�cative du temps d'exécution.

TCH IMP SDP TSD GRN ToP TYP SPD ENT ToSC OS PFL - PG EXE THD CLS OS OS THD EXE

Table 4.4: Caractéristiques de l'approche CARREFOUR

4.3.3 Interface memory a�nity MAI

1- Auteur

C. Pousa RibeiroDashti et. al [P.+09].

2- Idée

C' est une interface de placement de données dont l'implémentation fournit un certainnombre de politiques pour la distribution des pages d'un tableau :1- bind_all : place toutes les pages sur un seul n÷ud et ne passe pas à d'autres n÷udsque si toute la mémoire du n÷ud actuel est en cours d'utilisation.2- bind_block : divise d'abord le tableau en blocs, puis place chaque bloc sur un n÷uddi�érent.3- cyclique : distribue les pages d'un tableau de manière circulaire sur tous les n÷udsde la machine, de telle sorte que la iime page est placée sur le n÷ud dont l'identi�ant esti mod M, M étant le nombre de n÷uds.4- cyclic_block : distribue des blocs de pages suivantes sur des n÷uds de manièrecirculaire.

49

5- _mapp : combine deux politiques : d'abord, il associe des pages à P blocs de donnéesvirtuels en utilisant la politique cyclique. La deuxième étape consiste à redistribuer lesblocs virtuels aux n÷uds en utilisant à nouveau la politique cyclique.6- random : elle place les pages de manière aléatoire entre les n÷uds.

3- Expérimentation.

L'évaluation de MAI a été réalisée sur des systèmes à quatre et huit n÷uds NUMApour les applications FFT et CG de la version OpenMP du NAS PARALLEL BENCHMA-RKS ainsi que pour une implémentation OpenMP d'une application géophysique.

4- Evaluation.

Les stratégies proposées par MAI peuvent améliorer les performances de jusqu'à 31%par rapport à la stratégie d'AoFT par défaut du système d'exploitation, mais doivent êtrechoisies manuellement.

5- Commentaires

Les auteurs ont conclu que la meilleure stratégie pour le placement de données dépendde l'architecture cible ainsi que de la structure des accès mémoire. Les machines avec unegrande di�érence entre la latence des accès locaux et distants béné�cient d'un placementde données optimisé pour la localité, comme bind_block, tandis que l'exécution surdes machines avec une faible di�érence entre ces latences peut être améliorée avec unplacement qui améliore la répartition cyclique, aléatoire. Les applications avec une a�nitéclaire des calculs et des données donnent des performances plus élevées avec bind_blocket les applications avec des accès irréguliers béné�cient de la distribution des données surles n÷uds.

Les résultats présentés dans l'évaluation expérimentale de MAI montrent que le compo-rtement d'une application nécessite di�érents types de distributions de données aux n÷udset souligne que l'architecture joue également un rôle important dans la sélection d'unestratégie de placement.

TCH IMP SDP TSD GRN ToP TYP SPD ENT ToSP LB PRG ARY BL/PG EXE THD PIN - PTH SOX

Table 4.5: Caractéristiques de l'approche MAI

4.3.4 MINAS

1- Auteur

C. Pousa RibeiroDashti et. al [RM09].

2- Idée

MINAS combine les capacités de placement de données de MAI avec un préproces-seurappelé MAPP et NUMARCH, un module qui fournit des informations sur l'architecturecible. MAPP traite le code source d'une application, trouve des tableaux statiques partagéset remplace leurs déclarations par des appels appropriés aux fonctions d'allocation et dedistribution de mémoire de MAI. La politique réelle pour la distribution de donnéeschoisie par MAPP dépend des caractéristiques de la plate-forme NUMA signalée parNUMARCH. Pour les systèmes ayant une latence d'accès distant élevée par rapport à lalatence des accès locaux, la politique bind_block est choisie a�n d'optimiser la latence.

50

Sur les systèmes avec une latence d'accès à distance inférieure, le framework optimise labande passante et utilise la politique cyclique.

L'approche utilise deux métriques pour caractériser la communication :1- la première est basée sur la quantité de mémoire accessible par deux threads2- la seconde mesure le nombre d'accès aux blocs de mémoire partagée.

3- Expérimentation.

L'évaluation expérimentale a été réalisée sur un système AMD Opteron 875 avec 8n÷uds NUMA et 16 c÷urs au total, ainsi que sur un système Intel Xeon X7560 avec4 n÷uds NUMA et 32 c÷urs au total. Les performances de l'optimisation automatiqueavec MINAS sont comparées à la politique de placement de pages par défaut du systèmed'exploitation ainsi qu'aux versions des applications réglées manuellement en utilisant descombinaisons de stratégies de distribution correspondant le mieux aux modèles d'accèsaux données. Les applications utilisées pour l'évalua-tion sont les mêmes que pour l'évaluationde MAI avec un benchmark supplémentaire qui simule la propagation des ondes en troisdimensions.

4- Evaluation.

La solution automatique améliore les performances par rapport à la stratégie depositionnement de page par défaut du système d'exploitation, mais reste derrière lesperformances des codes réglés manuellement. La di�érence entre les versions automatiqueet manuelle varie de 0% à 25%.

Les auteurs ont montré que pour les mappages de threads et de données basés sur lamatrice de partage, des améliorations signi�catives du temps d'exécution allant jusqu'à75% peuvent être réalisées par rapport au mappage de thread et de données par défautdu système d'exploitation.

5- Commentaires

Bien que l'approche automatique ne puisse pas correspondre aux performances du coderéglé manuellement dans certain cas. L'approche montre que le pro�lage peut être utilisépour obtenir des informations détaillées sur les échanges de données entre threads, ce quipeut être exploité pour améliorer le positionnement des applications avec des modèlesdistincts pour les accès mémoire.

Figure 4.2: MINAS Framework

51

TCH IMP SDP TSD GRN ToP TYP SPD ENT ToSC PP+LB PPR ARY BL/PG EXE CoSCH DS PTHD SOX

Table 4.6: Caractéristiques de l'approche MINAS

4.3.5 Placement de pages orienté feedback FBoPP

1- Auteur

Marathe et al [MTM10].

2- Idée

C'est un placement guidé par la trace de pages pour les programmes OpenMP. L'appro-che est divisée en trois phases :

a- La génération de tracesPendant la génération de trace, le framework exécute une version tronquée du programmedont le placement de données doit être amélioré. il présente des informations détailléessur les accès mémoire et les allocations de mémoire en utilisant les outils pour enregistrerles performances des processeurs et en interceptant les appels à l'allocateur de mémoirede la bibliothèque d'exécution C / FORTRAN.

b- La décision d'a�nitéLes décisions d'a�nité consistent à déterminer sur quel n÷ud chaque page doit être placée,en fonction des accès de la trace. Le framework fournit un modèle simple, dans lequel lalatence d'un accès à distance est supposée être indépendante de la distance entre le c÷urdemandeur et le n÷ud qui satisfait la demande. Dans ce modèle, une page est associée aun÷ud ayant le plus grand nombre d'accès à la page. Ainsi qu'un modèle plus sophistiquéqui prend en compte des latences variables.

c- Le placement de pages guidées par traceLe placement de page réel est e�ectué lors de l'exécution du programme entier en intercep-tant les appels à l'allocateur de mémoire et en initialisant des pages sur le n÷ud appropriéavant de transmettre les régions de mémoire à l'application.

3- ExpérimentationLes auteurs ont testé cette approche sur les applications de la version C du NAS PARALLELBENCHMARKS et des applications des benchmarks SPEC OMPM2001 sur un systèmeNUMA avec quatre n÷uds.

4- Evaluationle nombre d'accès mémoire distants et le temps d'exécution peut être diminué de manièresigni�cative .

5- CommentairesLe placement de pages orienté feedback est une approche qui exploite les informationsobtenues par le biais du pro�lage pour améliorer le placement des données.


Table 4.7: Caractéristiques de l'approche FBoPP

52

4.4 Ordonnancement et placement combinés

Dans les sections suivantes, nous présentons les approches combinant l'ordonnan-cement et le placement dans le contexte NUMA.

4.4.1 FORESTGOMP

1- Auteur

Broquedis et al [Wac+10].

2- Idée

FORESTGOMP est un runtime OpenMP avec un ordonnanceur ressource-aware basésur l'ordonnanceur BUBBLESCHED [TNW07] et un allocateur NUMA-aware basé surl'interface mémoire MAMI [Bro+09]. il repose sur des indications précises sur les a�nitésentre les threads OpenMP et les données fournies par le programmeur. Il est basé surtrois concepts clés :

1- Le regroupement des threads OpenMP en bulles.a- Extraction automatiquement les informations sur la hiérarchie de la mémoire de laplateforme cible à l'aide de HWLOC [Bro+10]b- Création d'une hiérarchie de �les d'attente re�étant cette topologie. le système d'exécu-tion peut créer une �le d'attente pour l'ensemble de la machine, une �le d'attente pourchaque n÷ud NUMA, une �le d'attente pour chaque cache partagé et une �le d'attentepour chaque c÷ur. Chacune des �les d'attente d'exécution forme un domaine d'ordonnan-cement qui limite l'exécution des entités d'ordonnancement dans la �le d'attente à la partiede la hiérarchie de mémoire à laquelle la �le d'attente est associée.c- Les entités utilisées par l'ordonnanceur BUBBLESCHED sont des threads et des bullesOpenMP. Les bulles sont des groupes de threads ou des groupes imbriqués de bulles etexpriment le partage de données entre les threads ou l'accès d'un groupe de threads à desdonnées sur le même n÷ud. Les threads qui forment une bulle sont conservés ensemble leplus longtemps possible pour éviter que les threads accédant aux mêmes données soientdispersés sur l'ensemble de la machine. La création de bulles est e�ectuée par le systèmed'exécution et a lieu chaque fois qu'une section parallèle est rencontrée. L'ensemble dethreads qui forme une bulle est identique à l'ensemble de threads d'une section parallèle.Des sections parallèles imbriquées conduisent à la création de bulles imbriquées agrégeantd'autres bulles.

2- L'ordonnancement des threads et des bulles en utilisant une hiérarchie de �lesd'attente.L'ordonnancement basé sur les ressources est implémenté en utilisant deux algorithmes :a- L'ordonnanceur de bulle de mémoire.a- L'ordonnanceur de bulle de cache.

L'ordonnanceur NUMA-aware s'appuie sur ce que l'on appelle des indicateurs mémoi-re qui résument quelles régions de données seront accessibles par un seul thread ou ungroupe de threads. Ces derniers sont fournis par le programmeur en appelant les fonctionsappropriées du système d'exécution avant de créer une section parallèle ou à partir d'unthread dans une section parallèle.

53

L'exécution associe les informations dérivées de ces indicateurs aux threads et auxbulles, ce qui permet à l'ordonnanceur de distribuer les threads en conséquence.

Dans un premier temps, chaque thread est associé au n÷ud qui contient la fraction laplus élevée des données du thread parmi tous les n÷uds. Les bulles qui contiennent desthreads associés à di�érents n÷uds explosent et leurs threads sont répartis en conséquence.

3- La migration dynamique des données lors de l'équilibrage de charge .Si la distribution résultant de la première étape conduit à un déséquilibre entre les c÷urs,l'algorithme choisit les threads ayant le moins de données attachées pour la redistribution.Une fois la distribution des threads terminée, le système migre les données des threadsdéplacés vers les bons n÷uds.

A�n de pouvoir réagir aux changements de comportement du programme, l'exécu-tion permet à l'application de mettre à jour les indications de mémoire lors de l'exécutiond'une région parallèle. Chaque fois qu'un indice est mis à jour, l'ordonnanceur est appelépour véri�er la distribution actuelle des threads et pour redistribuer les threads demanière appropriée si nécessaire. Pour détecter les changements d'a�nités non indiquéspar le programmeur, FORESTGOMP surveille également les compteurs de performancematérielle et appelle l'ordonnanceur automatiquement si la fraction des accès mémoiredistants dépasse un certain seuil.

3- Expérimentation

L'évaluation a été réalisée sur une version modi�ée du STREAM BENCHMARK (deuxversion TWISTED-STREAM 100 et 66) et une application e�ectuant une décompo-sition LU s'exécutant sur une plate-forme AMD Opteron avec quatre n÷uds NUMA.Les performances de FORESTGOMP sur le banc d'essai TWISTED-STREAM sontcomparées à l'exécution OpenMP du compilateur GNU C nommé LIBGOMP et à lamigration de page en utilisant AFFINITY-ON-NEXT-TOUCH.

4- Evaluation

Pour TWISTED-100, FORESTGOMP a réduit de 25% le temps d'exécution parrapport à LIBGOMP. Le gain sur la migration de page dépend du nombre d'itérationse�ectuées par le test de performances après le changement d'a�nités, à mesure que lesurcoût relatif de la migration de page diminue à chaque itération.

Pour TWISTED-66, FORESTGOMP doit migrer un tiers des données. Pour moinsde trois itérations, FOREST-GOMP est donc plus lent que LIBGOMP, mais toujours plusrapide que AFFINITY-ON-NEXT-TOUCH. Pour plus de trois itérations, FORESTGOMPsurpasse à la fois LIBGOMP et AFFINITY-ON-NEXT-TOUCH. Les a�nités de donnéesdans l'application e�ectuant la décomposition LU sont plus complexes et changent plusfréquemment que pour le benchmark STREAM.

5- Commentaires

FORESTGOMP fonctionne le mieux avec des a�nités claires entre les threads etles données et si la localité pour changer les a�nités peut être restaurée grâce à laprogrammation sans migration. L'approche montre que les informations qui manquentdans une couche logicielle plus abstraite, c'est-à-dire le temps d'exécution, peuvent êtrecompensées en propageant des informations plus détaillées à partir de l'application.


54

Figure 4.3: Principe de FORESTGOMP Framework

Table 4.8: Caractéristiques de l'approche FORESTGOMP

4.4.2 LAWS

1- Auteurs

Chen et al. [CGG14]

2- Idée

L'approche associe l'allocation et l'ordonnancement compatibles avec NUMA avec laprogrammation des tâches CILK. Elle cible les algorithmes diviser pour régner avecles caractéristiques suivantes :a- les étapes récursives de l'algorithme sont représentées par un arbre de tâches danslequel chaque n÷ud représente une étape.b- les accès aux données ne se produisent que dans les tâches feuilles et le partage dedonnées entre les tâches du même niveau dans l'arbre.

LAWS a trois composants principaux :i- un allocateur de mémoire compatible NUMA,ii- un packer DAG adaptatifiii- un mécanisme de vol de travail compatible avec NUMA et le cache.

Son placement de données est e�ectué au cours de la première itération de l'algori-thme en a�ectant les ensembles de données des tâches crées de manière récursive de l'arbrede tâches aux n÷uds NUMA.

3- Expérimentation

LAWS a été testé sur un système AMD Opteron 8380 à quatre n÷uds exécutantun ensemble d'applications qui e�ectuent des calculs de stencil et des algorithmespour l'élimination gaussienne. Chaque benchmark est disponible en deux versions.La première version a une exécution DAG régulièrement structurée, tandis que lescalculs de la seconde version forment un DAG de structure irrégulière.

4- Evaluation

La performance de LAWS a été comparée à CILK simple sans aucune modi�cationet à un autre algorithme nommé CATS [CGH12], qui n'adapte pas le placement après

55

la première itération. L'amélioration de LAWS par rapport à CILK varie de 23 :5% à54 :2%. LAWS surpasse systématiquement CATS, ce qui améliore les performances parrapport à CILK jusqu'à 19 :6%.

5- Commentaires

LAWS montre que les informations implicites sur la structure des calculs ainsi que lesstructures de données impliquées dans les calculs peuvent être exploitées à la fois pourle placement de données et l'ordonnancement a�n d'augmenter la localisation des accèsmémoire automatiquement par le système d'exécution.

TCH IMP SDP TSD GRN ToP TYP SPD ENT ToSC RT DAG ARY BL EXE TSK DD Cilk TSK EXE

Table 4.9: Caractéristiques de l'approche LAWS

Les tableaux 1.10 et 1.11 donnent un récapitulatif des caractéristiques principales pourtoutes les approches présentées précédemment.

56

Num Scheduling/Mapping Policy ONU OCH DPL SCH Impl layer DoRD Sup-DT Granularity ToD ADA Ref1 A�nity on touch(OS) X - X - LIB/OS PROGr Any PGs EXE x [61,50]2 CARREFOUR X - X X OS PRFLg Any PGs EXE x [44]3 MAI X - X - LIB PROGr Arrays BLs/PGs EXE x [77]4 MINAS + pro�ling X X X (X) PPg + LIB PPr Static Arrays BLs/PGs EXE x [66,76]5 FBoPP X - X - LIB PRFLg Any PGs EXE x [62]6 SCHEDULE REUSE X - (X) X CMPL+ RT PROGr Arrays ELTs EXE x [68]7 Unstructured parallelism - X - X RT - - - EXE x [86]8 FORESTGOMP X X X X RT PROGr Not Speci�ed N/Speci�ed EXE x [29, 31]9 LAWS X X X X RT DAG Arrays BLs EXE x [38]

Table 4.10: Caractéristiques des approches et du placement de données associes

Num Scheduling/Mapping Policy Type of placement Source for PLC decision Scheduling entity Time of decision Auto.dyn.adjustment1 A�nity on touch(OS) - - - - -2 CARREFOUR Thread clustring OS/PMU OS threads Execution x3 MAI Thread pinning - PThreads Start of execution -4 MINAS + pro�ling Co-scheduling Data sharing PThreads Start of execution -5 Feedback-directed PLC Thread pinning - PThreads Start of execution -6 SCHEDULE REUSE Loop scheduling Data distribution Loop iteration Execution -7 Unstructured parallelism Task placement Data sharing Tasks Start of execution x8 FORESTGOMP Thread placement Data distribution OpenMP threads Execution x9 LAWS Task placement Data distribution Cilk tasks Execution x

Table 4.11: Caractéristiques de l'ordonnancement des approches vues

4.5 Stratégies d'équilibrage de charge dans NUMA

L'algorithme d'ordonnancement dynamique doit être générique, évolutif et �exiblesur la prise de décision. Cette �exibilité provient de la possibilité de choisir n'importequelle tâche prête tout en conservant la borne sur le temps d'exécution. Dans beaucoupd'algorithmes d'ordonnancement, l'objectif principal est de minimiser les temps d'inactivitéset surtout cela lors de la communication. Pour aider à atteindre cet objectif, Les algorithmesde l'équilibrage de charge permettent de réduire cette inactivité en préservant une chargeéquitable entre les processeurs.

Chaque processeur maintient sa propre liste locale des tâches prêtes. Cette commu-nication pourrait impliquer les transferts de données nécessaires pour compléter le travail,mais aussi les processeurs sont capables de communiquer pour échanger les tâches dansleurs �les d'attente fonctionnelles. Le processus d'échange de tâches entre �les d'attenteest l'essence même de l'ordonnancement des algorithmes dynamiques. [Qui11] Il existedeux grands paradigmes d'équilibrage de charge dynamique dans les plateformes parallèlesNUMA inclus :- Le partage de travail [BL99]- Le vol de travail [Blu+95]

4.5.1 Partage du travail

Dans la stratégie du partage de travail, chaque processeur a un ensemble de tâchesà exécuter. Ce travail est enregistré dans la mémoire du processeur qui doit exécuter latâche. Le risque est qu'un processeur ait plus de travail que les autres. Pour rééquilibrerla charge entre les processeurs, chaque processeur surveille sa quantité de travail . Si unprocesseur est surchargé, des tâches sont migrées vers les autres processeurs. Ainsi, lestâches sont échangées entre les processeurs pour équilibrer la charge. Le choix de migrationnécessite une méthode pour mesurer la quantité de travail totale et locale à un processeur,mais aussi le coût de la redistribution du travail. Au fur et à mesure de l'exécution, laquantité de travail diminue. Il est donc nécessaire de faire transiter des messages pouravoir les informations. Lorsque celles-ci sont connues, l'algorithme doit migrer les tâchesa�n d'obtenir un système dans lequel aucun processeur ne détectera de surcharge. [Qui11]

Pour les tâches homogènes et indépendantes, l'algorithme peut calculer la quantitéde travail sur toute la plate-forme et en local et il fonctionne bien dans ces conditions.En revanche, dans le cas général, cela implique des erreurs sur les temps d'exécution quipourront être compensées par des migrations de tâches. La prise en compte des relationsde précédences et des coûts de communications entre les tâches compliquent sa tâcheet demande d'importants changements dans l'algorithme. Dans ce cas, les migrations detâches risquent d'être fréquentes pour compenser le manque d'informations. Les performan-ces obtenues risquent d'être mauvaises. [Qui11]

4.5.2 Vol de travail (Work stealing)

Les processeurs tente de voler des tâches à partir de listes prêtes d'autres processeursqui sont appelés victimes (VICTIM) lorsque sa propre �le d'attente devient vide. Dans

58

ce cas, ce processeur est appelé voleur (THIEF), et la tâche volée migre vers la �led'attente de ce processeur en quittant celle du processeur volé [Spo+08]. Cet algorithmeest implémenté dans certains langages comme Cilk [Blu+95].

L'objectif du vol de travail est de s'abstraire de toutes les données fournies parl'utilisateur tout en ordonnançant e�cacement l'application sur un nombre de machinesnon dé�ni. Ce mécanisme a été proposé initialement par Blumofe [Blu+95]. Sa popularitéprovient de ses nombreux atouts, en voici quelques un :� algorithme distribué� passage à l'échelle� réactivité aux perturbations� temps d'exécution et nombre de tâches transférées analysés théoriquement

Dans cet algorithme, les décisions sont généralement prises avec les informationslocales à chaque processeur participant à l'exécution. Durant l'exécution, chaque processeura une liste de tâches qui représente le travail à e�ectuer. Lors de l'exécution d'une tâche,le processeur exécute les instructions associées qui peuvent générer d'autres tâches. Cestâches sont stockées pour la suite de l'exécution dans sa liste. L'ensemble des tâcheset leurs données décrivent l'application qui est représentée par un DAG. En fonctionde la quantité de travail présente dans la liste, deux états sont distinguables pour lesprocesseurs :- Travailleur (NORMAL) : un processeur qui exécute du travail (une tâche). Sa listede tâches peut être vide ou non.- Victime (V ICTIM) : un processeur qui exécute du travail (une tâche) et sa liste detâches contient plus de tâches qu'un seuil �xé (MAX_TK).- Voleur (THIEF ) : un processeur qui n'a plus de travail à exécuter. Sa liste de tâchesest vide ou contient moins de tâches d'un seuil �xé (MIN_TK)..

Il tente de trouver du travail auprès des autres processeurs. Tous les processeursévoluent entre ces trois états. Le passage de THIEF à NORMAL s'opère en demandantdu travail aux autres processeurs. Si un processeur reçoit une demande de travail et s'ila des tâches dans sa pile, il envoie du travail au THIEF . Le passage de NORMALà THIEF s'e�ectue en fonction des requêtes de vol et de l'exécution des tâches. Dansce mécanisme, l'ordre d'exécution des tâches est in�uencé par plusieurs décisions quiin�uencent énormément les performances du système :1- la prochaine tâche à exécuter,2- le processeur volé et la ou les tâches volées.

Ordre d'exécution local

L'ordre d'exécution est un des choix qui est le plus rarement modi�é, car l'analysethéorique initialement réalisée par Blumofe et Leiserson [Blu+95], montre que la décisionde suivre le parcours initial du programme sans création de tâches (l'ordre séquentiel) este�cace. Le respect de l'ordre séquentiel permet de conserver les optimisations réalisées parle programmeur. De plus, ce choix permet de borner l'espace mémoire utilisé par chaqueprocesseur. Cet espace mémoire est dans ce cas inférieur ou égal à l'espace mémoireutilisé par le programme séquentiel. Cet ordre d'exécution est équivalent à un parcoursen profondeur du DAG de l'application. Au niveau de la liste, ce parcours peut être réaliséen sélectionnant la dernière tâche ajoutée ('Last In First Out (LIFO)').

59

Requête de vol

Lorsqu'un processeur devient THIEF , il choisit le processeur V ICTIM duquel ilva prendre une partie du travail. Il existe un grand nombre de stratégies di�érentes.Une des stratégies pour le choix est simplement de réaliser un tirage aléatoire uniformeparmi les processeurs participant à l'exécution. Cette stratégie reste la plus simple, nenécessitant aucune information avec un nombre de requêtes de vol borné. Les analysesthéoriques montrent qu'avec une telle sélection de la victime, la probabilité de sélectionnerun processeur ayant une quantité importante de travail est grande même avec un nombrelimité de vols [Blu+95].

Une autre stratégie qui choisit le processeur ayant la tâche la moins profonde dans sapile. Cette solution minimise le temps d'exécution, mais elle nécessite de conserver uneinformation du processeur possédant cette tâche sur toute la plateforme. Pour prendreen compte l'in�uence des accès mémoires sur des plates-formes hiérarchiques ou non,des travaux ont montré qu'il est intéressant d'orienter les vols vers des tâches ayant desdonnées qui pourront être accédées rapidement par THIEF . [Qui11]

Réponse de vol

Sur réception d'une requête de vol, un processeur doit sélectionner le travail à fournir.L'algorithme réalisant la sélection du travail à transférer vers THIEF s'exécute enconcurrence du travail e�ectué par le processeur V ICTIM . Classiquement dans le volde travail, la dernière tâche ajoutée à la pile est la tâche sélectionnée pour être exécutée.Ainsi, les processeurs accèdent à leur pile par le bas (ordre 'LIFO'). Pour ne pas perturberle travail de la victime, les tâches volées sont choisies prioritairement en haut de la pile(ordre 'FIFO'). Les con�its d'accès risquent d'apparaître uniquement quand le nombre detâches est faible. Il reste à dé�nir le nombre de tâches prises dans la pile. Lors d'un vol,l'objectif est d'équilibrer le travail entre les deux processeurs (V ICTIM et THIEF ).Puisque THIEF n'a pas assez de travail, la quantité de travail prise doit être proche dela moitié de celle présente sur la victime.

60

4.6 Conclusion

Dans ce chapitre, nous avons exposé les di�érentes approches concernant l'ordon-nancement et le placement des tâches avec les données dans le contexte NUMA. Audébut, nous avons caractérisé de façon générique les approches qui tentent d'assurerun de ces rôles de point de vue prise décision. Ces approches sont basées sur certainescaractéristiques des architectures cibles et certaines informations à exploiter lors de sonfonctionnement. En se basant sur ces caractéristiques, nous pouvons regrouper les approchesen trois classes. la première qui focalise sur l'ordonnancement seulement, la deuxième surle placement et la troisième combine les deux aspects.

Par la suite, nous avons présenté l'idée derrière chaque approche ainsi que son implémen-tation et son évaluation. A la �n de chaque section, nous avons commenté les avantageset les limites de l'approche étudiée. Cette démarche nous permet de comparer l'impactde l'intégration de chaque approche sur les performances des systèmes NUMA.

Comme l'équilibrage de charge est important pour préserver les performances, ladernière section a détaillé les stratégies utilisées pour cette �n en particulier celle duvol de travail qui nous intéresse par la suite.

Le chapitre suivant est dédié à présenter notre approche dont le principe est d'exploiterl'horizon d'exécution pour guider les processus d'ordonnancement et exposer une variantede vol de travail basé sur la distance NUMA.

61

Chapitre 5

Horizon d'exécution étendu et Vol detravail adaptatif

Dans ce chapitre nous allons présenter les heuristiques proposées pour ordonnanceret placer les threads d'une application décrite par un DAG sur la plateforme NUMAmulticoeur. L'horizon d'exécution étendu X-VHFU (eXtended Visible, in Horizon,Far and Unseen) et le vol de travail adaptatif basé sur la distance (distancebased Work Stealing) sont les deux idées de base proposées dans cette thèse.

La première section 5.1 va exposer l'étude de la combinaison des politiques d'ordo-nnancement et les placements existants appliqués sur des applications constituées d'uneséquence de tâches indépendantes. Ensuite, nous présentons nos approches dans la deuxièmesection 5.3. Dans la troisième section 5.4, l'algorithme de l'équilibrage de charge est exposédont l'heuristique de base est le vol de travail basé sur la distance. En�n, la section 6.5conclue le chapitre.

5.1 Schémas des stratégies d'ordonnancement et placement

Les algorithmes O/M suivent le même motif structurel, ils di�èrent seulement par lastratégie de la sélection de l'entité courante à être servie. Les schémas algorithmiquessuivants explicitent cette idée :

Le schéma pour l'ordonnancement des tâches : il fonctionne selon la stratégie client/ serveur en attendant la soumission des tâches à exécuter, il attend la disponibilité d'uneressource d'exécution et puis il choisit la tâche qui optimise une heuristique donnée,en�n il programme l'exécution de celle-ci sur la ressource libérée. Ce schéma est denature distribuée événementielle selon le motif observateur/observable. L'algorithmescheduleTasks associé avec les évènements Event_OnTaskSubmission et Event_-OnTaskExecutionEnd illustre le principe de ce dernier.

Le schéma pour le placement des données des tâches : il fonctionne selon la stratégieclient / serveur en attendant les requêtes des tâches pour charger des données en mémoireou vers le processeur (deux types de requêtes allocation et libération de la mémoirelecture/écriture des pages/blocs mémoire), il attend la disponibilité d'une ressource destockage (mémoire) et puis il choisit la requête qui optimise une heuristique donnée, en�nil alloue un espace mémoire dans la mémoire cible pour les données choisies . Ce schémaest aussi de nature distribué évènementiel selon le motif observateur/observable.

62

L'algorithmemapTaskData associé avec les évènements Event_OnTaskAllocateMe-mory, Event_OnTaskFreeMemory, Event_OnTaskExecutionStart et Event_-OnTaskExecutionEnd illustre le principe de ce dernier.

Algorithme 3 : Algorithme générique d'ordonnancement des tachesinput : A DAG G=(V,E) and a toplogy graph TG=(N,P,L)output : A schedule of G on TG

Function initialize()begin

/* Q : ready tasks queue , A : available cpus */

Q∗ ←− {T0}A∗ ←− P ∗

processNotyetScheduledTasks()

Function processNotyetScheduledTasks()begin

while Q∗ 6= ∅ do//ready tasks not executed yet/* Ts : selected task to be scheduled now */

Ts = argMaxt∈Q∗ TaskSelectionHeuristic(t)if Ts 6= null then

Ps =argMaxp∈A∗ ProcesseurAllocationHeuristic(p, Ts)if Ps 6= null then

/* Ps : processor to be allocated now */

Trigger OnTaskExecutionStart(Ts, Ps)scheduleOn(Ts, Ps).

/* On task start event */

Event OnTaskExecutionStart(T , P )begin

Q∗ = Q∗ − {Ts}A∗ = A∗ − {P}

/* On task end event */

Event OnTaskExecutionEnd(T )begin

R∗ = getReadyNeighboursAfterEndOf(T )P = getAllocatedProcessorTo(T )Q∗ = Q∗ ∪R∗A∗ = A∗ ∪ {P}processNotyetScheduledTasks()

63

Algorithme 4 : Algorithme générique de placement des données des tachesinput : A DAG G=(V*,E*) and a toplogy graph TG=(N*[P*,M],L*)output : A schedule of G on TG

Function initialize()begin

/* D∗ : tasks load request data , M∗ : available memory pages */

D∗ ←− {T0.data}M∗ = getFreeMemoryPages()processnotyetMappedTasksData()

Function processnotyetMappedTasksData()begin

while D∗ 6= ∅ do/* D∗ : selected tasks data to be mapped now */

S∗ =argMaxd∈S∗ TaskDataSelectionHeuristic(d)if S∗ 6= ∅ then

/* P ∗ : memory pages to be allocated now */

D∗ = D∗ − {S∗}P ∗s =argMaxm∈M∗ MemoryMappingHeuristic(m , S∗)M∗ = M∗ − P ∗s

/* On task data load request event */

Event OnTaskDataLoadRequest(T ,L∗)begin

D∗ = D∗ ∪ {L∗}Trigger OnTaskAllocateMemory()

/* On task allocate memory event */

Event OnTaskAllocateMemory()begin

processnotyetMappedTasksData()

/* On task free memory event */

Event OnTaskFreeMemory(P ∗)begin

M∗ = M∗ ∪ {P ∗}processnotyetMappedTasksData()

64

5.2 Ordonnancement et placement des tâches indépendantes

Dans cette section nous allons présenter le cas ou les tâches de l'application sontindépendantes et partagent des données. Dans ce contexte, nous essayons de voir l'impactde la combinaison des di�érentes politiques d'ordonnancement et de placement sur lesperformances des applications parallèles. Cela va nous aider à évaluer la corrélationentre l'ordonnancement et le placement dans le contexte NUMA sans avoir une structureparticulière de l'application exécutée. Cette première stratégie nous permet de voir lesfacteurs in�uents sur le calcul (exécution) indépendamment de la communication etl'échange des données et d'inspecter le comportement de la plateforme et sa réactionlorsque nous exécutons la même suite de tâches parallèles indépendantes mais en changeantla paire (politique ordonnancement / politique placement) et l'in�uence de ce fait sur lesperformances du support exécutif et en particulier le temps total d'exécution, le facteurNUMA et l'équilibrage de charge.

5.2.1 Combinaison des politiques d'ordonnancement/placementclassiques

Par la suite, nous utilisons certaines politiques implémentées sur les plateformes actuellespour l'ordonnancement on a :

5.2.2 Politiques d'ordonnancement classique

Politique à tour de rôle (Round Robin RRS)

C'est la politique la plus simple à implémenter elle consiste à allouer les n÷uds decalcul aux tâches arrivantes à tour de rôle. Si m est le nombre de n÷uds disponibles pourexécution des tâches, et (k+1) est l'ordre d'arrivée de la tâche Tk+1 (k est le nombre destâches déjà ordonnancées, cette tâche sera l'entête de la queue Q utilisée pour mettre en�le d'attente les tâches reçues. L'heuristique de la sélection des tâches appelle Q.pop()alors cette tâche sera a�ectée au n÷ud k=n mod m si ce dernier est libre.

N∗[(k + 1)mod|N∗|]

Politique le moins utilisé (LessUsed)

Elle consiste à a�ecter les tâches arrivantes au n÷ud le moins utilisé parmi les ressourceslibres.

argMina∈A∗getProcessorNumberOfUses(a)

Politique le moins chargé (Less Loaded LLS)

Cette stratégie consiste à surveiller la charge courante de la plateforme en mainte-nant une structure de donnée qui représente sa charge et d'a�ecter la tâche courante aun÷ud le moins chargé. L'heuristique de l'allocation détermine argMin des processeurs en

65

fonction de leurs charges obtenues par une fonction getProcessorLoad(p) :

argMina∈A∗getProcessorsLoad(a)

5.2.3 Politiques de placement classique

Nous utilisons des politiques similaires implémentées sur les plateformes actuelles pourle placement et ainsi que d'autre spéci�ques au contexte NUMA, on a :

Placement à tour de rôle (Round Robin RRM)

C'est la politique la plus simple à implémenter elle consiste à allouer les mémoires desn÷uds aux tâches à tour de rôle a�n de stocker leurs données.

M∗[(k + 1)mod|M∗|]

Politique le moins utilisé (LessUsed)

Elle consiste à a�ecter les tâches arrivantes au n÷ud le moins utilisé parmi les ressourceslibres.

argMinm∈M∗getMemoryNumberOfUses(m)

Placement First Touch

Les données d'une tâche seront stockées sur la mémoire du n÷ud responsable del'exécution de la tâche associée. Lorsqu'une tâche demande le chargement d'une donnée,le mapper véri�e si elle est déjà chargée dans la mémoire d'un n÷ud sinon elle sera chargéedans la mémoire du n÷ud sur lequel la tâche est ordonnancée.

if (Ti.Load(Dataj) and Dataj .State == 'UNLOAD') M[getAllocatedNodeFor(Ti)].Load(Dataj)

Placement Next Touch

Les données d'une tâche seront stockées sur la mémoire du n÷ud responsable del'exécution de la tâche associée. Lorsqu'une tâche demande le chargement d'une donnée,le mapper veri�e si elle est déjà chargée dans la mémoire d'un n÷ud, alors il va fairemigrer cette tâche sinon elle sera chargé dans sa mémoire.

if (Ti.Load(Dataj) and Dataj .State == 'LOAD') M[getAllocatedNodeFor(Ti)].Migrate(Dataj)

Les politiques combinées sont round robin RRS, moins utilisé LUS et less loaded LLSpour la stratégie de l'ordonnancement et round robin RRM, moins utilisé LUM, �rsttouch FTM et next-touch NTM pour les stratégies de placement. nous obtenons douzecombinaisons.

66

5.3 Ordonnancement et placement d'un graphe de tâches

Dans cette section, nous présentons les idées derrières les heuristiques proposées ainsique les algorithmes associés.

5.3.1 Heuristique Horizon d'exécution Etendu X-VHFU

L'heuristique proposée est constituée de quatre phases. Au début de l'exécution, onextrait la topologie du DAG ainsi que les informations de communication (lesréférences et la taille des données utilisées et partagées par les tâches). Cette phasepréliminaire est basée sur les annotations faites par le programmeur dans le code sourceet qui seront convertit à une information utilisée par le support d'exécution. En se basantsur cette topologie on partitionne le DAG en sous DAGs de tailles presque similaireinitialement, ensuite elle les attache aux n÷uds de la plateforme (Fixer les préférencesdes tâches). Lors de l'ordonnancement d'une tâche, en fonction de son horizon d'exécutioncourant, elle est sélectionnée pour être exécutée soit sur le n÷ud du sous DAG à lequelcette tâche appartienne ou un autre selon son état courant. Si un autre n÷ud est choisialors la con�guration des sous DAGs est actualisée en recalculant les nouveaux sous DAGet en appliquant globalement une stratégie dite horizon d'exécution X-VHFU sur leDAG apres ce changement. En�n, elle équilibre la charge en utilisant une stratégie devol des travaux adapté et basé sur la distance au contexte NUMA.

Partitionner le DAG

Dans cette phase, le DAG G(V ∗, E∗) donné est partitionné en K sous DAGs (Gi)i:1..Ken utilisant un algorithme du partitionement des graphes adapté à ce contexte. Dansce cas , notre graphe sera pondéré avec le volume des donnés échangés entre les tâches(qui peut être obtenu au début l'analyse de notre DAG cible) et non par le temps de lacommunication entre les tâches (inconnu dans ce contexte). Le résultat de cette phase estune partition G.

Φ(G) = ({G1, G2, · · · , GK},MxKK)

Gi = (V ∗i , E∗i ) véri�ant la relation

⋃1≤i≤K

V ∗i = V ∗&V ∗i ∩ V ∗j = ∅ , ∀i 6= j

Où MxKK est la matrice de �ux inter sous-graphes (volume de données échanger entreles tâches des sous graphes connectés) et Gi le sous graphe numéro i. Dans un premiertemps, notre algorithme doit déterminer les di�érents niveaux des sommets sur le DAGdonné, ensuite il parcourt chaque niveau en essayant d'a�ecter le sommet courant à unsous graphe qui minimise le �ux des données échangées avec le reste des sous graphes déjàcalculer. Cet algorithme utilise les fonctions helper suivantes :

- getGraphLevels(G) : cette fonction détermine l'ensemble des niveaux des sommetsde notre DAG donnée. Comme vu dans le chapitre 2 graphe de tâches, un niveau de rangl dans un DAG est un ensemble de sommets dont les sommets parents sont tous dans leniveau de rang strictement inferieur ou égale à l− 1 et au moins un sommet parent dansle niveau l− 1. le niveau du rang 1 est constitué de l'ensemble des sommets qui n'ont pasde prédécesseurs. La �gure 5.4 illustre un DAG avec plusieurs niveaux.

67

Algorithme 5 : Partitionnement d'un DAG en sous DAGsinput : un graphe de tâche DAG G=(V*,E*), La matrice du �ux données

échangées entre les sommets Md, le nombre des partitions Koutput : une partition PAR P = [G*, Mx*], G* l'ensemble des sous DAGs et

Mx* : matrice du �ux entre les sous DAGs

beginL = getGraphLevels(G) //Levelsforeach l ∈ L do

foreach v ∈ l doj = argMin1≤i≤K computeEgdeCutWeight(v,G,Md,G*[i],Mx)G*[j].addVertex(v)updateEgdeCutWeightMatrix(v,G,Md,G*[j],G,Mx)

Function getGraphLevels(G(V*,E*))begin

U = V ∗ i = 0Levels[i] = getVertexWithoutPredecessorsIn(G,U)while U 6= ∅ do

U = U − Levels[i]i+ +Levels[i] = getVertexWithoutPredecessorsIn(G,U)

Return Levels

- getVertexWithoutPredecessorsIn(U) : Cette fonction détermine l'ensemble dessommets qui n'ont pas des sommets prédécesseurs dans l'ensemble U . Elle permet detrouver les sommets du niveau courant.

- computeEgdeCutWeight(v,G,Md,G*[i],G,Mx) : cette fonction permet de calculerle �ux des données échangés résultant de considérer le sommet v dans le sous graphe G∗[i]en utilisant la matrice des �ux trouvée Mx.

- updateEgdeCutWeightMatrix(v,G,Md,G*[j],G,Mx) : cette fonction met àjour la matrice des �ux après avoir ajouté v au sous graphe G∗[j].

La �gure 5.2 donne un exemple de l'application du processus du partitionnement duDAG donné dans la �gure 5.4. Les sous DAGs résultants sont montrés avec di�érentescouleurs.

Fixer les préférences de tâches en fonction des sous DAGs

Cette deuxième phase consiste à attacher (bind) chaque sous-DAG Gi à un n÷udparticulier Nj qui sera le n÷ud espéré d'exécution des tâches de Gi. Cette préférencepeut être changée en fonction de l'état actuel du processus généré par l'exécution duDAG G. Cette a�ectation peut être considérée comme un ordonnancement initial quisera actualisé au fur et à mesure qu'on avance dans le processus.

Φ({G1, G2, · · · , Gn}∗, {Nj}) = {(Gi1 , Nj1), (Gi1 , Nj1), · · · , (Gin , Njn)}

La fonction getPreferenceNode(Nd*, G*, Gi) permet de faire une correspondance

68

Figure 5.1: DAG avec plusieurs niveaux

Figure 5.2: Resultat de la partition d'un DAG

69

Algorithme 6 : Préférence d'exécution des sous DAGsinput : une partition PAR P = [G*, Mx*], matrice des distances NUMA Dxoutput : une liste de paires [(Gi, Nj) i ∈ I, j ∈ J]

beginNd* = getAllNode(Dx)L = ∅foreach Gi ∈ G* do

Nj = getPreferenceNode(Nd*, G*, Gi)Nd* = Nd* /Ni

L.addItem((Gi,Nj))

(bijection, matching) entre les n÷uds de la plateforme et les sous DAGs trouvés. Commele nombre de n÷uds K est égal au nombre des sous DAGs alors ce matching revientà trouver une permutation des n÷uds dont le nombre est K! qui préserve la relationdu voisinage existante entre les sous DAGs en a�ectant deux sous DAGs voisins surdes n÷uds voisin. On peut choisir une métrique qui quanti�e une permutation donnée(distance euclidienne ou autre) et ensuite prend le minimum.

Appliquer la stratégie horizon d'exécution étendu X-VHFU

Lors de l'ordonnancement, la prise de décision de quelle tâche à sélectionner et sur queln÷ud doit être exécutée est faite en fonction de l'état actuel du processus correspondantau DAG exécuté. Apres avoir décidé la tâche à exécuter Tc et le n÷ud exécutant alorson maintient un partitionnement basé sur la visibilité des tâches au support exécutif.Traditionnellement, à un moment donné pendant l'exécution de l'application parallèledécrite par un DAG, l'ensemble des tâches T est partitionné en quatre catégories :1- Tâches complètes (C), TC : Les tâches �nies (completed tasks)2- Tâches en exécution X, TX : Les tâches en exécution (running tasks)3- Tâches prêtes R (ready task)4- Tâches non prêtes Q (not ready yet task).

TR = {T ∈ T|∀Parent(T ) ∈ TC}

TQ = {T ∈ T|∃Parent(T ) /∈ TC}

T = TC ∪ TX ∪ TR ∪ TQA�n de contrôler mieux cette exécution, on partitionne davantage la dernière catégorie Qpour prévoir les tâches visibles à l'instant courant en se basant sur l'information disponibleau support exécutif à ce moment (les tâches complètes C, les tâche en exécution X, tâchesprêtes R). Cette vision est une extension de la visibilité immédiate à un niveau avancéqui permet d'aller au delà des tâches prêtes R. Les nouvelles catégories sont :

TQ = TV ∪ TH ∪ TF ∪ TU

Les tâches visibles V (visible task) :Les tâches à l'horizon 0, ce sont les tâches qui ont au moins une tâche prédécesseur enexécution et tous autre prédécesseurs sont des tâches complètes ou en exécution. Apres la

70

terminaison des prédécesseurs qui sont en exécution, Cette tâche change d'état et devientprête. Cette classe de tâche a une forte probabilité d'être exécuté prochainement.

TV = {T ∈ T|∀Parent(T ) ∈ TC ∪ TX et ∃Parent(T ) ∈ TX}

Les tâches dans l'horizon H (horizon task) :Les tâches à l'horizon 1, ce sont les tâches qui ont au moins une tâche prédécesseur prêteet tous autre prédécesseurs sont des tâches complètes, en exécution ou prête. On attendque leurs tâches prédécesseurs se terminent avant qu'elles deviennent prêtes. Cette classede tâche a une probabilité moyenne d'être exécuté prochainement.

TH = {T ∈ T|∀Parent(T ) ∈ TC ∪ TX ∪ TR et ∃Parent(T ) ∈ TR}

Les tâches au-delà de l'horizon F (beyond the horizon task) :Les tâches au-delà de l'horizon non visibles immédiatement qui ont au moins une tâcheprédécesseur visible et tous autres prédécesseurs sont des tâches complètes, en exécutionou visibles.

TF = {T ∈ T|∃Parent(T ) /∈ TC ∪ TX ∪ TV et ∃Parent(T ) ∈ TV }}

Les tâches non visible U (unseen task) :Les tâches non visibles sont les tâches qui ont au moins une tâche prédécesseur qui est nicomplète, ni en exécutons, ni prête et ni visible. Elles peuvent être loin du niveau actuelde l'exécution. Nous n'avons aucune information qui permet d'évaluer à quel point cettetâche est loin d'être exécutée prochainement.

TU = {T ∈ T|∃Parent(T ) /∈ TC ∪ TX ∪ TR ∪ TV }

Ce partitionnement va nous permettre d'anticiper certaines décisions et de se projeterdans le future prochain de l'exécution de l'application courante. Un nouveau critère desélection de la tâche courante vient d'être intégré dans le processus de la décision. Laprise de décision Dc que l'ordonnanceur doit assurer à chaque libération d'une ressourced'exécution est maintenant une combinaison de trois facteur :

Dc = Φ(Pf , Af , Hz)

Préférence Pf : le n÷ud à lequel le sous DAG qui contient la tâche concernée est attaché.A�nité Af : le n÷ud sur lequel une bonne partie des données utilisé par la tâcheconcernée y résident.Horizon Hz : A quel point si on sélectionne la tâche concernée, on va avancer dansl'horizon d'exécution (on va voir plus de tâches et on s'approche plus de la �n).

Donc, on partitionne l'ensemble des tâches en fonction de l'horizon d'exécution actuelle(est ce que elle est déjà exécutée ou en court d'exécution, prête, dans l'horizon ou loind'être exécutés dans le future prochain).

Le principe de la sélection de la tâche prête à exécuter Ts à un moment donné parl'ordonnanceur est basé sur l'idée de choisir celle qui va élargir l'horizon d'exécutionaprès le changement de son état vers l'exécution pour une meilleure visibilité a�n d'avoirplus d'informations qui aident à mieux ordonnancer les tâches suivantes et mieux placerles données associées. Pour déterminer cette tâche Ts, l'algorithme parcourt l'ensemble

71

Algorithme 7 : Algorithme Horizon d'exécution étendu XH-VHFUinput : la tâche récemment terminée ou commencée Tfoutput : L'horizon d'exécution courant VHFU

/* On task end event */

Event OnTaskExecutionEnd(Te)begin

TX = TX − TeTC = TC ∪ Te/* update the ready tasks */

TR = TR∪ updateSpeci�edHorizon(TV , TC)/* update the visible tasks */

TH = TH∪ updateSpeci�edHorizon(TF , TR)/* update the visible tasks */

TF = TF∪ updateSpeci�edHorizon(TU , TV )

/* On task start event */

Event OnTaskExecutionStart(Ts)begin

TR = TR − TsTX = TX ∪ Ts/* update the ready tasks */

TV = TV∪ updateSpeci�edHorizon(TH , TX)/* update the visible tasks */

TF = TF∪ updateSpeci�edHorizon(TU , TV )

/* update the specified horizon */

Function updateSpeci�edHorizon(TA, TB )begin

V ∗ = ∅foreach Ai ∈ TA do

if Ai.getParents() ⊂ TC ∪ TX ∪ TB and Ai.getParents() ∩TB 6= ∅ thenV ∗ = V ∗ ∪ {Ai}

Return V ∗

72

Figure 5.3: Graphe de transformation des niveaux de visibilité

des tâches prêtes TR et pour chacune d'elle Tr nous allons évaluer la mise à jours del'horizon de l'exécution ∆H(Tr) causée par son changement d'état. Cette quanti�cationest une combinaison pondérée du changement de chaque classe de visibilité. De façonintuitive, nous cherchons combien de tâche devient prête ∆V (Tr), visible ∆H(Tr), danshorizon ∆F (Tr) ou au-delà de l'horizon ∆U(Tr) après avoir choisi d'exécuter la tâcheTr. Les classes de visibilité n'ont pas le même degré d'in�uence ou d'importance sur leprocessus d'ordonnancement ou placement. La classe visible renseigne ce processus mieuxque celle de l'horizon et cette dernière apporte plus d'informations que celle de l'au-delàde l'horizon et en dernier celle l'invisible qui est loin d'être intégrée dans le processus dela prise de décision. Donc, nous allons associer à chaque classe un coe�cient (α, β, γ, θ)comme paramètre de l'importance et l'in�uence de la mise à jour de la classe courante.Alors la mise à jour globale de l'horizon est fonction linéaire des mises à jour des classesde visibilité pondérées par leurs coe�cients.

∆H∗(Tr) = α∆V (Tr) + β∆H(Tr) + γ∆F (Tr) + θ∆U(Tr)

En se basant sur cette formule, nous allons dé�nir nos heuristiques du modèle d'algorithmede l'ordonnancement et placement cités au début de ce chapitre. La première étapeconsiste dé�nir l'heuristique responsable de la sélection de la tâche à exécuter, ensuitecelle qui détermine le n÷ud à allouer à cette tâche et en�n la stratégie du placement desdonnées.

1- La tâche prête à choisir est celle qui va élargir au maximum l'horizon d'exécution∆H(Tr).

Ts = argMaxTr∈TR∆H∗(Tr)

2- Le n÷ud à choisir est celui qui va préserver la localité données ou à déjà exécuterles prédécesseurs de la tâche sélectionnée. Si le n÷ud du sous DAG contenant cettetâche contient une quantité de donnée utilisée par Ts dont le pourcentage dépasse un seuilprédé�ni alors on ne change pas la préférence de Ts et on reste sur le même n÷ud. Sinon

73

Figure 5.4: DAG avec plusieurs niveaux

Figure 5.5: Plateforme NUMA et stratégie de vol de travail

74

on cherche le n÷ud qui maximise la localité donnée pour Ts.

N (sT ) =

{SDN(T ), si getLDx(SDN(T ), T ) > DL_THRESHOLD

argMaxN∈N∗getLDx(N, T ), sinon

- La fonction getLocalityDistance : permet de calculer pour une tâche T sa distancede localité si elle est a�ecté au noeud N .- La fonction SDN : subDAGNode permet de déterminer le n÷ud sur lequel le sous DAGcontenant Ts est a�ecté (préférence).- Le seuil DL_THRESHOLD : pour décider si on reste sur le n÷ud de préférence ouon cherche une autre allocation- La fonction getLocalityDistance : quanti�er la localité des données pour la tâche Tssur le n÷ud choisi qui est une fonction de la matrice des distances et le placement courantdes données de Ts sur la plateforme.3- La mémoire sur laquelle on place les données pendant l'exécution. Pour cette �n,on utilise la stratégie A�nity_on_�rst_Touch dans sa forme la plus simple sansmigration ni modi�cation. c.-à-d. l'allocation de la mémoire pour une requête d'allocationfaite par Ts pendant son exécution sera demandée de la mémoire de son n÷ud.

5.4 Equilibrage de charge

Dans cette phase, un mécanisme classique du vol de travail adapté au contexte NUMqui sera responsable d'équilibrer la charge des entités du support exécutif.

5.4.1 Vol de travail basé sur distance et adaptatif

Algorithme 8 vol de travail adaptatif basé sur la distance NUMA a comme entrée lesparamètres suivants :ICNdx : La matrice des distances entre les n÷uds NUMA. Elle représente les poidsassocies aux liens du réseau d'interconnexion connectant les n÷uds de la plateforme.Step : C'est un paramètre qui représente l'écart entre les distances successivement parcourues.Try : Le nombre de tentatives pour passer à une distance supérieure.

Cet algorithme suit la stratégie du vol de travail classique où chaque thread (worker)qui représente un c÷ur à lequel est associé un ensemble de tâches à exécuter. Chaqueworker a une queue associe.Les étapes :1- Chaque worker inspecte la taille de sa queue si elle est supérieure à MAX alors ilchange son état à V ICTIM en donnant la possibilité aux autres workers de voler destâches de sa propre queue. par contre si sa queue est vide alors il passe à état THIEF ouil essaye de voler des tâches des autres workers qui sont dans un état V ICTIM . sinon saqueue contient déjà des tâches à exécuter alors il dépile sa queue de l'avant et commenceà exécuter la tâche courante et puis il met à jour son état en inspectant la taille de saqueue si elle est passé au dessous de MIN alors il change son état à THIEF .

Lors du changement de son état à THIEF , le worker lance le processus du vol detravail Dans le contexte de NUMA et dans cette variante du vol de travail, l'heuristiqueconçue est basée sur la matrice distance de NUMA et une distance limite à ne pas

75

Algorithme 8 : Vol de travail adaptatif basé sur la distanceinput : ICNdx : Matrix-distance des n÷uds NUMA, Paramètres Step :

incrément de distance, Try : Nombre de tentative de volsoutput : system load balancing state

begin/* change the state of the current worker */

if localTaskQueue.size == THRESHOLD_MAX_SIZE thencurrentWorker.status = VICTIM

if isEmpty(localTaskQueue) thencurrentWorker.status = THIEF

elserun : popAtFront(localTaskQueue, task)execute(task)if localTaskQueue.size == THRESHOLD_MIN_SIZE then

currentWorker.status = THIEF

if currentWorker.status == THIEF thendx = SteptheftSuccess = falsecount = Trywhile !theftSuccess and dx < DX_LIMIT do

for i =0 to count-1 dotaskQueue = searchForVictimQueueLessFar(dx, ICNdx)task = taskQueue.popAtRear()if !isNull(task) then

theftSuccess = truelocalTaskQueue.pushAtRear(task)goto run

elseif count > 1 then wait()

dx = dx + Stepif count > 1 then count = count - 1

76

dépasser LIMITE car la pénalité de la recherche au-delà de cette distance devient assezimportante. Cette stratégie commence par les n÷uds voisins loin par une distance dxspéci�ée comme paramètre et si la tentative de vol réussit alors il continue ce processuspour sortir de son état THIEF et revenir à l'état NORMAL. Par contre si à un momentdonné aucun voisin n'est dans un état de V ICTIM alors le worker courant doit voir desn÷uds qui sont loin par distance 2dx et il recommence de nouveau la tentative de vol à ceniveau et il continue comme ça jusqu' à ce qu'il revient à son état NORMAL ou il restesur son état THIEF après avoir fait une tentative de vol et ne trouver aucun V ICTIM .

Le code suivant représente le résultat de l'exécution de la commande NUMA sur lesystème linux numactl �hardware qui donne la topologie et en particulier la matricedes distances NUMA.

// command on NUMA enabled Linux to find out SLIT values provided by BIOS

numactl --hardware

//NUMA SLIT Matrix on 16 Nodes system used for testing -

node distances:

node 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0: 10 13 40 40 62 62 55 55 62 62 55 55 62 62 55 55

1: 13 10 40 40 62 62 55 55 62 62 55 55 62 62 55 55

2: 40 40 10 13 55 55 48 48 55 55 48 48 55 55 48 48

3: 40 40 13 10 55 55 48 48 55 55 48 48 55 55 48 48

4: 62 62 55 55 10 13 40 40 62 62 55 55 62 62 55 55

5: 62 62 55 55 13 10 40 40 62 62 55 55 62 62 55 55

6: 55 55 48 48 40 40 10 13 55 55 48 48 55 55 48 48

7: 55 55 48 48 40 40 13 10 55 55 48 48 55 55 48 48

8: 62 62 55 55 62 62 55 55 10 13 40 40 62 62 55 55

9: 62 62 55 55 62 62 55 55 13 10 40 40 62 62 55 55

10: 55 55 48 48 55 55 48 48 40 40 10 13 55 55 48 48

11: 55 55 48 48 55 55 48 48 40 40 13 10 55 55 48 48

12: 62 62 55 55 62 62 55 55 62 62 55 55 10 13 40 40

13: 62 62 55 55 62 62 55 55 62 62 55 55 13 10 40 40

14: 55 55 48 48 55 55 48 48 55 55 48 48 40 40 10 13

15: 55 55 48 48 55 55 48 48 55 55 48 48 40 40 13 10

77

5.5 Conclusion

Dans ce chapitre, nous avons présenté les heuristiques proposées dans cette thèse pourle problème étudié. Alors après une première tentative pour améliorer l'exécution desséquences de tâches indépendantes sur NUMA en combinant les paires des politiquesordonnancement/placement juste pour voir l'impact de cette combinaison sur les perfor-mances de deux processus. Dans un premier temps, nous avons exposé les idées de basede l'heuristique de l'horizon d'exécution étendu pour exécuter les tâches d'un DAG etdonné l'algorithme de cette approche. Cette stratégie vise à collecter plus d'informationsau processus d'ordonnancement en élargissant l'horizon d'exécution pour avoir une idéedes prochaines tâches à exécuter. La décision de l'ordonnancement est basée sur cettemétrique en choisissant la tâche qui va élargir le champ de visibilité de notre processusen aidant à mieux explorer le DAG à ordonnancer.

Ensuite, nous avons présenté la deuxième approche le vol de travail basé sur la distancequi est une adaptation de la stratégie du vol de travail conçu pour les multicores etvariante pour la plateforme NUMA dont le but d'équilibrer la charge des n÷uds. Cettestratégie tient en compte l'information collectée au début sur la plateforme (extraction dela topologie de l'environnement d'exécution et sa matrice de distance). Elle vise à limiterle champ du vol à une certaine distance, un certain nombre de fois si cela ne réussit pasalors elle va augmenter cette distance et voir. Par ce principe, elle favorise les n÷uds quisont proches et elle évite les n÷uds ou la pénalité NUMA est importante (en fonction dela distance entre les deux n÷uds concernés).

Le chapitre suivant constitue le cadre général pour expérimenter (en simulant), évalueret tester l'apport des ces heuristiques dans le contexte de NUMA pour le problème étudié.

78

Chapitre 6

Simulation et Analyse des résultats

Dans la première partie de ce chapitre, nous allons présenter en détail le simulateurconçu pour jouer les diverses politiques concernant les deux fonctions importantes pourune plateforme NUMA, ordonnancer les threads et placer les données. Ensuite, plusieursscenarios d'évaluation des diverses métriques des politiques intégrant les heuristiquesproposées sont simulés pour voir l'impact et l'e�cacité de cette modi�cation (approchesproposées) sur l'exécution des applications parallèles à base de tâches soit indépendantesou dépendantes (décrites par un DAG). Ensuite une partie complémentaire pour testerl'approche proposée pour équilibrer la charge en utilisant une variante du vol de travailadapté à NUMA.

Dans la section 6.1, nous présentons le simulateur utilisé par la suite et son architec-ture. Ensuite, l'expérimentation en combinant les politiques des deux processus ordonnan-cement et placement sur les tâches indépendantes est détaillée dans la section 6.2 suivie paranalyse des résultats obtenus pour les scénarios joués. Dans la section 6.3, l'expérimentationdes heuristiques proposées dans le chapitre précédent sur tâches dépendantes représentéspar DAG au format STG. Les résultats de ces scénarios seront analysés et commentésdans cette même section. La dernière idée proposée concernant équilibrage de charge parle vol de travail basé sur la distance et adapté à NUMA est testé dans cette section 6.4suivie par l'analyse de ces résultats. En�n dans la section 6.5, nous concluons ce chapitre.

6.1 Simulateur NUMA (HLSMN)

La simulation devient un outil important pour l'informatique scienti�que pour construi-re et concevoir un modèle avant la phase de production. Les systèmes embarqués etl'architecture informatique deviennent le domaine où cette approche est utilisée de manièreintensive pour éviter les problèmes de conception ou pour l'améliorer. Les plateformesNUMA sont assez compliquées et diversi�ées (architecture, con�guration) alors pourconcevoir une politique spéci�que à cette plateforme et générique à ses variantes et latester sur plusieurs architectures cible, la simulation est une bonne solution avec un coûtacceptable.

79

6.1.1 Etat de l'art des simulateurs Multicoeurs NUMA

Plusieurs simulateurs génériques adaptés au système multiprocesseurs et multicoeursont été développés. Comme exemple, on peut citer Simics, [MCE02], GEMS, [MSB05]et M5, [BDH06] permettant de concevoir et tester ces systèmes avant leur conceptionconcrète et leur production. Des simulateurs dédiés à des architectures spéci�ques ontégalement été développés. Par exemple, des outils pour la mémoire partagée, multicoeurs,manycore et NUMA architecture qui incluent un composant spéci�que qui expose lesprincipales fonctionnalités de ces sous systèmes.

RSIM (Rice Simulator for ILP Multiprocessors)C'est un simulateur de bas niveau piloté par exécution pour les systèmes multiprocesseursavec cc-NUMA basé sur un répertoire. Il met l'accent sur la précision et il simule unmécanisme de cohérence du cache réseau et un cache basé sur les répertoires. [PRA97 ;Hug+02].

SIMTC'est un outil de simulation pour les machines NUMA qui repose sur un autre outilAugmint [Ngu+96] pour fournir des données de référence de mémoire et se concentreprincipalement sur la hiérarchie de la mémoire, telles que les erreurs de cache et lesinvalidations de cache. Il ignore les réseaux d'interconnexion utilisant des constantescomme latences de communication et un temps estimé pour modéliser le temps d'exécutiondes instructions [TSK05].

GraphiteC'est un simulateur parallèle Open Source, distribué pour le laboratoire des architecturesmultidimensionnelles du MIT, il est conçu de manière à explorer les futurs processeursmultic÷urs contenant des dizaines, de centaines, voire des milliers de noyaux. Il est capabled'accélérer les simulations en les distribuant sur plusieurs machines Linux de commodité.[MK09]

SimNUMAC'est un simulateur de système complet piloté par exécution dédié aux systèmes d'architec-ture NUMA. Ses principales caractéristiques comprennent : l'utilisation du même typede processeur avec la machine cible dans le système hôte et une nouvelle méthode pourcapturer et simuler des accès à la mémoire distante. Il modélise les di�érents types deréseaux d'interconnexion. [LZ13]

AutresIl existe des simulateurs plus spéci�ques dédiés à un module, une fonctionnalité ouune modélisation de certains aspects de la plate-forme NUMA tel que la simulation deprotocole de cohérence de cache ou modélisation de performance. SICOSYS [PGB02] quiest un framework intégré pour évaluer les performances du réseau d'interconnexion. C'estun simulateur de réseau d'interconnexion à usage général. Memphis [CJ10] est un outilpour trouver et améliorer les problèmes de performance liés à NUMA sur les plateformesmultic÷ur.

6.1.2 Architecture et Conception du simulateur HLSMN

La plupart des simulateurs cités sont de bas niveau modélisent les éléments de basede ces systèmes et se concentrent sur la structure interne et le processus d'exécution

80

d'instructions en plus de détails (architecture matérielle). Cet aspect rend le processusde simulation plus complexe et di�cile à manipuler des politiques de haut niveau tellesque l'ordonnancement des threads et le placement de données. Un simulateur de haut

Figure 6.1: NUMA object model structure a- interne b- Arborescence de la topologie

niveau pour les plateformes multicoeur NUMA (Hihg Level Simulator of Multicore NUMAHLSMN) a été conçu. Sa conception est faite de telle façon qu'elle expose les fonctionnalitésde base de la machine MC-NUMA. Sa structure interne est constituée de plusieurscomposants interconnectés en fonction de la topologie de la machine cible. Le schémadonné par la �gure 6.1 représente cette conception.

Figure 6.2: Architecture du simulateur HLSMN

81

Modèle objet NUMA

Ce modèle est inspiré de l'outil Xml DTD de Hwloc. Nous e�ectuons le processusinverse de Hwloc, ces outils génèrent la description basée sur XML d'une plateformecible réelle à utiliser par l'ordonnanceur. Dans notre cas, nous allons prendre une telledescription et construire un modèle d'objet qui correspond à la plateforme cible. La �gure6.2 donne une représentation globale de l'architecture interne de ce simulateur. Le modèled'objet se compose de plusieurs modules, y compris :

- Machine : est le module principal à activer pour utiliser le modèle. Il connecte tousles autres modules de manière appropriée en fonction de la description de la topologie.

- HierarchicalNode : est une interface qui résume la structure hiérarchique de cetteplateforme. Comme la hiérarchie de la mémoire est structurée comme une arborescenceet elle est plus complexe dans NUMA, chaque élément de cette architecture est considérécomme un n÷ud dans cet arbre (bancs de mémoire, caches, noyau, ...) puis ils partagentles mêmes fonctionnalités d'entités connectées en arbre (accès root ou parent, énumérerla liste de n÷uds-�ls, noti�er la racine ou le parent, ...).

-NumaNode : c'est l'entité la plus importante dans la machine qui modélise l'élémentNUMA. Il sera connecté au réseau d'interconnexion et il se comportera seul comme entitéSMP.

- Socket : le package processeur contient les unités de calculs (c÷urs) et le reste dela hiérarchie mémoire de di�érents niveaux.

-Core : l'unité de calcul de base qui exécute les threads associés aux tâches d'application.

- Interconnexion : un réseau spécial pour connecter NumaNodes et router les messagesentre les di�érentes entités.

- Mémoire : unités de stockage associées à NumaNode. C'est le stockage local pource n÷ud associé avec une faible latence et une bande passante élevée, contrairement àd'autres n÷uds non directement connectés (n÷ud distant) où la latence est élevée et labande passante basse.

La �gure 6.2 (a) montre les principaux composants de cette partie et expose l'architecturede l'objet NUMAModèle de HLSMN avec ses composants principaux montrant la relationentre les classes dans le package NUMA. Chaque classe implémente l'interface HierarchicalNodeou étend une autre classe qui l'implémente, de sorte qu'elles héritent des mêmes propriétéset comportements. Sur la base de cette interface, nous pouvons identi�er les n÷uds-parents et les n÷uds-�ls dans la hiérarchie en appelant les fonctions getParent() etgetChildren() et en récupérant les objets de type HierarchicalNode.

Gestionnaire des topologies

Il est responsable du chargement de la topologie à simuler. Après avoir chargé correctementle �chier associé, il a�che la structure dans la visionneuse de topologie (6.2 (b)). Ensuite,en fonction de cette structure, il crée le modèle d'objet en instanciant un objet de typeMachine et en fait la racine de la hiérarchie. Chaque composant de la topologie possèdesa propre classe de représentation qui est initialisée et qui invoque une autre méthodepour créer des sous-éléments ou des enfants dans cet ordre :

82

Générateur de l'application

Pour exécuter di�érents scénarios de simulation, nous avons conçu un générateur desapplications modèles (Template). Sa tâche consiste à générer des tâches aléatoires enfonction du modèle donné. Le modèle d'application se compose de tâches dé�nies avec descaractéristiques de calcul et la communication doit représenter une classe d'applicationsparallèles réelles qui partagent un certain pro�l (application avec plus de calcul et moins decommunication ou communication intense) et spéci�e les données et le volume nécessairependant l'exécution. Selon ce modèle, ce module générera une instance d'application àtransmettre comme paramètre au modèle d'objet.

Noyau de simulation

Ce module est le c÷ur du simulateur. C'est le noyau qui est responsable de la gestiondes processus de simulation, de la synchronisation des événements et de la communicationentre les entités de simulation. Lors du démarrage du simulateur et après le chargement dela topologie et de la génération de tâches / données (instance), le module de con�gurationobtient divers types de paramètres sur la machine cible à partir du modèle d'objet, telque le nombre de processeurs, la taille de la mémoire, les paramètres d'interconnexiontels que le type, la topologie, la bande passante, la politique de routage, etc. et lastructure et les détails de l'instance d'application. Ce module essaie de jouer une politiqued'ordonnancement choisie sur l'instance donnée de l'application pour prendre les décisionsconcernant le temps début d'exécution et les n÷uds alloués. Ensuite, il mappe les donnéesassociées sur les mémoires de n÷ud en utilisant une autre politique de placement dedonnées choisie. En�n et lorsque les tâches sont prêtes à être exécutées sur la ressourcedisponible, l'exécution est lancée sur le n÷ud alloué et en a�ectant les données à lamémoire choisie. Il est basé sur la capture des événements survenus sur chaque objet dumodèle d'objet, le renvoi et la noti�cation des parties intéressées aux événements survenus.À mesure que les modules fonctionnent simultanément dans ses threads de travail (c÷urs,mémoires, interconnexions), il assure la synchronisation et la communication entre euxpour accéder aux ressources partagées (événements de �le d'attente, ...).

Comme il est important et critique dans le processus de simulation de garder l'historique,nous avons conçu avec le simulateur, un outil pour enregistrer la trace de la simulationet en collectant les statistiques.

83

6.2 Expérimentation tâches indépendantes

Le scénario de simulation spéci�que consiste à con�gurer les paramètres de l'enviro-nnement de simulation en spéci�ant la topologie cible, le modèle d'application pour créerune instance, en choisissant les stratégies d'ordonnancement et de placement à appliquersur les tâches et les données. Ensuite, nous lançons l'expérimentation en utilisant lesparamètres spéci�és. En�n, nous recueillons les résultats de cette simulation en enregistrantles événements. La dernière étape consiste à analyser les résultats obtenus.

6.2.1 Con�guration de la simulation

Cette étape consiste à dé�nir les informations de con�guration utilisées lors du processusde simulation. En combinant les di�érentes valeurs des paramètres, la con�guration obtenuecorrespond à un scénario d'expérimentation par la suite. Les paramètres les plus importantssont :

- Topologie cible : est dé�nie via le chargeur de topologie en fournissant le �chierde con�guration XML de cette topologie.

- Modèle d'application : il est spéci�é dans le générateur d'application en donnantle pro�l de l'application soumise. Ce générateur crée une instance avec le nombre spéci�éde tâches avec des données privées prédé�nies et selon le pro�l spéci�é.

- Politique ordonnancement/placement : spéci�er quelle stratégie à utiliser pourl'exécution en fonction des politiques/heuristiques implémentées (à évaluer et à tester).

6.2.2 Expérimentation des scénarios

Dans cette section, nous aborderons le processus d'expérimentation et d'évaluationde certains scénarios de simulation. Le scénario de simulation avec la topologie cible, lemodèle d'application des tâches indépendantes de grains de taille moyenne avec moinsde communication (opérations de données Read / Write faibles) et l'ordonnancement detype X avec Y comme stratégie de placement représente une expérience qui va mesurerl'impact de combiner ces deux stratégies sur la classe de l'application choisie. Aux �ns decette expérimentation, nous avons mis en ÷uvre :- Politiques d'ordonnancement : Round Robin (SRR) et Load Balanced (SLL)- Stratégies de placement : First Touch (PFT) et Round Robin Allocation (PRR)

Notre expérience consiste à tester toutes les politiques possibles d'ordonnancementet placement combinées avec deux modèles d'application T50 et T250 (la premièrecontient 50 tâches indépendantes avec ses 50 données associées et la seconde avec 250)cela nous donnera 8 di�érents scénarios [SRR, SLB] [PRR, PFT] [T50, T250].Et, par conséquent, nous sommes intéressés par le temps d'exécution total et le nombred'accès distant dans chaque scénario.

6.2.3 Analyse des Résultats

Nous présentons ici la moyenne des résultats après la répétition des expériences quicorrespondent à chaque scénario. D'abord une première expérimentation concernant la

84

métrique temps total d'exécution et puis nous montrerons une deuxième mesurant lapénalité NUMA.

Le tableau 6.1 donne le temps total d'exécution pour chaque scenario qui est graphique-ment représenté par La �gure 6.3.

Dans les scenarios de 50 tâches, les scenarios con�gurés avec le placement PFT (6.18,7.213) donnent un temps total d'exécution meilleur que celui du PRR (7.854, 11.372).Dans les scenarios de 250 tâches, toujours le placement PFT (21.877, 39.084) présentedes meilleurs résultats par rapport à l'autre stratégie PRR (25.799, 40.107). En comparantcette fois par rapport à la stratégie d'ordonnancement, nous observons que la politiqueSRR n'a pas pu dépasser sa concurrente en donnant un temps total d'exécution (25.799,40.107) nettement supérieur à celui de SLL (21.877, 39.084).

Le fait de mapper les données d'une tâche selon la stratégie PFT (sur la mémoire dun÷ud sur lequel elle tourne), cette décision a in�uencé son temps total d'exécution parrapport PRR (de distribuer les données à tour de rôle sur les mémoires des n÷uds de laplateforme). Cela est peut-être dû à un nombre d'accès moins important que celui de PRRpuisque chaque tâche charge ses données dans sa mémoire locale si elle est la première à yaccéder. Alors ce facteur a réduit la communication distante donc il a permis de terminertôt la tâche et en conséquence de donner un temps total d'exécution inférieur par rapportla distribution RR qui ne tient pas en compte la source de la requête d'allocation mémoire(quelle tâche a demandé cette donnée). C'est pourquoi il va générer plus de communicationdistante donc retarder la terminaison de la tâche et donner un Cmax important.

Tasks/Policy PRR-SRR PRR-SLL PFT-SRR PFT-SLL

50 Tasks 7.854 11.372 6.18 7.213

250 Tasks 25.799 40.107 21.877 39.084

Table 6.1: Temps total d'exécution de chaque scénario 50/250 tâches

La �gure 6.4 montre graphiquement les accès distants aux données e�ectués par lestâches résidants sur les n÷uds de la plateforme. Comme prévu, Les 50 tâches ont unnombre d'accès distants moins important que les 250 tâches. En comparant maintenantentre les stratégies testées, le nombre des accès distant pour PRR-SRR et PFT-SRR estnettement inferieurs (moins de lignes colorées) à celui de PRR-SLL et PFT-SLL pour lesdeux scénarios. (La densité des lignes en vert et rouge est faible par rapport la densitédes lignes en bleu et jaune).

Ce scénario a donné un résultat qui n'était pas prévu puisque la politique PFT s'estcomportée comme l'autre politique PRR en générant un nombre similaire d'accès distantmalgré qu'elle charge les données dans la mémoire locale de la tâche demandeuse. Uneinterprétation possible est qu'il y a assez de tâches qui partagent la même donnée etpuisque il n'y a pas de migration de tâche alors la première qui demande la donnée ellel'obtient en local mais le reste doit faire une communication distante pour l'utiliser (enlecture ou écriture).

85

Figure 6.3: Temps total d'exécution pour chaque scénario (a) 50 tâches (b) 200 tâches

Figure 6.4: Trace des acces mémoire distants (a) 50 tâches (b) 200 tâches

6.3 Expérimentation tâches dépendantes DAG

Dans cette section nous allons expérimenter notre heuristique. Tout d'abord, unscenario d'expérimentation sur des applications parallèles de di�érente con�guration (DAGsdont le nombre de tâches et structures di�érentes) est réalisé en mesurant le temps totald'exécution sur des plateformes NUMA de di�érentes architectures. Ensuite le mêmescenario d'expérimentation est répété pour les même applications parallèles mais cettefois on s'intéresse à la pénalité NUMA.


A�n de con�gurer les scénarios de simulation, nous présentons les di�érentes rubriqueset les options à paramétrer :Topologie simulée :- Plateforme con�guration Nombre de n÷uds/c÷urs (xNyC)- Réseaux ICN : La matrice des distances entre les n÷uds est donnée comme paramètrede simulation.

86

Jeu de TestCe jeu de test est choisi parmi l'ensemble des DAGs au format STG [Lab16] qui constitueune référence pour le test des problèmes utilisant des DAGs. Le format STG a été enrichien ajoutant un champ appelé motif d'accès mémoire spéci�que pour les architecturesNUMA. Le listing suivant donne un exemple d'un DAG codé en STG avec l'extensionmotif d'accès. La notation utilisée est DAGXx ou Xx est le nombre de tâches du DAGutilisé (DAG50 contient 50 tâches).

//DAG050 au format STG de 50 Tâches et avec sa précédence

50

00 00 0 - S;0;20;R;1;50;W;0;30;E;1;0

01 09 1 0 S;2;30;R;3;20;W;2;50;E;3;0

02 04 1 0 S;4;50;R;5;30;W;4;20;E;5;0

03 03 1 0 S;6;20;R;7;50;W;6;30;E;7;0

04 06 1 0 S;0;20;R;1;50;W;0;30;E;1;0

05 04 1 1 S;2;30;R;3;20;W;2;50;E;3;0

06 03 1 5 S;4;50;R;5;30;W;4;20;E;5;0

07 03 1 0 S;6;20;R;7;50;W;6;30;E;7;0

08 08 1 6 S;0;20;R;1;50;W;0;30;E;1;0

09 09 1 0 S;2;30;R;3;20;W;2;50;E;3;0

10 02 3 2;6;8 S;4;50;R;5;30;W;4;20;E;5;0

11 01 1 9 S;6;20;R;7;50;W;6;30;E;7;0

12 10 1 0 S;0;20;R;1;50;W;0;30;E;1;0

........

Task.id Length Number of Prec Precedences Task Data access pattern

10 2 3 2 ;6 ;8 S ;4 ;50 ;R ;5 ;30 ;W ;4 ;20 ;E ;5 ;0

Table 6.2: Ligne tâche dans le �chier DAG au format STG étendu

Le DAG décrit par ce �chier a 50 tâches dont la tâche 0 est la tâche d'entrée, chaqueligne contient l'identi�ant de la tâche, sa longueur, le nombre de ses prédécesseurs,la liste de ses prédécesseurs et à la �n le champ supplémentaire pour le cas de NUMAou en spéci�ant le motifs d'accès aux données. Ce motif décrit le schéma d'exécutionde sa tâche, il commence avec S (start) en spéci�ant les données à charger ou lancementde la tâche ensuite le pourcentage des instructions exécuter par le c÷ur par rapportau nombre total des instructions de la tâche suivi par une communication soit lecture(READ/LOAD) ou écriture (WRITE/STORE) en spéci�ant la donnée concernéeet en�n l'étape de la �nalisation E (end) de l'exécution de la tâche en sauvegardant lesdonnées avant sa terminaison.Heuristiques simulés Ordonnancement- NXH : sur la plateforme NUMA sans Horizon d'exécution- WXH : sur la plateforme NUMA avec l'heuristique Horizon d'exécution X-VHFUPlacement- AoFT : A�nity-on-First-TouchMétriques mesurées- Cmax : Temps Total d'exécution- NR : Penalité NUMA

87


Nous allons réaliser deux scénarios qui ont la même con�guration d'expérimentation.L'objectif visé dans le premier est de mesurer le temps total d'exécution et dans ledeuxième sera la pénalité NUMA.Scenario 01 :La con�guration de ce scénario est la suivante :- PF : 8N2C, 4N4C, 8N1C, 4N2C, 2N4C, 2N2C- DAG : DAG25, DAG50, DAG75, DAG100, DAG125, DAG150- S/P : NXH, WXH / AoFT- Métrique mesurée : Temps Total d'exécutionScenario 02 :La con�guration de ce scénario est la suivante :- PF : 8N2C, 4N4C, 8N1C, 4N2C, 2N4C, 2N2C- DAG : DAG25, DAG50, DAG75, DAG100, DAG125, DAG150- S/P : NXH, WXH / AoFT- Métrique mesurée : Penalité NUMA


Scenario 01 :La �gure 6.5 donne un exemple d'une expérience e�ectuée en exécutant un DAG STGde 100 tâches sur une plateforme de 4 n÷uds et 2 c÷urs sur chaque n÷uds. La �gurereprésente le diagramme de GANT de l'exécution des tâches sur les c÷urs (Pi) desn÷uds de la plateforme. Nous pouvons voir l'a�ectation de chaque tâche, sa date débutd'exécution, sa �n d'exécution et son temps d'exécution. Les contraintes de précédenceimposent la précédence et une synchronisation entre les tâches dépendantes (tâches �lleset mères) qui se manifestent comme un temps d'attente (de communication inter tâchesCi) de la terminaison des tâches précédentes pour lancer une tâche �lle. Cmax est le tempsmaximum enregistré par la dernière tâche du DAG pour �nir. La �gure 6.6 donne le Cmaxassocié à chaque DAG ordonnancé sur la plateforme cible. Il montre que pour les DAGsqui ont plus de 100 tâches le Cmax dépasse 200 unité temps sur toute les plateformes. Maispour les DAGs dont le nombre de tâches est inferieur à 75 cette valeur reste au dessousde 150 unités temps sur les plateformes testées.

Dans ce premier scénario, Les statistiques collectées concernent le temps total d'exécutionen fonction de la politique utilisée pour ordonnancer les tâches (en utilisant l'heuristiqueXH-VHFU ou non). La stratégie XH est basé sur le principe de la sélection de la tâcheà exécuter qui va élargir l'horizon d'exécution après sa sélection, par contre la stratégieclassique sélectionne la première qui est en-tête de la liste de tâches prêtes.

La �gure 6.7 donne les détails de l'expérimentation du scénario courant dont lamétrique mesurée est le temps total d'exécution pour l'ensemble des DAGs pour les deuxcas avec activation XH ou non. En fonction de chaque DAG,

- DAG25 : 4 cas sur 6 que les tests avec XH activé dépassent ceux sans XH avec unemoyenne d'écart de 4 % et les valeurs des deux tests s'étalent sur la plage 55 à 88.- DAG50 : 5 cas sur 6 que les tests avec XH activé dépassent ceux sans XH avec une

88

Figure 6.5: Diagramme GANT résultat de l'exécution d'un scénario

Figure 6.6: Scénario d'expérimentation pour mesurer Cmax

moyenne d'écart de 6 % et les valeurs des deux tests s'étalent sur la plage 75 à 112.- DAG75 : 5 cas sur 6 que les tests avec XH activé donnent des valeurs supérieures auxvaleurs du tests ans XH avec une moyenne d'écart de 7% et les valeurs des deux testss'étalent sur la plage 110 à 180.- DAG100 : 5 cas sur 6 que les tests sans XH activé dépassent ceux avec XH avec un écartfaible dont la moyenne est -3 % et les valeurs des deux tests s'étalent sur la plage 190 à290.- DAG125 : 5 cas sur 6 que les tests avec XH activé dépassent ceux sans XH avec unemoyenne d'écart de 4% et les valeurs des deux tests s'étalent sur la plage 215 à 355.- DAG150 : 4 cas sur 6 que les tests avec XH activé dépassent ceux sans XH avec unemoyenne d'écart de 3 % et les valeurs des deux tests s'étalent sur la plage 255 à 360.

Les résultats présentés montrent que l'intégration de heuristique XH a donnée dansla plupart des cas (en moyenne 4 cas sur 6) des écart positif en améliorant le temps total

89

Figure 6.7: Temps total d'exécution mesuré pour le scénario joué

d'exécution entre 3% à 6% en moyenne par rapport à la stratégie normale. La découvertede l'horizon au fur et a mesure de l'avancement du processus de l'ordonnancement permetde guider le processus de la prise de décision pour sélectionner la tâches courante àexécuter en exploitant les informations de la visibilité des tâches non encore exécutées enrécompensant le manque de l'information concernant la longueur de tâches et les donnéeset le volume échangés entre les tâches.Scenario 02 :Dans ce deuxième scénario, Les statistiques collectées concernent la pénalité NUMA (lerapport entre le nombre des accès distants par rapport le nombre des accès locaux, nousallons utiliser un facteur équivalent le pourcentage des accès distants par rapport aunombre total d'accès) en fonction de la politique utilisée pour ordonnancer les tâches(en utilisant l'heuristique XH-VHFU ou non). Lors de l'exécution du code d'une tâche,si l'instruction exécutée est un chargement/une sauvegarde (LOAD/STORE) alors unerequête qui correspond à cette opération est faite au système mémoire si la donnéesollicitée est sauvegardé dans la mémoire du n÷ud exécutant sa tâche alors c'est accèslocal. Le c÷ur exécutant adresse cette requête au contrôleur mémoire local qui se chargede récupérer la donnée. Par contre si l'emplacement est sur une mémoire distante alorsl'accès est distant.

Le tableau 6.3 donne le nombre des accès locaux et distants pour l'ensemble des DAGstestés et les valeurs de la pénalité associées pour la première option sans l'utilisation del'heuristique proposée. Pour la plateforme PF2N2C, la plage des valeurs enregistrées estentre 74% et 79%. Le deuxième tableau 6.4 utilise le même paramètre sauf que cette foisla politique con�gurée est l'heuristique XH-VHFU. Pour la même plateforme PF2N2C, laplage des valeurs enregistrée est entre 70% et 78%. Dans les deux cas, le nombre des accèsdistants dépasse 70% qui est un pourcentage élevé et un indicateur d'une mauvaise localitémalgré l'utilisation de la stratégie AoFT. La deuxième série de tests (avec heuristique) arelativement des valeurs inferieures à par rapport à la première série (sans heuristique),mais cette amélioration est minime et n'est pas signi�cative pour réduire l'impact de cettepénalité sur la performance système.

La �gure 6.8 donne Les détails de l'expérimentation du scénario courant dont lamétrique mesurée est la pénalité NUMA pour l'ensemble des DAGs pour les deux casavec activation XH ou non. En fonction de chaque plateforme,

- PF2N2C : 5 cas sur 6 que les tests avec XH activé dépassent ceux sans XH avec unemoyenne d'écart de 4 % et les valeurs des deux tests s'étalent sur la plage 70% à 78%.- PF2N4C : 4 cas sur 6 que les tests avec XH activé dépassent ceux sans XH avec unemoyenne d'écart de 2 % et les valeurs des deux tests s'étalent sur la plage 80% à 89%.- PF4N2C : 4 cas sur 6 que les tests avec XH activé donnent des valeurs légèrementsupérieure aux valeurs du tests ans XH avec une moyenne d'écart de -2 % car les deuxautre cas présentent un écart important et les valeurs des deux tests s'étalent sur la plage80% à 89%.- PF8N2C 3 cas sur 6 que les tests sans XH activé dépasse ceux avec XH avec un écartremarquable dont la moyenne est -3 % et les valeurs des deux tests s'étalent sur la plage82% à 92%.- PF8N1C 3 cas sur 6 que les tests avec XH activé dépassent ceux sans XH avec unemoyenne d'écart de 2 % et les valeurs des deux tests s'étalent sur la plage 82% à 89%.- PF4N4C 3 cas sur 6 que les tests avec XH activé dépassent ceux sans XH avec une

91

Access DAG25 DAG50 DAG75 DAG100 DAG125 DAG150

Local 25 54 64 108 110 161

Remote 83 154 243 300 398 447

Rate 77 74 79 74 78 74

Table 6.3: Pénalité NUMA pour chaque instance DAG sans XH-VHFU

Access DAG25 DAG50 DAG75 DAG100 DAG125 DAG150

Local 28 62 74 101 139 167

Remote 80 146 234 307 369 441

Rate 74 70 76 75 73 73

Table 6.4: Pénalité NUMA pour chaque instance DAG avec XH-VHFU

moyenne d'écart de 1 % et les valeurs des deux tests s'étalent sur la plage 82% à 91%.

Les résultats présentés montrent que l'impact de l'intégration de heuristique XH n'apas été signi�catif pour réduire le nombre d'accès distant certes dans 4 tests sur 6 elle acontribué à réduire cette pénalité mais cette réduction n'est pas su�sante vu que la plagedes valeurs reste très importante et l'écart trouvé relativement faible.

92

Figure 6.8: Pénalité NUMA mesuré pour scénario joué

6.4 Expérimentation Equilibrage de charge

Dans cette section nous allons expérimenter notre heuristique concernant l'équilib-rage de charge lors de l'exécution des tâches sur une plateforme NUMA. Dans un premiertemps, un scenario d'expérimentation con�guré sans option d'équilibrage de charge. Dansce scénario, une série de tâches est lancée sur une plateforme NUMA et durant le déroulem-ent de l'exécution nous allons collecter l'information sur la charge courante sur chaquen÷ud à la �n nous calculons la charge moyenne sur le système. Un deuxième scénario estcon�guré avec l'activation de l'option de l'équilibrage de charge en utilisant la stratégieproposée dans de cette thèse à savoir le vol de travail basé sur la distance et adapté àl'architecture NUMA.


La con�guration simulée est la suivante :- Topologie simulée : Plateforme con�guration Nombre de n÷uds/c÷urs (4N1C)- Jeu de Test : Une série de 1500 tâches- Heuristiques simulés Equilibrage de charge : sans /avec vol de travail basé sur ladistance- Métriques mesurées : La charge moyenne


Scenario 01

Dans ce scenario, l'expérimentation est faite sur une plateforme NUMA de quatren÷uds et un c÷ur pour chaque n÷ud avec 1500 tâches indépendantes en la paramétrantsans ou avec une stratégie de l'équilibrage de charge. Pour cette stratégie, nous avonstesté dreux variantes basées sur le vol de travail celle la classique (dont la sélection desvictimes est aléatoire) et celle l'adaptée à NUMA basée sur la distance. Le but de cetteexpérimentation est d'évaluer la charge instantanée au cours de l'exécution et sa chargemoyenne.1- Topologie simulée : 4N1C2- Jeu de Test : 1500 tâches3- Heuristiques simulés Equilibrage de charge : sans ou avec vol de travail (NWS,WWS)4- Métriques mesurées : AL la charge moyenne

Une série de test sur 1500 tâches est lancée en mesurant instantanément la charge surchaque n÷ud de la plateforme et à la �n nous calculons la charge moyenne.

Dans un premier temps, la stratégie de l'équilibrage de charge est désactivée.- Heuristiques simulés Equilibrage de charge : - NLB sans vol de travail

Ensuite un deuxième lot de test avec la même con�guration est lancé en utilisant levol de travail classique pour équilibrer la charge.- Heuristiques simulés Equilibrage de charge : - CWS avec vol de travail classique

En�n un troisième lot de test avec la même con�guration est lancé mais cette fois en

94

Figure 6.9: Charge instantanée des n÷uds avec/sans vol de travail adapté NUMA

activant l'équilibrage de charge utilisant l'heuristique vol de travail basée sur la distanceadaptée à NUMA.3- Heuristiques simulés Equilibrage de charge : - dbANWS avec vol de travail AdaptéNUMA basé sur la distance

L'évolution de la charge instantanée sur les n÷uds correspond à ce scénario estprésentée par la �gure 6.9. Le cas A représente le scénario sans l'utilisation du vol detravail et le cas B active cette option la variante basé sur la distance adaptée NUMA.


La �gure 6.10 représente l'évolution de la charge moyenne des n÷uds de la plateformeNUMA. La partie A concerne les tests sans équilibrer la charge. Dans la partie B, le vol detravail classique est utilisé comme stratégie pour équilibrer la charge, et la dernière partieC, nous avons remplacé la stratégie vol de travail classique par notre variante adaptéeNUMA.

Figure 6.10: Charge moyenne de la plateforme NUMA 4 noeuds

Dans ce scénario, les statistiques collectées concernent la charge sur les noeuds en fonctionde la politique d'équilibrage de charge utilisée (sans vol de travail, avec vol travail aléatoire

95

et avec vol travail adapté NUMA). Apres la soumission d'un lot de taches à un ordonnanceurà exécuter, nous avons enregistré la charge instantanée sur chaque noeud. Selon la �gure6.9, l'évolution de la charge sur les noeuds s'est accelérée pour atteindre un pic maximumde 70 taches et un pic minimum de 50 taches pour le cas sans utilisation de vol de travail.Par contre, lorsque nous avons activé cette option un pic maximum 52 taches et minimumde 28 taches ont été enregistré. Nous constatons que cette option a redistribué la chargede la plateforme en évitant une surcharge sur les noeuds au meme moment. La �gure6.10 montre que les charges moyennes enregistrées avec les deux premieres strategies sontpresque similaires dont l'évolution est croissante jusqu'à un pic maximum de 50 taches.Par contre, la stratégie vol de travail basé sur la distance a donné une charge moyenne plusstable et beaucoup plus inferieure que la précedente. Avec un pic de 35 taches maximumet répartiton temporelle accepatble. Une amélioration moyenne de la charge de 15% (picmaximum).

96

6.5 Conclusion

Dans ce chapitre, nous avons conçu et mis en ÷uvre HLSMN un simulateur de hautniveau de plateforme multicouches NUMA qui nous permet de nous concentrer sur l'aspectalgorithmique des politiques et de masquer les détails de bas niveau. HLSMN expose lemodèle NUMA avec la hiérarchie des n÷uds, des interconnexions et des mémoires, permetd'implémenter et de tester di�érentes politiques d'ordonnancement et de placement dedonnées, d'exécuter des processus de simulation et de générer les statistiques concernantl'exécution des applications à base des tâches (le temps d'exécution total des tâches et lapénalité NUMA comme facteurs les plus importants dans un tel contexte).

Sur la base de ces facteurs, nous avons utilisé ce simulateur pour mesurer l'impactde la combinaison des di�érentes stratégies d'ordonnancement et de placement (roundrobin et �rst touch, ...) des tâches indépendantes de la performance globale du systèmeen terme de temps d'exécution total et de nombre de mémoire d'accès à distance.

La deuxième partie est consacrée au test et validation de nos heuristiques proposées,Pour le premier lot des scénarios pour expérimenter l'horizon d'exécution étendu, nousavons choisit une série de DAG de taille et structure di�érentes et nous avons simulé leprocessus de l'ordonnancement sur des plateformes de topologie di�érente a�n de mesurerle gain de cette approche en fonction des métrique classique le temps total d'exécutionet la pénalité NUMA. Pour la première métrique, l'horizon d'exécution étendu a donnéun Cmax inférieur à celui de l'approche ordinaire mais malheureusement ces résultatssont relativement faibles (ne dépassent pas 10%) dans la plus part des scénarios. Pour ladeuxième métrique, l'horizon d'exécution étendu n'a pas pu améliorer la pénalité NUMAen donnant un taux NUMA presque similaire à celui de l'approche ordinaire pour la pluspart des scénarios.

Pour le deuxième lot des scénarios pour expérimenter le vol de travail basé sur ladistance, nous avons soumis à cet algorithme un lot de tâches (plus de 1000 tâchesindépendantes) et nous avons simulé l'exécution des tâches sur des plateformes de topologiedi�érente a�n de mesurer le gain de cette approche en fonction des métrique classiquela charge des n÷uds. Pour cette métrique, le vol de travail basé sur la distance a donnéun bon écart en améliorant la charge par rapport celle des approches ordinaire (sanséquilibrage de charge) ou celle en utilisant le vol de travail aléatoire. Ces résultats sontrelativement bons (dépassent 15% en moyenne).

97

Chapitre 7

Conclusion et perspectives

Dans le cadre de cette thèse, nous avons étudié le problème de l'ordonnancementdes applications parallèles décrites par un graphe de tâches DAG qui s'exécutent sur laplateforme à accès mémoire non uniforme NUMA dont les tâches partagent et échangentdes données. En plus de l'aspect ordonnanccement des tâches et l'allocation de processeurs/ coeurs aux tâches, un deuxieme aspect qui se manifeste dans ce contexte est le placementdes données des tâches sur les mémoires des noeuds puisque la cible est non unforme etasymmétrique pour l'opération des accès mémoire. Cette asymmétrie qui se manifeste parun temps d'accès mémoire di�erent et non néglegeable pour les données d'une tâches quirésident sur une mémoire d'un noeud di�érent de celui sur lequel la tâche tourne.

Cet ordonnancement et placement dynamique nous imposent une connaissance impar-faite des conditions d'exécution (nous ne connaissons pas la durée de chaque tâches, levolume exacte des données échangées, certains paramètres de la plateforme d'exécution).En pratique, ce manque d'informations a�aiblit fortement les performances des di�érentsalgorithmes envisageables. Nous avons cherché à travers notre travail à tirer parti de lamoindre information disponible pour réduire l'impact de la pénalité NUMA au maximum.A�n de réaliser ces objectifs, nous avons proposé des heuristiques qui visent à améliorerces deux processus dans ce contexte.

La première idée était de collecter, au début de l'exécution, plus d'informations prove-nant de l'application parallèle à exécuter et de la plateforme cible et d'utiliser cetteinformation pour guider le processus de l'ordonnancement et le placement (la structureDAG de l'application, la topologie de la plateforme,..). A chaque instant ou un évenementse produit en changeant l'état d'exécution (le début/la �n de l'exécution d'une tâche,déclencher un accès mémoire (R/W),..), l'information collectée est mis à jour.

7.1 Résultats

Nous avons réalisé un ensemble d'expériences testant les algorithmes proposés viala simulation. Nous avons mis en évidence la réduction de la pénalite NUMA qui setraduit e�ectivement par une amélioration des temps total d'exécution. En�n, nous avonsmontré que l'utilisation de vol de travail basé sur la distance permet réellement d'étendrele champs d'application du vol de travail aléatoire vers des platesformes hiérarchiqueNUMA.

Le premier lot d'expériences, c'était l'ordonnancement des tâches indépendantes en

98

combinant les politiques ordonnancement et placement classiques juste pour mesurerl'é�et de cette combinaison sur la pénalité NUMA et son impact sur le temps totald'exécution. Ces expériences réalisées montrent que certaines combinaison aident à amélio-rer la premiere métrique Cmax par contre elle échoue à réduire la pénalite (le cas FFLB)et l'inverse pour d'autres cas (RRFT).

Le deuxieme scénario est de tester et valider nos propres heuristiques. Notre travailde simulation se divise en deux parties.- La première tente d'évaluer l'heuristique horizon d'exécution étendu sur un DAG ;- La seconde quant à elle tente de valider le vol de travail basé sur la distance.

Nous avons pu exploiter certaines informations collectées à di�érents niveau pourguider le processus de l'ordonnancement placement dans le contexte NUMA.

L'heuristique de l'horizon d'exécution a été expérimentée sur plusieurs DAG et desplateformes di�érentes. Les résultats obtenus montrent que l'integration de heuristiqueXH a donné dans la plupart des cas des écarts positifs en améliorant le temps totald'éxecution jusqu'à 6% en moyenne par rapport la strategie normale. Par contre, Lesresultats présentés pour la métrique NUMA ratio montrent que l'impact de l'intégrationde l'heuristique XH n'a pas été signi�catif pour réduire le nombre d'accès distant malgréque dans la plupart des tests, elle a contribué à réduire cette pénalité mais cette réductionn'etait pas su�sante vu que la plage des valeurs reste très importante et l'écart trouvérelativement faible.

L'heuristique du vol de travail basé sur la distance dont l'idée est de faire des tentativesde vol en commencant d'abord par les plus proches voisins qui sont loin du noeud voleurd'une certaine distance si cette tentative reussit alors le voleur continue son travailordinnaire sinon il va chercher ailleurs chez des voisins distants en se limitant à unedistance supérieure à la précédente. s'il y des tâches à volées alors il le fait et il reprend sontravail. Sinon il refait le meme processus en incrémentant la distance jusqu'à la reussite dela tentative ou l'atteinte de la distance maximale. Cette heuristique a été testée avec unesérie de tâches (plus de 1400) et sur une plateforme NUMA de con�guration moyenne. Ellea donné des bons résultats par rapport l'algorithme brut sans mécanisme d'équilibrage decharge et par rappport l'approche utilisant le vol de travail classique basé sur la sélectionaléatoire de la tâche à voler. En moyenne, cette stratégie a pu réduire la charge à 20%(les valeurs mesurées en moyenne n'ont pas dépassé le pic 50 tâches par noeud par contreles deux autres ont atteint un pic de 70 tâches) en comparant avec les deux autres avecun faible écart par rapport les seuils �xés pour l'état V ICTIM et THIEF au cours del'exécution. Une charge stable et équilibrée contribue à réduire le temps total d'exécutionde l'ensemble des tâches et à gagner en accelération pour l'application parallèlle.

Nous avons également montré, en simulant le vol de travail adapté à NUMA, quecette technique peut contribuer à réduire l'impact NUMA sur les applications parallèlesen équilibrant la charge sur les n÷uds de la plateforme.

7.2 Limites

Comme tout travail de recherche, certainement cette thèse a des limites :

- Certes que la simulation est un moyen limité pour valider et juger objectivement lesrésultats d'une recherche mais elle reste un outil à faible coût qui permet de tester les idées

99

et de les ra�ner avant d'appliquer cela à un système réel ou de production (minimiser lesrisques).

- Nous avons évalué nos heuristiques sur un jeu de test synthetique (DAG formatSTG enrichi avec l'information du partage des données). Bien que cette méthode n'estpas su�sante à elle seule pour donner des resultats proches de la réalité.

- Manque d'une validation statistique des résultats de la simulation.

7.3 Perspectives

Les principales perspectives de recherche qui apparaissent à l'issue de cette thèseconcernent la continuité de notre travail. Elles sont de plusieurs ordres.

- À plus court terme et pour valider résultats obtenus par simulations, nous pouvonsenvisager d'implementer ces heuristiques dans un ordonnannceur d'un systeme d'exploita-tion réel tel que linux et tester cela sur une machine NUMA et cluster NUMA avec desapplications parallèles réelles a�n de voir l'apport de ces heuristiques.

- À moyen terme, L'ajout d'autres aspects comme la migration des tâches, le routagedes réseaux d'interconnexion, etc peut etre considéré. Ainsi que l'amélioration du simulateur,en faisant intégrer la cohérence au cache.

- A�n de modéliser les aspects rencontrés dans ce travail, il serait envisageable de faireune analyse théorique surtout pour le vol de travail basé sur la distance.

Au �nal, nous espérons avoir montré, à travers nos travaux, que d'une part l'aspectasymmétrique des plateformes NUMA ne pose pas un probleme très contraignant pourles applications déja dévelopées pour UMA pour sa portabilité. d'autre part, l'absenced'informations (volume de données échangées, la durée des tâches,...) lors de l'ordonnance-ment/placement d'applications parallèle à base de tâches décrite par un DAG n'est pasforcément une des contraintes insurmontables.

100

References

[ABB00] Umut A. Acar, Guy E. Blelloch et Robert D. Blumofe. �The DataLocality of Work Stealing�. In : Proc. 2000 ACM Symposium on ParallelAlgorithms and Architectures (SPAA). 2000, p. 1-12.

[ALL89] Thomas E. Anderson, Edward D. Lazowska et Henry M. Levy. �ThePerformance Implications of Thread Management Alternatives for Shared-Memory Multiprocessors�. In : IEEE Transactions on Computers 38.12 (déc.1989), p. 1631-1644.

[Amd] AMD HyperTransport Technology. url : http://www.amd.com/uk/products/technologies / hypertransport - technology / Pages / hypertransport -

technology.aspx.

[AP11] Albert Cohen Antoniu Pop. �A stream-computing extension to OpenMP�.In : Proceedings of the 6th International Conference on High Performanceand Embedded Architectures and Compilers. New York, USA, ACM, 2011,p. 5-14.

[Asc+11] Markus Aschinger et al. �Optimization Methods for the Partner UnitsProblem�. In : Proceedings of the 8th International Conference on Integrationof Arti�cial Intelligence and Operations Research Techniques in ConstraintProgramming for Combinatorial Optimization Problems (CPAIOR 2011) . LectureNotes in Computer Science. Berlin, Germany, 2011.

[BDH06] N. L. Binkert, R. G.Dreslinski et L.R.Hsu. �The M5 Simulator : ModelingNetworked Systems�. In : IEEE Micro 26.4 (2006), p. 52-60.

[BL99] Robert D. Blumofe et Charles E. Leiserson. �Scheduling MultithreadedComputations by Work Stealing�. In : J. ACM 46.5. 1999, 720�748. url :http://doi.acm.org/10.1145/324133.324234 .

[Blu+95] Robert D. Blumofe et al. �Cilk : An E�cient Multithreaded Runtime System�.In : Proceedings of the Fifth ACM SIGPLAN Symposium on Principles andPractice of Parallel Programming. PPOPP '95. Santa Barbara, California,USA, 1995, p. 207-216. isbn : 0-89791-700-6. url : http://doi.acm.org/10.1145/209936.209958.

[Blu+96] Robert D. Blumofe et al. �An Analysis of Dag-Consistent Distributed Shared-Memory Algorithms�. In : Proceedings of the Eighth Annual ACM Symposiumon Parallel Algorithms and Architectures (SPAA). Padua, Italy, juin 1996.

[Boa01] OpenMP Architecture Review Board.OpenMP Application Program InterfaceVersion 3.1. 20011.

101

http://www.amd.com/uk/products/technologies/hypertransport-technology/Pages/hypertransport-technology.aspx



http://doi.acm.org/10.1145/324133.324234

http://doi.acm.org/10.1145/209936.209958

http://doi.acm.org/10.1145/209936.209958

[Boa08] OpenMP Architecture Review Board.OpenMP Application Program InterfaceVersion 3.0. 2008.

[Boa13] OpenMP Architecture Review Board.OpenMP Application Program InterfaceVersion 4.0. 2013. url : http://www.openmp.org/wp-content/uploads/OpenMP4.0.0.pdf.

[Bro+09] François Broquedis et al. �Dynamic Task and Data Placement over NUMAArchitectures : an OpenMP Runtime Perspective�. In : Evolving OpenMPin an Age of Extreme Parallelism, 5th International Workshop on OpenMP,IWOMP 2009. Sous la dir. de Barbara Chapman Matthias S. Muller

Bronis R. de Supinski. T. 5568. Lecture Notes in Computer Science. Dresden,Germany : Springer, 2009, p. 79-92. url : http://hal.inria.fr/inria-00367570.

[Bro+10] François Broquedis et al. �hwloc : a Generic Framework for ManagingHardware A�nities in HPC Applications�. In : PDP 2010 - The 18th EuromicroInternational Conference on Parallel, Distributed and Network-Based Computing .Sous la dir. d'IEEE. Pisa, Italie, fév. 2010.

[CGG14] Quan Chen, Minyi Guo et Haibing Guan. �Laws : Locality-aware work-stealing for multisocket multi-core architectures�. In : Proceedings of the 28thACM International Conference on Supercomputing, ICS '14 . New York, NY,USA : ACM, 2014, p. 3-12.

[CGH12] Quan Chen, Minyi Guo et Zhiyi Huang. �CATS : Cache aware task-stealingbased on online pro�ling in multi-socket multi-core architectures�. In : Proc.of the 26th ACM Intl. Conf. on Supercomputing, ICS '12 . New York, NY,USA : ACM, 2012, 163�172.

[Cha a] Alan Charlesworth. �The Sun Fireplane Interconnect�. In : Venray Technology(7August 2002), p. 36-45. url : http : / / www . venraytechnology . com /Papers/INTEL_TOMI_strategy2.htm.

[CJ10] M. Collin et V. Jeffrey. �Memphis : Finding and �xing NUMA-relatedperformance problems on multi-core platforms�. In : ISPASS. IEEE-PRESS,2010, p. 87-96. url : http://dx.doi.org/10.1109/ISPASS.2010.5452060 .

[cor13] IBM corp. Le serveur IBM Power 720 Express. IBM corp, 2013. url : http://avenue-e-solutions.com/sites/default/files/files/ibm_power_

720_express.pdf.

[CSG99] David E. Culler, Jaswinder Pal Singh et AnoopGupta. Parallel ComputerArchitecture : a Hardware/Software Approach. Morgan Kaufman, 1999.

[Das+13] Mohammad Dashti et al. �Tra�c management : A holistic approach tomemory placement on NUMA systems�. In : Proc. of the 18th Intl. Conf. onArchitectural Support for Programming Languages and Operating Systems,ASPLOS '13. New York, NY USA : ACM, 2013, 5381�394. url : http://hal.inria.fr/inria-00358172.

[DG04] Je�rey Dean et Sanjay Ghemawat. �MapReduce : Simpli�ed Data Processingon Large Clusters�. In : Proceedings of the 6th Conference on Symposiumon Opearting Systems Design & Implementation - Volume 6 . OSDI'04. SanFrancisco, CA : USENIX Association, 2004, p. 10-10. url : http://dl.acm.org/citation.cfm?id=1251254.1251264.

102

http://www.openmp.org/wp-content/uploads/OpenMP4.0.0.pdf

http://www.openmp.org/wp-content/uploads/OpenMP4.0.0.pdf

http://hal.inria.fr/inria-00367570


http://www.venraytechnology.com/Papers/INTEL_TOMI_strategy2.htm


http://dx.doi.org/10.1109/ISPASS.2010.5452060

http://avenue-e-solutions.com/sites/default/files/files/ibm_power_720_express.pdf





http://dl.acm.org/citation.cfm?id=1251254.1251264

http://dl.acm.org/citation.cfm?id=1251254.1251264

[Dre15] Andi Drebes. �Dynamic optimization of data-�ow task-parallel applicationsfor large-scale NUMA systems�. Thèse de doct. Paris, France : UniversitéPierre et Marie Curie, 2015.

[Dro07] Paul J. Drongowski. �Instruction-Based Sampling : A New PerformanceAnalysis Technique for AMD Family 10h Processors�. In : AMD, 2007.

[FBD12] Thierry Gautier François Broquedis et Vincent Danjean. LIBKOMP,an e�cient OpenMP runtime system for both fork-join and data �ow paradigms .Berlin, Heidelberg, Springer-Verlag, 2012, p. 102-115.

[Fisvea] Russell Fish. �The future of computers - Part 1 : Multicore and the MemoryWall�. In : EDN Network (November 17, 2011). url : http://www.edn.com/design/systems-design/4368705/The-future-of-computers--Part-1-

Multicore-and-the-Memory-Wall.

[Fisveb] Russell Fish. �Some Thoughts on INTEL�. In : Venray Technology (November29, 2010). url : http://www.venraytechnology.com/Papers/INTEL_TOMI_strategy2.htm.

[FLR98] Matteo Frigo, Charles E. Leiserson et Keith H. Randall. �The implementationof the Cilk-5 multithreaded language�. In : Proc. of the ACM SIGPLAN 1998Conf. on Programming Language Design and Implementation . New York,USA, ACM, 1998, p. 212-223.

[GF09a] BriceGoglin et Nathalie Furmento. �Enabling High-Performance Memory-Migration in Linux for Multithreaded Applications�. In : MTAAP'09 : Workshopon Multithreaded Architectures and Applications, held in conjunction withIPDPS 2009. Rome, Italy : IEEE Computer Society Press, 2009. url : http://hal.inria.fr/inria-00358172.

[GF09b] BriceGoglin et Nathalie Furmento. �Enabling High-Performance Memory-Migration in Linux for Multithreaded Applications�. In : MTAAP'09 : Workshopon Multithreaded Architectures and Applications, held in conjunction withIPDPS 2009. Rome, Italy : IEEE Computer Society Press, 2009. url : http://hal.inria.fr/inria-00358172.

[GLS99] William Gropp, Ewing Lusk et Anthony Skjellum. Using MPI : PortableParallel Programming with the Message-Passing Interface . 2e éd. MIT Press,1999.

[Gra99] M.Grajcar. �Genetic List Scheduling Algorithm for Scheduling and Allocationon a Loosely Coupled Heterogeneous Multiprocessor System�. In : DesignAutomation Conference(DAC). T. 00. Juin 1999, p. 280-285. url : doi .ieeecomputersociety.org/10.1109/DAC.1999.82 .

[GSP17] N. J.Gunther, S. Subramanyam et S. Parvu. A Methodology for OptimizingMultithreaded System Scalability on Multicores. Addison Wiley, Series onParallel et Distributed Computing, 2017. url : http://www.perfdynamics.com/Manifesto/USLscalability.html.

[Gue16] Yannick Guerrini. �Fin de la loi de Moore : la �nesse de gravure bloquéeen 2021 ?� In : Toms Hardware (2016). url : https://www.tomshardware.fr/articles/transistor-loi-moore-miniaturisation-processeur,1-

60558.html.

103

http://www.edn.com/design/ systems- design/4368705/The-future-of-computers--Part-1-Multicore-and-the-Memory-Wall









doi.ieeecomputersociety.org/10.1109/DAC.1999.82

doi.ieeecomputersociety.org/10.1109/DAC.1999.82

http://www.perfdynamics.com/Manifesto/USLscalability.html

http://www.perfdynamics.com/Manifesto/USLscalability.html

https://www.tomshardware.fr/articles/transistor-loi-moore-miniaturisation-processeur,1-60558.html



[HL14] Maurice Herlihy et Zhiyu Liu. �Well-structured Futures and Cache Locality�.In : Proceedings of the 19th ACM SIGPLAN Symposium on Principles andPractice of Parallel Programming. PPoPP 14. Orlando Florida, USA : ACM,2014, 155�166. url : http://doi.acm.org/10.1145/2555243.2555257 .

[HP17] John Hennessy et David Patterson. Computer Architecture : A QuantitativeApproach, 6th ed. Morgan Kaufmann Publishers, 2017. isbn : 1-55880-069-8.

[HRR07] Sascha Hunold, Thomas Rauber et Gudula Rünger. �Dynamic Schedulingof Multi-Processor Tasks on Clusters of Clusters�. In : Proceedings of theSixth International Workshop on Algorithms, Models and Tools for ParallelComputing on Heterogeneous Networks (Heteropar'07) . Austin, TX, 2007,p. 507-514.

[Hug+02] C. J. Hughes et al. �RSIM Simulating Shared-Memory Multiproeessors withILP Proeessors�. In : IEEE Computer Society, 2002, p. 40-49.

[Int09] Intel. An introduction to the Intel QuickPath Interconnect . 2009. url :http://www.intel.com/content/www/us/en/io/quickpath-technology/

quick-path-interconnect-introduction-paper.html .

[KA02] K. Kennedy et J. Allen. Optimizing compilers for modern architectures :A dependence-based approach. Morgan Kaufmann, 2002.

[KA99] Yu-Kwong Kwok et IshfaqAhmad. �Static Scheduling Algorithms for AllocatingDirected Task Graphs to Multiprocessors�. In : ACM Computing Surveys 31(1999), p. 406-471.

[Kru88] Boontee Kruatrachue. �Grain Size Determination for Parallel Processing�.In : IEEE Software 5.1 (jan. 1988), p. 23-32.

[Lab16] Kasahara. Lab. �STG Standard Task Graph Set�. In : Waseda Univ, 2016.url : http://www.kasahara.elec.waseda.ac.jp/schedule/index.html .

[LH05] Henrik Lof et Sverker Holmgren. �a�nity-on-next-touch : increasing theperformance of an industrial PDE solver on a cc-NUMA system�. In : 19thACM International Conference on Supercomputing . Cambridge, MA, USA,juin 2005, p. 387-392.

[Lin] Linux. Linux Manual. url : https://linux.die.net/man/8/numactl.

[LZ13] Y. Liu et Y. Zhu. �SimNUMA Simulating NUMAArchitecture MultiprocessorSystems E�ciently�. In : PDS ICPADS, 2013, p. 341-348.

[MCE02] P. S. Magnusson, M. Christensson et J. Eskilson. �Simics a full systemsimulation platform�. In : IEEE Computer, 2002, p. 50-58.

[McK04] Sally A. McKee. �Re�ections on the memory wall�. In : Proceedings of the1st Conference on Computing Frontiers, CF '04, pages 162 (2004).

[MER] Gianni MEREU. �Conception, Analysis, Design and Realization of a Multi-socket Network-on-Chip architecture and of the Binary Translation supportfor a VLIW core targeted to Systems-on-Chip�. Thèse de doct. Universitadegli Studi di Cagliari. url : http://www.diee.unica.it/driei/tesi/19_mereu.pdf.

[MK09] J. E. Miller et H. Kasture. �Graphite A Distributed Parallel Simulatorfor Multicores�. In : MIT- CSAI-Lab Technical report, 2009.

104

http://doi.acm.org/10.1145/2555243.2555257

http://www.intel.com/content/www/us/en/io/quickpath-technology/quick-path-interconnect-introduction-paper.html

http://www.intel.com/content/www/us/en/io/quickpath-technology/quick-path-interconnect-introduction-paper.html

http://www.kasahara.elec.waseda.ac.jp/schedule/index.html

https://linux.die.net/man/8/numactl

http://www.diee.unica.it/driei/tesi/19_mereu.pdf

http://www.diee.unica.it/driei/tesi/19_mereu.pdf

[Moo+65] Gordon EMoore et al. �Cramming more components onto integrated circuits�.In : McGraw-Hill, 1965. url : https://www.cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf.

[MSB05] M.Martin, D. J. Sorin et B. M. Beckmann. �Multifacet general executiondriven multiprocessor simulator GEMS toolset�. In : ACM SIGARCH ComputerArchitecture News. 2005, p. 92-99.

[MTM10] JaydeepMarathe, Vivek Thakkar et FrankMueller. �Feedback-directedpage placement for ccnuma via hardware-generated memory traces�. In :Cambridge, Massachusetts : J. Parallel Distrib. Comput., 70(12), 2010, p. 1204-1219.

[Mul13] Daniel Muller. �Memory and Thread Management on NUMA Systems�.Master. Technische universitat Dresden : CS, 2013.

[Ngu+96] A. T. Nguyen et al. �The Augmint Multiprocessor Simulation Toolkit forIntel x86 architectures�. In : IEEE Computer Society, 1996, p. 486 -491.

[Nik+01] Dimitrios S. Nikolopoulos et al. �Exploiting Memory A�nity in OpenMPthrough Schedule Reuse�. In : ACM Computer Architecture News 29.5 (déc.2001), p. 49-55. url : http://people.cs.vt.edu/~dsn/papers/COMPUTER_ARCHITECTURE_NEWS_COPYRIGHTED.pdf.

[P.+09] Ribeiro C. P. et al. �Memory A�nity for Hierarchical Shared Memory Multiprocessors�.In : 21st International Symposium on Computer Architecture and High PerformanceComputing (SBAC-PAD) (2009), p. 1-8.

[Pan11] lakovos Panourgias. �NUMA e�ect on multicore multisocket systems�. Master.Edinburgh : Edenberg university, 2011. url : https://static.epcc.ed.ac.uk/dissertations/hpc-msc/2010-2011/IakovosPanourgias.pdf .

[PGB02] V. Puente, J.A.Gregorio et R. Beivide. �SICOSYS An Integrated Frameworkfor studying Interconnection Network Performance in Multiprocessor Systems�.In : Proc. of Parallel, Distributed et Networkbased Processing(PDP), 2002,p. 15-22.

[Pla+09] Judit Planas et al. �Hierarchical task-based programming with StarSs�. In :International Journal of High Performance Computing Applications . SagePublications, CA USA, 2009, p. 284-299.

[Pla15] Maksym Planeta. �Simulation of a Scheduling Algorithm for DAG-basedTask Models�. Mém. de mast. Technische Universität Dresden, 2015.

[PRA97] V. S. Pai, P. Ranganathan et S. V. Adve. �RSIM An Execution DrivenSimulator for ILP Based Shared Memory Multiprocessors and Uniprocessors�.In : Proc of the Third Workshop on Computer Architecture Education, 1997.

[Qui11] Jean-Noël Quintin. �Equilibrage de charge dynamique sur plates-formeshiérarchiques�. Thèse de doct. 2011. url : http://www.theses.fr/2011GRENM066.

[RM09] Christiane Pousa Ribeiro et Jean-FrançoisMéhaut.Minas : Memory A�nityManagement Framework. Rapp. tech. RR-7051. 2009.

105

https://www.cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf

https://www.cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf

http://people.cs.vt.edu/~dsn/papers/COMPUTER_ARCHITECTURE_NEWS_COPYRIGHTED.pdf

http://people.cs.vt.edu/~dsn/papers/COMPUTER_ARCHITECTURE_NEWS_COPYRIGHTED.pdf

https://static.epcc.ed.ac.uk/dissertations/hpc-msc/2010-2011/IakovosPanourgias.pdf

https://static.epcc.ed.ac.uk/dissertations/hpc-msc/2010-2011/IakovosPanourgias.pdf

http://www.theses.fr/2011GRENM066

[Sin+08] Gurmeet Singh et al. �Work�ow task clustering for best e�ort systems withPegasus�. In : 15th ACM Mardi Gras Conference : From lightweight mash-ups to lambda grids : Understanding the spectrum of distributed computingrequirements, applications, tools, infrastructures, interoperability, and the incrementaladoption of key capabilities (MG'08). Baton Rouge, LA : ACM, 2008, 9 :1-9 :8.url : http://doi.acm.org/10.1145/1341811.1341822 .

[SL93] M.S. Squillante et E.D. Lazowska. �Using processor-cache a�nity informationin shared-memory multiprocessor scheduling�. In : Parallel and DistributedSystems, IEEE Transactions 4.2 (1993), p. 131-143.

[Spo+08] Daniel Spoonhower et al. �Beyond Nested Parallelism : Tight Bounds onWork-Stealing Overheads for Parallel Futures�. In : SPAA08, ACM. 2008.

[SS14a] Mohamed Slimane et Larbi Sekhri. �Modeling the Scheduling Problem ofIdentical Parallel Machines with Load Balancing by Time Petri Nets�. In :International Journal of Intelligent Systems and Applications 7 (déc. 2014),p. 42-48. url : http://www.mecs-press.org/ijisa/ijisa-v7-n1/IJISA-V7-N1-4.pdf.

[SS14b] Mohamed Slimane et Larbi Sekhri. �Parallel Pipelined Implementation ofDES Cryptographic Algorithm on Multicore Machines�. In : 1ères journéesScienti�ques du Laboratoire d'Architectures Parallèles, Embarquées et du Calculintensif (LAPECI). Sept. 2014.

[SS17] Mohamed Slimane et Larbi Sekhrii. �HLSMN High level Multicore NUMASimulator�. In : Electrotehnica, Electronica, Automatica, vol. 65, no. 3, pp.170-175 (2017). url : http://www.eea-journal.ro/ro/d/5/p/EEA65_3_25.

[TG13] Rauber Thomas et Rünger Gudula. Parallel Programming for Multicoreand Cluster Systems. Springer, 2013.

[TNW07] Samuel Thibault, RaymondNamyst et Pierre-AndréWacrenier. �BuildingPortable Thread Schedulers for Hierarchical Multiprocessors : the BubbleSchedFramework�. In : Euro-Par 2007 Parallel Processing. 2007, p. 42-51. url :http://arxiv.org/abs/0706.2069.

[TS02] Andrew S. Tanenbaum et Maarten van Steen.Distributed systems, Principlesand Paradigms. International Edition. Prentice Hall, 2002.

[TSK05] J. Tao, M. Schulz et W. Karl. �SIMT Simulation as a tool for optimizingmemory accesses on NUMA machines�. In : Performance Evaluation, 2005,p. 31-50.

[Ull75] J.D. Ullman. �NP-complete scheduling problems�. In : Journal of Computerand System Sciences 10.3 (1975), p. 384-393.

[Wac+10] P. Wacrenier et al. �Structuring the execution of OpenMP applicationsfor multicore architectures�. In : IEEE International Symposium on Paralleland Distributed Processing (IPDPS). T. 00. Avr. 2010, p. 1-10. url : doi.ieeecomputersociety.org/10.1109/IPDPS.2010.5470442 .

[Yoo+13] Richard M. Yoo et al. �Locality-aware task management for unstructuredparallelism : A quantitative limit study�. In : Proc. of the 25th Annual ACMSymp. on Parallelism in Algorithms and Architectures, SPAA 13 . New York,NY USA : AM, 2013, 315�325.

106

http://doi.acm.org/10.1145/1341811.1341822

http://www.mecs-press.org/ijisa/ijisa-v7-n1/IJISA-V7-N1-4.pdf

http://www.mecs-press.org/ijisa/ijisa-v7-n1/IJISA-V7-N1-4.pdf

http://www.eea-journal.ro/ro/d/5/p/EEA65_3_25

http://www.eea-journal.ro/ro/d/5/p/EEA65_3_25

http://arxiv.org/abs/0706.2069

doi.ieeecomputersociety.org/10.1109/IPDPS.2010.5470442

doi.ieeecomputersociety.org/10.1109/IPDPS.2010.5470442

I.J. Intelligent Systems and Applications, 2015, 01, 42-48 Published Online December 2014 in MECS (http://www.mecs-press.org/)

DOI: 10.5815/ijisa.2015.01.04

Copyright © 2015 MECS I.J. Intelligent Systems and Applications, 2015, 01, 42-48

Modeling the Scheduling Problem of Identical

Parallel Machines with Load Balancing by Time

Petri Nets

Sekhri Larbi Industrial Computing and Networking Laboratory, Computer Science Department, University of Oran, BP 1524 Oran,

Algeria

E-mail: [email protected]

Slimane Mohamed Industrial Computing and Networking Laboratory, Computer Science Department, University of Oran, BP 1524 Oran,

Algeria

E-mail: [email protected]

Abstract—The optimal resources allocation to tasks was the

primary objective of the research dealing with scheduling

problems. These problems are characterized by their complexity,

known as NP-hard in most cases. Currently with the evolution

of technology, classical methods are inadequate because they

degrade system performance (inflexibility, inefficient resources

using policy, etc.). In the context of parallel and distributed

systems, several computing units process multitasking

applications in concurrent way. Main goal of such process is to

schedule tasks and map them on the appropriate machines to

achieve the optimal overall system performance (Minimize the

Make-span and balance the load among the machines). In this

paper we present a Time Petri Net (TPN) based approach to

solve the scheduling problem by mapping each entity (tasks,

resources and constraints) to correspondent one in the TPN. In

this case, the scheduling problem can be reduced to finding an

optimal sequence of transitions leading from an initial marking

to a final one. Our approach improves the classical mapping

algorithms by introducing a control over resources allocation

and by taking into consideration the resource balancing aspect

leading to an acceptable state of the system. The approach is

applied to a specific class of problems where the machines are

parallel and identical. This class is analyzed by using the TiNA

(Time Net Analyzer) tool software developed in the LAAS

laboratory (Toulouse, France).

Index Terms— Scheduling Problem, Load Balancing, Time

Petri Net, Identical Parallel Machines

I. INTRODUCTION

Recent works in scheduling tend to classify problems

and to find techniques to reduce their complexity by

developing optimal and efficient algorithms. Among all

classifications existing in the literature, Convay’s and

Graham’s classifications are considered as the most used

to encode such problems [1] and [2]. In [2], a clear

separation is made between the three parts of the problem:

task, resource and the objective to optimize. In these

works, a task is an important element and it doesn’t carry

about resources just using them without conflicts [3].

Nowadays with the technology advances, these traditional

methods have proved to be inadequate because degrading

system’s performances (inflexibility, lack of strategy in

the adopted solutions for use resources, etc.) .

Petri nets are a formal tool for modeling and analyzing

systems that exhibit behaviors such as competition,

conflicts and the causal dependencies between events.

They are appropriate to model and validate discrete event

systems (DES). They are used for modeling concurrent

systems such as Occam programs [4], the design of an

automated production system [5] and recently in the

protocol modeling for wireless sensor network [6].

Petri nets based approaches address the issue of

flexibility of tasks and resources. The modeling power

and analysis power of Petri nets theory can explore easily

different aspects of the scheduling problem (behavioral

and structural properties) and integrate factors ignored in

previous works [7].

In scheduling related literature, Petri nets theory is

applied in several fields. Ramamoorthy used graphical

techniques to analyze the cyclical flow in automated

production systems in order to represent the scheduling

problem by cyclic Petri Nets [8]. Chrétienne provides a

timed Petri nets based approach for cyclic generic

scheduling problem [9]. Van Der Aalst exploits Petri nets

to minimize the cycle time for planning repetitive

problems [10]. Korbaa proposes a colored Petri nets

based approach to model cyclic scheduling and to reduce

the complexity analysis [11]. In [12], a Petri net-based

model for scheduling problems with a branch and bound

algorithm is proposed using dynamic branching strategy

and resource-based lower bound. Other works on

scheduling flexible manufacturing systems using Petri-

nets and genetic algorithms are proposed in [13]; and

colored Petri nets [14].

In these works, performance evaluation of the system

is defined only in term of the task execution ordering

without conflicts and resources sharing. This fact leads to

a bad system performance.

In this paper, we extend classical methods by taking

into account the load balancing aspect in the system, and

mailto:[email protected]

Modeling the Scheduling Problem of Identical Parallel Machines with Load Balancing by Time Petri Nets 43


ensuring an acceptable operating level. The method

improves the conventional Petri nets based approaches by

ensuring an economic resources using and achieving an

acceptable state of the system. The modeled system can

be analyzed to verify some properties like: finding a

feasible scheduling, detecting conflict, eliminating

redundancy, finding the lower/upper limit for the total

execution time.

This work focuses on the formal modeling of identical

parallel machines scheduling problem by using time Petri

net and the formal validation of its properties by using

TiNA tool. The preliminary results reveal that the

obtained model load is bounded and adjusted among the

resources.

The paper is structured as follows. Section 2 introduces

some definitions on scheduling problem area with an

illustrative example. In section 3, we introduce briefly the

time Petri nets model. In section 4, we detail our method

by explaining different mapping steps translating a

scheduling problem into a time Petri net. The method is

applied to an illustrative example and analyzed by TiNA

tool. Finally we conclude with a conclusion and future

prospects.

II. SCHEDULING PROBLEM (SP)

Scheduling can be defined as the allocation of scares

resources over time to perform a collection of tasks. It is

concerned with finding the optimal one.

Scheduling techniques are used to answer questions

that arise in production planning, project planning,

computer control, manpower planning, cloud tasks

scheduling, distributed simulations, etc. [15] and [16].

Many techniques have been developed for a variety of

problems and classified by categories (single machine,

parallel machine, flow job, job shop, etc.). To fix the

terminology, we begin by defining the general scheduling

problem.

Many problems fit into this definition. In essence,

scheduling boils down to the allocation of resources to

tasks over time. Some authors refer to resources as

‘machines’ or ‘processors’ and tasks are called

‘operations’ or ‘steps of a job’. Resources are used to

process tasks. However, it is possible that the execution

of a task requires more than one resource, i.e. a task is

processed by a resource set. Moreover, there may be

multiple resource sets that are able of processing a

specific task. The processing time of a task is the time

required to execute the task given a specific resource set.

By adding precedence constraints it is possible to

formulate requirements about the order in which the tasks

have to be processed. We will assume that resources are

always available, but we shall not necessarily assume the

same for tasks. Each task may have a release time, i.e. the

time at which the task becomes available for processing.

A schedule is an allocation of resources to tasks over time

and for each task it is specified when it is processed and

which resources process it.

A. Definitions

Formally, an SP is defined as a triplet (GT (T, C<), R,

CR) where GT (T, C<) is the tasks graph with:

- T: finite set of tasks T = {Ti}i..n with :

- si: starting time of the task execution Ti

- pi: processing time of task Ti

- ci: completion time of task Ti

- ri: release time of the task Ti

- di: due time

C<: precedence constraint (partial order relation on

T×T).

T and C< make GT task-Graph.

Feasible scheduling: A scheduling is feasible if it

satisfies the precedence constraints and resource

availability constraint.

Objective function: The objective function is a metric

that describes the quality of the solution based on specific

objectives.

(1)

(2)

Optimal scheduling: The optimal schedule is a feasible

solution that optimizes the objective function on the state

space.

(3)

R: finite set of resources R= {Ri}i.m with the maximum

available amount mi

CR: resources constraint. It defines for each task,

resource requirements with aij the necessary amount of

resources Rj for the execution of Ti.

Scheduling: The scheduling of an instance of an SP is

an application that associates to each task Ti and its

resource requirements, start time of its execution during

pi.

(4)

( ) (5)

State space (Π): The state space is the set of all

possible scheduling on T × R.

In the sequel we adopt the Graham’s notation [4]

<α|β|γ> for SP where:

- α represents the machine environment,

- ß represents the characteristics of tasks,

- γ is the objective function.

B. Illustrative Example.

The example illustrated by the Fig. 1 will be used in

the sequel as a reference for our mapping method.

Fig.1. Tasks graph for a scheduling problem

44 Modeling the Scheduling Problem of Identical Parallel Machines with Load Balancing by Time Petri Nets


According to Graham notation, Fig. 1 represents an

instance of the SP, where the environment machine

contains two identical parallel machines with precedence

constraints and optimizing the total execution time as

objective. The different elements of the SP are:

T = {T0, T1, T2, T3, T4, T5, T6}

P = {2, 2, 2, 3, 2, 3, 2}

< = {(T0, T1), (T0, T2), (T0, T3), (T1, T4), (T2, T5), (T3,

T5), (T4, T6), (T5, T6)}

R = {R1, R2} two instances of this kind of resources are

available (processors).

CR: each task uses a unit of this resource for its

execution.

Fig. 1 gives a possible solution to this instance, its

configuration is:

Scheduling = {(T0, R1, 0), (T1, R1, 4), (T2, R1, 2), (T3, R2,

3), (T4, R1, 6), (T5, R2, 6), (T6, R2, 10)}.

C. Working hypotheses

In this study, a number of assumptions on the SP

model are to consider:

- Simultaneous use of a resource by tasks is prohibited.

- Once launched, a transaction must complete without

interruption.

- Lack of communication between resources and tasks.

- No duplication of tasks.

- Processing times are fixed and known in advance.

- Model used is parallel identical machines SP where

resources are independent and having the same features.

This model is classified by Graham as <P|β|γ>.

III. TIME PETRI NETS

Time Petri nets (or TPN for short) [17] and [18] are a

convenient model for real time systems and

communication protocols. TPN extend Petri nets by

associating two values (min, max) of time (temporal

interval) to each transition. The value min (min≥0), is the

minimal time that must elapse, starting from the time at

which transition t is enabled until this transition can fire

and max (0≤max‹∞), denotes the maximum time during

which transition t can be enabled without being fired.

Time min and max, for transition t, are relative to the

moment at which t is enabled. If transition t has been

enabled at time α, then t cannot fire before α+min and

must fire before or at time α+max, unless it is disabled

before its firing of another transition.

We assume that the reader is familiar with the

definitions and basic concepts of Petri nets [19].

IV. MODELING SP BY TIME PETRI NETS

This section presents main steps of modeling SP by

Petri nets. Entities of SP (task, resource, constraint) are

associated to elements of Petri net model (place,

transition, edge). Two main known translating methods

are referenced in literature. These methods enable to map

a SP into a Petri net model. The first method is due to

Chrétienne and the second one is due to Van der Aalst. In

both methods, translating process is made up of six steps:

- Modeling tasks,

- Modeling precedence constraints,

- Modeling resources,

- Modeling constraints of available resources,

- Initial marking of time Petri net

- Synchronization mechanism.

Unfortunately in these methods, there is no way to

control the policy of the resources used by the system.

This fact is considered as the main drawback of such

methods. For this reason, in this paper, we propose an

extension of these traditional approaches by taking into

account this fact.

A. Scheduling Problem Modeling with Load Balancing

In previous methods there is no way to know how

resources were used; also the interest is oriented only to

tasks availability not for their loading. Our approach tries

to combine the best of both previous methods by

incorporating load balancing of resources. The main idea

is to model separately each constraint, then separate the

Petri net corresponding to the tasks graph from those

corresponding to resources. Both Petri nets are connected

in specific points through which communication is done.

This approach allows us to adjust the load on resources

resulting from the execution of tasks and therefore

achieve a steady state system with a feasible scheduling.

The method will be applied to the case study formed by

identical parallel machines. Our mapping method

proceeds in three main steps: mapping tasks graph into

time Petri net task, mapping resources into time Petri net

resources and finally connect these two generated nets

[20] and [21].

Fig.2. Tasks Time Petri net

Let SP = (GT (T, C<), R, CR) be an identical parallel

machine scheduling problem. Mapping tasks graph

GT (T, C<) is transformed into tasks time Petri net



Step1. Modeling tasks Ti (see Fig. 3 (a)).

- TSi start transition to launch Ti

- Pi associated place for Ti

- TCi completion transition to end Ti.

- Create an arc from TSi to Pi and another from Pi to TCI

Step2. Modeling the precedence constraint Ti <Tj by

adding (see Fig. 3 (b)):

- Pij place associated with this constraint

- Create an arc from Pij to TSJ and another from TCI to

Pij

Step3. Defining the initial marking

- All places are empty (initially no task is in execution).

Step4. Modeling the synchronization mechanism

- The time is associated with completion transitions TCi

and equal to pi

Fig.3. Tasks Time Petri net

In the resulting net, two specific places are added:

PS: Start place to start the process. PS is initialized with

a token that passes through the rest of the net.

PC: Completion place to end the process. The process

stops when the token reaches the place PC.

By applying the mapping process to the SP illustrated

by the Fig. 1, we obtain the tasks time Petri net

represented by the Fig. 2. This part of solution illustrates

a task graph side as a time Petri net node starting by task

start transition. The place having a token represents the

task processing and the task end transition represents the

task delay. When the task finishes then delivers its

outputs to the next step. The overall process starts with

token on its first place PS and ends when the last

transition PC expires it’s waiting time as execution of the

last task in the task graph.

Mapping resources

Resources are translated into Resources Petri Net.

Step1. Modeling Input / Output Resources:

- RIP, ROP, PSW, Input/ Output / Switch place.

Step2. Modeling resource Rj is achieved by introducing:

- PRJ place

- QIRj, QORj place points of entry / exit non-reentrancy be

associated with Rj

- TIRj, TORj transitions input / output of Rj

- (PIR, TIRj) (TORj, POR) arcs are connected to the outside

- (TORj-1 QORj) (TIRj-1 QIRj) arcs connecting the preceding

and following resources

Step3. Defining the initial marking

- PRJ contains m tokens.

By applying these steps to SP of Fig. 1, we obtain the

resource time Petri net illustrated by the Fig. 4.

Fig. 4. Resources Time Petri net

Connection of Tasks time Petri Net and Resources

time Petri Net

Before the connection we model resource constraints

and allocation of resources to tasks.

- (POR, TSi): Resource application.

- (TSi, PSW): Notification of use of the resource.

- (TCI PIR): Release of the resource.

Connection of tasks time Petri net (Fig. 2) and

resources Petri net (Fig. 4) forms a time Petri net

illustrated by the Fig. 5.

When the task is ready to run it consumes available

resources modeled by the place POR. Then, this task

generates a token on the place PSW meaning that the next

resource is ready to be consumed. The load distribution is

ensured by the fact that each resource can be fairly used.

When the place PSW will be marked up it goes out to the

next resource that will put the token in the place Por (see

Fig. 5). This process is repeated while exist enough

resources to satisfy requests made by tasks. In other

words, we expect the release of used resources. When a

task completes then it releases the possessed resource. By

recovering this resource, the place PIR gives the control to

the next resource.

This solution respects two principles; the first one

using the resources in round robin fashion and the second

concerns the availability of the resource for task

execution. In this situation, the execution is blocked until

a resources is released (become available) then it will be

allocated to one of the waiting tasks. After this we will

pass turn token to the next resources as marked for

allocating next time.

B. Properties Analysis

The analysis of time Petri net illustrated by the Fig. 5 is

performed using the TiNA tool software version 8.0

(www.laas.fr/bernard/tina.htm). The analysis has shown

that the network has good properties. Fig. 6 summarizes

some analytical results given by Net Control Draw of

TiNA tool. It is possible to analyze all firing sequences of

a time Petri net corresponding to a scheduling problem.

Each firing transitions sequence starting from initial

marking to final marking corresponds to a feasible



scheduling. Transition sequences belonging to time Petri

net given by Fig. 5 define the using of resources by the

tasks. A transition sequence from the initial place PS to

final place PC models ordered execution of tasks and

ordered use of resources.

Fig. 5. Time Petri net of SP

In the time Petri net of Fig. 5, a transition sequence

generated by using TiNA tool is given as scheduling

solution such a 5-tuple (Task, tbegin, Used-Ressource,

Execution-time, tend) :

Fig. 6. Gant chart for resources utilization

TRACE = [email protected] [email protected] [email protected]

[email protected] [email protected] [email protected] [email protected] [email protected]





[email protected]



SOLUTION = {(T0, 0, R1, 2, 2), (T1, 2, R1, 2, 4), (T2,

2, R2, 2, 4), (T3, 4, R1, 3, 7), (T4, 4, R2, 2, 6), (T5, 6, R2,

3, 10), (T6, 10, R1, 2, 12)}

Resources utilization of R1 and R2 are 75% and 58%

respectively with a load average of 56% to R1 and 44% to

R2 (number of assigned tasks), maximal difference

between loading of R1 and loading of R2 is equal to one

task. For our example above, the obtained solution has an

acceptable balanced load among the whole system. This

situation allows us to get good level of performance using

the available resources. The classical methods do not

permit to know such information because there is no way

to save which resource executes which task. Fig. 6 shows

the solution of the previous example, the load of each

resource and the average load of using them.

Many of the scheduling problem solution can be

modeled as reachability problems. In [22], the authors

propose a constraint programming based approach to

address the reachability problem. The authors use an

incremental methodology based on linearization

techniques to translate the reachability graph of a timed

Petri net into a mathematical programming model.

An enumerative method exists in order to exhaustively

validate the behavior of time Petri net. This technique is

related to the reachability analysis method for usual Petri

nets and allows one to formally verify time dependent

systems. The TiNA tool uses the enumerative method and

is applied to the verification of time Petri net model of SP

illustrated by the Fig. 5. The analyze reveals that our SP

has good properties as summarized in Fig. 7.

Fig. 7. Analysis Results given by TiNA

The reachability graph shows all accessible states. In

the context of our case study by time Petri nets, the

reachability graph represents a spanning tree of all

possible paths for task execution. Based on the properties

of such graph, we can determine not accessible states, all

terminal states (leaves of the tree), etc. If one of these

leaves matches a final task in the task graph then we find

a critical path that shows the longest sequence of tasks

execution in this graph.

After launching the simulation, we will save its trace.

By analyzing it, we will depict the most important

features of this modeling method. Fig. 7 depicts that time

Petri net of Fig. 5 is bounded and the reachability graph

(state classes’ graph) contains 174 markings (state classes)

and 318 transitions. The trace generated by TiNA

simulator shows that the obtained solution has 12 units

length, this means that the optimal solution has a

Makespan Cmax <= 12 units for this instance of problem.

So, based on this result, we can fix the parameters of

other algorithms to get this optimal solution.

V. CONCLUSION AND FUTURE PERSPECTIVES

In this paper we have proposed a new approach to

mapping a scheduling problem into a time Petri net. This

work extends previous works by taking into consideration

the load balancing factor. Our mapping method is applied

to specific class of SP (identical parallel machines). The

method is based in a clear separation between main parts

of a SP: tasks graph and resource constraints. Both parts

are translated independently into a time Petri net. The

resources time Petri net can be apportioned equally

(resource use policy) serving requests from the first time

Petri net (tasks Petri net). The transformation of a SP into

a time Petri net allows us to analyze properties as:

detecting resources conflicts, search of feasible

scheduling, determining bound inf/sup of global run time,

load balancing, etc. This validation can be done by

software TiNA tool. Actually, as future prospects, we plan

to extend our method to other classes of SP as no

identical heterogeneous parallel machines.

ACKNOWLEDGMENT

This work was supported in part by the Industrial

Computing and Networking Laboratory of Oran

University.

REFERENCES

[1] R.W. Conway, W.L. Maxwell and L.W. Miller. Theory of

Scheduling. Addison Wesley, Reading, Mass. USA, 1967.

[2] R. L. Graham, E. L. Lawler, J. K. Lenstra and A. H. G.

Rinnooy Kan. Optimization and Approximation in

Deterministic Sequencing and Scheduling Theory: a survey,

Discrete Math. 5, 1979, 287-326.

[3] E.L. Lawler, J.K. Lenstra, A.H.G. Rinnooy Kan and D.B.

Shmoys. Sequencing and Scheduling: Algorithms and

Complexity, vol. 4, Handbook in OR and Management

Science. North-Holland, Amsterdam, 1993.

[4] Y. Slimani, A. Imine and L. Sekhri, Modelling Parallel

Programs: A Formal Approach. International Eurosim

Conference. HPCN Challenges in Telecomputing and

Telecommunication: Parallel Simulation of Complex

Systems and Large Scale Applications, 10-12 June 1996,

Delft, the Netherlands.

[5] L. Sekhri, A.K.A Toguyeni and E. Craye. Diagnosability

of Automated Production Systems Using Petri Net Based

Models, IEEE SMC' 2004, International Conference on

Systems, Man and Cybernetics. October 10-13, 2004,

Hague, Netherlands.

[6] B. Kechar, L. Sekhri and M. K. Rahmouni, CL-MAC:

Energy Efficient and Low Latency Cross-Layer MAC

Protocol for Delay Sensitive Wireless Sensor Network

Applications. The Mediterranean Journal of Computers

and Networks, ISSN:1744-2397,vol.6, No.1, 2010.

[7] K. Hsing-Pei, B. Hsieh and Y. Yingchieh. A Petri Net

Based Approach for Scheduling Resource Constrained

Multiple Project, JCIIE, vol. 23, No. 6, pp. 468-477, 2006.



[8] C V. Ramamoorthy and M. J. Gonzalez, A Survey of

Techniques for Recognizing Parallel Processable Streams

in Computer Programs, AFIPS Conf. Proceedings, 1980,

pp. 1-15.

[9] J. Carlier and P. Chretienne. Timed Petri Net Schedules,

Advances in Petri Nets. Springer, vol. 62/84. 1989.

[10] W.M.P. Van Der Aalst. Petri Net Based Scheduling,

Operation Research Spectrum, vol.18, No 4, 1995.

[11] O. Korbaa, A. Benasser and P. Yim. Two FMS Scheduling

Methods Based on Petri Net: A Global and a Local

Approach, IJPR, vol.41, No.7, pp1349-1371, 2002.

[12] J. K. Hyun, L. Jun-Ho and L.Tae-Eog, A Petri Net-based

Modeling and Scheduling with a Branch and Bound

Algorithm, IEEE International Conference on Systems,

Man and Cybernetics, (SMC’02), October 6-9, 2002,

Hammamet, Tunisia.

[13] D. J. Sampathi, Scheduling FMS Using Petri-nets and

Genetic Algorithms, IISST, July 2012.

[14] I. S. Pashazadeh and N.E. Abdolrahimi, Modeling

Entreprise Architecture Using Timed Colored Petri Nets,

Single Processor Scheduling, vol. l5, No.1, 2014.

[15] A. E. Keshk, A. B. El-Sissi and M. A. Tewfeek, Cloud

Task Scheduling for Load Balancing based on Intelligent

Strategy, International Journal of Intelligent Systems and

Applications (IJISA), 2014, 05, 25-36.

[16] R. E. De Grande, M. Almulla and A. Boukerche,

Autonomous Configuration Scheme in a Distributed Load

Balancing System for HLA-based Simulations, 17th

IEEE/ACM International Symposium on Distributed

Simulation and Real Time Applications, Delft, The

Netherlands, 30 October-1 November, pp. 169-176, 2013.

[17] B. Berthomieu. and M. Menasche. An Enumerative

Approach for Analyzing Time Petri Nets. IFIP Congress

Series, vol. 9, 1983, pp. 41-46, North Holland.

[18] P. M. Merlin, A Study of the Recoverability Systems of

Computing. Irvine Univ. California, PhD thesis, 1974.

[19] T. Murata, Petri Nets: Properties, Analysis and

Applications, Proc. of IEEE, vol.77, No. 4, pp. 541-580,

1989.

[20] M. Slimane and L. Sekhri, Modeling the Scheduling

Problem of Identical Parallel Machines with Load

Balancing by Time Petri Nets. International Symposium on

Modeling and Implementation of Complex Systems, (MISC

2010), Constantine, Algeria, May 30-31, 2010.

[21] F. Abdiche, K. Mesghouni and L. Sekhri, Meta-Heuristic

Optimization Based on P-Time Petri Nets Model for

Deadlock Avoidance in Flexible Manufacturing Systems.

21th International Conference on Production Research.

(ICPR 21), July 31-August 4, 2011, Stuttgart, Germany.

[22] Y. Huang. T. Bourdeaud, P. A. Yvars and A. Toguyeni, A

Constraint Programming Model for Solving Reachability

Problem in Timed Petri nets. ICMOS, 2012

Bordeaux,France.

Authors’ Profiles Sekhri Larbi is an Associate Professor at

the Computer Science Department of Oran

University. His current research area of

interests include formal modeling in

distributed and mobile systems, wireless ad-

hoc and sensor networks, systems modeling

using Petri nets, diagnosability and

monitoring of automated production

systems. He is member of the Industrial Computing and

Networking Laboratory at Oran University. He has been a

visiting professor at Cedric-CNAM research laboratory, in Paris,

France, and Ecole Centrale de Lille (LAGIS) where he worked

in Diagnosis of Industrial Systems; and LIUPA Laboratory at

the University of Pau, France and distinguished lecturer at

University of Ottawa, Canada.

Slimane Mohamed is a Ph. D. candidate in

Department of Computer Science; University

of Oran, Algeria. His current research area

includes Flexible Manufacturing Systems

Modeling, Scheduling Problems, distributed

and parallel programming, simulation and

information security. He received his Ms.Bc

degree in scheduling and mapping distributed

applications from Le Havre University, France. He is an assitant

professor in Computer Science Departement at University of

Chlef, Algeia.

1

DAG Automatic parallel code generation using MS TPL library

Mr SLIMANE Mohammed CSD-UHB-Chlef

[email protected]

Mr BENMAHJOUB Aek CSD-UHB-Chlef

[email protected]

Mr BENHADJA Sadam CSD-UHB-Chlef

[email protected]

Abstract The evolution of the parallel architectures and The rise of new class of unsolved, partially

solved problems or that require more computational power and performance (cryptographic algorithms, DNA sequence analysis algorithms,..) are two factors that oblige programmers to update their methods and techniques used to design & implement the software in new way suitable to the new platforms (Multicore , manycore, with Accelerator, cloud, cluster,..) to increase their performance. In order to make the task of parallelizing the code easy for developers, the compilers, IDEs and others software creation tools must help them to achieve this goal.

Most of time for developers to transform their applications into parallel code, they break the sequential code into DAG by analyzing the dependencies among their parts then they inject the parallelization directives of a specific parallel library (MPI, OpenMP...) for parallel execution. This manual or semi automatic parallelization use low level details of parallelism management (Thread management, ThreadPool, synchronizations, locks,..) which are not easy to use.

This work tries to make a part of this process automatic by generating automatically the parallel code from DAG program description just using high level parallelism provided by MS TPL library (Task APIs) keeping away the programmer from complicated details to focus more on parallelized solution not how to manage threads and low level details. It is a software tool providing automated functionalities for parallelization and/or parallel code generation that can make the parallel programming task much easier.

Key words: Parallel program, Code generation, DAG, TPL, Fork-join model.

2

1. Introduction

Design and implementation of tools for parallelization and/or code generation software for parallel program become more urgent than any time. These tools must provide automated functionalities for parallelization and parallel code generation in order to exploit in optimal way the computational power of the most recent less expensive parallel platforms as multicore and manycore with accelerator, and increase the performance of the implemented applications. Other side of this need is to help the programmers by making the parallel programming task much easier and ensure a smooth transition to the parallel world.

Parallelization is the process of analyzing sequential programs for parallelism and restructuring them to run efficiently on parallel systems. During last decade, the researches in this field are accelerated. The main motivation is the fact that the software parallelism is too late from hardware parallelism. Several works aimed to provide solutions most of case partial and specific for particular platform or library (platform or technology dependent). The most relevant parallelizing and/or code generation tools, which have been published since 2000 based on survey

of F.M. Ciorba [01] (A complete list of

parallelization and parallel code generation software tools can be found in this survey since 1990), we can cite:

Hypertool/2 [02], 2000 – is a runtime scheduling system. A CDAG (Compact Directed Acyclic Graph) is generated at compile-time, which is expanded incrementally into a DAG at runtime, then scheduled and executed on a parallel machine. ParAgent [03], 2002 – (Parallelization Agent) a domain specific, interactive automatic parallelization tool, used to diagnose, analyze and parallelize serial programs, using the domain decomposition method. PETSc [04], 2003 – (Portable Extensible Toolkit for Scientific computation) is a powerful set of

tools for the related problems on high-performance computers. Cronus/1 [05], 2003 – is a semi-automatic parallelization and code generation tool for distributed message passing architectures (MPI).

Most of this works are based on classical parallel libraries MPI, OpenMP, PThread which make extensive use of the low level techniques to manage the parallelism inside software.[06]

In 2008, a specific parallel library is integrated to the framework .NET as solution for application parallelization for this platform its main goal is to hide complicated low level details of parallelism (Threadpool, Locks, low synchronization,..) from programmer by providing high level techniques to manage the parallelism easily.[07]

This paper is organized as follow, In the section 2.the current state of parallelization program model & libraries are exposed and also the automatic parallelization techniques. Then the Code Generation approaches & tools are presented in the section 3. The main part of this paper is DAG model transformation into intermediate model suitable for automatic parallel code generation is given in the section 4. In order ot test our model, the next section 5 explains the implementation details of this idea using MS TPL and experimentation to validate the results of this generation.

2. Program Parallelization

Make an algorithm a parallel program needs some extract inherent parallelism from it by describe it as formal parallel program model (DAG or others) then use parallel libraries to inject parallel directives (synchronization primitives,..) to schedule its parallel activities then allocate them to the processing agent of the target platform.[08]

2.1 Parallel program model

In order to manipulate the parallel program, we represent them in formal way. The most appropriate way is as direct acyclic graph (DAG) mode that consists of tasks and dependencies among them.

3

2.2 Parallel libraries

Several libraries are implemented from common specification or particular one to provide APIs and directives to inject parallelism in applications. The most used:

a- OpenMP : [09] (Open Multiprocessing) is an API that supports multi-platform shared memory multiprocessing programming in C, C++, and Fortran, on most processor architectures and operating systems. b- MPI : [10]. The standard defines the syntax and semantics of a core of library routines useful to writing portable message-passing programs in Fortran 77 or the C programming language. c- PThreads : [11]. The standard, POSIX.1c, Threads extensions (IEEE Std 1003.1c-1995), defines an API for creating and manipulating threads. d- Microsoft-TPL : [12]. is a library for .NET that makes it easy to take advantage of potential parallelism in a program. e- Intel-TBB : [13]. Intel Threading Building Blocks (TBB) is a C++ template library developed by Intel Corporation for writing software programs that take advantage of multi-core processors.

2.3 Automatic parallelization

Manual parallelization is not easy and often errors prone. So it is important to accomplish this task automatically. It consists to convert sequential code into multi-threaded or vectorized (or even both) code in order to utilize multiple processors simultaneously in a shared memory multiprocessor (SMP) machine.

3. Code Generation

The code generator becomes helpful tool for programmer to focus more on modeling of its solution and let tools generate the appropriate code for the created model. In addition to the classical wizards in IDEs, The most important and recent approach in this field is the MDE (Model driven engineering).[14]

3.1 MDE/MDA

In order to raise productivity, the idea is to make models productive and executable, and the MDE/MDA [15] (Model driven architecture) has been introduced. It consists of using models at each level of conception, and to make models transformations between these levels. So that, once the system is modeled at a high abstraction level, only refinements are needed instead of rebuilding all the system at the new level. Such an approach allows to be independent of implementation details since they are managed by the transformations.[16]

4. DAG model transformation

This Transformation takes a user program DAG as input, The first step is to define partitioning of this DAG. Then generate the parallel code bloc for these partitions with insertion proper synchronization primitives where needed inter-ParallelBloc automatically. The sequence of partitions is called Fork-Join Graph (FJG). Each partition represents fork of several tasks as children of the previous level. The complete of execution of all tasks of the partition represents its join point to next level.

i- DAG –Transformation-> FJG ii- FJG –Generation->Parallel Code

a-First step is the transformation of DAG into FJG. In this phase, we aggregate the independent tasks in the DAG together as collection and consider it as one bloc to execute in parallel no data exchange or other thing that need the use of synchronization mechanisms. This step is showed by the Algorithm 1 The figure Fig01 shows the principal of the transformation DAG to FJG.

Fig 01 Object model DAG auto parallel code generator.

b-Next, We will try to generate the parallel code for each independent tasks bloc and interlevel synchronization mechanism in order to ensure that the precedent level tasks have completed their execution we can launch the next bloc Until the last one.

http://en.wikipedia.org/wiki/Fortran_77

http://en.wikipedia.org/wiki/C_(programming_language)

http://en.wikipedia.org/wiki/IEEE

http://en.wikipedia.org/wiki/Application_programming_interface

http://en.wikipedia.org/wiki/C%2B%2B

http://en.wikipedia.org/wiki/Template_(programming)

http://en.wikipedia.org/wiki/Library_(computer_science)

http://en.wikipedia.org/wiki/Intel

http://en.wikipedia.org/wiki/Corporation

http://en.wikipedia.org/wiki/Multi-core

http://en.wikipedia.org/wiki/CPU

http://en.wikipedia.org/wiki/Source_code

http://en.wikipedia.org/wiki/Multi-threaded

http://en.wikipedia.org/wiki/Multiprocessor

http://en.wikipedia.org/wiki/Symmetric_multiprocessing

4

Algorithm 1: DAG to FJG transformation Input : DAG Output : FJG Levels[] //Array of the task level CTasks=GetRootTasks(DAG) CurrentLevel =0 While Not IsEmpty(CTasks) Do NewCT = Empty For each Task in CTasks Levels[GetTaskIndex(Task)]=CurrentLevel

NewCT = NewCT U GetTaskNeighbour(Task) Next CTasks = NewCT CurrentLevel = CurrentLevel + 1 End //Aggregation of tasks by computed level For i=0 to CurrentLevel-1 FJG.AddLevel(i, GetTasksOfLevel(i,Levels,DAG.Tasks) Next Return FJG

Algorithm 2: Generate Parallel Code for FJG Input : FJG Output : ParallelCode //Aggregation of tasks by computed level For each level in FJG.Levels ITB = GenerateIndependentTasksBloc(level) ScheduleCurrentITB(ParallelCode) Next Return ParallelCode

5. Implementation & Experimentation

This section will presents the implementation of precedent transformation by creation of the object model that defines simple APIs for this application (all entities). In the second part, we will launch a sequence of experimentations for sequential and parallel version of the same program.

5.1 Object Model & Implementation

Object model DAG automatic parallel code generator has the following entities:

* GraphModel: base class of graph entities

*DAGraph: parallel program model representation. As a collection of tasks and dependencies.

*ForkJoinGraph: Level aggregation of the independent tasks in the same level from DAG.

As collection of levels each level is collection of independent tasks.

*Dependency: class that represent dependency between two dependent tasks. It may have several features (id, name, cost...).

*Task: class that represent the task entity. It may have several features (length, id, type,..).

*ParallelCodeGenerator: this is the main class that applies transformation and generates the result.

*TPLSyntaxTransformation: this is the parallel derictvies syntax used by MS TPL.

*ParallelSyntaxTransformation: abstract class that contents the high level parallel structure patterns (Fork join pattern, Parallel For, Barrier Pattern...).

There exist the utilities classes that encapsulate certain specific functionalities for UI, Xml manipulation and other aspect of the application. As result, it is a project that content classes for different tasks and main class that content the parallel code calling actions from tasks classes synchronized by TPL directives injected during generation. The figure Fig02 presents the object model of generator where ParallelCodeGenerator uses ForkJoinGraph class for transformation of DAGraph instance then generate the code using TPLSyntaxTrnsformation

Fig 02 Object model DAG auto parallel code generator.

The figure Fig03 is the interface of the generator application. In the main area, we edit the DAG (tasks & its class code, then dependencies)

5

in the background we launch the transformation /generation of the parallel code.

Fig 03 Generator Application interface

5.2 Experimentation

For the same sequential code, we will extract its DAG with different granularity then apply the transformation process to get the correspondent parallel code for it. We launch the execution of the both codes (sequential & parallel) and compare the total execution time (completion time Cmax) for them. The result of a such comparison is given in Fig04 and it shows clearly the speedup achieved by the parallelization process over the sequential.

Fig 04 Execution comparison between the sequential version (SQ code) & DAG parallel generated version (PR code) of

the same program. The execution completion time in function of program size (program length/tasks number).

Conclusion & future perspectives

This work tries to bring another contribution in process of automatic application parallelization by transformation the DAG extracted from sequential program then convert it to FJG which will be parallelized by injection TPL parallel structures and primitives (APIs) in high level

manner to allow focus more on program logic and avoid managing low level complicated parallelism inside software (Thread pool, synchronization,..).

As first paper, it is just a proof of the concept, we focused on transformation process no optimization is done inside result of the transformation. Several aspects of this work can be revisited in future in order to optimize DAG to FJG conversion (by compacting DAG or FJG), code generation and the TPL structures & primitives selection. This optimization may increase more the speedup of the parallel code and its efficiency.

References: [01] F.M.Ciorba "A Brief Survey of Parallelization and/or Code Generation Software Tools"

[02] M.-Y. Wu, W. Shu, Y. Chen, "Runtime Parallel Incremental Scheduling of DAGs", ICPP-2000, Toronto, Canada, pp. 541-548, IEEE Press, 2000

[03] S.C. Kothari, J. Cho, Y. Deng, "Software Tools and Parallel Computing for Numerical Weather Prediction Models", Proceedings of IPDPS 2002 Workshops, IEEE Press, April, 2002

[04] S. Balay, K. Buschelman, V. Eijkhout, W. Gropp, D. "The PETSc User's Manual",URL: http://www-unix.mcs.anl.gov/petsc/ petsc-2/snapshots/petsc-current/docs/manual.pdf, 2003

[05] F.M. Ciorba, T. Andronikos, G. Papakonstantinou, "Simple code generation for special UDLs", In BCI'03 pp. 466-475, Thessaloniki, Greece, November 21-23, 2003.

[06] T.Rauber, G.Runger "Parallel programming for multicore and cluster systems" springer edition 2010

[07] A.Freeman "Pro .Net 4 Parallel programming in C# " Apress Edition 2010

[08] O.Sinnen "Task scheduling for Parallel system" John Wily & Sons publication Edition 2007

[09] OpenMP Architecture Review Board (2007). OpenMP Application

Program Interface Draft 3.0.

[10] W.Gropp; L.Ewing; S.Anthony (1996). "A High-Performance,

Portable Implementation of the MPI MPI".Parallel Computing.

[11] D.R. Butenhof. "Programming with POSIX Threads". A.Wesley.

[12] D.Leijen, W.Schulte, S. Burckhardt "The Design of a Task Parallel Library" Microsoft Research.

[13] "http://www.threadingbuildingblocks.org" Threading Building

Blocks Open Source Project Homepage.

[14] Aho, A. V., Sethi, R., Ullman, J. D. "Compilers: Principles,

Techniques, and Tools". Addison Wesley, 1986.

[15] Schmidt, D.C. (February 2006). "Model-Driven Engineering".

[16] http://www.omg.org/mda

[17] Foster, Ian "Designing and Building Parallel Programs"

Addison-Wesley (1995

http://www-unix.mcs.anl.gov/petsc/

http://www.threadingbuildingblocks.org/

http://www.cs.wustl.edu/~schmidt/PDF/GEI.pdf

vol. 65 nr. 3 iulie–septembrie 2017 Scopul revistei Revista EEA își propune să publice numai acele articole care

atât prin ideile noi, cât și prin rezultatele prezentate, să aducă contribuții importante la cercetarea românească de avangardă din electrotehnică, electronică, automatică, informatică și din celelalte domenii ale științelor inginerești.

Articolele, publicate în două versiuni pe suport de hârtie și online, sunt identice. Accesul liber online asigură o mare vizibilitate articolelor.

Prezentare Revista EEA a fost fondată în anul 1950 sub numele de

„Electricitatea” (ISSN 1220-2533; vol. 1-3) care, în 1953, și-a schimbat numele în „Electrotehnica” (ISSN 0013-5321; vol. 1-22), care, în 1975, după integrarea „Automatica și Electronica (ISSN 1220-2584) apare cu numele actual Electrotehnică, Electronică, Automatică (EEA) [ISSN 1582-5175; e-ISSN 2392–828X] (pentru detalii, a se naviga pe site-ul www.eea-journal.ro).

Încă de la primele numere, deși era unica revistă specializată din domeniul electrotehnicii, EEA a fost constant apreciată pentru nivelul științific ridicat al articolelor publicate.

În prezent, EEA este recunoscută ca lider printre publicațiile științifice, pentru calitatea și standardele înalte ale articolelor apărute în domeniul științelor inginerești. Printre autori se numără specialiști, cercetători și cadre didactice din Algeria, Belgia, R.P. China, Finlanda, Franța, Germania, Italia, Moldova, Serbia, Slovacia, Spania, Ungaria etc.

În paginile revistei, se regăsesc lucrări științifice originale care nu au mai fost publicate și care nu sunt luate în considerare pentru publicare în altă parte, cât și articolele prezentate la conferințe, cu condiția să nu fi fost publicate (parțial sau integral) în volumele manifestărilor științifice (min. 6 pagini–max. 16 pagini), sinteze ale unor proiecte de cercetare, dezbateri științifice și sinteze pe teme prioritare din cercetarea fundamentală și aplicativă (max. 20 pagini), recenzii / note de lectură ale celor mai recente apariții de cărți tehnico-științifice (max. 1 pagină), liste de resurse bibliografice comentate din domeniul științelor inginerești (max. 8 pagini).

Pentru a dovedi deschiderea către noile domenii de frontieră, Colegiul editorial a creat o secțiune-varia (Miscellanea Section), în care sunt publicate articole a căror tematică aparține altor domenii (matematică, științe socio-umane, științe economice, științele vieții și ale pământului (inclusiv mediul), științe agricole, științe medicale etc.) și care, tangențial, pot fi corelate cu domeniul științelor inginerești datorită viziunii, conexiunilor și al abordării inedite a subiectelor.

Revista are un Colegiu de redacție format din academicieni, profesori universitari și cercetători științifici din România și din străinătate — personalități recunoscute din domeniul științelor inginerești (în special, din electrotehnică, electronică, automatică și din celelalte domenii ale ingineriei).

Revista EEA este clasificată B+ de Consiliul Național al Cercetării Științifice din Învățământul Superior (CNCSIS) și este indexată în bazele internaționale de date: Elsevier, Scopus, Compendex, ProQuest, EBSCO, Ulrich’s, Index Copernicus International. În prezent, este în proces de evaluare de Thomson Reuters – ISI.

Scope The EEA Journal aims to publish only those papers that by the

new ideas and the results shown to bring significant contributions to research in the Romanian avant-garde engineering as electrical engineering, electronics, automation and other engineering sciences.

The papers, published in two versions on paper and online, are identical. The online open access ensures a high visibility of the papers.

Description The EEA Journal is founded in 1950 under the title

„Electricitatea” (ISSN 1220-2533; vol. 1-3) that, in 1953, changed its title in „Electrotehnica” (ISSN 0013-5321; vol. 1-22) that, in 1975, after merging „Automatica și Electronica (ISSN 1220-2584) is published under the present title Electrotehnica, Electronica, Automatica (EEA) [ISSN 1582-5175; e-ISSN 2392–828X] (for further details, please navigate on the site www.eea-journal.ro).

Since the early issues, although it was the only scientific journal specialized in the field of electrical engineering, the EEA has been consistently highly rated for the level of its scientific papers.

At present, the EEA is recognized as a leader among the scientific publications for the quality and high standards of the papers belonging to the field of engineering sciences. The authors are specialists, researchers and academics from Algeria, Belgium, PR of China, Finland, France, Germany, Italy, Moldova, Serbia, Slovakia, Spain, Hungary, etc.

In the EEA, there are published original papers that haven’t been previously published and are not under consideration for publication somewhere else, as well as papers presented at conferences, only if they have not been published (partially or fully) in the proceedings of that scientific event (min. 6 pages, max. 16 pages), syntheses of research projects, scientific debates and syntheses on priority themes of fundamental and applied research (max. 20 pages), reviews / reading notes of the latest scientific and technical books (max. 1 page), commented lists of bibliographic resources in engineering sciences (max. 8 pages).

To prove the openness to new frontier areas, the Editorial Board has created a varia section (Miscellanea Section) for papers belonging to other thematic areas (mathematics, social studies, economics, life and earth sciences (including the environment), agricultural sciences, medical sciences, etc.) and, tangentially, they are related to engineering sciences thanks to vision, connections and novel approach of the topics.

The Editorial Board includes academicians, university professors and researchers from Romania and abroad that are well-known personalities in the field of engineering sciences (especially, in electrical, electronics, automation, computer science and other fields of engineering).

The EEA journal is included in the B+ category by the National Council of Scientific Research in Higher Education (CNCSIS) and indexed in international data bases: Elsevier, Scopus, Compendex, ProQuest, EBSCO, Ulrich's, Index Copernicus International. Currently, EEA is under evaluation by Thomson Reuters - ISI.

EDITORIAL BOARD

Editorial Consortium - ICPE - Electrical Engineering Faculty (FIE) within University Politehnica

of Bucharest (UPB) - Scientific Society of ICPE (SS ICPE)

Editors Mihaela CHEFNEUX, Eng., ICPE Ioan Florea HĂNȚILĂ, professor, UPB, Technical Sciences Academy

of Romania Valentin NĂVRĂPESCU, professor, UPB Ionel POPA, PhD, ICPE, SS ICPE

Scientific Board President: Mihai Octavian POPESCU, professor, UPB

General Secretary of the Editorial Board: Ionel POPA, PhD, ICPE

Florin FILIP, academician, vice-president, Romanian Academy Marius PECULEA, academician, Romanian Academy Andrei ȚUGULEA, academician, Romanian Academy Xi WENHUA, academician, Sciences Academy of Gansu, P.R. of

China Adrian-Alexandru BADEA, professor, UPB, vice-president of

Scientists Academy of Romania Aurel CÂMPEANU, professor, University of Craiova; vice-president of

Technical Sciences Academy of Romania Ion CHIUȚĂ, professor, UPB; Scientists Academy of Romania

(president of Section VI – Technical Sciences) Nicolae GOLOVANOV, professor, UPB; president of the Technical

Sciences Academy of Romania Dumitru Felician LĂZĂROIU, professor, technical and scientific

consultant, Paris (France); honorary member of the Technical Sciences Academy of Romania

Teodor LEUCA, professor, University of Oradea; Scientists Academy of Romania; Technical Sciences Academy of Romania

Andrei MARINESCU, professor, University of Craiova; Technical Sciences Academy of Romania

Radu MUNTEANU, professor, Technical University of Cluj-Napoca; vice-president of the Technical Sciences Academy of Romania

Florin Teodor TĂNĂSESCU, professor, president of Romanian Electrotechnical Committee (CER); vice-president of the Technical Sciences Academy of Romania; honorary member of the Sciences Academy of Moldova

Horia Leonard ANDREI, professor, „Valahia” University of Târgoviște Jozef BALOGH, professor, Technical University of Košice, Slovakia George BEREZNAI, professor, University of Ontario, Institute of

Technology (UOIT), Canada Mihail CECLAN, professor, UPB Rodica Elena CECLAN, professor, UPB Costin CEPIȘCĂ, professor, UPB Amit CHAUDHRY, PhD, University of Panjab (UIET), Chandigarh,

India Roman CIMBALA, professor, Technical University of Košice, Slovakia

Grigore DANCIU, professor, UPB Jaroslav DŽMURA, professor, Technical University of Košice, Slovakia Vasile DOBREF, professor, „Mircea cel Bătrân” National Academy of

Constanța Istvan FARKAS, professor, „Szent Istvan” University of Gödöllö,

Hungary Stergios GANATSIOS, professor, Technological Education Institute

(TEI) of Kozani, Greece Horia IOVU, professor, UPB Nicolae JULA, professor, Technical Military Academy of București Hans-Georg KOGLMAYR, professor, University of Pforzheim,

Germany Iosif LINGVAY, PhD, INCDIE ICPE-CA Mihai LUCANU, professor, „Gh. Asachi” Technical University of Iași Magdalena-Valentina LUNGU, PhD, INCDIE ICPE-CA Aurelia MEGHEA, professor, UPB Simona MICLĂUȘ, professor, „Nicolae Balcescu” Land Forces

Academy of Sibiu Etienne MILENT, professor, University of Lille, Franța Dan MOROLDO, professor, Technical University of Civil Engineering

of București Valentin NĂVRĂPESCU, professor, UPB Nicolae OLARIU, professor, „Valahia” University Târgoviște Jaroslav PETRÁŠ, professor PhD, Technical University of Košice,

Slovakia Emil POP, prof. PhD, University of Petroșani Claudia Laurenția POPESCU, professor, UPB Luminița Georgeta POPESCU, professor, „Constantin Brâncuși”

University of Târgul Jiu Mihai Octavian POPESCU, professor, UPB Alexandru SOTIR, professor, „Mircea cel Bătrân” National Academy

of Constanța Ion STRATAN, professor, Technical University of Moldova, Chișinău,

Moldova Janos TAKACS, professor, Technical University of Bratislava, Slovakia Andrei VLADIMIRESCU, professor, University of California, Berkeley,

SUA; Institut Supérieur d'Electronique de Paris

Scientific Reviewers Paula ANGHELIȚĂ, PhD, ICPE Jănel ARHIP, CS II, Technical Military Academy of Constanța Mihai BĂDIC, PhD, INCDIE ICPE-CA Cornel JIVAN, PhD, ICPE Paul MINCIUNESCU, PhD, ICPE Nicolae MOCIOI, PhD ICPE

Mihăiță Gabriel NEACȘU, PhD, ICPE Alexandru RADULIAN, PhD ICPE Nicolae VASILE, professor, „Valahia” University of Târgoviște;

Technical Sciences Academy of România Bogdan Dumitru VĂRĂTICEANU, PhD, ICPE Ion VONCILĂ, professor, „Dunărea de Jos” University of Galați

Editor-in-Chief Elena POPA, senior scientist Sponsorship: Publisher: Editura „ELECTRA” (as part of ICPE) Issuing body: ICPE

Editorial Office: Editura „ELECTRA” Splaiul Unirii, nr. 313; 030138 București, Romania Tel.: +4021 589 34 82 // Mobile: +40749 070 395 e-mail: [email protected] internet: www.eea-journal.ro

Contents

Articol pp.

Elemente de izolare electrică performante destinate instalaţiilor de gaze (High Performance Electrical Insulation Elements for Gas Installations) (Full text in Romanian) Iosif LINGVAY, Octavian TĂNĂSESCU, Ladislau RADERMACHER, Andrei-Tiberiu MATEI, Daniel LINGVAY,

Adriana-Mariana BORȘ

05

Skyrmioni magnetici (Magnetic Skyrmions) (Full text in Romanian) Titu-Marius I. BĂJENESCU

11

Three-Phase four-Wire Active Power Filter fed by PV System using Fuzzy MPPT Controller Rachid Belaidi, Ali Haddouche

17

Power Quality Monitoring and Analysis of a Grid-Connected PV Power Plant Lucia-Andreea EL-LEATHEY, Adrian NEDELCU, Marin DORIAN

26

Sensorless Optimal Power Control of Doubly Fed Induction Wind Generator based on Extended Kalman Filter

Serhoud Hicham, Djilani Benattous

34

Analysis of Traction Control System in Hybrid Electric Vehicle based on Engine-Motor Coordinated Control Strategy

Xingzhi Hu

42

Nonlinear Modelling Analysis of Engineering Vehicle Hydro-Pneumatic Suspension based on ADAMS and Simulink

Wenlong Ma, Guojun Zhang, Xiangzhu Wang

49

Surse de înaltă tensiune pentru aplicații speciale (High Voltage Sources for Special Applications) (Full text in Romanian) Mihai BĂDIC, Cristian MORARI, Jana PINTEA

55

Modelling and Analysis of Two-Degree of Freedom Permanent Magnet Synchronous Generator Zheng Li, Lingwei Zhang, Xiaoxue Yu, Qunjing Wang

63

Continuous Trajectory Planning of Permanent Magnet Spherical Motor by Cubic Spline Interpolation Xiwen Guo, Shen Li, Qunjing Wang, Yan Wen, Lijuan Zhao

70

Behaviour Analysis of the Lead-Zirconate-Titanate (PZT) Piezo-Actuator for Different Wave Excitation. A Comparative Study

Albert ARNAU CUBILLO, Lucian PÎSLARU-DĂNESCU, Ion FUIOREA, Daniel LIPCINSKI

76

Shunt Active Power Filtering based on the p-q Theory Control Kelthoum Hachani, Djillali Mahi, Abdellah Kouzou

85

A Model of a Three-Phase Two-Rotor Axial Generator Nikola GEORGIEV

90

Asymmetrical Short-Circuit of 20 kV Medium Voltage Feeders Waluyo, Teguh Arfianto, Muhammad Iqbally

97

Comportarea electrică și dielectrică a unor mortare de ciment (Behaviour Electric and Dielectric of Cement Mortars) (Full text in Romanian) Georgeta VELCIU, Alina-Ruxandra CARAMITU, Adriana MOANTA, Jana PINTEA, Ladislau RADERMACHER,

Iosif LINGVAY

106

ELECTROTEHNICA, ELECTRONICA, AUTOMATICA (EEA), 2017, vol. 65, nr. 3 4

Control Isolated Intersections with Hybrid Petri Nets and Hybrid Automaton Samir Derai, Rachida Ghoul Hadiby

112

Analiza influenței câmpului electric asupra dezvoltării biomasei algale cu aplicații în biotehnologii (Analysis of the Electric Field Influence on the Algal Biomass Growth with Applications in

Biotechnologies) (Full text in Romanian) Carmen MATEESCU, Andreea VOINA, Nicoleta BUTOI, Marius LUNGULESCU, Ana-Maria LUCHIAN,

Daniel LIPCINSKI

117

Evaluarea efectului câmpului magnetic de 5-10 mT asupra microalgelor Chlorella sorokiniana (Evaluation of the Magnetic Field Effect of 5-10 mT on Chlorella sorokiniana Microalgae) (Full text in Romanian) Ana-Maria LUCHIAN, Marius LUNGULESCU, Andreea VOINA, Carmen MATEESCU, Nicoleta BUTOI,

Eros Alexandru PATROI

123

Numerical Simulations of Helium Flow through an Ion-Guide Mihail Victor CERNAT, Andreea BOBONEA

128

Iterated Extended Kalman Filter with Perturbation Estimator for Localization of Wheeled Mobile Robot

Ben Cherif Aissa, Fatima Chouireb

135

Progrese ale fizicii cuantice (Progresses of Quantic Physics) (Full text in Romanian) Titu-Marius I. BĂJENESCU

140

Wireless Car Control System based on Single Chip Microcomputer Zhang Jianbo, Yin Qun, Liu Si

147

Optimization of MRAS based Speed Estimation for Speed Sensorless Control of DSIM via Genetic Algorithm

Khaled Sahraoui, Katia Kouzi, Ameur Aissa

156

Power Factor Definition based on Metering Error for Non-Sinusoidal Systems Mingxing Tian, Ziting Wu, Jun Li, Yuanxin Zhao

163

HLSMN: High Level Multicore NUMA Simulator Mohammed Slimane, Larbi Sekhri

170

Set Inversion for Identifying the Parameters of a Chemostat Borsali Salima

176

Implementation of a Neutron Imaging Decision Support System (NDSS) Arezki Sekhri

183

Optimal Placement of PMUs in Algerian Network using a Hybrid Particle Swarm–Moth Flame Optimizer (PSO-MFO)

Anfal Mansouri, Abdelhafid Hellal

191

Development of Genetic Algorithm for the Improvement of the Performances of Flexible Manufacturing Systems (FMS)

Habiba Houari, Ahmed Hassem, Mehdi Souier, Zaki Sari

197

OFDM PAPR Reduction in DTMB Systems using ACE and TFD-TR Techniques Feng Hu, Libiao Jin

205-210

MISCELLANEA SECTION

Mediul ambiant: modelator al existenței umanității (partea 3) (Environment: the Modeller of the Mankind Existence (Part 3)) (Full text in Romanian) Eugeniu Alexandru STERE, Ionel POPA

213

Relationship between Corporate Culture and Organizational Performance Ionica ONCIOIU (corresponding author), Alina STANCIU, Carmen BOTEANU, Florentina-Raluca BÎLCAN

221

Semantic Correlation for Alarms Classification in Maintenance Process Bekkaoui Mokhtaria, Mohamed Hedi Karray, Fatima Bekaddour, Sidi Mohammed Meliani

227-234

HLSMN: High Level Multicore NUMA Simulator (Full text in English)

Mohammed Slimane1, Larbi Sekhri1 1Industrial Computing and Networking Laboratory, Computer Science Department, University of Oran1, Ahmed

Benbella, BP 1524 Oran, Algeria

Abstract Multisocket multicore platforms have proven to be a trend in computing systems due to its scalability. It is designed to avoid shared bus constraint exposed by classical design of multicore processors, which is based on shared canal connecting processing units and shared storage unit. Such architecture with poor designed scheduling and mapping policies leads quickly to system performance degradation especially when it has complex design. Therefore, the problem of scheduling and data placement in this context becomes more challenging and urgent to solve. Testing the new and adapted policies or tuning parameters of a specified one for range of Non-Uniform Memory Access (NUMA) target platforms is costly, not practical in most cases. So, simulating the impact of these policies allows improving the system performance with low cost. In this paper, we present HLSMN, a simulation framework for multisocket-multicore NUMA systems based on HWLOC topology description in multithreaded fashion. The simulator supports core components of NUMA platform (node, interconnects and memory hierarchy). Its primary purpose is to allow to study the impact of combining different scheduling policies and data locality of parallel applications execution on the system overall performance testing them on several NUMA target platform topologies. Keywords: Multisocket, Multicore, NUMA platform, remote-memory access, Simulator, multithreaded Simulation,

Data Locality.

Received: April 08, 2017

To cite this article: Mohammed Slimane, Larbi Sekhri, “HLSMN: High Level Multicore NUMA Simulator”, in Electrotehnica, Electronica, Automatica (EEA), 2017, vol. 65, no. 3, pp. 170-175, ISSN 1582-5175.

1. Introduction

NUMA Architecture has unlocked the possibility of building systems that support multisocket hardware for multiprocessors system. They more scalable than symmetric multiprocessing (SMP) architecture. It solves the problem of the shared bus bottleneck to access the shared memory when the number of cores increases. Most recent multicore processors include an interconnect system that allows to build NUMA platform by connecting them through this network. But this complex architecture makes the design and implementation of all policies to exploit its potential power more challenging since the classical ones are no more efficient in this context.

In order to adopt new approaches for such task, we need to design, implement and test system policies on multitude of NUMA platforms with different topologies and characteristics to see the impact of them on the overall system performance. Get access and manipulate those resources is not always available with low cost. To achieve this goal, simulation brings the solution.

In this paper, we present HLSMN, a high level multithreaded simulator dedicated for NUMA systems in order to build and test the different scheduling and memory management policies on such platform and analysis of the impact of their combination on its performance. The simulator is based on HWLOC to describe the topology (based on this description, it generates its object model) and with concurrent multithreaded design to speed-up its process.

The rest of this paper is organized as follows. Section 2 shows the main characteristics of NUMA architecture. Section 3 gives an overview of related works especially the first version. Section 4 explains the design and architecture of improved simulator and summarizes its main characteristics. Section 5 tests and evaluates some simulation scenarios of combining the different policies. Section 6 concludes this paper.

2. NUMA Architecture

NUMA is multicore multisocket shared memory architecture with identical processors (NUMA node) connected to a scalable network, and each processor has a portion of memory attached directly to it and processor can have mappings to memory connected to other processors with high cost than directly connected to it.

Figure 1. (a) NUMA platform architecture (b) Two CPU-Sockets

connected by QPI

This situation introduces classification of local memory and remote memory based on access latency to

ELECTROTEHNICA, ELECTRONICA, AUTOMATICA (EEA), 2017, vol. 65, nr. 3

171

different memory regions seen from each processor and makes the data locality (placement of threads data) more sensible to this characteristic. This classification defines hierarchical memory of this platform. With these features, NUMA has a major advantage of being scalable.

Figure 1(a) shows typical NUMA architecture with Pi as it nodes and private RAM module associated to each node. All nodes are connected by interconnection network (ICN) which is responsible for routing communication requests among different entities. As example of such platform, the Nehalem [1] architecture consists of basic building blocks. The main blocks are a microprocessor core (with its own L2 cache), a shared L3 cache, an Integrated Memory Controller (IMC) that connects it to its own memory banks, and graphics core, a Quick Path Interconnect (QPI) [2] bus controller that connects it to other NUMA node.

Figure 1(b) shows two Nehalem CPU-Sockets connected by QPI which also connects them to I/O hub and to DDR3 RAM banks through IMC [3]. Each processor can access any data elements across the shared interconnection network. Furthermore, NUMA platforms use specialized cache coherency protocols that try to reduce the amount of communication between the processors [4]. It is necessary for operating systems to exploit NUMA-architectures that can be scaled up/down flexibly in modular based on the interconnection technologies such as Intel QPI, AMD HC [5] and Infiniband [6] in efficient way.

In order to use efficiently platform, the operating systems and applications must be aware of running inside this hardware. In this case and to achieve this awareness, OS must use some tools to gather the maximum of information about NUMA target characteristics (topologies).

The Portable Hardware Locality (HWLOC) [7] software package provides a portable abstraction (across OS, versions, architectures, etc.) of the hierarchical topology of modern architectures including NUMA memory nodes, sockets, shared caches, cores and simultaneous multithreading. It also gathers various system attributes such as cache and memory information as well as the locality of I/O devices such as network interfaces, Infiniband HCAs or GPUs. It primarily aims helping OS and applications with gathering information about hardware in order to exploit them accordingly and efficiently in managing system resources.

Figure 2 shows the topology of the underlying NUMA platform with several informations; memories size, caches size, links latency extracted by HWLOC tool, then it makes them available to the OS and applications to take benefit.

Figure 2. Partitions of devices in Remote Device Management

(RDM)

The two main management policies of NUMA aware operating system are scheduling and memory data mapping (placement). The following section details the role of such policies

2.1 NUMA scheduling policies

For this aspect, NUMA uses adapted scheduling techniques assign different threads to nodes and their cores. As example of those techniques, we can cite:

A- Round Robin Scheduling (RRS)

In order to schedule processes fairly, a round-robin scheduler employs time sharing, giving each job a time slot, and interrupting it if not completed by then. It is resumed next time a time slot is assigned to its process. By using Round Robin on a NUMA platform, The CPU scheduler is further responsible for keeping a process and its data co-resident on the same NUMA node. This is important with regards to performance as it helps reduce remote memory access latency and promote cache sharing [8].

B- Load Balancing Aware Scheduling (LBS)

Obviously an important goal in a multiprocessor system is to balance the load between processors, so that one processor won't be sitting idle while another is overloaded, it is also called Less Load Scheduling, as we are going to assign a task to the core that is idle or less loaded. Systems using a common ready queue are naturally self-balancing, and do not need any special handling. Most systems, however, maintain separate ready queues for each processor. Balancing can be achieved through either push migration or pull migration. This task of moving processes from processor to processor to achieve load balancing works against the principle of processor affinity if not carefully managed. When placing a new thread, the kernel picks the least loaded NUMA node, and then the least loaded core on that node, etc. Moreover, the kernel places threads onto resources: sockets, cores, pipelines, etc. Without regard to the threads process membership. In this class we can cite the NUMALB algorithm, it is a List Scheduling, greedy algorithm, that picks the heaviest (largest execution time) unassigned Chare and assigns it to the core that presents the smaller cost. The choice for a greedy algorithm is based on the idea of fast convergence to a balanced situation by mapping the greatest source of imbalance first [9].

2.2 NUMA mapping policies

Memory management policies in NUMA architectures should be targeted to address the disparity between access times for data located in caches, local memories and remote memories. The most important policies are:

A- Round Robin Allocation (RR)

In this allocation scheme, pages of data are allocated in a Round Robin fashion across the nodes. A page i is allocated to memory i Modulo N, where N is the number of memory modules in the system. The distribution of the pages is extremely uniform thus smoothening out the traffic generated in the network and in most cases making sure that simultaneous accesses to different data from different processors are interleaved among the different nodes. However, the scheme does not place data intelligently enough to reduce the number of


172

remote accesses. Since the distribution is regular in most scientific applications, many processors tend to access multiple pages on the same node in a given time interval. This queues up requests at the network interface and the memory subsystem [10].

B- First Touch Allocation (FT)

In this allocation scheme, each page is located at the processor that first accessed the page. In other words, at the time of the first page fault, it is allocated to the local memory of the faulting processor. The advantage to this scheme is that each page is positioned with limited knowledge of initial application behaviour. A well-written application can exploit the use of this scheme and certainly gain in performance. On the other hand, this scheme notices only the first access to the page. Poorly written applications (e.g. initializations performed at a single processor before main parallel computation begins) will locate pages based incorrectly on the first access and cause remote memory accesses during later accesses to the page by other processors. The First Touch scheme is the default policy, which is provided in Linux system (RR is a super user choice) [10].

3. Related works

Simulation becomes an important tool to scientific computing to build and design model in earlier stage. The embedded systems and computer architecture becomes the field where this approach is used intensively to avoid design problems or improve it. Last years, several generic simulators suitable for all purpose system were developed as example Simics [11], GEMS [12] and M5 [13]. Simulators dedicated for specific architectures have also been developed. e.g., tools for shared memory, multicore, manycore and NUMA architecture which include a specific component that exposes main functionalities of these platforms.

RSIM [14] [15] (Rice Simulator for ILP Multiprocessors) is an execution driven low level simulator for multiprocessor systems with directory based cc-NUMA. it emphasizes on accuracy and it can only simulate mesh network and directory-based cache coherence mechanism.

SIMT [16] is a simulation tool for NUMA machines which relies on another tool Augmint [17] to provide memory reference data, and mainly focuses on memory hierarchy such as cache misses and cache invalidations. It ignores interconnection networks using constants as communication latencies and estimated time to model the execution time of instructions.

Graphite [18] is an Open Source, distributed parallel simulator for multicore architectures of MIT, it is designed from the ground up for exploration of future multicore processors containing dozens of hundreds, or even thousands of cores. It is capable of accelerating simulations by distributing them across multiple commodity Linux machines.

MCoreSim [19] for manycore and multicore platforms using Omnet++

SimNUMA [20] is an execution-driven, full-system simulator dedicated for NUMA-architecture systems. Its main characteristics include: using the same type of processor with the target machine in the host system and a new method to capture and simulate remote-memory accesses. It models different kinds of interconnection networks.

There are more specific simulators dedicated to one module, functionality or modeling certain aspect of the NUMA platform as cache coherence protocol simulation or performance modeling. SICOSYS [21] which is an integrated framework for evaluating the interconnection network performance. It is a general-purpose interconnection network simulator. Memphis [22] is tool to find and fix NUMA-related performance problems on multicore platforms.

Most of these are low level simulators model the basic elements of these systems and it focus on internal structure and instruction execution process in more details (hardware architecture). This aspect makes the simulation process more complex and hard to manipulate high level policies such as threads scheduling and data placement. Their overhead is important compared to useful works (simulated model).

4. HLSMN- Simulator design and architecture

In this section, we will address the design and the architecture of our simulator, discussing its structure and the most important interactions between its modules. It has three major components or parts. The first part is an object model representing NUMA platform is built based on topology information passed as parameter and which contains all core components and exposes main functionalities offered by NUMA platforms. The second one is the simulation kernel which is responsible of the interaction with this model to drive the simulation process. The Third is application pattern generator, its main task is to generate set of tasks with their associated data to model an application submitted to the platform target.

In this work, we assume the following assumptions: H1- The set of tasks of the tested application are

independent and no precedence relation exist among them.

H2- No shared data between the sub tasks of simulated application. All data are private to the current sub task.

Figure 3 shows clearly the three parts as global structure of HLSMN, their interaction and input/output of each stage.

Figure 3. Architecture of HLSMN simulator and NUMA object

model structure

4.1 NUMA Object model

This model is inspired from the Xml DTD of HWLOC tool. We perform the reverse process of HWLOC, this tools generates the XML based description of a real target platform to be used by the scheduler. In our case, we will take such description and build object model that correspond to the target platform.


173

The object model is composed of several modules including:

- Machine: is the main module to be instantiated to use the model. It connects all other modules in appropriate way based on the description of the topology.

- HierarchicalNode: is an interface that abstracts the hierarchical structure of such platform. As memory hierarchy is structured as tree and it is more complex in NUMA, Each element in this architecture is considered as node in this tree (memory banks, caches, core,..) then they share the same tree connected entities functionalities (access root or parent, get children, notify root or parent,etc.). So this interface is designed to define them.

- NumaNode: the most important entity in the machine that models the NUMA element. It will be connected to the interconnection network and it behaves alone as SMP entity.

- Socket: package of processor contains the computing units (cores) and the rest of memory hierarchy caches of different levels.

- Core: the basic computation unit that executes the threads associated to application tasks.

- Interconnection: a special network to connect NumaNodes and routes the messages between the different entities.

- Memory: storage units associated to one NumaNode. It is the local storage for this associated node with low latency and high bandwidth for in contrary to other not directly connected nodes (remote node) where latency is high and bandwidth is low.

In figure 4, the class diagram exposes the architecture of NUMA object Model of HLSMN with its core components showing relationship between classes within NUMA package.

Figure 4. NUMA Object Model class diagram

Each class either implements the interface HierarchicalNode or extends another class that implements it, so they inherit the same properties and behaviors. Based on this interface, we can identify parents and children in the hierarchy by calling getParent() and getChildren() and getting in return HierarchicalNode objects.

Topology loader module is responsible for loading the topology to be simulated. After loading correctly associated file, it shows the structure in the topology viewer (Figure 3. (b)). Then based on this structure, it

creates the object model by instantiating an object of type Machine and makes it as the root of the hierarchy. Each component of the topology has it own representing class that is initialized and that invokes another method to build sub elements or children in this order:

− getNUMAFor() calls getSocketFor() and getMemorFor()

− getSocketFor() calls getCacheFor() − getCacheFor() calls getCoreFor() − getCoreFor() calls getPUFor()

4.2 Application Generator

In order to run different simulation scenarios, we designed application patterns generator. Its task is to generate randomly set of tasks based on given template (pattern). Application pattern or template consists of set tasks with some computational characteristics and communication need to represents class of real parallel applications that share the same profile (application with more computation and less communication, or communication intense) and specifies which data and how much needed during the execution. Based on this pattern, this module will generate an application instance to be passed to the object model.

4.3 Simulation kernel

This module is the heart of the simulator. It is the kernel which is responsible for managing simulation processes, synchronizing the events and ensuring communication between simulation entities. during startup of the simulator and after loading the topology and generating tasks/data (instance), the configuration module obtains various kinds of parameters about target machine from the object model, such as number of processors, memory size, interconnection parameters such as type, topology, bandwidth, routing policy, etc. and application instance structure and details. The policy executor module tries to play each policy on the given instance of the application to take some decisions. Launch the process of the simulation of application running on the target NUMA platform. By applying the scheduling policy on tasks and allocating cores for them. Then it maps the associated data on node memories using data placement policy. Finally, launch each task on the allocated core. It is based on the capture of occurred events on each object of the object model and forwarding and notifying the interested parts to the occurred events. As modules run concurrently each one in its working threads (cores, memories, interconnect), it ensures the synchronization and communication between them to access shared resources (queue events).

Since it is important and critical in simulation process to keep its history, we have designed along with the simulator some other tools to help us with this task by logging simulation events and collecting statistics of played simulations. We have integrated two tools, these are:

Remote Access Graph which will keep trace which task access which data and where and it shows in real-time the remote communications of tasks to manipulate the data which are not in their local memory, if a task_i scheduled on node_i’s core requires data_j placed in the memory of node_j a line from i to j is drawn, the color of the line is determined by the policy used during the execution.


174

Policy execution speed chart is a stand-alone tool that draws charts of execution times for a policy; this last defines the color of the chart. The data used to draw these charts is acquired from history file created by the simulator. The y axis represents the execution time and the x axis shows stored information of previous executions, this information are the number of data and tasks generated for this execution with a policy and the length of the chart is the execution time for that configuration.

5. Simulation process

Specific simulation scenario consists to configure the simulation environment settings by specifying the target topology, Application template to create an instance, choosing the scheduling and memory mapping policies to apply on tasks and data. Then we launch the experimentation using the specified settings. Finally, we collect the results of this simulation by logging the events of simulation kernel.

5.1 Configuration

This step consists to set the configuration information used during the simulation process. The most important parameters are:

− Target topology: is set through the topology loader by reading its XML configuration file.

− Application pattern: specified in the application generator. By reading the desired parallel application features, this generator creates an instance with the specified number of independent tasks with grain size predefined and associated private data.

− Scheduling & Mapping policies. In order to allocate the computing units and place data on node memories, we implement the policies to be evaluated and tested.

By combining the different parameters values, this configuration already gives us an unlimited number of possible scenarios. Each specific configuration setting is named and considered itself as simulation scenario. As example, simulation scenario with the following settings target topology that correspond to the figure 3, application patterns of medium sized grain independent tasks with less communication (low R/W data operations), and round robin scheduling with first touch placement policies represents an experiment to be played on HLSMN and collecting the statistic of its simulation.

5.2 Experimentation and results analysis

At this section, we will go through experimentation and evaluation process of specific simulation scenarios as described above. For the purpose of such experimentation, we have implemented:

− Two scheduling policies: Round Robin Approach (TRR) & Less Load Heuristic (TLL)

− Two placement strategies: First Touch Policy (DFT) & Round Robin Allocation (DRR)

Our experiment consists of testing all the possible combined implemented scheduling and mapping policies with two different generated applications (synthesized applications based on parallel application pattern) AP1 et AP2 (the first on contains 50 independent tasks with its associated data and second one with 250 tasks) this will give us 8 different scenarios [TRR, TLL] x [DRR, DFT]

x [AP1, AP2]. And as result, we are interested in the total execution time and the number of remote access memory in each scenario.

Experiments are repeated several times taking the mean values of results at end.

In figure 5, we see what the remote data access graph has as output after playing both scenarios. It shows that the combination DFT-TRR (green) has less remote data access (access to data located on memory of other nodes shown by line connecting local request of loading data and remote response of sending data).

Figure 5. Remote Access memory trace

Its shows that number of drawn lines corresponding to remote access memory in case of DFT-TRR is less than others followed by DRR-TRR (red) combination, compared to the density of the blue and yellow lines, which represents respectively DRR-TLL and DFT-TLL.

In figure 6, we see the execution time of applications for different scenarios, in both scenarios.

Figure 6. Total execution time in each scenario

DRR-TLL takes much time to complete its job (running all submitted tasks) comparing to others combinations. DFT-TLL has longer executing time in scenario 250 tasks and less time in the second one. In both scenarios, DFT-TRR takes less time to complete the execution of all tasks.

6. Conclusion

As NUMA machines are becoming widely spread many operating systems, schedulers are considered to work with NUMA platforms and take advantage of them. In this work we have focused on the fundamental aspects that could help the research in this field to update or build a NUMA aware scheduler or memory manager. In this paper, we have designed and implemented HLSMN a high level simulator of multicore NUMA platform that allows focusing on algorithmic aspect of policies and hiding low level details. HLSMN exposes NUMA model with main parts computing node, interconnect and memories hierarchy, allows to implements and tests different


175

policies for scheduling and data mapping, run simulation process and captures the total execution time of tasks and the remote memory access as the most important factors in such context. Based on these factors we have used this simulator to measure the impact of combining the different policies scheduling & mapping (round robin and first touch,..) of the overall system performance in term of total execution time and number of remote access memory. Even if this initial model is mach simplified simulator by discard some aspects and make restriction on thread locality (no migration) and with basic assumption tasks dependency, as future work we will include other factors such as tasks migration.

7. References

[1] Intel Corp, First the Tick, Now the Tock: Intel® Microarchitecture (Nehalem) White paper 2009. http://www.intel.com/content/dam/doc/white-paper/intel-microarchitecture-white-paper.pdf.

[2] Intel Corp, An Introduction to the Intel QuickPath Interconnect, 2009, www.intel.com/ technology/ quickpath.

[3] M. Thomadakis, The Architecture of the Nehalem Processor and Nehalem-EP SMP Platforms, Research Report, SCF - Texas and M University 2011.

[4] P. Lakovos, NUMA effects on multicore multisocket systems. MSc Thesis, University of Edinburgh, 2011.

[5] AMD Corp, HyperTransport Technology I/O Link A High Bandwidth I/O Architecture. 2001, http://www.hypertransport.org/docs/wp/25012a_htwhite_paper_v1.1.pdf.

[6] A.R. Mamidala L. Chai H. Jin, D. K. Panda, “Efficient SMP-Aware MPILevel Broadcast over InfiniBand's Hardware Multicast”, IEEE International Parallel and Distributed Processing Symposium(IPDPS), 2006.

[7] F. Broquedis, J. C. Ortega, et al. “HWLOC: A Generic Framework for Managing Hardware Affinities in HPC Applications” 18th EICPDNBC, Pisa Italy, 2010

[8] Raman, P.K. Mittal, “An Efficient Dynamic Round Robin CPU Scheduling Algorithm”, IJARCSSE vol4-i5 2014.

[9] K. Wang, K. Qiao, Load-balanced and locality-aware scheduling for data intensive workloads at extreme scales, CCPE 2015.

[10] R. Iyer; H. Wang, L. Bhuyan, “Design and analysis of static memory management policies for CC-NUMA multiprocessors”, JSA 48 2002, pg: 59-80.

[11] P. S. Magnusson, M. Christensson, J. Eskilson, et al, “Simics: a full system simulation platform”, IEEE Computer, 2002, 35(2), pg:50-58.

[12] M. Martin, D. J. Sorin, B. M. Beckmann, et al, “Multifacet's general execution-driven multiprocessor simulator (GEMS) toolset”, ACM SIGARCH Computer Architecture News, 2005, 33(4): 92-99.

[13] N. L. Binkert, R. G. Dreslinski, L.R. Hsu, et al. “The M5 simulator: modeling networked systems”, IEEE Micro, 2006, 26 (4), pg: 52-60.

[14] V. S. Pai, P. Ranganathan, and S. V. Adve. “RSIM: An Execution- Driven Simulator for ILP-Based Shared-Memory Multiprocessors and Uniprocessors”, Proc. of the Third Workshop on Computer Architecture Education, Feb. 1997.

[15] C. J. Hughes, V. S. Pai, P. Ranganathan, S. V. Adve, “RSIM: Simulating Shared-Memory Multiproeessors with ILP Proeessors”, IEEE Computer, 2002.35(2), pg: 40-49.

[16] J. Tao, M. Schulz, and W. Karl, “SIMT Simulation as a tool for optimizing memory accesses on NUMA machines”, Performance Evaluation, 2005, 60(1-4), pg: 31-50.

[17] A. T. Nguyen, M. Michael, A. Sharma, J. Torrellas, “The Augmint Multiprocessor Simulation Toolkit for Intel ×86 architectures”, International Conference on Computer Design, IEEE Computer Society, October 1996, pg: 486–491.

[18] J. E. Miller, H. Kasture, et al, “Graphite: A Distributed Parallel Simulator for Multicores”, MIT-CSAI-Lab Technical report 2009.

[19] S. Kumar, T. Cucinotta, G. Lipari, “A Latency Simulator for Many-core Systems – McoreSim”, ACM NSS 11 SCSI 2011, pg: 151-158.

[20] Y. Liu, Y. Zhu, et al, “SimNUMA: Simulating NUMA-Architecture Multiprocessor Systems Efficiently”, PDS ICPADS; 2013 Seoul, pg: 341-348.

[21] V. Puente, J.A. Gregorio, R. Beivide, “SICOSYS: An Integrated Framework for studying Interconnection Network Performance in Multiprocessor Systems”, Proc. of Parallel, Distributed and Networkbased Processing(PDP) , 2002: pg: 15-22.

[22] M. Collin, V. Jeffrey, “Memphis: Finding and fixing NUMA-related performance problems on multicore platforms”, Proc. IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), 2010, pg:87-96.

Biography

Mohamed Slimane is a Ph.D. candidate in Department of Computer Science; University of Oran, Algeria. He received his Ms.Bc degree in scheduling and mapping distributed applications from the Havre University, France.

His current research area includes Flexible Manufacturing Systems Modeling, Scheduling Problems, distributed and parallel programming, and simulation. Correspondence address: [email protected]

Larbi Sekhri is a Professor at the Computer Science Department of Oran University. He is a member of the Industrial Computing and Networking Laboratory at Oran University. He has been a visiting professor at

Cedric-CNAM research laboratory, in Paris, France, and Ecole Centrale de Lille (LAGIS) where he worked in Diagnosis of Industrial systems; and LIUPA Laboratory at the University of Pau, France; and distinguished lecturer at University of Ottawa, Canada. His current research area of interests include formal modeling in distributed and mobile systems, wireless ad-hoc and sensor networks, systems modeling using Petri nets, diagnosability and monitoring of automated production systems. Correspondence address: [email protected], [email protected]

Résumé

Les algorithmes d'ordonnancement des graphes de tâches (DAG) selon l'approche classique se concentrent davantage sur les tâches de calcul et leurs dépendances (communication) et donnent moins d'importance au placement des données lors de l'allocation. Dans le contexte des plateformes hiérarchiques, ne pas placer les données des threads de façon appropriée impacte les performances du système. Avec l'introduction des architectures d'accès non uniforme à la mémoire (NUMA), l'optimisation simultanée du placement des threads et des données d'un DAG est devenue cruciale. Une telle architecture possède un système de mémoire hiérarchique multi niveaux avec des caractéristiques différentes qui rend le coût de la communication différent dans chaque niveau. Une bonne partie du temps des tâches dépendantes orientées données se consomme en chargeant ou sauvegardant ses données de la mémoire en fonction du placement initial. Les performances d'un tel système et son ordonnanceur dépendent non seulement de sa décision d'affectation des threads mais aussi de sa décision du placement des données. Dans cette thèse, nous abordons le problème de l'ordonnancement d'applications parallèles décrites par un DAG sur la plateforme cible en explorant le cas où non seulement le calcul et la communication sont considérés, mais aussi le placement de données sur les plateformes hiérarchiques. Les politiques courantes de l'ordonnancement et l'allocation de la mémoire tentent d'atténuer l'effet NUMA en réduisant la pénalité d'accès distant à la mémoire en tenant en compte la localité des données lors de la décision de l'ordonnancement. Ce travail propose de 1. Inclure l'information sur la topologie (fournie par l'environnement runtime au début de l'exécution de l'application) de la plateforme. 2. Utiliser le motif de l'application (sa classe information fournie par le développeur de l'application) à exécuter.3. Regrouper les tâches dans des classes disjointes en se basant sur cette structure et l'état de la tâche.4. Elargir le champ de visibilité des tâches en explorant un large horizon an de collecter plus d'informations sur l'état courant du processus d'exécution de DAG.5. Equilibrer la charge au temps d'exécution en utilisant la stratégie de vol de travail basée sur la distance. Comme idées de bases, ces propositions seront intégrées comme heuristiques dans la politique de l'ordonnancement des threads et le placement des données pour guider ce processus et l'aider à réduire l'effet NUMA sur le temps total d'exécution d'un DAG et de préserver les performances du système.

Mots-clés :

Graphe acyclique dirigé DAG; Ordonnancement DAG; Placement; Localité de données; Machines multicore;

Architectures NUMA; Plateformes hiérarchiques; Equilibrage de charge; Horizon d’exécution; Facteur NUMA.

Soutenue le 20/12/2018

Documents

INFORMATIQUE Ordonnancement d'un DAG avec transfert des ... · Ordonnancement d'un DAG avec transfert des données sur une plateforme NUMA multicore Présentée par Slimane Mohammed