Vue sch´ematique de l’architecture de base

FIG. 4.1 – Vue sch´ematique de l’architecture de base

tensibilit´e des bus est tr`es limit´ee, et la complexit´e des crossbars devient trop importante

pour le nombre de processeurs vis´e.

La topologie utilis´ee est un maillage 2D puisque cette derni`ere a un bon ratio temps de

travers´ee/complexit´e, et a de bonnes propri´et´es pour le passage sur silicium.

Le composant de mesure du temps utilis´e compte un cycle pour 200 cycles de

simula-tions. Aussi, les valeurs pr´esent´es en cycles sur les graphes ne sont pas `a prendre comme

des cycles de simulations, mais doivent d’abord ˆetre multipli´ees par 200 pour cela.

Il aurait ´et´e int´eressant d’utiliser une m´emoire de typescratch-padau lieu d’une m´emoire

reli´ee au r´eseau local (i.e. une m´emoire connect´ee directement au processeur par

l’in-term´ediaire d’une interface d´edi´ee [PDN97]), mais cela n’a pas ´et´e explor´e car ´etant une

limitation des mod`eles disponibles dans l’environnement de simulation. Cependant, du fait

de la latence du crossbar local, les comportements temporels de ces deux solutions auraient

´et´e relativement proches.

L’espace d’adresses vu par les processeurs est partitionn´e en un ensemble de segments.

Un ou plusieurs segments peuvent ˆetre associ´es `a un p´eriph´erique ou une m´emoire, en

respectant les contraintes suivantes : les segments associ´es `a un p´eriph´erique ne peuvent

pas ˆetre cach´es, et les segments d’une mˆeme m´emoire doivent avoir le mˆeme attribut de

cachabilit´e (cach´e ou non).

Pour r´esumer, l’espace de conception mat´eriel qui sera explor´e dans notre ´etude

con-sistera principalement `a l’´evaluation de la mani`ere dont les DMAs et/ou les caches

peu-vent am´eliorer la localit´e des donn´ees et comment le placement physique des verrous peut

acc´el´erer la synchronisation.

4.2.2 Syst`eme d’exploitation et assignation des tˆaches

Nous utilisons la configurationordonnanceur d´ecentralis´e (DS) d’un noyau l´eger appel´e

multi-Chapitre 4 Performances du vol de travail et ´etude de propri´et´es architecturales

processeurs `a m´emoire partag´ee. Contrairement `a la configuration SMP dans laquelle tous

les processeurs partagent un seul ordonnanceur pour accomplir la s´election des tˆaches, la

configuration DS limite grandement la congestion puisque chaque processeur poss`ede son

propre ordonnanceur. Les tˆaches peuvent ˆetre fix´ees sur un processeur d´esir´e afin d’´eviter

la migration. Dans ce cas, chaque thread est assign´e `a un processeur `a sa cr´eation. Les piles

des threads et les donn´ees locales sont situ´ees dans les m´emoires locales des processeurs.

Toutes les exp´erimentations pr´esent´ees dans cette partie sont faites en utilisant cette

mˆeme configuration du syst`eme.

4.2.3 Crit`eres de s´election et choix du micro-kernel

Afin de r´epondre aux diff´erents probl`emes d´efinis, nous avons choisi de faire dans un

premier temps nos exp´erimentations avec un micro-kernel. Le choix de ce micro-kernel a ´et´e

motiv´e par trois points.

Premi`erement, de mani`ere `a ´evaluer le surcout du vol de travail par rapport aux

ap-proches classiques des syst`emes embarqu´es, le micro-kernel doit permettre la calibration

d’applications pour lesquelles une parall´elisation optimale est connue. Deuxi`emement, les

applications multim´edia demandent beaucoup de ressources en calcul et en

communica-tion : le micro-kernel doit donc avoir un grain fin et ˆetre repr´esentatif d’une classe

d’ap-plications multim´edia tels que les filtres num´eriques ou les transform´ees. Troisi`emement, il

doit permettre une analyse th´eorique sur l’impl´ementation du vol de travail afin de donner

un retour sur les exp´erimentations.

Nous avons s´electionn´e un micro-kernel satisfaisant ces contraintes, qui consiste `a faire

des op´erations ind´ependantes sur les ´el´ements d’un tableau, dont le contenu constitue

l’entr´ee et la sortie du programme. Ce tableau est allou´e en m´emoire partag´ee.

En consid´erant une op´eration de traitement quasiment nulle sur chaque ´el´ement, cela

donne au micro-kernel un tr`es haut ratio communicationvs.calcul, ce qui permet une

anal-yse du surcout du vol de travail en nombre de cycles. De plus, en consid´erant un nombre

de processeurs identiques et un temps de traitement de chaque ´el´ement constant, ce surcout

peut ˆetre compar´e au nombre de cycles de la parall´elisation standard statique, d´enot´ee PAR :

les donn´ees d’entr´ees de taille n sont partag´ees de mani`ere ´egale entre lesp processeurs,

chaque processeur ´etant donc en charge d’un bloc contigu de taille ⁿ_p.

4.3 Analyse th´eorique du temps parall`ele pour le micro-kernel

La simplicit´e du micro-kernel choisi et de son impl´ementation permet une analyse

th´eorique. Les notations suivantes sont utilis´ees : comme d´efini dans le chapitre 3, Tseq,

T_p et T∞ d´enotent respectivement le temps d’ex´ecution s´equentiel, le temps d’ex´ecution

parall`ele sur pprocesseurs et le chemin critique, i.e. le temps d’ex´ecution parall`ele sur un

nombre non born´e de processeurs (sans tenir compte des synchronisations finales). On

sup-pose que le temps de calcul τ d’un ´el´ement v´erifie τ_min ≤ τ ≤ τ_max. Nous consid´erons

aussi dans cette section que le cache d’instructions peut contenir toute l’application et nous

restreignons notre analyse au cache de donn´ees.

4.3.1 Analyse th´eorique pour le PAR

Consid´erons d’abord le nombre de d´efauts en cache de donn´ees. Soit M_seq le nombre

de d´efauts de l’ex´ecution s´equentielle, qui correspond au parcours lin´eaire du tableau.

Dans l’ex´ecution PAR, chaque processeur ex´ecute l’algorithme s´equentiel sur sa partie

4.4 Param`etres de l’architecture

des donn´ees. Ainsi, le nombre de d´efauts de cacheM_p^{P AR} par processeur v´erifieMseq ≤

p×M_p^{P AR} ≤ Mseq +p. Puisque p ≪ Mseq, le surcout induit par les d´efauts de cache en

parall`ele est n´egligeable.

Le temps d’ex´ecution T_p^{P AR} est donc ´egal au temps d’ex´ecution de la portion des

donn´ees prenant le plus de temps pour ˆetre calcul´e. En supposant un temps constant pour

le calcul de l’op´eration d’un ´el´ement, on a :

T_p^{P AR}≃ ^Tseq_p . (4.1)

Dans le cas g´en´eral dans lequel le temps de calcul d’un ´el´ement peut varier, on a

seule-ment :

Tseq

p ≤T_p^{P AR}≤ ^τ_τ^max

min

Tseq

p ^. (4.2)

4.3.2 Analyse th´eorique pour AWS

Pour AWS, on noteτstealune borne sur le temps d’une op´eration de vol (qui r´eussit ou

qui ´echoue) sur un processeur donn´e. Ce surcout li´e `a AWS est reli´e au nombre totalS de

vols, qui est proportionnel `aT∞.

Du fait de l’initialisation, de l’extraction de la moiti´e du travail lors des vols et de

l’ex-traction locale delog2 du travail restant, on a que :T∞=O(log2Tseq).

De plus, du fait de la recherche cyclique d’un processeur victime, le nombre total

d’op´erations de vol estS =O(p×T∞).w.h.p., et dans le pire des cas :

S =O(p²×T∞). (4.3)

De la mˆeme mani`ere que pour le PAR, le nombreM_p^{AW S} de d´efauts de cache par

pro-cesseur pour le parcours du tableau est born´e au pire des cas par : le nombre Mseq de

d´efauts de cache de l’ex´ecution s´equentielle, plus au plus deux d´efauts suppl´ementaires

apr`es chaque op´eration de vol r´eussie – un sur le processeur voleur pour charger la

nou-velle partie du tableau, et un sur le processeur vol´e pour mettre `a jour son travail local.

Nous avons donc ainsi :Mseq ≤p×M_p^{AW S} ≤Mseq+ 2S.

Il est `a noter que dans le cas du micro-kernel choisi, le processeur qui effectue une

op´eration de vol est consid´er´e en attente, et n’a par cons´equence pas de donn´ee utile dans

son cache. C’est pourquoi on peut ignorer les d´efauts de cache avant un vol r´eussi. Le temps

d’ex´ecution finalement attendu est donc de :

T_p^{AW S} = ^Tseq

p +O(S) = ^Tseq

p +O(p²×T∞). (4.4)

On remarque entre autre que le surcout li´e aux vols (et notamment `a la synchronisation

finale) est proportionnel au carr´e du nombre de processeurs.

4.4 Param`etres de l’architecture

Au-del`a de l’analyse th´eorique, les performances effectives pour le PAR et AWS sont

fortement relatives `a la configuration mat´erielle. `A grain fin, le micro-kernel fait beaucoup

Chapitre 4 Performances du vol de travail et ´etude de propri´et´es architecturales

Un des moyens pour am´eliorer les performances est de faire se recouvrir les calculs et les

communications. Dans le contexte de notre ´etude, cela peut consister `a utiliser les m´emoires

locales pour r´eduire la latence d’acc`es `a la m´emoire principale : en utilisant un DMA, il

est possible de copier les donn´ees de la m´emoire principale vers la m´emoire locale d’un

processeur tandis que ce dernier est en train de faire des calculs. L’utilisation de caches sera

aussi ´etudi´ee, ainsi que l’utilisation jointe de caches et de DMAs.

Par ailleurs, dans AWS, des op´erations de synchronisation suppl´ementaires sont

n´ecessaires du fait des appels `a extract par() et des vols, n´ecessitant entre autres

des prises de verrous. En l’occurrence, acc´eder un verrou lors de chaque op´eration

extract seq() peut se r´ev´eler peu efficace `a grain fin. Puisque la plupart des acc`es sont

locaux, on peut esp´erer que distribuer les verrous et les structures sur les r´eseaux

d’inter-connexion locaux r´esulte en une r´eduction du temps de latence moyen.

4.4.1 Utilisation de DMAs

Afin d’explorer l’usage de DMAs, l’architecture de base est modifi´ee par l’ajout d’une

unit´e de DMA sur chaque r´eseau local (figure4.2). De cette mani`ere, les donn´ees en entr´ee

pour un processeur peuvent ˆetre acc´ed´ees dans la m´emoire locale au lieu de la m´emoire

partag´ee. L’allocation dans les m´emoires locales est rendue possible grˆace `a un appel

syst`eme sp´ecifique.

TTY

c

a

c

h

e

Processeur 0

INST. DON.

SPARC V8

DMA

Mémoire locale

Pont

TTY

Processeur p-1

INST.DON.

SPARC V8

DMA

Mémoire locale

Pont

. . . .

Timer

Module de locks

Mémoire partagée 0 Mémoire partagée 1

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