Pa 04

UNIVERSIT de PARIS-SUD
U.F.R. SCIENTIFIQUE d'ORSAY
THSE
prsente pour obtenir

Le GRADE de DOCTEUR en SCIENCES
de l'UNIVERSIT de PARIS XI ORSAY
Spcialit :
Informatique
par
David PARELLO
Sujet :
Mthodologie d'optimisation de programmes
pour architectures complexes de processeurs
soutenue le vendredi 17 septembre 2004 devant le jury compos de :
M. Olivier TEMAM
Universit de Paris-Sud
Directeur
M. Franois BODIN
Universit de Rennes 1
Rapporteur
M. Pascal SAINRAT
Universit Paul Sabatier, Toulouse III
Rapporteur
M. Albert COHEN
INRIA
Examinateur
M. Jean-Marie VERDUN
HP France
Examinateur
Remerciements
Je tiens adresser mes remerciements Franois Bodin et Pascal Sainrat pour avoir accept
d'tre rapporteurs. Je remercie galement les autres membres du jury : Albert Cohen, Jean-Marie
Verdun et Olivier Temam.
Je remercie nouveau Albert Cohen pour les prcieuses connaissances dans le domaine de
la compilation qu'il dissipe autour de lui. Je remercie nouveau Jean-Marie Verdun pour sa
disponibilit et les prcieuses informations et connaissances qu'il m'a apportes. Je remercie Olivier Temam pour m'avoir enseign non seulement la recherche mais galement l'art de partager,
diuser et prsenter son travail.
Je remercie les membres de l'quipe Avant-Vente de HP France pour m'avoir chaleureusement
accueilli. Je remercie galement tous les membres de l'quipe Alchemy pour leur convivialit.
Je remercie ma famille et mes amis pour m'avoir soutenu pendant la thse. Je remercie tout
particulirement mon amie Anne-Lise.
ii
Remerciements
iii
Rsum
L'augmentation de la complexit des processeurs rend de plus en plus dicile l'intgration
de modles prcis d'architectures dans les compilateurs. En consquence, l'ecacit des compilateurs statiques dcrot. Actuellement, les compilateurs statiques sont enrichis d'informations
dynamiques sur le comportement de l'architecture la manire des techniques d'optimisation
bases sur les prols d'excutions ou des techniques de re-compilation dynamique. Malheureusement, seules quelques informations lmentaires sur le comportement de l'architecture sont
utilises.
Dans cette thse, nous montrons de quelle manire les interactions entre les dirents composants d'une architecture rendent complexe le comportement des programmes et nous montrons
qu'il est possible de capturer cette complexit pour en dduire les transformations apporter aux
programmes. Nous avons tudi une mthode plus systmatique pour adresser le problme de la
complexit. Nous proposons un processus itratif d'optimisation manuelle bas sur une analyse
dynamique dtaille. Nous montrons exprimentalement l'ecacit de ce processus.
Cette approche prsente potentiellement une stratgie pour guider de futurs environnements
d'optimisation itratifs et propose, dans l'immdiat, un processus d'optimisation manuelle systmatique pouvant tre utilis par des ingnieurs ou des chercheurs.
iv
Rsum
Table des matires

Remerciements
Rsum
Table des matires
Introduction
1 Architecture et Optimisation
1.1
1.2
Complexit des architectures superscalaires
. . . . . . . . . . . . . . . . . . . . .
i
iii
v
1
5
5
1.1.1
Architecture gnrale du processeur Alpha-21264 (EV68) . . . . . . . . . .
1.1.2
Pipeline du processeur Alpha-21264 (EV68) . . . . . . . . . . . . . . . . .
1.1.3
Cas particuliers d'excutions
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Optimisation de programmes
1.2.1
Transformations de programmes
. . . . . . . . . . . . . . . . . . . . . . .
10
1.2.2
Optimisation automatique . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.2.3
Optimisation manuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
1.3
Synthse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Environnement de travail
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.3
Optimisation du produit de matrices base sur une analyse dynamique dtaille .
24
2.4
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.1
Identication des problmes de performance sur une architecture complexe . . . .
3.2
Normalisation des anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.3
Construction de l'arbre de dcision
2 Optimisation et Analyse dynamique dtaille

3 Processus d'optimisation systmatique
3.5
23
37
37
. . . . . . . . . . . . . . . . . . . . . . . . . .
42
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Processus d'optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.4.1
Description du processus . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.4.2
Dcomposition des problmes de performance . . . . . . . . . . . . . . . .
49
3.4.3
Annulation des itrations
. . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.4.4
3.3.1
3.4
23
Construction empirique
Comparaison avec un compilateur statique . . . . . . . . . . . . . . . . . .
51
Rsultats exprimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.5.1
53
Optimisation du programme wupwise . . . . . . . . . . . . . . . . . . . .
vi
Table des matires
3.6
3.5.2
Association entre anomalies et optimisations . . . . . . . . . . . . . . . . .
57
3.5.3
Squences d'optimisations . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Conclusions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusions et perspectives
Table des gures
Liste des tableaux
A Journaux d'optimisations itratives
A.1
Journal d'optimisation du programme wupwise
A.1.1
Itration 1 :
A.1.2
Itration 2 :
232
210
7! 210 (sec.)
7 80 (sec.) .
!
. . . . . . . . . . . . . . . . . . . . . . . . .
A.2
Journal d'optimisation du programme equake
A.3
Journal d'optimisation du programme applu
A.2.1
Itration 1 :
A.3.1
Itration 1 :
A.3.2
Itration 2 :
A.3.3
Itration 3 :
Bibliographie
290
312
294
211
7! 116 (sec.)
7! 294 (sec.)
7 211 (sec.)
!
7 143 (sec.)
!
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
58
60
62
65
71
71
71
72
81
81
. . . . . . . . . . . . . . . . . . . .
94
. . . . . . . . . . . . . . . . . . . . . . . . .
94
. . . . . . . . . . . . . . . . . . . . . . . . .
99
. . . . . . . . . . . . . . . . . . . . . . . . .
106
110
Introduction
L'augmentation de la performance des processeurs est due d'une part l'avance des techniques de gravure qui permettent d'accrotre la vitesse de fonctionnement des processeurs et d'autre
part l'volution de l'architecture qui intgre de nombreux mcanismes complexes. Ces mcanismes, comme par exemple la prdiction de branchement, l'excution dans le dsordre et la
hirarchie mmoire, ont pour objectif d'acclrer l'excution du programme en exploitant au
mieux le paralllisme des instructions et la localit des donnes. Les optimisations modient les
programmes an qu'ils protent pleinement de ces dirents mcanismes.
Quel que soit le domaine, les excutions des applications sont soumises des contraintes
donnant l'optimisation de programmes toute son importance. Dans le domaine du calcul scientique, les applications de modlisation et de simulation numriques ralisent de grands volumes
de calculs. Aussi bien le secteur de la recherche que le secteur industriel ont besoin de modles
de plus en plus prcis et de plus en plus grands, rclamant sans cesse d'importantes ressources
de calculs. L'optimisation de programmes est donc cruciale pour ces applications an de leur
permettre d'utiliser pleinement ces ressources. La principale contrainte est donc le temps d'excution. Les applications embarques ont la fois des contraintes de temps, des contraintes sur
l'espace mmoire et des contraintes sur la consommation d'nergie. Ce domaine a galement des
besoins croissants notamment avec le rle croissant des applications de traitement de l'image
et du son. La recherche d'une utilisation optimale des ressources est donc primordiale dans le
domaine de l'embarqu.
L'optimisation de programmes
Mme si les contraintes de chaque domaine d'application sont direntes, les techniques
d'optimisation sont trs similaires. L'optimisation de programmes peut se faire de manire automatique ou manuelle.
L'optimisation automatique
Elle est gnralement ralise par un compilateur ou bien un
pr-processeur. Dans chacun des cas, elle consiste eectuer une longue squence de transformations parmi lesquelles certaines sont parfois rptes. A chaque tape de cette squence, la
phase d'optimisation utilise une analyse statique de la reprsentation intermdiaire dans le but
de dcider l'application ou non de la transformation et si oui avec quels paramtres. Les analyses statiques se basent sur des modles de l'architecture et du programme pour en deviner leur
comportement. Les optimisations diriges par l'analyse dynamique apportent des informations
supplmentaires que l'analyse statique ne peut pas obtenir pour apprhender plus prcisment
Introduction
le comportement des programmes.
L'optimisation manuelle
Elle est gnralement ralise lorsque l'optimisation du compilateur
n'est pas satisfaisante. Un utilisateur peut transformer le programme source ou bien intervenir
sur les optimisations du compilateur au travers des options de compilations. Son champ d'actions
est trs vaste : il peut en eet modier l'algorithme, les boucles et galement apporter des modications qui peuvent changer le comportement des optimisations du compilateur (par exemple, il
peut agir sur la gnration de code). Le programmeur peut utiliser des informations sur le comportement du programme lors de son excution pour choisir les optimisations. Par l'exemple, il
peut utiliser des outils de prolage. Gnralement, l'optimisation manuelle est une tche dicile
qui est rserve un petit nombre d'experts ayant une bonne connaissance de l'architecture du
compilateur et des transformations de programmes.
Problmatique
Les mcanismes, comme la prdiction de branchement, l'excution dans le dsordre et la
hirarchie mmoire augmentent la performance crte des architectures. Le comportement de ces
mcanismes volue durant l'excution des programmes gnrant parfois des phnomnes complexes ayant des eets nfastes sur les performances. Par exemple, des conits de mmoire cache
peuvent fortement dgrader les performances. Il est dicile de modliser ces phnomnes et leurs
interactions et donc de comprendre prcisment le comportement des programmes sur les architectures. Par consquent, la comprhension du comportement devient de moins en moins prcise,
empchant ainsi l'optimisation automatique comme manuelle de maintenir des performances
soutenues proches de la performance crte des processeurs.
Contribution et Organisation
Dans le premier chapitre, nous prsentons l'architecture du processeur Alpha-21264 que nous
avons utilis comme cible pour l'ensemble de nos tudes. Nous illustrons galement les mcanismes complexes des processeurs superscalaires et dtaillons des particularits d'excution qui
sont rarement prises en compte lors de l'optimisation de programmes. Ensuite, nous examinons
l'optimisation de programmes.
Le second chapitre prsente l'tude de l'optimisation d'un noyau de calcul sur le processeur
Alpha-21264. Cette tude montre la complexit des phnomnes se produisant au sein d'une
architecture superscalaire lors de l'excution d'un programme. Elle montre que certains problmes
de performance peuvent tre mis en vidence uniquement par une analyse dynamique dtaille
et suggre donc l'adoption d'une telle analyse pour guider un processus d'optimisation ecace.
Le troisime chapitre prsente un processus systmatique d'optimisation manuelle bas sur
l'analyse dynamique dtaille. L'identication des problmes de performances base sur une
analyse dynamique dtaille est systmatique et formalise par un arbre de dcision. Ce dernier
permet de formaliser l'exprience empirique de l'optimisation manuelle. La nature itrative du
processus permet de construire des squences d'optimisations et permet ainsi d'adresser plusieurs
Introduction
problmes de performances. L'application de ce processus un ensemble de programmes de la

suite SpecFP2000 montre son ecacit.
Finalement, nous prsentons les conclusions et les perspectives de ces travaux.
En annexe, nous prsentons les journaux d'optimisation de 3 des 11 programmes optimiss.
Ces journaux dtaillent l'optimisation itrative ralise en utilisant le processus d'optimisation
prsent dans le chapitre 3.
Introduction
Chapitre 1
Architecture et Optimisation
Nous avons brivement prsent l'optimisation manuelle et l'optimisation automatique. Dans
la section 1.1, nous dcrivons l'architecture d'un processeur superscalaire complexe. La section 1.2
prsente l'optimisation de programmes. Elle se concentre plus particulirement sur les mthodes
de slection des optimisations.
1.1 Complexit des architectures superscalaires

Les processeurs superscalaires possdent des mcanismes complexes pour exploiter le paralllisme d'instructions. Ces mcanismes sont capables, d'une part d'excuter des instructions indpendantes dans le dsordre pour masquer les latences et d'autre part de prdire le comportement
des instructions de branchement pour excuter spculativement de longues squences d'instructions et enn ils possdent une hirarchie mmoire complexe pour exploiter dynamiquement la
rutilisation des donnes et des instructions.
Le processeur Alpha-21264 est un processeur superscalaire excution dans le dsordre possdant de tels mcanismes ; nous l'avons utilis comme architecture cible pour nos expriences
durant cette thse. Nous donnons une description dtaille de son architecture dans les soussections suivantes.
1.1.1
Architecture gnrale du processeur Alpha-21264 (EV68)
L'architecture gnrale du processeur Alpha-21264 est dcrite par la gure 1.1. Les composants Ebox et Fbox contiennent respectivement 4 units fonctionnelles entires et 2 units
fonctionnelles ottantes. Le composant Ibox contient les dirents mcanismes relatifs au pipe-
line, il est capable de charger 4 instructions depuis le cache d'instructions et de lancer jusqu'
6 instructions vers les units fonctionnelles chaque cycle. Il gre l'excution dans le dsordre
des instructions. Les caches d'instructions (Icache) et de donnes (Dcache) ont chacun une taille
de 64 Koctets, une associativit d'ordre 2 et des lignes de 64 octets. Le second niveau de cache
a galement des lignes de 64 octets mais il a une taille de 8 Moctets et il est correspondance
directe. Le composant Mbox contrle les accs au cache de donnes et assure une excution correcte de toutes les oprations mmoires. Il contient une queue des oprations de lecture et une
queue des oprations d'criture de 32 entres chacune (Load/Store queue), une table des adresses
1. Architecture et Optimisation
des oprations mmoires en chec (MAF Miss Address File) et un cache de translation d'adresses
(TLB) de 128 entres compltement associatif mmorisant les adresses des pages dont la taille
est de 8 Koctets ou des adresses de groupes de 8, de 64 ou de 512 pages de 8Koctets. Les registres
du processeur sont dupliqus : 2 x 80 registres entiers et 2 x 72 registres ottants.
ICache 64KB 2way associative

Physical
Adress
128
Cbox
Probe
Queue
Ibox
20
IOWB
BCache
128
Cache
Index
Dup.
Tag
Ebox
Cache
Data
8MB direct
mapped
System
Bus
Fbox
Victim
Buffer
64
System
Adress
Arbiter
Memory
Chipset
15
Mbox
TLB
(128 entry)
Load
Queue
Store
Queue
MAF
(8 entry)
Data
Physical
Adress
Data
DCache 64KB 2way associative
Fig. 1.1 Architecture gnrale du processeur Alpha-21264/EV68
1.1.2
Pipeline du processeur Alpha-21264 (EV68)
Le pipeline du processeur comporte 8 tages qui sont reprsents sur la gure 1.2 et dont le
fonctionnement est dcrit dans les paragraphes suivants.
Etage 0, Chargement des instructions (fetch )
Le prdicteur de branchement combine un
prdicteur local et un prdicteur global en utilisant un prdicteur de slection.

L'tage charge jusqu' 4 instructions alignes depuis le cache d'instructions. Les tables de
prdiction sont accdes durant ce cycle. S'il y a plus d'un branchement parmi les instructions
charges et que le premier branchement est prdit non pris alors le prdicteur de branchement
prdit les branchements suivants raison d'un par cycle.
Chaque ligne du cache d'instructions contient un champ de prdiction de ligne. Ce champ
indique le prochain numro de ligne du cache d'instructions charger. Mme si les tables de
prdictions de branchement sont accdes durant ce cycle, le rsultat de la prdiction n'est connu
qu'au cycle suivant. Le champ de prdiction de ligne permet donc d'viter l'insertion d'une bulle
dans le pipeline chaque branchement. Le champ de prdiction de ligne pointe initialement vers
1.1.
Fetch
0
Branch
Predictor
Rename
2
Issue
3
Integer
Register
Rename
Integer
Issue
Queue
(20
entries)
Reg Read Execute

4
5
Integer
Reg.
File
(80)
Memory
6
Integer
Execution
Integer
Execution
Integer
Reg.
File
(80)
Addr
Integer
Execution
Integer
Execution
Addr
Data
Cache
64 KB
2-way
LevelTwo
Cache
and
System
Interface
Line / Set
Prediction
Inst.
Cache
64 KB
2-way
FloatingPoint
Register
Rename
FloatingPoint
Issue
Queue
(15)
FP
Reg.
File
(72)
Floating-Point Multiply
Execution
Floating-Point Add
Execution
Fig. 1.2 Pipeline du processeur Alpha-21264/EV68
la ligne suivante, lorsqu'un branchement est pris, le champ est mis jour.
Etage 1, Placement des instructions (slot )
A ce cycle, le rsultat de la prdiction de
branchement est disponible et la prdiction de ligne peut tre vrie.

Les instructions charges au cycle prcdent sont distribues sur les pipelines (ottant et
entier).
Etage 2, Renommage des registres (rename )
Durant ce cycle, le renommage de registres
est eectu. Les instructions se voient attribuer un numro unique (inum ) d'identication pour
la dure pendant laquelle elles seront en vol dans le pipeline. Ces numros permettent d'identier
les instructions et l'ordre du programme. Les instructions sont considres comme tant en vol
(inight ) entre l'tage de renommage et l'tage de terminaison des instructions. Les instructions
sont places dans les queues d'instructions ottante et entire.
Etage 3, Lancement des instructions (issue )
La queue de lancement entire peut lan-
cer jusqu' 4 instructions par cycle et la queue de lancement ottante peut lancer jusqu' 2
instructions par cycle. Les instructions ne sont supprimes des queues que 2 cycles aprs leur
lancement.
Etage 4, Lecture des registres (reg )
Les instructions, qui viennent d'tre lances, lisent
leurs oprandes dans les bancs de registres et reoivent les renvois anticips (bypass ).
Etage 5, Excution des instructions (execute )
Les units fonctionnelles commencent les
calculs, l'addition et la multiplication ottantes ont une latence de 4 cycles, la division ottante
a une latence entre 9 et 15 cycles et la racine carre a une latence entre 15 et 33 cycles. La
plupart des oprations arithmtiques entires ont une latence de 1 cycle sauf la multiplication
entire qui a une latence de 7 cycles.
Etage 6, Accs mmoires (memory )
Dans cet tage, les oprations mmoires accdent au
cache de donnes et au cache de traduction d'adresses (TLB ). Les oprations de lectures accdent
aux tables d'tiquettes et de donnes alors que les oprations d'criture n'accdent qu' la table
d'tiquettes, la donne est crite dans la queue des instructions d'criture et ne sera crite dans
le cache que lorsque l'instruction sera retire.
Etage 7 (non reprsent), Terminaison des instructions (retire )
Dans cet tage, les
instructions sont retires dans l'ordre du programme. Le processeur peut retirer jusqu' 11 instructions par cycles.
1.1.3
Cas particuliers d'excutions
Lancement spculatif des instructions

Le pipeline possde des mcanismes de renvois anticips (bypass ). Une instruction
dante d'une instruction
i1
i2
dpen-
est donc lance dans l'tage de lecture des registres pendant le cycle
prcdant la n de l'excution de l'instruction
i1.
Lorsqu'une instruction
i2
dpend d'une ins-
truction de lecture mmoire i1, elle est lance spculativement : si i1 fait un succs dans le cache
alors l'instruction
i2
est retire de la queue de lancement 2 cycles aprs son lancement. Si
un dfaut de cache alors l'instruction
i2
i1
fait
est annule et reste dans la queue de lancement depuis
laquelle elle sera relance.

L'excution des instructions de la queue de lancement entire est annule si celles-ci ont
t lances dans la fentre de spculation d'une opration de lecture entire, mme si elles ne
dpendent pas de l'instruction de lecture. Cette fentre de spculation est de 2 cycles, la table 1.1
montre la fentre de spculation entire dans laquelle deux instructions
i2
et i3 sont lances. Un
compteur, fonctionnant en mode satur, est incrment chaque fois qu'une opration de lecture
entire fait un succs dans le cache et est dcrment chaque dfaut. Lorsque le bit de poids
fort de ce compteur est zro, la latence des lectures entires passe de 3 5 cycles et la fentre de
spculation est ainsi supprime. Les oprations de prchargement dans le registre
R31
ne crent
pas de fentre de spculation.
Cycles
i1 (lecture entire)
i2
i3
1
Q
2
R
3
E
4
D
Q
5
B
R
Q
Symboles Descriptions
Q
R
E
D
B
Queue de lancement
Lecture des registres
Excution
Accs au cache
Accs au bus
Tab. 1.1 Fentre de spculation entire : cycles 4 5
La fentre de spculation des instructions ottantes n'est que d'un cycle. Si une instruction i1
se trouve dans la fentre de spculation d'une opration de lecture ottante faisant un dfaut de
cache alors cette instruction (i1) est annule uniquement si elle dpend de l'opration mmoire.
La table 1.2 montre la fentre de spculation ottante de 1 cycle dans laquelle l'instruction
est lance.
i2
1.1.
Cycles
i1 (lecture ottante)
i2
i3
1
Q
2
R
3
E
4
D
5
B
Q
Symboles Descriptions
Q
R
E
D
B
Queue de lancement
Lecture des registres
Excution
Accs au cache
Accs au bus
Tab. 1.2 Fentre de spculation ottante : cycles 5
Excution des oprations mmoires

Il existe des situations dans lesquelles l'excution d'une opration mmoire ncessite d'tre
retarde. Ces situations dpendent des adresses des oprations mmoires, elles ne sont donc dtectes qu'au moment de l'excution. Lorsqu'une telle situation est dtecte, l'opration mmoire
responsable de la situation et toutes les instructions plus jeunes sont supprimes du pipeline et
recharges depuis l'tage de chargement d'instructions. Ce mcanisme est appel un replay trap.
L'excution des instructions se fait dans le dsordre mais l'architecture garantit une cohrence mmoire et maintient un ordre d'excution entre certaines oprations mmoires. L'ordre
d'excution est maintenu dans les deux cas suivants :
lorsque les oprations mmoires s'eectuent sur la mme adresse (quelles que soient les
oprations),
lorsque les oprations mmoires sont des oprations d'criture sur des adresses direntes.
Les entres dans les queues des oprations de lecture et d'criture sont alloues dans l'ordre
du programme. Ces queues sont des tampons de r-ordonnancement (reorder buers ) pour les
oprations mmoires.
Oprations mmoires ordonnes
Lorsqu'une opration mmoire est excute, son adresse
est calcule et compare avec les adresses des oprations se trouvant dans les queues des oprations de lecture et d'criture. Si une opration mmoire est en cours sur la mme adresse,
l'excution est annule partir de l'opration la plus jeune. Dans le cas o l'adresse d'une opration d'criture est identique l'adresse d'une opration de lecture plus jeune, se trouvant dans
la queue de lectures, l'opration de lecture est annule. Cet vnement est appel une purge
d'ordonnancement d'criture-lecture (store-load order trap ). Pour viter que cet vnement ne
se reproduise trop souvent, une table de 1024 entres indexe par le compteur de programme,
mmorise dans 1 bit si cet vnement s'est dj produit. Si une opration de lecture se trouve
dans la queue de lancement et que le bit correspondant est 1 alors le lancement de l'opration
est retard jusqu' ce que toutes les oprations mmoires d'criture plus anciennes soient lances.
La table des bits d'attente est remise zro tous les 16384 cycles.
Oprations mmoires en conits
La mmoire cache de donnes ne peut garantir l'excution
correcte d'une opration de lecture et d'criture dans le mme ensemble. Toute nouvelle opration
mmoire qui entre en conit avec une opration dans les queues des oprations mmoires est
relance.
Oprations mmoires et ressources
Le mcanisme de purge des oprations mmoires est
utilis pour relancer les oprations lorsque les queues des oprations mmoires sont pleines ou
10
lorsque le tampon des oprations mmoires en chec est plein.
1.2 Optimisation de programmes
slectionner
vrier
transformer
Pour raliser une optimisation de programmes, il est ncessaire de raliser trois tapes :

une transformation et la partie de programme sur laquelle il faut l'appliquer,
que la transformation est lgale, c'est--dire qu'elle ne modie pas la smantique
du programme,
et enn
le programme.
La sous-section suivante prsente un aperu des transformations que l'on peut appliquer aux
programmes.
1.2.1
Transformations de programmes
Les transformations peuvent tre appliques dirents niveaux dans le programme :

Au niveau de l'instruction du langage source (statement ) : les transformations n'aectent
que les instructions du langage machine correspondant l'instruction du langage source.
Au niveau du bloc de base : les transformations aectent uniquement les instructions d'un
mme bloc de base (un bloc de base est form d'instructions parmi lesquelles il n'y a qu'une
seule instruction de contrle.)
Au niveau des nids de boucles : les transformations aectent les instructions appartenant
au nid de boucles.
Au niveau des procdures : les transformations aectent toutes les instructions d'une procdure. Ces transformations sont aussi appeles des transformations globales ou intra-
procdurales.
Au niveau du programme complet : les transformations aectent plusieurs procdures ; elles
sont appeles transformations inter-procdurales.
Plus le niveau d'une transformation est lev, comme c'est le cas pour les transformations
inter-procdurales, plus les trois tapes ncessaires pour raliser la transformation (slection,
vrication et transformation) sont diciles mettre en uvre. En revanche, plus le niveau
d'une transformation est lev et plus ses gains de performance sont potentiellement importants.
Des ouvrages de rfrences prsentent les transformations de programmes de manire dtaille
et exhaustive [AhSeUl86, Mu97, AlKe01]. Bacon et al. [BaGrSh94] prsentent les bnces et
les dfauts de nombreuses transformations au niveau des nids de boucles. Les dirents niveaux
d'applications des transformations peuvent servir de classement. Cependant de plus en plus de
transformations sont ralises plusieurs niveaux, par exemple la propagation de constantes est
ralise au niveau des blocs de bases et au niveau inter-procdurale. Le classement n'a donc plus
un intrt majeur.
Les optimisations peuvent tre groupes en 3 grandes catgories :
Les transformations de simplications
Elles sont gnralement assez indpendantes des
autres optimisations et leur eet sur la performance est le plus souvent positif. Il est donc possible
de slectionner ces optimisations de manire systmatique pour l'ensemble du programme. Parmi
1.2.
11
ces transformations de programmes, on trouve la propagation de constantes, le remplacement de

sous-expressions, les simplications algbriques, l'limination de code mort, la factorisation des
invariants de boucles. Muchnick [Mu97] dcrit de manire trs dtaille toutes ces transformations.
Les transformations spciques la gnration de code
L'allocation de registres et le
rordonnancement d'instructions sont deux optimisations qui ne doivent tre eectues qu'une
fois les simplications faites et la structure du programme xe.
L'allocation de registres dtermine les variables temporaires du programme qui vont tre
mmorises dans les registres logiques de la machine pour minimiser le nombre des instructions
de lecture et des instructions d'criture mmoire. Lorsqu'il n'y a plus susamment de registres
disponibles, les variables temporaires sont mmorises dans la pile par du code de dbordement
(Spill code ) [BrCoKe89].
Le rordonnancement d'instructions est une optimisation uniquement ddie au paralllisme
d'instructions. Elle rordonne les instructions pour maximiser l'utilisation des ressources du processeur. Les techniques bases sur le rordonnancement par liste (list scheduling ) [GiMu86] sont
trs ecaces pour optimiser l'ordre des instructions dans un bloc de base.
L'allocation de registres et le rordonnancement des instructions sont corrls. Le rordonnancement des instructions modie la dure de vie des registres et a un impact direct sur l'allocation
des registres [Pi93].
La promotion de scalaires n'est pas une transformation spcique la gnration de code,
cependant elle est fortement lie l'allocation de registres. Elle consiste identier les multiples
accs une mme rfrence mmoire pour placer la valeur de celle-ci dans un registre. La gure 1.3
montre la promotion des scalaires
do j = 1, n
do i = 1, m
a(i) = 2 * b(i)
c(j) = c(j) + b(i)
b(i)
et
c(j).
do j = 1, n
t = c(j)
do i = 1, m
u = b(i)
a(i) = 2 * u
t = t + u
c(j) = t
(a) avant
(b) aprs
Fig. 1.3 Promotion de scalaires
La promotion des scalaires augmente le nombre de registres utiliss, par consquent, promouvoir agressivement les scalaires peut gnrer du code de dbordement et peut ainsi dgrader les
performances. La promotion des scalaires [CaKe94] doit donc tenir compte de la pression qu'elle
exerce sur les registres.
Les transformations spciques aux structures de contrles et aux structures de

donnes
Les transformations faisant partie de ce groupe ont gnralement un impact impor-
tant sur les optimisations des deux groupes prcdents et plus particulirement sur l'allocation
de registres et le rordonnancement des instructions. Ce groupe est form des transformations
12
relatives la structure de procdure, celles relatives aux nids de boucles et celles relatives aux
structures de donnes.
Expansion de code
Cette transformation consiste remplacer un appel une procdure
par le code de celle-ci. Cette transformation est gnralement ralise lorsque le corps de la
procdure est de petite taille et si l'appel est souvent excut. La taille de la procdure peut tre
connue statiquement, en revanche, le nombre d'excutions de l'appel peut dpendre du jeu de
donnes.
Droulage de boucles
Drouler une boucle
fois et multiplier le pas de l'itrateur par
k.
fois consiste recopier le corps de la boucle
La transformation rduit le nombre d'instructions
excutes relatives au branchement et ventuellement le nombre d'instructions excutes relatives aux calculs d'adresse des rfrences mmoires. Cette instruction a un impact important sur
le rordonnancement des instructions et l'allocation de registres. Dans le cas idal, c'est--dire
lorsqu'il n'y a pas de dpendances entre les itrations, le droulage de boucle permet au rordonnancement d'instructions de trouver plus de paralllisme. Ce rordonnancement augmente
le nombre de variables temporaires en vie simultanment ce qui peut permettre de proter des
registres potentiellement disponibles mais cela peut galement obliger l'allocation de registres
gnrer du code de dbordement. Dans le mme temps, le droulage de boucles augmente la taille
du programme, cela peut avoir un impact sur le nombre de dfauts du cache d'instructions. Le
droulage de boucles peut aussi favoriser la promotion de scalaires, par exemple dans la boucle
droule de la gure 1.4, les rfrences
b(i), b(i+1), b(i+2)
et
b(i+3)
peuvent proter de
la promotion de scalaires. Le nombre d'itrations droules doit donc tre judicieusement choisi
an d'obtenir le meilleur compromis entre paralllisme, utilisation des registres, rduction des
instructions excutes et dfauts du cache d'instructions.
do i = 2, n
a(i) = b(i+1) + b(i) + b(i-1)
do i = 2, n-3, 4
a(i) = b(i+1) +
a(i+1) = b(i+2)
a(i+2) = b(i+3)
a(i+3) = b(i+4)
do i = i, n
a(i) = b(i+1) +
(a) avant
b(i) + b(i-1)
+ b(i+1) + b(i)
+ b(i+2) + b(i+1)
+ b(i+3) + b(i+2)
b(i) + b(i-1)
(b) aprs
Fig. 1.4 Droulage de boucles
Permutation de boucles
La permutation de boucles consiste permuter deux boucles
appartenant un mme nid. Cette optimisation est gnralement utilise pour amliorer la
localit mais ses eets sont varis. Considrons l'exemple de la gure 1.5, supposons que le
tableau
est rang en mmoire par colonne. La localit spatiale des rfrences au tableau
est
mal exploite. La permutation de boucles permet de l'amliorer. Cet exemple, montre galement
que la permutation un impact sur la promotion des scalaires et sur le paralllisme d'instructions.
Supposons cette fois-ci que le code original est le code de droite (b) sur la gure, la permutation
de boucles favorise la promotion des scalaires du tableau
toutes les itrations de la boucle interne
a. En revanche,
cette permutation rend
i dpendantes. Sur un exemple aussi simple, il n'est pas
1.2.
13
facile de slectionner une permutation d'autant plus que le comportement du programme dpend
des paramtres
m,n
et des tailles des tableaux
do j = 1, n
do i = 1, m
a(j) = a(j) + b(j,i)
et
b.
do i = 1, m
do j = 1, n
a(j) = a(j) + b(j,i)
(a) avant
(b) aprs
Fig. 1.5 Permutation de boucles
Fusion et ssion de boucles
La fusion et la ssion de boucles sont souvent utilises pour
amliorer la localit et le paralllisme d'instructions. Ces deux optimisations sont opposes mais
ont pourtant les mmes objectifs. La fusion consiste regrouper les oprations eectues dans
deux boucles spares dans une seule boucle. La ssion est l'inverse de la fusion, elle spare des
calculs eectus dans une boucle en deux boucles spares. La gure 1.6 montre un exemple
de fusion ou bien de ssion de boucles. Le premier bnce apport par la fusion est la rduction du nombre d'instructions excutes relatives aux instructions de branchement et de calcul
d'adresses. La fusion permet d'amliorer la rutilisation des donnes et peut favoriser l'application de la promotion des scalaires et d'optimisations de simplications comme la suppression
des tableaux temporaires. Elle permet aussi d'augmenter la diversit des oprations d'une mme
boucle et d'amliorer ainsi l'utilisation des ressources. Dans le cas o l'architecture cible du programme de la gure 1.6 possde une unit fonctionnelle d'addition et une unit fonctionnelle
de multiplication, la fusion amliore le paralllisme. Cependant, la fusion peut galement avoir
des eets opposes aux amliorations que nous venons de citer. Dans l'exemple, le bnce de
l'amlioration de la localit sur le tableau
tableaux
et
d.
peut tre inhib par des conits de cache entre les
La fusion a galement un impact sur le rordonnancement des instructions car
elle peut augmenter les dpendances dans le corps de la boucle. La ssion de boucle est donc
utilise pour rduire les conits de cache et les dpendances.
do i =
a(i)
do i =
d(i)
1, n
= b(i) + c(i)
1, n
= a(i) * d(i)
do i = 1, n
a(i) = b(i) + c(i)
d(i) = a(i) * d(i)
(a) avant fusion ou aprs ssion
(b) aprs fusion ou avant ssion
Fig. 1.6 Fusion et ssion de boucles
Dcalage d'itrations
Le dcalage d'itrations gnralise l'optimisation connue sous le
nom de pipeline logiciel en permettant de dcaler des groupes complets d'oprations dans l'espace d'itration. La gure 1.7 montre un exemple de dcalage d'itrations o des calculs intermdiaires sont anticips en tant dcals sur les deux itrations prcdentes. Le dcalage d'itrations
augmente le paralllisme d'instructions en augmentant la dure de vie des variables temporaires
et donc la pression sur les registres.
Blocage de boucles
Le blocage de boucles consiste dcouper l'espace d'itrations d'un
nid de boucles pour le parcourir diremment. Cette transformation est habituellement utilise
14
do i = 1, n
a(i) = a(i)-k*(b(i)+c(i))*(d(i)+e(i))
t3
t1
t2
do
= b(1) + c(1) * d(1) + e(1)

= b(2) + c(2)
= d(2) + e(2)
i = 1, n-2
a(i) = a(i) - k * t3
t3 = t1 * t2
t1 = b(i+2) + c(i+2)
t2 = d(i+2) + e(i+2)
a(n-1) = a(n-1) - k * t3
a(n) = a(n) - k * (t1 * t2)
(a) avant
(b) aprs
Fig. 1.7 Dcalage d'itrations
pour amliorer la localit. La gure 1.8 montre un exemple de blocage de boucles sur un produit
de matrices et la gure 1.9 reprsente les accs aux matrices correspondantes. Cette optimisation
peut tre ralise pour des niveaux dirents de la hirarchie mmoire et de manire hirarchique [NaJuLa94, CaFeHu95]. Dans l'exemple du produit de matrices, les paramtres
doivent tre choisis de manire ce que le bloc
matrice
Tj*Tk
de la matrice
et la colonne
tiennent dans le niveau de cache considr.
do kk=1,Nk,Tk
do jj=1,Nj,Tj
do i=1,Ni
do k=kk, MIN(kk+Tk-1,Nk)
R=b(k,i)
do j=jj, MIN(jj+Tj-1,Nj)
c(j,i)=c(j,i)+R*a(j,k)
do i=1,Ni
do k=1,Nk
R=b(k,i)
do j=1,Nj
(a) avant blocage
(b) aprs blocage
Fig. 1.8 Exemple d'un blocage de boucle sur un produit de matrices
boucle j (interne)
boucle j (interne)
boucle k
boucle k
boucle i
B
k
boucle i
j
j
j
A
(a) avant blocage
(b) aprs blocage
Fig. 1.9 Ordre d'accs aux matrices
Tj
Tk
et
Tk
de la
1.2.
15
Rarrangement de donnes
Le rarrangement de donnes consiste modier les dcla-
rations de donnes et ventuellement les accs aux donnes an que le placement des donnes en
mmoire permette au programme d'exploiter une meilleure localit. La gure 1.10 montre deux
types de rarrangement de donnes. Le premier modie la structure du tableau
en inversant
ses dimensions et modie les rfrences correspondantes. Ce genre de rarrangement peut tre
plus complexe lorsque, par exemple, les accs une matrice se font en diagonale. Le second est
l'insertion d'une variable fantme
qui permet d'viter des conits de cache lorsque les tailles
de matrices sont des multiples d'une puissance de 2 ; cette transformation est appele padding.
double precision a(m,n), b(n,m)

...
do j = 1, n
do i = 1, m
a(i,j) = a(i,j) * b(j,i)
double precision a(m,n), d(8),b(m,n)

...
do j = 1, n
do i = 1, m
a(i,j) = a(i,j) * b(i,j)
(a) avant
(b) aprs
Fig. 1.10 Rarrangement des donnes
1.2.2
Optimisation automatique
Les optimisations automatiques sont ralises par les compilateurs et les prprocesseurs qui
doivent suivre l'volution des architectures et s'adapter leur complexit croissante.
Pour raliser une optimisation automatiquement, un compilateur doit raliser les trois tapes
ncessaires : la slection, la validation et la transformation. Nous nous intressons plus particulirement l'tape de slection. Elle ncessite une analyse du programme et une modlisation
de l'architecture pour valuer le comportement du programme sur celle-ci. Cette valuation doit
permettre de dterminer si une transformation doit tre applique, c'est--dire si elle amliore la
performance.
Modlisation de l'architecture et analyse du programme

Les transformations de simplications ne ncessitent pas de modle de l'architecture parce
qu'elles sont gnralement indpendantes de l'architecture. Les transformations relatives la
gnration de code sont, elles aussi, systmatiquement appliques. Cependant, leurs algorithmes
ncessitent un modle prcis de l'architecture interne. L'algorithme de rordonnancement des
instructions doit possder une reprsentation des units fonctionnelles, connatre la fois la
latence de chaque instruction, le nombre d'instructions charges depuis le cache d'instructions
par cycle, le nombre d'instructions lances l'excution par cycle, les tailles des queues des
oprations mmoires et les dirents conits que peuvent rencontrer certaines instructions dans
le pipeline, etc.
Les transformations relatives aux structures de contrles et aux structures de donnes ncessitent des modles complexes. Ces transformations sont utilises principalement pour amliorer
la localit, les premiers travaux se sont donc focaliss sur la modlisation de la hirarchie mmoire. L'analyse du programme qui doit tre associe au modle de l'architecture s'est inspire de
l'analyse des dpendances plus particulirement des vecteurs de distances. Les premiers rsultats
16
consquents en analyse ddie la slection sont ceux de Wolf et Lam [WoLa91] qui ont formalis deux concepts : la rutilisation et la localit. Cette formalisation leur a permis d'automatiser
des transformations uni-modulaires avec un algorithme favorisant la rutilisation. Le modle de
hirarchie mmoire implicitement utilis est trs abstrait car il s'agit d'un espace mmoire sans
fonction de placement.
Nous allons illustrer ci-dessous, l'aide des optimisations pour la mmoire, comment des
modles de plus en plus prcis de l'architecture ont t utiliss.
Analyses et modlisations de la hirarchie mmoire
Lam, Rothberg et Wolf [LaRoWo91]
ont mis en vidence les problmes lis au comportement du cache sur les programmes utilisant
le blocage de boucles. Les dfauts de caches sont de trois types : les dfauts de dmarrage (com-
pulsory misses ), les dfauts de conits (conict misses ), et les dfauts de capacit (capacity
misses ). Ils ont montr la dicult du choix des paramtres (T j et
T k)
pour rduire les conits
dans le cache et ont tudi le comportement du cache en faisant varier la taille des blocs et la
taille des matrices. Ils prsentent un algorithme permettant de calculer la taille de bloc rectangulaire maximale n'engendrant pas de conit de cache sur lui-mme (self interference ). Le cache
considr pour l'algorithme est un cache correspondance directe. Le modle utilis pour guider
l'algorithme est trs simple puisqu'il utilise uniquement la taille du cache.
Coleman et McKinley [CoKi95] prsentent un algorithme bas sur la division euclidienne pour
calculer plusieurs tailles de blocs rectangulaires sans conit de cache entre eux. Ils enrichissent
leur algorithme d'une fonction de cot qui propose de slectionner les tailles de blocs minimisant
les interfrences entre les dirents blocs et entre les direntes variables. Le cache considr
pour l'algorithme est toujours un cache correspondance directe mais le modle utilis pour
guider l'algorithme prend en considration la taille du cache et la taille d'une ligne du cache.
Rivera et Tseng [RiTs99] comparent dirents algorithmes de blocage de boucles. Ils simplient l'algorithme de Coleman et McKinley par un algorithme rcursif. Ils proposent de combiner
le rarrangement des donnes (padding ) avec les algorithmes de blocage pour rsoudre les problmes de conits de cache rencontrs pour certaines tailles de matrices. Le cache considr pour
tous les algorithmes reste un cache correspondance directe et les modles utilisent la taille du
cache et de la ligne.
Navarro, Juan et Lang [NaJuLa94] gnralisent un algorithme de blocage pour une hirarchie
mmoire
niveaux prenant ainsi en compte les eets du blocage sur le cache de traductions
d'adresses (TLB ). L'algorithme ralise le blocage successivement sur les dirents niveaux de la
hirarchie mmoire. La hirarchie mmoire considre est un ensemble de caches correspondance
directe modliss par leurs tailles et celles de leur ligne.
Mitchell et al. [MiCaFe97] revisitent cet algorithme de blocage pour une hirarchie mmoire
en utilisant une fonction de cot global pour l'ensemble de la hirarchie.
Ghosh, Martonosi et Malik [GhMaMa99] dcrivent une mthode gnrale pour mettre en
quations les relations prcises entre les indices des nids de boucles, les tailles de tableaux,
leurs adresses de bases, et les paramtres du cache. Ces quations appeles CME pour Cache
Miss Equations permettent de dterminer prcisment le comportement du cache et peuvent

ainsi guider l'optimisation des nids de boucles. L'architecture considre est un cache allou
en criture avec une associativit quelconque et une politique de remplacement de type LRU.
Les CME peuvent tre tendues plusieurs niveaux de caches mais le temps de calcul devient
1.2.
17
prohibitif.
Chatterjee et al. [ChPaHaLe01] ont dvelopp un modle pour caractriser le comportement
exact des nids de boucles sur une hirarchie mmoire. Ils utilisent l'arithmtique de Presburger [We97] pour identier dirents types de dfauts de caches et pour dterminer l'tat du
cache la n des boucles. La hirarchie mmoire considre possde deux niveaux de cache
allou en criture avec une associativit quelconque.
Les architectures deviennent de plus en plus complexes, par consquent, les modles d'architectures utiliss par les heuristiques des compilateurs sont de moins en moins prcis et de plus
en plus diciles construire et intgrer dans les compilateurs.
Monsifrot, Bodin et Quiniou [MoBoQu02] ont montr qu'il tait possible de gnrer une heuristique l'aide d'une mthode d'apprentissage pour le droulage de boucle. Ils utilisent une
mthode d'apprentissage base sur les arbres de dcision. Les paramtres d'apprentissage qui
caractrisent les boucles sont extraits statiquement du programme. Pour le droulage de boucles,
la mthode utilise 6 paramtres : le nombre d'instructions, le nombre des oprations arithmtiques, le nombre minimum d'itrations, le nombre d'accs aux tableaux, le nombre d'lments de
tableau rutiliss et le nombre d'instructions conditionnelles. Les boucles ayant des paramtres
identiques appartiennent la mme classe. Le processus d'apprentissage applique le droulage
un ensemble de boucles et identie les classes bnciant de cette optimisation. Ils utilisent
un outil de classication gnrant des arbres de dcision obliques. L'intgration des heuristiques
dans le compilateur se fait par une implmentation des arbres de dcision gnrs. Le temps
moyen des excutions des programmes dont le droulage est guid par l'heuristique d'apprentissage est infrieur de 4% au temps moyen des excutions des programmes dont le droulage est
guid par l'heuristique du compilateur g77. En appliquant la mthode d'apprentissage avec les
mmes paramtres sur deux architectures direntes, ils dmontrent que la mthode s'adapte
l'architecture cible.
Stephenson et al. [StAmMaOR03] proposent un algorithme gntique permettant de construire des fonctions de priorits utilises par les heuristiques. L'algorithme gntique gnre
directement la fonction de priorit. Ils montrent le fonctionnement de l'algorithme pour construire
les fonctions de priorits des heuristiques pour trois optimisations : la construction d'hyper-blocs,
l'allocation des registres et le prchargement des donnes. Contrairement aux travaux prcdents,
les paramtres d'apprentissage ne sont pas uniquement statiques, ils utilisent galement des
informations dynamiques obtenues par prolage. Par exemple, pour la construction d'hyperblocs, ils utilisent comme paramtre la frquence d'excutions des chemins.
Le compromis des mthodes d'apprentissage est le choix des paramtres. En eet, la taille
de l'ensemble des programmes d'apprentissage ou de la population (et par voie de consquence
le temps d'apprentissage) crot de manire exponentielle avec le nombre de paramtres. Les
mthodes d'apprentissage simplient la construction des compilateurs, il reste cependant des
eorts fournir pour identier les paramtres d'apprentissage pertinents et pour congurer le
processus d'apprentissage.
Importance de l'ordre de transformations

L'analyse statique et la modlisation des architectures ne sont pas les seules dicults que
rencontrent les compilateurs. La phase d'optimisation d'un compilateur est scinde en sous-
18
phases dans lesquelles sont eectues plusieurs optimisations. La plupart du temps l'ordre suivant
lequel sont appliques les transformations est g. Allen et Kennedy ainsi que Muchnick[AlKe01,
Mu97] dcrivent les structures gnrales des compilateurs et les optimisations de chaque phase
de manire dtaille. Par exemple, la structure du compilateur Open Research Compiler [ORC]
est dcoupe en 5 phases ralisant toutes les optimisations :

PreOPT
(Pre-Optimizations ) : cette phase ralise des pr-optimisations simples telles l'li-
mination de code mort et ralise aussi les analyses statiques qui vont tre utilises par les
phases suivantes.

LNO
(Loop Nest Optimizations ) : cette phase contient toutes les transformations sur les
tableaux et les nids de boucles.

WOPT
(WHIRL or global Optimizations ) : cette phase eectue des optimisations gnrales
comme l'limination d'expressions redondantes, des optimisations sur les pointeurs et sur
le graphe de contrle ainsi que des optimisations de simplications arithmtiques.

CG (Code
Generation ) : cette phase ralise toutes les optimisations relatives la gnration
de code.
Gnralement, les squences d'optimisations ralises dans chaque phase sont ges. Seules
quelques transformations peuvent tre rptes et permutes, par exemple dans le compilateur
ORC, seules la fusion et la ssion de boucles peuvent tre permutes et appeles plusieurs fois.
L'importance des compositions de transformations a t montre par de nombreux travaux.
Rivera et Tseng [RiTs98, RiTs98+] ont propos des algorithmes de rarrangement des donnes
(Padding ) pour minimiser les interfrences dans le cache. Ils ont ensuite tudi le comportement
du cache vis--vis de direntes transformations de programmes et ils ont commenc tudier les
combinaisons d'optimisations comme la fusion de boucles et le rarrangement des donnes pour
augmenter la rutilisation tout en limitant les conits de cache. Ils ont tendu ces combinaisons
d'optimisations pour des hirarchies mmoires plusieurs niveaux de caches [RiTs99].
Whiteld et Soa [WhSo90] proposent un environnement pour tudier les interactions entre
les optimisations. L'environnement permet d'exprimer les pr-conditions et post-conditions des
transformations. Si la pr-condition d'une transformation
d'une transformation
t1
alors
t1
autorise
t2 .
t2
est incluse dans la post-condition
L'tude des conditions d'un ensemble de transfor-
mations permet de driver un ordre qui favorise l'application des transformations.

Triantafyllis et al. [TrVaVaAu03] ont rcemment propos une structure de compilateur qui
explore simultanment plusieurs squences d'optimisations diriges par direntes heuristiques.
Ils proposent de slectionner, a posteriori, la meilleure squence d'optimisations l'aide d'un
prdicteur de performance travaillant sur le code gnr.
Zhao et al. [ZhCaWh02] ont prsent un environnement de compilation interactif utilis pour
l'optimisation de programmes pour l'embarqu (VISTA). Cet environnement permet l'utilisateur de contrler les parties de programmes sur lesquelles ils appliquent des squences d'optimisations, de modier manuellement les transformations de programmes, de dfaire des transformations de programmes dj ralises et de visualiser la reprsentation intermdiaire du programme
en cours d'optimisation.
Kulkarni et al. [KuZhMo03] ont utilis l'environnement de compilation interactif VISTA
et ont intgr un algorithme gntique pour rechercher des squences d'optimisations. Ils ont
ensuite propos des algorithmes pour acclrer le temps de recherche des algorithmes gntiques [KuHiHi04].
1.2.
19
Almagor et al. [AlCoGr04] ont tudi l'espace des squences d'optimisations an de caractriser celui-ci et de dterminer le cot de construction de squences d'optimisations adaptes. Ils
proposent trois algorithmes de recherche dans l'espace des squences d'optimisations.
Optimisation dirige par l'analyse dynamique

L'analyse dynamique permet d'amliorer le processus de slection des optimisations en intgrant des informations sur le comportement du programme sur l'architecture. En outre, lors
de la compilation d'un programme, de nombreux paramtres sont inconnus car ils dpendent du
jeu de donnes utilis par le programme. Ainsi, le nombre d'itrations des boucles, la taille des
tableaux, le comportement des branchements ne sont connus que lors de l'excution. Direntes
techniques [DeHiWa97, PerfMon3, OProle, VTune] sont utilises pour collecter ces informations
lors de l'excution ; elles sont ensuite utilises par les compilateurs pour guider leurs optimisations.
Cohn et Lowney [CoLo99] dcrivent les optimisations diriges par l'analyse dynamique dans
le compilateur Alpha. Ils obtiennent un gain de 17% par rapport aux optimisations guides
statiquement. Les optimisations diriges par l'analyse dynamique sont gnralement des transformations pour amliorer le paralllisme d'instructions. Elles visent gnralement amliorer le
comportement des branchements.
La principale dicult de l'optimisation dirige par l'analyse dynamique est qu'elle rend
les optimisations ralises sur le programme trs dpendantes du jeu de donnes utilis la
compilation. Pour adapter les optimisations dirents jeux de donnes, Bala, Duesterwald et
Banerjia [BaDuBa00] ont propos un systme permettant d'optimiser les programmes durant
leurs excutions. Le systme collecte des informations sur l'excution en cours d'un programme
et optimise les parties de programmes les plus coteuses en temps. La principale dicult est
de grer le surcot de l'optimisation qui a lieu sur le mme processeur que le programme excut. Voss et Eigenmann [VoEi00, VoEi01] propose un environnement similaire mais dcoupl,
c'est--dire un environnement o les optimisations sont ralises sur un processeur dirent de
celui excutant le programme. Ils proposent un langage permettant de dnir des heuristiques
d'optimisations dynamiques.
Kistler et Franz [KiFr03] prsentent l'tude d'un systme permettant de raliser des optimisations lors du chargement du programme et lors de son excution. Ils proposent, comme les
autres travaux sur l'optimisation dynamique, des optimisations pour amliorer le paralllisme
d'instructions mais ils proposent galement une optimisation pour amliorer l'utilisation de la
hirarchie mmoire base sur le rarrangement des donnes.
Kisuki et al [KiKnOB00, KiKnOB00+] ont introduit la compilation itrative et son utilisation
pour rechercher simultanment les paramtres d'une combinaison de transformations (droulage,
blocage de boucles et rarrangement des donnes). Le principe de la compilation itrative est,
pour slectionner la meilleure combinaison de paramtres, de rpter la compilation et l'excution
du programme avec des paramtres dirents. Ils ont explor l'utilisation de dirents algorithmes
pour parcourir l'espace de recherche. Ils ont galement tudi l'apport d'un modle de cache
pour rduire l'espace de recherche [KKGO00]. Malheureusement, l'espace de recherche crot de
manire exponentielle avec le nombre de transformations utilises. Le temps de recherche devient
prohibitif pour un nombre important de transformations.
20
1.2.3
Optimisation manuelle
Il existe peu de travaux acadmiques sur l'optimisation manuelle, en revanche, de nombreux

outils ont t dvelopps pour que celle-ci soit pratique.
Les outils de prolage [DeHiWa97, PerfMon3, OProle, VTune] utilisent des compteurs matriels. Les compteurs matriels comptent les dirents vnements se produisant dans une architecture lors de l'excution d'un programme comme par exemple le nombre de dfauts de cache.
Les capacits des outils de prolages dpendent des architectures qui mettent disposition du
programmeur plus ou moins d'informations. Lors de l'excution d'un programme, chaque fois
qu'un vnement se produit le compteur correspondant est incrment. Lorsque ce compteur
dborde, une interruption apparat, le numro du compteur et l'adresse de l'instruction ayant
provoqu le dbordement sont transmis au systme qui collecte les informations. Plus une instruction provoque un vnement, plus la probabilit que cette instruction fasse dborder le compteur
est importante. Aprs l'excution du programme, l'information collecte par le systme est une
distribution statistique des vnements sur les instructions du programme. En fonction des architectures, l'attribution d'un vnement une instruction est plus ou moins prcise. En eet,
les processeurs excution dans le dsordre comme les processeurs EV6, EV7, Opteron ou Pen-
tium ont parfois des dicults identier l'instruction provoquant un vnement. En revanche,
les processeurs excution dans l'ordre comme les processeurs EV5 ou Itanium attribuent les
vnements prcisment aux instructions qui les provoquent. Les processeurs les plus rcents,
comme l'Itanium2 [IPF2], permettent de mesurer jusqu' 4 compteurs simultanment et plus de
300 vnements dirents.
L'optimisation manuelle de programmes est une tche dicile car elle ncessite une connaissance prcise de l'architecture des machines et des transformations de programmes. Cette double
connaissance doit permettre de trouver les opportunits de transformations et de construire
des squences de transformations. L'objectif des travaux prsents ci-dessous est de faciliter et
d'acclrer le processus manuel d'optimisation.
Le projet MHAOTEU [AbToAn00] propose un ensemble organis d'outils d'analyse (statiques
et dynamiques) et d'optimisation pour les hirarchies mmoires. Les outils sont accessibles par
l'utilisateur travers une interface unique. Elle est connecte un serveur qui communiquent avec
les outils d'analyses et de transformations. Le serveur enregistre toutes les informations relatives
aux analyses dans une base de donnes. Parmi les outils d'analyses dynamiques proposs pour
la hirarchie mmoire, les outils de visualisation de mmoire cache (CVT ) [Wa02] permettent
l'utilisateur de visualiser les phnomnes de conits. Cet outil instrumente le programme de
l'utilisateur pour que l'excution de celui-ci transmette les oprations mmoires un simulateur
de cache pas pas. Une interface graphique montre le placement des donnes dans le cache.
Monsifrot et Bodin [MoBo01] proposent un environnement interactif d'optimisation. L'environnement CAHT est bas sur le raisonnement partir de cas. Il permet de rechercher, dans
les parties critiques d'un programme, les opportunits d'optimisation (dont la lgalit n'est pas
garantie) et de les proposer l'utilisateur. Ce dernier a la responsabilit de vrier et de valider le
programme optimis. Une base de connaissances mmorise les couples (cas,transformation). Les
cas sont des conjonctions de proprits de boucles ou des reconnaissances de structures de calculs.
Les proprits, au nombre de 31, sont extraites par une analyse statique des nids de boucles.
Les cas ont t construits partir des guides d'optimisation. L'environnement est volutif car
l'utilisateur peut dnir de nouveaux cas et ajouter des transformations de programmes.
1.3.
Synthse
21
La construction des cas est un travail d'expert qui ncessite une bonne pratique de l'optimisation de programmes. Cette automatisation de la recherche des cas est complmentaire de nos
travaux, qui sont focaliss sur la slection rapide des transformations et l'ordre de composition
des transformations.
L'environnement CAHT prsente un point commun majeur avec le processus d'optimisation
que nous proposons dans le chapitre 3 : ils mettent prot l'expertise empirique de l'optimisation
manuelle en la formalisant et permettent son volution, En revanche, les principales dirences
apparaissent dans l'identication des cas. Eectivement, l'identication est base sur une analyse
statique des programmes pour CAHT alors qu'elle est base sur une analyse dynamique pour le
processus prsent. Enn contrairement CAHT, le processus que nous proposons est itratif.
1.3 Synthse
Les architectures ont volu de manire incrmentale en intgrant des mcanismes de plus
en plus complexes. L'association de ces mcanismes et l'volution de la technologie ont considrablement augment la performance crte des processeurs. Les optimisations des compilateurs
sont cruciales pour permettre aux programmes d'exploiter une partie de cette performance (la
performance soutenue ). L'augmentation de la complexit des architectures rend trs dicile le
maintien d'une performance soutenue peu loigne de la performance crte des processeurs.
Les techniques classiques d'optimisation automatique utilisent des analyses statiques et des
modles simplis des architectures pour prdire le comportement des programmes.
Ces techniques rencontrent deux problmes majeurs :
d'une part certains paramtres des programmes ne sont connus qu'au moment de l'excution ce qui restreint le pouvoir de l'analyse statique,
d'autre part, les architectures devenant de plus en plus complexes, les modles d'architectures ont de plus en plus de dicults reprsenter dlement le comportement des
composants.
Les optimisations guides par l'analyse dynamique pallient le manque d'information des analyses statiques. Les informations extraites de l'analyse dynamique prcisent gnralement le comportement du programme vis--vis d'un seul composant de l'architecture, par exemple le cache
d'instructions. Malheureusement, la majeure partie de la prdiction du comportement des programmes reste la charge des modles d'architectures.
Les mthodes d'apprentissage et les algorithmes gntiques ont montr des rsultats intressants pour automatiser la cration des heuristiques. Malheureusement, ces mthodes sont coteuses en temps d'apprentissage et ne sont envisageables qu'individuellement pour chaque optimisation. La complexit de ces mthodes ne permet pas de les utiliser pour crer des heuristiques
prenant en compte des ensembles d'optimisations.
Les techniques d'optimisation automatiques doivent aronter une dicult supplmentaire
qu'elles utilisent ou non des analyses dynamiques. Cette dicult est le choix de l'ordre d'application des transformations. En eet, le plus souvent cet ordre est g. Peu de travaux ont tudi les
interactions entre les optimisations, notamment l'impact des compositions des transformations
sur la performance. Comme pour les heuristiques, les mthodes d'apprentissage sont des moyens
obscurs de construire de nouvelles squences d'optimisations. Mmes si ces mthodes obtiennent

des rsultats, elles manquent d'informations dtailles sur le comportement des programmes pour
22
que l'apprentissage soit pertinent.

Les travaux sur l'optimisation manuelle se sont focaliss sur des thmes dirents mais complmentaires qui sont l'analyse dynamique et la formalisation de l'expertise empirique.
L'ecacit d'un processus d'optimisation peut tre accrue par une amlioration de la comprhension du comportement des programmes sur les architectures complexes. La tendance suivie
par l'optimisation automatique est l'apport de plus d'informations issues de l'analyse dynamique
des programmes mais soit cet apport est encore trs insusant, soit le temps de convergence des
heuristiques de recherche est long.
Dans cette thse, nous allons d'abord mettre en vidence l'importance de disposer des informations dtailles sur le comportement du programme sur l'architecture. Puis, nous verrons
comment nous pouvons mettre prot une expertise manuelle d'optimisation de programmes
pour construire une heuristique rapide d'optimisation itrative de programmes.
23
Chapitre 2
Optimisation et Analyse dynamique

dtaille
2.1 Introduction
La complexit des processeurs ne cessent d'augmenter et il devient de plus en plus dicile pour
les compilateurs de gnrer des programmes performants. En eet, les compilateurs utilisent
des modles d'architectures simplis leurs permettant de slectionner et de paramtrer des
optimisations dans des contraintes de temps relativement raisonnable pour les utilisateurs. Il
existe de nombreux travaux sur les transformations de programmes [BaGrSh94, LaRoWo91,
ChPaHaLe01, Ca96, McTe96, CoKi95, KiKnOB00, NaJuLa94] qui se focalisent le plus souvent sur
un ou deux composants de l'architecture, en revanche, seul un petit nombre d'entre eux tudient
l'optimisation pour plusieurs composants de l'architecture simultanment et leurs ventuelles
interactions.
Le but de ce chapitre est de montrer qu'il est possible et ncessaire d'utiliser une analyse
dynamique trs dtaille pour guider les optimisations et ainsi d'obtenir de bonnes performances. Pour cela, nous avons choisi d'optimiser un noyau de calcul trs tudi pour lequel de
nombreux travaux d'optimisation ont t raliss : le produit de matrices. Nous avons extrait
un sous-ensemble de transformations de programmes de la littrature et de l'industrie et nous
avons appliqu ces transformations en fonction d'une analyse dynamique trs prcise. L'analyse
dynamique a t obtenue l'aide du simulateur cycle cycle du processeur Alpha-21264 (EV68).
La section 2.2 prsente l'environnement de travail dans lequel nous avons ralis cette tude.
Dans la section 2.3 seront dtailles l'analyse et l'optimisation du noyau de calcul. La section 2.4
apporte les conclusions et discussions.
2.2 Environnement de travail

Le processeur cible est un Alpha-21264 (EV68) cadenc 1GHz et excution dans le dsordre
avec une mmoire cache de second niveau de 8 Moctets. Son architecture est dcrite par la
gure 1.1 dans le chapitre 1. Le systme d'exploitation est Tru64-Unix 5.A qui utilise des pages
mmoires de 8 Koctects.
24
2. Optimisation et Analyse dynamique dtaille
Pour chaque exprience ralise sur le produit de matrices, nous avons mesur les temps
d'excutions pour un intervalle de tailles de matrices centr autour de 1060 lments. Tous
les gains en temps d'excution indiqus dans cette section sont donc calculs l'aide de cette
moyenne.
2.3 Optimisation du produit de matrices base sur une analyse

dynamique dtaille
Notre travail d'optimisation a t guid par la performance mais surtout par le comportement du programme sur chaque composant de l'architecture. L'analyse dynamique dtaille
fournie par le simulateur cycle cycle du processeur Alpha-21264 nous a permis de comprendre
les phnomnes qui se produisent sur chaque composant de l'architecture. Pour chacun de ces
phnomnes, nous avons test plusieurs optimisations et slectionn celles qui apportaient le plus
de performance. Le rsultat de ces expriences est une suite de versions du produit de matrices
optimises. La table 2.1 montre, pour chaque tape d'optimisation, le gain obtenu par rapport
au code initial. Elle montre galement le gain obtenu avec le niveau d'optimisation maximum du
compilateur Fortran (V5.4) (-O5) et le gain obtenu avec l'association du prprocesseur KAP [Kap]
(-O5
+ KAP).
Etape
Transformation
gain
Etape 0
Programme initial
1.00
Etape 1
Blocage sur 2 dimensions pour cache de niveau 1
2.48
Etape 2
Blocage sur 3 dimensions pour TLB
2.62
Etape 3
Blocage sur 3 dimensions + permutation de boucle
3.11
pour queue d'criture

Etape 4
3.71
+ droulage pour ILP

Etape 5
9.90
+ droulage + blocage pour les registres

Etape 6
Blocage sur 2 dimensions pour cache de niveau 1 +
8.43
copie pour TLB + permutation de boucle + droulage de boucle + blocage pour les registres
Etape 7
Blocage sur 2 dimensions + copie + permutation de
12.25
boucle + droulage de boucle + blocage pour registres + prchargement pour latence

Etape 8
12.75
boucle + droulage de boucle + blocage pour registres + prchargement pour latence + Blocage sur
3 dimensions pour cache de niveau 2
Etape 9
13.56
boucle + droulage de boucle + blocage pour registres + prchargements pour latence + Blocage sur
3 dimensions pour cache de niveau 2 + optimisation
spcique pour l'architecture
-O5
3.26
-O5 + KAP
3.37
Tab. 2.1 Gains moyens pour des matrices de l'ordre de
106 lments
Le programme initial (Etape 0) est prsent dans la gure 2.1. Chaque version a t compile
2.3.
Optimisation du produit de matrices base sur une analyse dynamique
25
dtaille
avec les options suivantes :
-O2 -unroll 1 -nopipeline an d'appliquer les optimisations utiles
la gnration de code et d'inhiber les optimisations spciques l'architecture et les transformations sur les boucles. Ces options de compilation vitent galement que les optimisations
manuelles ne soient dtruites par les optimisations du compilateur.
do i=1,Ni
do k=1,Nk
R=b(k,i)
do j=1,Nj
Fig. 2.1 Etape 0 : Programme initial
Dans les paragraphes suivants, nous tudions chaque composant de l'architecture. Au dbut
de chaque paragraphe, nous nommons le composant cible et nous donnons le gain obtenu par
l'optimisation ainsi que sa contribution au gain nal en pourcentage.
Cache de niveau 1
(Etape 1, gain=2,48, contribution=12%). De nombreux travaux de re-
cherches sur l'optimisation de programmes de calculs scientiques, et plus particulirement sur le

produit de matrices, se sont focaliss sur les mmoires caches. En eet, ces programmes utilisent
gnralement de grands espaces de donnes, ralisant par consquent une utilisation intensive de
la mmoire. Dans un premier temps, nous avons observ que le taux d'checs du premier niveau
de cache (Dcache pour l'Alpha) tait de 32%.
Le blocage de boucle [WoLa91, LaRoWo91, CoKi95] est la transformation de programmes la
plus connue pour amliorer l'utilisation des mmoires caches. Rothberg et al. [LaRoWo91] ont
montr que la taille du bloc doit tre choisie de telle manire que les conits de cache soient minimiss. Les performances des techniques de slection des tailles de blocs bases sur l'organisation
du cache et des donnes [CoKi95] sont moins bonnes que les performances des techniques de slection bases sur le temps d'excution global [KiKnOB00]. Cette dernire technique base sur le
temps d'excution prend en considration de manire implicite l'ensemble de l'architecture. Nous
avons bloqu sur deux dimensions la matrice
A. Nous avons
fait une recherche exhaustive an de
trouver une taille de bloc qui minimise le temps d'excution et nous avons trouv
Tk
Tj
= 33.
Mme si l'optimisation a considrablement rduit le taux de dfaut de premier niveau de cache

(rduction de 95%), le rsultat se traduit uniquement par une contribution au gain nal de 12%.
do kk=1,Nk,Tk
do jj=1,Nj,Tj
do i=1,Ni
R=b(k,i)
Fig. 2.2 Etape 1 : Blocage sur 2 dimensions
Cache de niveau 1 + TLB
(Etape 2, gain=2,62, contribution=1%). Plusieurs travaux
[MiCaFe97] ont montr que le blocage de boucle pour le cache peut avoir un eet nfaste sur le
26
cache de traduction d'adresse (TLB). La gure 2.3a reprsente l'ordre d'accs aux matrices pour
le produit de matrices de l'tape 0 avant le blocage et la gure 2.3b reprsente l'ordre d'accs
aprs le blocage. Rappelons-nous qu'en fortran les lments des tableaux sont rangs en mmoire
suivant la premire dimension (la plus gauche), ici les lments des matrices sont rangs suivant
les colonnes. Supposons que la taille d'une colonne des matrices soit gale la taille d'une page
mmoire (8Koctets sur le processeur Alpha). Dans la version non-bloque, pour chaque itration
de
i,
une entre du cache de translation d'adresse est utilise pour chacune des colonnes des
matrices
C.
et
Ensuite, l'entre de la colonne de
l'entre de la colonne de
itrations
et
est rutilise au cours de l'itration
de TLB contenant les colonnes de
jj
est rutilise au cours de l'itration
j.
et
Dans la version bloque, les
sont beaucoup plus courtes, les entres de TLB ne sont donc que partiellement
utilises lors de ces itrations. La taille de l'itration
et
et
i tant
grande, la probabilit que les entres
soient purges avant les prochaines itrations de
kk
est importante. Nous avons observ une augmentation du taux d'checs de TLB de 4,98e-4
5,08e-4. Ce taux est relativement faible mais l'impact des dfauts de TLB sur la performance
est important.
boucle j (interne)
boucle j (interne)
boucle k
boucle k
boucle i
B
k
boucle i
j
j
j
A
(a) avant blocage
(b) aprs blocage
Fig. 2.3 Ordre d'accs aux matrices
An de ne pas perdre le bnce du blocage pour le cache, nous avons bloqu la troisime
dimension
de
en faisant en sorte que le nombre d'entres de TLB utilises par les blocs de
et
soit infrieur au nombre total d'entres de TLB. Le programme correspondant est prsent
dans la gure 2.4. Le blocage sur les trois dimensions a rduit le taux d'chec de TLB de 5,08e-4
2,08e-5. Cette optimisation a augment le nombre de dfauts de cache de premier niveau mais
cela n'est pas susant pour compenser le bnce obtenu par la rduction des dfauts de TLB.
Le gain a donc augment, il est de : 2,62.
Cache de niveau 1 + TLB + queue d'criture
(Etape 3, gain=3,11, contribution=4%).
Gnralement, les oprations mmoires d'criture (de rangement) ne sont pas considres comme
tant prioritaires pour les optimisations. En eet les oprations d'criture sont envoyes la mmoire et aucun calcul ne dpend de leurs excutions (contrairement aux oprations de lecture ou
de chargement). Cependant, plusieurs composants de l'architecture peuvent dgrader les performances du processeur cause des oprations d'criture, en particulier la queue des oprations
d'criture. Nous avons observ ici un phnomne dirent. Dans les processeurs superscalaires,
on rencontre des cas o des oprations mmoires doivent tre annules et leurs excutions doivent
2.3.
27
dtaille
do ii=1,Ni,Ti
do kk=1,Nk,Tk
do jj=1,Nj,Tj
do i=ii, MIN(ii+Ti-1,Ni)
R=b(k,i)
Fig. 2.4 Etape 2 : Blocage sur 3 dimensions
tre retardes. Dans le processeur Alpha, il y a plusieurs cas o deux oprations mmoires ne
peuvent pas tre excutes simultanment. Un exemple serait lorsqu'une opration d'criture et
une opration de lecture doivent accder au mme ensemble dans le cache. Comme le montre
l'exemple de la gure 2.5, si l'opration de lecture
celui de l'opration d'criture
plus jeunes que
Sj (k > j ).
Si
Sj
doit accder un ensemble identique
alors elle est purge du pipeline avec toutes les oprations
Sk
Ce type d'vnements est appel purge de conit mmoire.
Etage memoire
programme :
Queue de lectures
...
Si: stt $F1, @A
...
comparaison
...
dadresses
Sj: ldt @A, $F3
...
Queue decritures
...
Conflit memoire : Purge de Sk pour k>=j,
Rechargement de toutes les instructions depuis Sj
Execution dans le desordre
Fig. 2.5 Conit mmoire
Pour le programme optimis de l'tape 2, nous avons observ un nombre important de purges
dues des conits mmoires qui taient souvent produits par l'opration d'criture et les deux
oprations de lecture de la boucle interne (j ). An de rduire la probabilit d'avoir des conits
et donc des purges du pipeline, nous avons rduit le nombre d'oprations d'criture. Nous avons,
pour cela, permut les boucles
et
ainsi montres dans la gure 2.6. L'ordre d'accs aux
matrices est reprsent dans la gure 2.7.

La permutation des boucles permet de mmoriser
le nombre d'oprations d'criture par la taille du bloc
c(j; i) dans un registre et de diviser ainsi

T k (33). Le nombre de purges dues des
conits mmoires a ainsi t divis par 24 et le gain est pass de 2,62 3,11.
Cache de niveau 1 + TLB + queue d'critures + ILP
(Etape 4, gain=3,71, contribu-
tion=5%). Les registres sont souvent une ressource critique et les corps de boucles importants
produisent gnralement des instructions de dbordements (lectures/critures), appeles aussi
28
do ii=1,Ni,Ti
do kk=1,Nk,Tk
do jj=1,Nj,Tj
R=c(j,i)
R=R+b(k,i)*a(j,k)
c(j,i)=R
Fig. 2.6 Etape 3 : Permutation de boucle pour la queue des critures
i
boucle k (interne)
boucle j
boucle i
Fig. 2.7 Ordre d'accs aux matrices aprs blocage sur 3 dimensions
spill code. Dans le cas du produit de matrices, le corps de la boucle est relativement petit
et plusieurs registres restent donc disponibles. Les compilateurs utilisent gnralement ces registres disponibles pour augmenter le paralllisme d'instructions (ILP) en utilisant le droulage
de boucles ou bien le pipeline logiciel. An d'augmenter le paralllisme d'instructions, nous avons
droul 8 fois la boucle interne et obtenu un gain de 3,71.
Cache de niveau 1 + TLB + queue d'critures + ILP + Registres
(Etape 5, gain=9,90,
contribution=49%). Durant les tapes prcdentes, nous avons rduit les nombres de dfauts du
cache de donnes et du cache de traduction d'adresses (TLB). Nous avons ainsi rduit la latence
mmoire moyenne. Cependant, les performances du programme optimis sont toujours limites
par la mmoire. Eectivement, le rapport du nombre de calculs sur le nombre d'oprations
mmoires est faible, il est approximativement gal 1. Or, les registres (premier niveau de
la hirarchie mmoire) peuvent tre utiliss pour rduire le nombre d'accs mmoires. Aprs
l'optimisation prcdente (le droulage de boucle pour augmenter le paralllisme d'instructions),
nous avons observ qu'il restait des registres disponibles que nous pouvons utiliser pour rduire
le nombre d'accs mmoires. Le blocage pour les registres peut se faire par un simple droulage
de boucle externe [CaGu97]. La gure 2.8 montre le mme programme que celui de la gure 2.6
pour lequel la boucle externe
La rfrence
a t droule deux fois.
b(k; i) peut tre place dans un registre, supprimant ainsi un accs mmoire. De
2.3.
29
dtaille
do ii=1,Ni,Ti
do kk=1,Nk,Tk
do jj=1,Nj,Tj
do j=jj, MIN(jj+Tj-1,Nj), 2
Rc0=c(j,i)
Rc1=c(j+1,i)
Rb0=b(k,i)
Rc0=Rc0+Rb0*a(j,k)
Rc1=Rc1+Rb0*a(j+1,k)
c(j,i)=R
Fig. 2.8 Etape 4 : Blocage de registres
la mme manire, nous pouvons drouler la boucle i. Nous avons recherch, de manire exhaustive,
la meilleure faon de drouler les boucles et nous avons trouv un droulage de 3-4-8, c'est--dire
3 fois pour la boucle
i,
4 fois pour la boucle
et 8 fois pour la boucle interne
k.
Rappelons que
le droulage de la boucle interne ne favorise pas la rutilisation des registres mais qu'il favorise
plutt le paralllisme d'instructions. Nous avons observ une diminution du nombre des lectures
mmoires de 69% et le rapport du nombre de calculs sur le nombre d'oprations mmoires a
augment de 300%. Par consquent, l'utilisation des units fonctionnelles est beaucoup plus
importante. Le gain passe de 3,71 9,90 soit une contribution au gain nal de 49%.
En considrant les registres comme un niveau de la hirarchie mmoire supplmentaire, il
est possible d'amliorer la bande-passante mmoire du programme. Il n'est pas facile de bien
exploiter les registres physiques d'un processeur superscalaire excution dans le dsordre car
ses registres sont cachs par le mcanisme de renommage dynamique [SmSo95]. En revanche,
certaines architectures comme l'architecture EPIC de l'itanium [Epic] exposent de nombreux
registres logiques au programmeur et au compilateur.
Interaction entre cache de niveau 1, TLB, queue d'critures et Registres
(Etape 6).
L'importance du gain obtenu lors de la prcdente tape suggre de prter plus d'attention et de
privilgier le blocage de registres. Dans ce paragraphe, nous rvisons les optimisations jusqu'ici
appliques an de favoriser le blocage de registres. Nous allons voir comment l'interaction entre
plusieurs composants de l'architecture peut inuencer les optimisations individuellement et la
squence des optimisations.
Dans le paragraphe prcdent, nous avions amlior la rutilisation des registres pour les
rfrences
a(j; k )
et
b(k; i)
mais nous n'avions pas mentionn la rfrence
c(j; i).
Le droulage de
boucle n'amliore pas la rutilisation de cette rfrence, c'est la taille de la boucle

dtermine la rutilisation de
c(j; i).
Plus la longueur de l'itration
des lectures/critures des rfrences
c(j; i)
k (T k )
qui
est grande, plus le nombre
diminue. Or, nous utilisons une taille d'itration
relativement petite (T k = 33), nous pouvons donc augmenter la rutilisation de registre sur la
rfrence
c(j; i)
en augmentant
blocs des matrices
et
B.
T k.
Lorsque nous augmentons
T k,
nous augmentons la taille des
Nous avons fait plusieurs tests qui nous ont montr qu'il n'tait pas
avantageux de perdre la rutilisation du cache de premier niveau au prot de la rutilisation de

registres. Nous devons donc faire en sorte que les blocs (T k
matrice
T i) de la matrice B et (T j T k) de la
A tiennent dans le cache. D'autre part, nous devons conserver la rutilisation de registres
30
pour les matrices

nous devons avoir
A et B obtenu par
T i 3 et T j 4.
le droulage des boucles externes (3-4-8), c'est--dire que

Nous avons donc choisi de maximiser
tailles telles que les blocs de la matrice
B (T k 3)
et de la matrice
(4
Tk
en utilisant des
T k) soient inclus dans
le cache de premier niveau. Ces blocs tant trs troits, nous avons obtenu une valeur pour
Tk
N k . Le programme correspondant prsent dans la gure 2.9 conserve le blocage

k avec le paramtre T k . On remarque que le blocage des boucles i et j a disparu
t remplac par le blocage de la boucle k associ au droulage des boucles externes
suprieure
de la boucle
puisqu'il a
et
j.
do kk=1,Nk,Tk
do i=1,Ni,3
do j=1,Nj,4
Rc0=c(j,i)
Rc1=c(j+1,i)
...
Rb0=b(k,i)
Rb1=b(k,i+1)
Rb2=b(k,i+2)
Ra0=a(j,k)
Ra1=a(j+1,k)
Ra2=a(j+2,k)
Ra3=a(j+3,k)
Rc0=Rc0+Rb0*Ra0
Rc1=Rc1+Rb0*Ra1
Rc2=Rc2+Rb0*Ra2
...
c(j,i)=Rc0
c(j+1,i)=Rc1
...
Fig. 2.9 Compromis entre rutilisation registres/cache
En observant la performance de ce programme, nous pouvons constater une chute de performance de 48% due une augmentation du nombre de dfauts du cache de traduction d'adresses
(TLB) qui ont t multiplis par 780. La valeur de
le TLB lors des itrations de la boucle interne
k.
Tk
est telle que les rfrences
a(j; k )
purgent
Pour viter de purger le TLB sans rduire
nous avons choisi de copier les blocs des matrices
et
T k,
dans des espaces mmoires contigus.
T k par N j=4 lments pour copier les blocs de la matrice A et

T k par N i=3 lments pour copier les blocs de la matrice B . La copie des blocs
Nous avons donc un tableau de 4

un tableau de 3
de
A se fait en
parcourant
A suivant
les colonnes (une colonne du bloc de
premires lignes du tableau de copie). Pour les blocs de
B,
A est
copie dans les 4
les 4 premires colonnes du bloc sont
copies dans la premire colonne du tableau de copie. Le schma de la copie est reprsent avec
le schma d'accs aux matrices dans la gure 2.10, le programme correspondant est reprsent
dans la gure 2.11.
La copie nous a permis de rduire le nombre de dfauts du cache de traduction d'adresses de
98%. La copie permet galement de rduire les dfauts de cache dus des conits [TeGrJa93].
Enn, nous avons eectu plusieurs tests de droulage (nous avons simultanment fait varier
le droulage externe sur les boucles
i, j
et le droulage interne sur la boucle
k ).
Dans la section
prcdente, le meilleur facteur de droulage tait de 3-4-8. Suite une nouvelle recherche ex-
2.3.
31
dtaille
boucle k (interne)
boucle j
boucle i
B
Copie de B
j
A
Copy de A
k
Fig. 2.10 Schma d'accs aux matrices avec copies
do kk=1,Nk,Tk
do i=1,Ni,4
Copie du bloc de la matrice B
C
...
do j=1,Nj,4
C
Copie du bloc de la matrice A
...
Rc0=c(j,i)
Rc1=c(j+1,i)
...
C
Code de la boucle interne travaillant sur les copies
...
c(j,i)=Rc0
c(j+1,i)=Rc1
...
Fig. 2.11 Copie des blocs des matrices
et
pour rduire les dfauts de TLB
haustive, nous avons observ que le meilleur facteur de droulage n'tait plus 3-4-8 mais 4-4-2
car la valeur de
Tk
favorise la rutilisation des registres.
Finalement, le gain obtenu par cette suite d'optimisations est seulement de 8,43 (tape 6)
contre 9,90 pour l'tape 5. Cette perte est due essentiellement une dgradation de l'utilisation
du cache pour les matrices
A et C
et au cot de la copie. Toutefois, le paragraphe suivant va nous
montrer une optimisation pour laquelle le programme de l'tape 6 est plus adapt que le programme de l'tape 5. D'autre part, cette mme optimisation permet galement de rduire le cot
de la copie (au nal, nous obtiendrons un meilleur gain avec l'tape 6). Une approche similaire
est utilise pour le produit de matrices dans la librairie mathmatiques optimise manuellement
pour le processeur Alpha [Cxml].
32
Cache de niveau 1 + TLB + queue d'critures + ILP + Registres + Prchargement
(Etape 7, gain=12,25, contribution=19%). Le prchargement est une optimisation qui consiste

prcharger une donne dans le cache an que l'opration de lecture associe accde au cache avec
la latence la plus courte. Dans certaines architectures, il existe des mcanismes de prchargement
dynamiques. Pour le processeur Alpha ce mcanisme n'existe pas, en revanche des instructions
de lecture particulires ont t prvues pour eectuer un prchargement logiciel.
Nous avons appliqu le prchargement logiciel sur le programme initial (tape 0) du produit de
matrices (nous avons prcharg toutes les matrices). Nous avons ainsi obtenu un gain de 1,33 car
la mauvaise utilisation des caches et des registres gnre un trac mmoire important ne laissant
pas susamment de bande-passante pour le prchargement. Nous avons galement appliqu
l'optimisation de prchargement logiciel sur le programme de l'tape 5 et nous avons obtenu un
gain de 1,05 par rapport au temps d'excution du programme de l'tape 5. Ce faible gain est d
la taille des blocs
T k.
En eet, l'itration de la boucle interne
est petite (T k = 33), elle lit 4
lignes de cache (chaque ligne contient 8 lments de 8 octets) ce qui laisse peu d'opportunits de
prchargement (moins de 4 car la distance de prchargement doit tre suprieur une itration
pour tre ecace).
Dans le programme de l'tape 6, nous utilisons une taille d'itration bien plus grande (T k =
N k)
qui permet au prchargement d'tre beaucoup plus ecace. Aprs avoir rduit la bande-
passante mmoire utilise avec le blocage pour les registres et le cache de traduction d'adresses
(TLB), la rduction de la latence mmoire avec le prchargement permet de cacher le cot de la
copie dans cette version du produit de matrices. Nous avons appliqu le prchargement plusieurs
endroits dans le programme : la fois dans les copies des blocs des matrices
A et B
pour masquer
la latence entre le second niveau de cache et la mmoire et aussi dans la boucle interne
le chargement de la copie de
pour
an de masquer la latence entre le premier et le second niveau
de cache. Le programme de la gure 2.12 reprsente l'insertion du prchargement en considrant

que celui-ci puisse tre eectu au niveau du programme source. Lorsque nous avons ralis ces
optimisations, les directives de compilation du compilateur Alpha pour insrer des instructions
de prchargement n'taient pas encore supportes. Nous avons donc insr les instructions de
prchargement au niveau assembleur. Les instructions de prchargement assembleur sont des
instructions de lecture dont le registre de destination est le registre nul du processeur Alpha
(f31) :
ldl f31, 16*8(r5)
/ prchargement de a(j,k)
La distance de prchargement est le nombre d'itrations entre l'itration pendant laquelle

la donne est prcharge et l'itration durant laquelle la donne est eectivement lue. Cette
distance doit tre choisie susamment grande pour cacher la latence mmoire souhaite mais
cette distance ne doit pas tre trop grande pour viter que les donnes prcharges ne soient
jectes du cache avant d'tre utilises. Aprs plusieurs tests, nous avons trouv une distance de
prchargement de 2 itrations.
Finalement, le prchargement appliqu au programme de l'tape 6 permet d'obtenir un gain
de 12,25 alors que le prchargement appliqu au programme de l'tape 5 n'obtient qu'un gain de
10,37.
Cache de niveau 1 + TLB + queue d'critures + ILP + Registres + Prchargement

+ Cache de niveau 2
(Etape 8, gain=12,75, contribution=4%). Les algorithmes de blocage
2.3.
33
dtaille
do kk=1,Nk,Tk
do i=1,Ni,4
Copie du bloc de la matrice B
C
Prchargement(b(k+4,i))
...
do j=1,Nj,4
C
Copie du bloc de la matrice A
Prchargement(a(j+4,k))
...
Rc0=c(j,i)
Rc1=c(j+1,i)
...
C
Prchargement(a(j,k+4))
...
c(j,i)=Rc0
c(j+1,i)=Rc1
...
Fig. 2.12 Etape 7 : prchargements
de boucles se focalisent gnralement sur le cache de premier niveau. Cependant, les pnalits
engendres par des dfauts de caches des niveaux infrieurs sont souvent beaucoup plus importantes que celles du premier niveau. Par exemple, pour le systme que nous utilisons, un accs
au cache de second niveau (Bcache) cote 12 cycles processeur alors qu'un accs mmoire cote
140 cycles processeur. D'autre part, de rcents travaux [SrLe98] ont montr que la latence de
plusieurs dfauts de cache de premier niveau peut tre masque par le rordonnancement dynamique des instructions dans les processeurs excution dans le dsordre. Cela se traduit par de
faibles gains de performances lors de l'optimisation pour le cache de premier niveau.
L'optimisation de blocage de boucles pour une hirarchie de mmoires caches complte est
particulirement dicile : il est ncessaire de trouver le bon compromis entre les dirents niveaux
de cache [NaJuLa94, CaFeHu95]. En eet le blocage pour un niveau particulier engendre souvent
des dgradations sur les autres niveaux de la hirarchie mmoire.
Dans la version du programme optimis de l'tape 6, nous utilisons une taille de bloc de 4
pour les matrices
et
matrice
i,
le bloc de
i = 1 utilise
A. A la n de
car le facteur de droulage est 4-4-2. La premire itration
le premier bloc de la matrice

l'itration
T k
durant laquelle l'itration
parcourt les blocs de
ne sera plus utilis. Lors de l'itration
est utilis et les blocs de la matrice
suivante, le second bloc de la
rutiliss (voir gure 2.10). Mais la distance de
A est trop grande pour que ceux-ci soit encore dans le cache de second
N k et N i = N j = N k = 1060 et la taille du cache de second niveau
de l'Alpha est de 8 Moctets. Nous avons bloqu les boucles i et j an de rduire la distance de
rutilisation des matrices A et B . Le choix des tailles de blocs est fait de telle sorte que le bloc
de la matrice A (T j T k ) et le bloc de la matrice B (T k T i) tiennent dans le second niveau
rutilisation des blocs de
niveau. En eet,
Tk
de cache. Le programme correspondant est reprsent sur la gure 2.13. Il est trs similaire au
programme ralisant le blocage sur 3 dimensions utilis pour le cache de premier niveau et le
cache de traduction d'adresses (TLB), cependant, les tailles de blocs (T i et
T j)
ciblent, ici, le
second niveau de cache. Gnralement, le choix des tailles des blocs est trs important lorsque
l'associativ du cache est faible, il permet de minimiser les conits dans le cache [CoKi95, RiTs99].
34
Mme si le cache de second niveau du processeur Alpha est correspondance directe, les conits
sont dj minimiss car le cache contiendra les copies des blocs et non pas les blocs eux-mmes
(les copies sont dclares dans des espaces contigus en mmoire).
do ii=1,Ni, Ti
do kk=1,Nk,Tk
Copie du bloc de la matrice B (Tk * Ti)
C
Prchargement(b(k+4,i))
...
do jj=1,Nj, Tj
C
Copie du bloc de la matrice A (Tj * Tk)
Prchargement(a(j+4,k))
...
do i=ii,MIN(ii+Ti-1,Ni), 4
do j=jj,MIN(jj+Tj-1,Nj), 4
Rc0=c(j,i)
Rc1=c(j+1,i)
...
do k=kk, MIN(kk+Tk-1,Nk), 2
C
Prchargement(a(j,k+4))
...
c(j,i)=Rc0
c(j+1,i)=Rc1
Fig. 2.13 Etape 8 : blocage des boucles
et
pour le cache de second niveau
Le blocage pour le second niveau de cache a permis de rduire les dfauts de cache de second
niveau de 11%. Dans le mme temps, les dfauts de cache du premier niveau ont augment de
9% 10%, mais le gain reste positif et il est de 12,75.
Cache de niveau 1 + TLB + queue d'critures + ILP + Registres + Prchargement + Cache de niveau 2 + Architecture
(Etape 9, gain=13,56, contribution=7%). Les
composants de l'architecture pour lesquels nous avons optimis jusqu'ici sont des composants
classiques, communs de nombreuses architectures. Les architectures de processeurs possdent

de nombreuses caractristiques spciques qui retent les compromis faits par les architectes
lors de la conception. Parfois, ces caractristiques propres chaque architecture peuvent avoir
un impact signicatif sur la performance.
L'architecture du processeur Alpha possde deux pipelines : un pour les instructions entires
et un pour les instructions ottantes. Chaque pipeline possde ses propres units fonctionnelles et
leurs queues d'instructions : la queue d'instructions entires et la queue d'instructions ottantes.
La gure 2.14 reprsente le pipeline du processeur Alpha. Lorsque les queues d'instructions
contiennent de nombreuses instructions, il se peut que tous les registres physiques du processeur
soient utiliss, toute nouvelle instruction doit alors attendre qu'un registre se libre. Dans ce
cas, le chargement des instructions doit tre suspendu. Les tages de chargements (Fetch), de
placement (Slot), et de renommage (Map) sont donc suspendus. Cependant, l'tage de renommage ne peut pas redmarrer immdiatement aprs la libration des registres : il doit attendre
2 cycles supplmentaires de suspension. L'tage de renommage peut galement tre suspendu
lorsqu'une des deux queues d'instructions (entires ou ottantes) dborde. Dans le cas du produit de matrices, l'tage de renommage est rgulirement suspendu par un dbordement de la
2.4.
35
Conclusions
queue d'instruction ottantes. Pour viter les suspensions de l'tage de renommage, nous devons
diminuer le ux d'instructions ottantes. La solution, que nous avons choisie, est d'insrer des
instructions fantmes (NOP). Ces instructions ne modient pas les calculs du programme car
elles ne s'excutent pas : elles ne traversent qu'une partie du pipeline, de l'tage de chargement
tire
Re
Me
m
c
Ex
e
g
Re
ue
Iss
Ma
p
Slo
t
Fe
tc
jusqu' l'tage de renommage, ensuite elles sont retires.
Floating
Point
STALL
Integer
Fig. 2.14 Architecture du pipeline du processeur Alpha-21264
Nous avons insr ces instructions fantmes au niveau assembleur comme pour les instructions
de prchargement et comme cela est indiqu dans la gure 2.15. Le nombre de suspensions du
pipeline dues aux dbordements de la queue d'instructions ottantes a diminu de 60%. Le gain
nal est de 13,56 par rapport au programme initial.
add
mul
ld
add
f18,f12,f18
f14,f26,f12
f8 , 0*SIZE(r3)
f17,f11,f17
add
nop
mul
ld
f18,f12,f18
mul
ld
...
...
f14,f27,f11
f19, 0*SIZE(r5)
add
nop
mul
ld
f17,f11,f17
...
f14,f26,f12
f8 , 0*SIZE(r3)
f14,f27,f11
f19, 0*SIZE(r5)
...
Fig. 2.15 Insertion des instructions fantmes
2.4 Conclusions
Dans ce chapitre, nous avons montr la complexit du comportement de programmes aussi
simples que le produit de matrices. Cette complexit est lie la complexit de l'architecture du
processeur et aux nombreuses interactions entre les dirents composants. Nous avons galement
montr qu'une analyse dynamique trs prcise peut aider comprendre les phnomnes complexes
qui se produisent lors d'une excution. L'analyse dynamique peut ainsi guider un processus
d'optimisation. Cette tude montre galement que les processus d'optimisation ne doivent pas
36
uniquement se focaliser sur les transformations de programmes les plus populaires comme le
blocage pour les caches, dont la contribution au gain nal est seulement de 12% ici, mais ils
doivent prendre en compte tous les composants de l'architecture.
37
Chapitre 3
Processus d'optimisation systmatique

Dans le chapitre 1, nous avons vu que la complexit des architectures augmentant, les compilateurs ont beaucoup de mal prendre les bonnes dcisions lors des phases d'optimisation. Nous
avons vu galement que l'information obtenue par l'analyse statique n'est pas susante pour
en dduire le comportement des programmes. Le chapitre 2 a montr que l'analyse dynamique
dtaille permet d'obtenir des informations essentielles pour prendre les bonnes dcisions lors du
processus d'optimisation. Dans ce chapitre, nous prsentons un processus d'optimisation bas
sur une analyse dynamique dtaille. Ce processus est guid par un arbre de dcision. Chaque
branche de l'arbre est une suite d'tapes d'analyses et de dcisions bases sur des mtriques
d'analyses dynamiques. Nous appelons ces mtriques des anomalies de performance. Chaque
feuille de l'arbre identie un problme de performance dominant, pour lequel nous suggrons
une ou plusieurs optimisations. Une itration du processus consiste raliser une optimisation,
ventuellement l'adapter et la gnraliser d'autres parties du programme. Progressivement, le
processus cre des squences ou des compositions de transformations de programmes et continue
jusqu' ce que les optimisations n'apportent plus susamment de gain de performance.
3.1 Identication des problmes de performance sur une architecture complexe

Le processus d'optimisation est guid par l'arbre de dcision. La dcision prise chaque nud
est un choix systmatique bas sur des mtriques issues de l'analyse dynamique. Chaque dcision
est une tape dans l'identication du problme de performance dominant. Notre motivation
principale tait de trouver la cause exacte de toutes les dgradations de performance observes lors
de l'excution d'un programme et ainsi de trouver une optimisation adapte. Dans un processeur
superscalaire excution dans le dsordre comme le processeur Alpha-21264, il n'est pas facile
de trouver la cause exacte d'une dgradation de performance. Par exemple, lorsqu'une station de
rservation pleine cause le gel du pipeline, il faut remonter la trace d'excution des instructions
se trouvant dans les stations de rservation pour trouver la cause exacte : il se peut qu'au dpart
une lecture mmoire fasse un dfaut de cache, que celui-ci ralentisse l'excution de plusieurs
oprations arithmtiques, qui elles-mmes ralentissent un calcul d'adresse, le calcul d'adresse
ralentit l'excution d'autres oprations mmoires pour enn geler le pipeline. Les instructions
fautives peuvent donc avoir quitt le processeur de nombreux cycles avant que la dgradation
38
3. Processus d'optimisation systmatique
de performance ne soit observe. D'autre part, les causes exactes de la mme dgradation de
performance peuvent tre partages entre de multiples vnements.
Plutt que de rechercher les causes exactes l'instant o une dgradation de performance
apparat, nous avons choisi de relever tous les vnements pouvant tre l'origine d'une dgra-
dation de performance au moment mme o ils apparaissent. Nous avons appel ces dirents
vnements des anomalies de performance et nous les combinons an de dterminer, parmi plusieurs causes, la cause dominante (la plus responsable de la dgradation de performance ). Lorsque
nous relevons une anomalie lors de l'excution d'une instruction, nous analysons uniquement les
instructions parentes dans le graphe de ot de donnes, c'est--dire les instructions fournissant
les oprandes. Par exemple, dans la gure 3.1 si une anomalie est rvle pour l'instruction
nous limitons notre analyse aux instructions
S1 ldt $f1,0(a1)
S4
S2
S3
mult $f1,$f2,$f3
S5
addt $f4,$f3,$f4
S6
et
S5.
S6,
ldt $f2,0(a2)
S4
ldt $f7,0(a3)
addt $f4,$f7,$f4
limite de lanalyse
Fig. 3.1 Exemple de graphe de ot de donnes
Pour slectionner la transformation de programmes adapte, il est ncessaire de caractriser

au mieux la nature de la dgradation de performance. Le point de dpart de l'analyse est bas sur
l'observation de l'cart entre la performance soutenue et la performance crte. La performance
crte est atteinte lorsque toutes les units fonctionnelles du processeur sont utilises cent
pour cent, c'est--dire chaque cycle de l'excution. Nous observerons donc une dgradation de
performance chaque fois qu'une unit fonctionnelle ne sera pas utilise.

Si toutes les units fonctionnelles sont utilises cent pour cent, alors le programme est limit
par son nombre d'oprations. Dans le cas contraire, il y a une perte de performance qui peut
tre due trois causes :
une mauvaise utilisation de la hirarchie mmoire,
un manque de paralllisme,
une mauvaise utilisation de composants spciques l'architecture,
ou bien encore, les trois la fois.
Pour dterminer la cause principale, il faut observer des Anomalies de performance relatives
aux units fonctionnelles, aux queues de lancement associes (ou stations de rservations), la
nature des oprandes des instructions dans les queues de lancement, ou encore des Anomalies de
performance relatives aux composants spciques de l'architecture.

Le raisonnement permettant d'identier la cause dominante de la dgradation de performance
est dcrit par l'arbre de dcision reprsent dans la gure 3.2.
3.1.
Identification des problmes de performance sur une architecture
39
complexe
Les units fonctionnelles sontelles

utilises chaque cycle ?
oui
non
Existetil des instructions dans la
queue de lancement ddies aux units
fonctionnelles non utilises ?
Programme limit par

le nombre doprations
non
oui
Existetil des instructions du mme type

ddie dautres units fonctionnelles
dans la queue de lancement ?
oui
Quel est le type des oprations ?
non
Utilisation
dsquilibre
des units
fonctionnelles
flottantes
(FU_fp)
Oprations mmoires
Estce un problme dinstructions ou un

problme spcifique de larchitecuture
li aux oprations mmoires
instruction
Utilisation
dsquilibre
des units
fonctionnelles
entires
(FU_int)
Quel est le type des

instructions sources ?
Estce un problme
de chargement
des instructions ?
Problme de latence ou
de bande passante
Oprations arithmtiques
Manque de paralllisme
memoire
Quel type de problme

spcifique ?
Type des oprations ?
int
Problme
de flot
de contrle
(BR Miss)
Problme de TLB
dinstructions
(ITB Miss)
Problme de conflits
des accs au cache
(Ld/st order trap
+load retry
+MAF conflict trap)
Quel est le type

de problme ?
Problme de
dpendances sur
des oprations
entires
(DEPoO_int)
Problme de
capacit
(LQ full+SQ full
+MAF full)
Problme de cache
dinstruction
(ICM Miss)
fp
Problme de
dpendances sur
des oprations
flottantes
(DEPoO_fp)
La latence mmoire estelle leve ?
non
Problme de bande passante

(MEM_LAT)
oui
Problme de latence mmoire

(MEM_LAT)
Problme de cache
ou de TLB ?
Problme de TLB de donnes

(DTB Miss)
Problme de cache
Type des oprations mmoires ?

fp
Problme de cache sur

les oprations flottantes
(MEM_LAT_fp)
int

les oprations entires
(MEM_LAT_int)
Fig. 3.2 Arbre de dcision
La branche souligne par les ches en gras donne un exemple de raisonnement identiant un
problme de latence mmoire. A la racine de l'arbre, nous constatons que les units fonctionnelles
ne sont pas utilises chaque cycle. Il peut y avoir deux explications cela : la premire est qu'au
40
cycle o l'unit fonctionnelle n'est pas utilise, il n'y a aucune instruction ddie cette unit
dans la queue de lancement. La seconde explication est qu'au cycle o l'unit fonctionnelle n'est
pas utilise, il y a bien une instruction ddie cette unit dans la queue de lancement mais au
moins l'un de ses deux oprandes n'est pas prt. Nous avons donc une anomalie de performance
qui compte le nombre de cycle o une unit fonctionnelle n'est pas utilise et o il n'y a pas
d'instruction ddie dans la queue de lancement, et une autre anomalie de performance qui,
chaque fois qu'une unit fonctionnelle n'est pas utilise, compte le nombre d'oprandes non prts
appartenant aux instructions ddies cette unit, dans la queue de lancement. Nous verrons plus
loin dans la section 3.2 comment comparer des anomalies de performance ayant des probabilits
d'occurrence et des impacts sur la performance dirents. Mais supposons ici que l'anomalie de
performance dominante soit la seconde (oprandes non prts), dans ce cas la cause dominante
peut tre soit un manque de paralllisme, soit un problme mmoire. Pour distinguer ces deux
cas, l'anomalie de performance est rane en deux sous-anomalies, c'est--dire que chaque fois
qu'une unit fonctionnelle n'est pas utilise et qu'une instruction ddie se trouve dans la queue
de lancement, nous observons la nature des instructions devant fournir les oprandes non prts.
Si ces instructions sont majoritairement des oprations arithmtiques alors la cause dominante
sera un manque de paralllisme. Si, au contraire, ces instructions sont en majorit des oprations
de lecture mmoire alors la cause dominante sera un problme mmoire. Supposons, dans notre
exemple que nous ayons aaire un problme mmoire, nous devons alors dterminer si la cause
dominante est un problme de bande passante ou bien un problme de latence. Pour cela, nous
combinons l'anomalie prcdente avec une nouvelle anomalie : la latence mmoire. Si la latence
mmoire est leve alors le problme est identi comme tant un problme de latence sinon
il est identi comme tant un problme de bande passante. L'identication du problme de
performance a pour objectif de trouver la transformation de programmes la plus adapte.
Pour collecter les anomalies de performance, nous observons le comportement des instructions sur l'architecture chaque cycle. Considrons l'exemple de la gure 3.1 et supposons que
l'excution de celui-ci illustre l'exemple du problme de performance dcrit ci-dessus. Pour un
S6 est dans la queue

pas. L'instruction S4
cycle donn, l'unit fonctionnelle d'addition n'est pas utilise et l'instruction
f4 est prt alors que son oprande f7 ne l'est

f7, elle est en cours d'excution. Cette instruction
de lancement. Son oprande

est l'instruction source de
est une lecture m-
moire, nous incrmentons donc le compteur d'anomalies de type dpendances sur une opration
mmoire. Indpendamment et paralllement, nous mesurons la latence de l'opration de lecture

mmoire. Si ce cas de gure se prsente souvent alors l'anomalie de dpendances sur des oprations mmoires et l'anomalie latence mmoire seront leves, nous en dduirons un problme
de latence mmoire. Au contraire, si la latence mmoire est faible alors nous en dduirons un
problme de bande passante.
3.2 Normalisation des anomalies

La table 3.1 prsente la hirarchie des anomalies utilises dans le processus d'identication
formalis par l'arbre de dcision. Les quatre principales catgories d'anomalies sont :
les anomalies de dpendances (DEP),
les anomalies d'utilisation des units fonctionnelles (FU),
la latence mmoire (MEM),
3.2.
41
Normalisation des anomalies
les purges de pipeline dues des comportements spciques l'architecture des composants
(TRAPS).
Statistiques
DEP
DEP_fp
DEPoO_fp
DEPoM_fp
DEP_int
DEPoO_int
DEPoM_int
FU
FU_fp
FU_int
MEM_LAT
MEM_LAT_fp
MEM_LAT_int
Traps
ITraps
BR Miss
IC Miss
ITB Miss
DTraps
DTB Miss
Cache
conflict
LSQ/MAF
full
ma
7.38
a
5.08
2.09
0.54
Latence mmoire de toutes les oprations de lecture
12.84
8.13
Anomalies spciques aux comportements de certains composants de l'architecture (ITraps + DTraps)
0.005
0.041
Descriptions
Les anomalies de dpendances (DEP_fp + DEP_int)

DEPoO_fp + DEPoM_fp
Nombre d'oprandes, en cours de calcul, des instructions (se trouvant

dans la queue de lancement) ddies une unit fonctionnelle ottante
non utilise.
Nombre d'oprandes, en cours de chargement (par des oprations de
lecture mmoire), des instructions (se trouvant dans la queue de lancement) ddies une unit fonctionnelle ottante non utilise.
DEPoO_int + DEPoM_int
Nombre d'oprandes, en cours de calcul dans les units fonctionnelles,
des instructions (se trouvant dans la queue de lancement) ddies une
unit fonctionnelle entire non utilise.
Nombre d'oprandes, en cours de chargement (par des oprations de
lecture mmoire), des instructions (se trouvant dans la queue de lancement) ddies une unti fonctionnelle entire non utilise.
Anomalies d'utilisation des units fonctionnelles (FU_fp +
FU_int)
Nombre de fois o une unit fonctionnelle ottante n'est pas utilise
sans qu'il y ait une seule instruction ddie dans la queue de lancement
Nombre de fois o une unit fonctionnelle entire n'est pas utilise sans
qu'il y ait une seule instruction ddie dans la queue de lancement
Latence des oprations de lecture ottantes
Latence des oprations de lecture entires
BR Miss + IC Miss + ITB Miss
Nombre de mauvaises prdictions de branchements

Nombre de dfauts dans le cache d'instructions
Nombre de dfauts dans le cache de traductions d'adresses d'instructions
DTB Miss + Cache conflict + LSQ/MAF full
Nombre de dfauts dans le cache de traductions d'adresses de donnes
Nombre de conits d'accs au cache dus une opration de lecture et
d'criture qui accdent la mme ligne de cache
Nombre de fois o la queue d'instructions de lecture, la queue d'criture,
ou bien la queue de oprations en cours d'chec dans le cache sont
pleines et provoquent un gel de pipeline.
Tab. 3.1 Anomalies utilises pour identier les problmes de performance
Il est important de noter que les anomalies de dpendance sont comptabilises uniquement
si des units fonctionnelles ne sont pas utilises et si les oprandes sont en cours de calcul. Cela
permet de comptabiliser un problme de dpendance uniquement au moment o il se produit.
En eet, si on compte tous les oprandes non prts, y compris ceux devant tre fournis par des
instructions se trouvant dans la queue de lancement, alors l'anomalie est pollue. Une dpendance
entre deux instructions dans la queue de lancement ne doit pas tre comptabilise car il se peut
que, pendant les cycles d'excution de l'instruction devant fournir l'oprande, toutes les units
fonctionnelles soient utilises.
Pour dterminer la cause dominante d'une dgradation de performance, nous devons pouvoir
comparer les direntes anomalies entre elles. Nous avons donc normalis les anomalies. La
42
premire normalisation est simple et permet de comparer une mme anomalie entre des parties
direntes de programmes. Les mtriques absolues des anomalies sont divises par le nombre de
cycles sauf pour les anomalies de latence mmoire qui sont divises par le nombre de lectures
mmoires. Nous noterons
a
la mtrique normalise d'une anomalie
a.
La seconde normalisation
permet de comparer deux anomalies direntes pour une mme partie de programmes. Nous
voulons galement savoir si une anomalie est leve ou pas. Pour cela, nous avons collect les
anomalies pour l'ensemble des programmes de la suite SpecFP2000 et nous avons dni une
mtrique normalise
anorm
de la faon suivante :
anorm
o
ma
et
a
a
ma
a
sont respectivement la moyenne et l'cart type de la mtrique
1
programmes de la suite SpecFP2000 . Par consquent, pour une anomalie
de la mtrique normalise
va sur l'ensemble des

a donne, la moyenne
anorm sur l'ensemble des programmes est gale 0 et son cart type est
gal 1. D'une manire plus intuitive, cela signie que nous utilisons l'ensemble des programmes
de la suite comme point de rfrence des anomalies.
Nous utilisons la normalisation uniquement au dbut de l'arbre pour comparer des anomalies
qui n'ont aucune relation entre elles et qui sont dicilement comparables en valeur absolue. Par
exemple, nous comparons des anomalies de type dpendance (DEP) avec des anomalies de type
units fonctionnelles (FU) ou bien encore avec des anomalies de type latence mmoire (MEM). Dans
la suite de l'arbre, nous utilisons directement les valeurs absolues des anomalies. Par exemple, les
anomalies de dpendances sur la mmoire ou de dpendances sur les oprations arithmtiques
peuvent tre compares en valeur absolue. La moyenne et l'cart-type des mtriques
a
des
anomalies sont donns dans la table 3.1.
3.3 Construction de l'arbre de dcision

L'arbre de dcision a deux objectifs :
formaliser l'analyse d'un humain expert permettant d'identier les problmes de performance l'aide d'informations dynamiques dtailles,
mmoriser l'association, faite par l'humain expert, entre les problmes de performance identis par l'analyse et les transformations de programmes utilises.
Dans la sous-section suivante, nous dcrivons la dmarche que nous avons suivi pour construire
l'arbre de dcision de la gure 3.2.
3.3.1
Construction empirique
Pour construire l'arbre, nous avons optimis manuellement un ensemble de programmes pour
une architecture spcique. Nous avons utilis 12 programmes de calculs ottants parmi les programmes de la suite SpecFP2000. L'architecture cible est le processeur Alpha-21264 superscalaire
d'ordre 4 excution dans le dsordre. Nous avons utilis le simulateur cycle cycle du processeur Alpha pour collecter un grand nombre d'informations sur le comportement des programmes.
Nous avons optimis manuellement un premier programme (applu) l'aide de ces informations.
1 Les
Bases
mtriques sont collectes par la simulation des programmes compils avec les options des SpecFP2000
3.4.
Processus d'optimisation
43
Pour ce premier programme, le travail d'optimisation n'tait pas rellement structur : l'objectif
tait d'obtenir une squence d'optimisations orant les meilleures performances possibles. Ensuite, nous avons inversement examin cette squence d'optimisations pour en extraire l'analyse
des informations du simulateur permettant d'obtenir cette squence. Cette analyse a ensuite t
formalise sous la forme d'un arbre de dcision. L'optimisation de chaque nouveau programme
nous a permis de raner et d'tendre l'arbre : pour chaque nouvelle analyse, nous avons construit
une nouvelle branche. Le but de la formalisation de l'analyse est de pouvoir rutiliser les optimisations associes aux analyses (feuilles des branches de l'arbre). Pour que la rutilisation soit
possible, il est ncessaire de trouver un compromis dans le niveau de dtail de l'analyse. En eet,
si l'analyse n'est pas susamment prcise alors les branches de l'arbre n'identieront pas les
problmes de manire susamment prcise pour donner les bonnes solutions (optimisations). En
revanche, si l'analyse est trop dtaille alors chaque feuille de l'arbre correspondra un problme
bien particulier dont la solution propose est spcique chaque programme optimis. Dans ce
cas, la rutilisation devient impossible. Pour que l'association entre un problme de performance
et une optimisation soit la plus indpendante possible de la structure des programmes, nous formalisons uniquement l'analyse dynamique permettant d'identier un problme de performance
sur un composant de l'architecture. Contrairement ce qui est fait dans les compilateurs, nous
ne formalisons pas l'analyse statique que nous eectuons sur les programmes pour raliser les
transformations.
Nous avons poursuivi l'optimisation des autres programmes en systmatisant la dmarche et
le processus que nous dcrivons plus loin dans la section 3.4. La formalisation de l'analyse base
sur les informations dynamiques dtailles lors de l'optimisation des programmes est reprsente
dans l'arbre de la gure 3.2. Les branches en pointills reprsentent des problmes que nous
avons identis mais auxquels nous n'avons pas t confronts. Ce sont donc des problmes pour
lesquels nous n'avons pas fait d'optimisations, par exemple, les problmes de cache d'instructions.
3.4 Processus d'optimisation

Les processus d'optimisation itratifs proposs jusqu' aujourd'hui [KiKnOB00] sont bass
sur la recherche des paramtres d'un nombre restreint de transformations. Si l'on dsire tendre
ces processus itratifs des nombres importants de transformations alors l'espace de recherche
des paramtres crot de manire exponentielle et le temps de recherche devient dissuasif. Notre
approche de l'optimisation itrative n'est pas conue pour rechercher la performance optimale
mais plutt pour assurer une progression de performance sur chaque composant de l'architecture
au fur et mesure des itrations. Nous avons observ exprimentalement que cette approche
apporte des gains de performance signicatifs.
3.4.1
Description du processus
Le processus d'optimisation itratif que nous avons utilis est relativement simple. Chaque
itration du processus se dcompose de la faon suivante :
1. collecter les Anomalies de performance,
2. utiliser l'arbre de dcision an d'identier le problme de performance dominant,
44
3. localiser, dans le programme source (ou ventuellement dans le programme assembleur), la

partie de code o le problme de performance est le plus prsent,
4. slectionner, parmi les optimisations associes chaque problme de performance, l'optimisation qui amliore au mieux le problme localement,
5. eectuer des itrations d'adaptations,
6. gnraliser les optimisations d'autres parties du programme,
7. recommencer une nouvelle itration.
Collecte des Anomalies de performance
Nous avons modi le code source du simulateur
du processeur Alpha en insrant des sondes permettant de compter tous les vnements lists dans
la table 3.1 ainsi que le nombre de cycles et le nombre d'oprations mmoires (ncessaire pour
la normalisation des anomalies). Avant de dmarrer le processus d'optimisation pour chaque
programme, nous avons eectu un prol en temps. Ces prols nous ont permis d'identier
l'ensemble des procdures dont le temps cumul correspond environ 90% du temps total de
chaque excution. Le temps de simulation d'un programme complet de la suite SpecFP2000
pouvant atteindre plusieurs mois, nous avons simul uniquement les procdures slectionnes
suivant les prols et nous avons limit chaque simulation 4 milliards d'instructions excutes. Le
processus d'optimisation est fortement squentiel : les simulations pour la collecte des anomalies
ne peuvent pas tre eectues en parallle.
Utilisation de l'arbre de dcision
Une fois les anomalies de performance collectes, l'uti-
lisation de l'arbre de dcision est totalement systmatique : les rponses aux questions poses
dans l'arbre de dcision sont les vrications d'quations ou d'inquations dont les variables sont
les anomalies de performance. Par exemple, la rponse la premire question :
les units fonctionnelles sont-elles utilises chaque cycle ?
est non si l'inquation suivante est vrie :
DEP + FU > 0
La gure 3.3 reprsente l'arbre de dcision prcdemment dcrit avec les quations et les
inquations sur les arcs permettant d'identier le problme de performance de manire systmatique.
Localisation dans le programme source
Aprs l'identication d'un problme dominant,
il est ncessaire de localiser ce problme, c'est--dire trouver la rgion responsable. Il est donc
ncessaire que la collecte des anomalies de performance conserve l'association entre une anomalie
et une instruction. Lors de la simulation, nous associons le plus prcisment possible les anomalies
aux instructions assembleurs en cours d'excution :
les anomalies de dpendance (DEP) sont associes aux instructions se trouvant dans la queue
de lancement pour lesquelles les oprandes ne sont pas prtes.
les anomalies d'utilisation des units fonctionnelles (FU) ne peuvent pas tre associes
une instruction puisqu'elle rvle un manque d'instruction ddie une unit fonctionnelle.
Cette anomalie a donc t associe au bloc de base des instructions en cours d'excution,
3.4.
45
1 : DTB miss > Cache conflict & DTB miss > LSQ/MAF full
2 : Cache conflict > DTB miss & Cache conflict > LSQ/MAF full
3 : LSQ/MAF full > Cache conflict & LSQ/MAF full > DTB miss
Les units fonctionnelles sontelles

utilises chaque cycle ?
DEP+FU=0
DEP+FU>0
Existetil des instructions dans la
queue de lancement ddies aux units
fonctionnelles non utilises ?
Programme limit par

le nombre doprations
DEP<FU
DEP>FU
Existetil des instructions du mme type

ddie dautres units fonctionnelles
dans la queue de lancement ?
FU_x<<<FU_y
FU_x~FU_y
DTraps < ITraps
Utilisation
dsquilibre
des units
fonctionnelles
flottantes
(FU_fp)
DEPoM > DEPoO
Estce un problme dinstructions ou un

problme spcifique de larchitecuture
li aux oprations mmoires
Quel est le type des oprations ?
Utilisation
dsquilibre
des units
fonctionnelles
entires
(FU_int)
Quel est le type des

instructions sources ?
Estce un problme
de chargement
des instructions ?
Problme de latence ou
de bande passante
Problme de TLB
dinstructions
(ITB Miss)
Manque de paralllisme
DTraps > ITraps
Quel type de problme

spcifique ?
Type des oprations ?
Problme
de flot
de contrle
(BR Miss)
Problme de conflits
des accs au cache
(Ld/st order trap
+load retry
+MAF conflict trap)
Quel est le type

de problme ?
DEPoM < DEPoO
DEPoO_int > DEPoO_fp
Problme de
dpendances sur
des oprations
entires
(DEPoO_int)
Problme de
capacit
(LQ full+SQ full
+MAF full)
Problme de cache
dinstruction
(ICM Miss)
DEPoO_int < DEPoO_fp
Problme de
dpendances sur
des oprations
flottantes
(DEPoO_fp)
La latence mmoire estelle leve ?
norme(MEM_LAT) < 0
Problme de bande passante

(MEM_LAT)
norme(MEM_LAT) > 0
Problme de latence mmoire

(MEM_LAT)
Problme de cache
ou de TLB ?
Problme de TLB de donnes

(DTB Miss)
Problme de cache
Type des oprations mmoires ?
MEM_LAT_int < MEM_LAT_fp

les oprations flottantes
(MEM_LAT_fp)
MEM_LAT_int > MEM_LAT_fp

les oprations entires
(MEM_LAT_int)
Fig. 3.3 Arbre de dcision systmatique
c'est--dire au bloc de base de l'instruction la plus proche de l'anomalie : la premire

instruction trouve soit dans les queues de lancement, soit dans les tages prcdents du
pipeline.
les anomalies de latence mmoire (MEM_LAT) sont associes aux instructions assembleurs
ralisant les chargements mmoires. La latence des instructions de prchargement n'est pas
comptabilise dans les anomalies de latence mmoire.
les anomalies spciques l'architecture (Traps) sont comptabilises suivant les instructions assembleurs.
46
Slection d'une optimisation
C'est la partie du processus qui demande le plus de travail
l'utilisateur. Mais c'est galement celle qui laisse le plus de libert. Il doit choisir une optimisation
adapte la partie de programme identie lors de la localisation. L'utilisateur doit vrier la
lgalit et doit valider ses optimisations.
Lors de la construction de l'arbre de dcision, les utilisateurs peuvent suggrer des optimisations adaptes et les rajouter aux feuilles de l'arbre.
Itrations d'adaptation
Les itrations d'adaptation sont quasiment identiques aux itrations
gnrales du processus. Elles dirent uniquement au niveau de la phase d'identication du problme de performance. Lors de ces itrations, le processus ne se focalise pas sur le problme
de performance dominant mais se focalise uniquement sur des augmentations de problmes en
observant les augmentations d'anomalies de performance. Les itrations d'adaptation permettent
d'ajuster le paramtrage d'une optimisation ou bien de composer des transformations de programmes an d'amliorer nement le comportement local du programme sur l'ensemble des
composants de l'architecture.
Considrons, par exemple, le programme applu dont la premire itration a ncessit une
adaptation. Les anomalies de performance et l'arbre de dcision nous ont permis d'identier
un problme de dpendances sur des oprations arithmtiques ottantes localis dans la procdure
blts,
plus prcisment sur l'opration de soustraction
v(m,i,j,k)-omega
reprsente sur
la gure 3.4. Cette soustraction dpend de 4 multiplications et de 2 additions. Nous avons bru-
do k = 2, nz-1
do j = 2, ny-1
do i = 2, nx-1
do m = 1, 5
do l = 1, 5
v(m,i,j,k) = v(m,i,j,k) - omega *
( ldz(m,l,i,j,k) * v(l,i,j,k-1)
+ ldy(m,l,i,j,k) * v(l,i,j-1,k)
+ ldx(m,l,i,j,k) * v(l,i-1,j,k)
Fig. 3.4 Dpendance sur les instructions de la procdure
blts
talement optimis pour rduire au maximum le problme de dpendances : nous avons scind le
nid de boucle (m,l) en deux en scindant l'instruction pour sparer les multiplications du calcul.
De plus, nous avons eectu un dcalage d'itration (shifting ) du second nid cr par la ssion
de boucles. La partie de programme rsultante est montre sur la gure 3.5. Aprs cette optimisation, nous avons procd une itration d'adaptation : nous avons collect de nouvelles
anomalies et nous avons observ la rduction des anomalies de dpendances sur des oprations
arithmtiques ottantes. En revanche, nous avons constat une augmentation des anomalies de
dpendances sur des oprations arithmtiques entires localises sur les instructions de rangements en mmoire des tableaux temporaires dans le second nid de boucle. Nous avons donc choisi
de rduire les instructions de rangements mmoires en modiant lgrement la ssion de boucle :
nous avons regroup les additions et les multiplications dans le mme nid de boucle pour rduire
le nombre de tableaux temporaires. Le programme correspondant est reprsent sur la gure 3.6
La table 3.2 montre l'volution des anomalies de dpendances entires (DEP_int) et ottantes
3.4.
47
do k = 2, nz-1
do j = 2, ny-1
...
do i = 2, nx-1
do m = 1, 5
do l = 1, 5
v( m, i, j, k ) = v( m, i, j, k )
- omega * ( tmpldz(m,l)
+ tmpldy(m,l)
+ tmpldx(m,l) )
do m = 1, 5
do l = 1,5
tmpldx(m,l) = ldx( m, l, i+1, j, k )
* v( l, i-1+1, j, k )
tmpldy(m,l) = ldy( m, l, i+1, j, k )
* v( l, i+1, j-1, k )
tmpldz(m,l) = ldz( m, l, i+1, j, k )
* v( l, i+1, j, k-1 )
...
Fig. 3.5 Fission de boucle et dcalage d'itration (procdure
blts)
do k = 2, nz-1
do j = 2, ny-1
do i = 2, nx-1
do m = 1, 5
do l = 1, 5
v( m, i, j, k ) = v( m, i, j, k )
- omega * tmpldxyz(m,l)
do m = 1, 5
do l = 1,5
tmpldx = ldx( m, l, i+1, j, k )
* v( l, i-1+1, j, k )
tmpldy = ldy( m, l, i+1, j, k )
* v( l, i+1, j-1, k )
tmpldz = ldz( m, l, i+1, j, k )
* v( l, i+1, j, k-1 )
tmpldxyz(m,l) = tmpldx + tmpldy + tmpldz
Fig. 3.6 Modication de la ssion de boucle (procdure
blts)
(DEP_fp), en nombre d'anomalies par cycle, au cours des direntes optimisations.
Anomalies
original
itration 1
adaptation 1
DEP_fp
5.50
3.78
4.03
DEP_int
2.49
3.65
3.31
Tab. 3.2 volution des anomalies de dpendances.
Les itrations d'adaptation peuvent agir rcursivement les unes sur les autres, le processus
doit donc xer une limite au nombre d'adaptations par itration. Nous nous sommes limits
deux ou trois adaptations par itration.
48
Gnralisation
Le paragraphe 3.4.1 dcrit la localisation des anomalies et donc des problmes
de performance. Lors de la construction de l'arbre de dcision et de l'optimisation des dirents

programmes, nous avons observ plusieurs reprises qu'un mme problme de performance
pouvait tre localis dans des parties de programmes distantes. La raison est que plusieurs parties
d'un mme programme peuvent parfois avoir la mme structure, le mme comportement et
donc les mmes problmes de performance. Nous avons ajout une sixime tape la n du
processus d'optimisation : la gnralisation. Elle consiste rechercher et localiser des parties
de programmes avec des problmes de performance identiques ceux de l'itration en cours
an d'appliquer systmatiquement les mmes optimisations. La gnralisation peut reproduire la
transformation de l'optimisation principale, celle d'une des adaptations, ou bien encore plusieurs
simultanment.
Cette tape de gnralisation peut parfois tre suivie d'tapes d'adaptation. En eet, mme
si la gnralisation s'applique sur des parties de programmes similaires, elles ne sont pas identiques. Le comportement des parties du programme optimises par la gnralisation peut parfois
tre dirent des autres parties du programme optimises et peut donc ncessiter la ralisation
d'tapes d'adaptation.
Exemple applu
Pour illustrer le fonctionnement de l'tape de gnralisation, nous consi-
drons une nouvelle fois l'exemple du programme applu. Lors de la premire itration, nous
avions identi un problme de dpendances sur des oprations arithmtiques localis sur le nid
de boucle de la procdure
blts.
La localisation d'autres instructions exprimant le mme pro-
blme de performance donne des instructions ayant une structure trs similaire appartenant la
procdure
buts
(gure 3.7).
do k = 2, nz-1
do j = 2, ny-1
do i = 2, nx-1
do m = 1, 5
do l = 1, 5
v(m,i,j,k) = v(m,i,j,k) - omega *
( ldz(m,l,i,j,k) * v(l,i,j,k-1)
+ ldy(m,l,i,j,k) * v(l,i,j-1,k)
+ ldx(m,l,i,j,k) * v(l,i-1,j,k)
procdure
do k = nz-1, 2
do j = 2, ny-1, 2
do i = 2, nx-1, 2
do m = 1, 5
tv(m) = 0.0d+00
do l = 1, 5
tv(m) = t(m) - omega *
( udz(m,l,i,j,k) * v(l,i,j,k+1)
+ udy(m,l,i,j,k) * v(l,i,j+1,k)
+ udx(m,l,i,j,k) * v(l,i+1,j,k)
blts
Fig. 3.7 Gnralisation des optimisations de
procdure
blts
sur
buts
buts
Supposons que l'on utilise le processus d'optimisation sans gnralisation. Si un problme de

performance dominant est rparti sur deux parties de programmes distinctes alors l'optimisation
de la premire partie peut changer le problme dominant. Si le processus d'optimisation n'choue
pas et s'il est conduit susamment longtemps alors le problme de performance localis sur la
seconde partie de programmes pourra redevenir le problme dominant. La gnralisation permet
d'exploiter au mieux le bnce des optimisations qui peut tre parfois partiellement perdu par
le processus sans gnralisation.
Avant la gnralisation, une tape de validation de l'optimisation est ncessaire pour vrier si
elle a t bnque. Cette validation consiste excuter le nouveau programme et collecter les
3.4.
49
Contributions de la gnralisation
9%
equake
wupwise
41%
applu
38%
mgrid
6%
galgel
8%
Moyenne
20%
Tab. 3.3 Contribution de la gnralisation
anomalies an de constater la rduction du problme de performance. Dans le cas du programme

wupwise, l'application du processus sans gnralisation a rduit le temps de 232 secondes 135
secondes ; la gnralisation rduit le temps d'excution 80 secondes.

La table 3.3 montre la contribution (en pourcentage) de la gnralisation au gain nal.
3.4.2
Dcomposition des problmes de performance
Comme nous l'avons expliqu prcdemment dans la section 3.4, le processus n'adresse qu'un
seul problme de performance par itration (le problme dominant). Adresser plusieurs problmes
simultanment permettrait certainement d'acclrer le processus. Cependant, il serait beaucoup
plus dicile d'adapter nement les optimisations comme nous venons de le voir dans la soussection prcdente. D'autre part, dans certains cas, il arrive qu'un problme soit cach par un
autre et ce n'est qu'une fois le problme dominant rduit que le second problme apparat. Le
processus doit adresser les problmes un un pour garantir la progression du processus.
Exemple applu
Considrons nouveau l'exemple du programme applu, dont la premire
itration et son adaptation ont t dcrites prcdemment. Nous avons donc scind le nid de
boucle (m,l) en deux comme le montre la gure 3.6. A l'itration suivante, le problme de
dpendance sur des oprations arithmtiques n'est plus le problme dominant. Le nouveau problme dominant est un problme de latence mmoire localis sur les rfrences aux tableaux
ldy
et
ldz.
ldx,
Ce nouveau problme n'a pas t cr par la ssion de boucle, il tait dj visible
lors de la prcdente itration car les anomalies de dpendance sur des oprations mmoires et
la latence mmoire taient dj leves (voir le dtail de l'optimisation du programme applu
annexe A.3). Cet exemple illustre le fait qu'il existe des cas pour lesquels il serait possible de
traiter simultanment plusieurs problmes de performance.
Exemple equake
Cet autre exemple illustre les cas o certains problmes sont latents et
masqus par des problmes plus importants. La gure 3.8 montre une partie de la procdure
smvp
du programme equake et la partie du programme principal dclarant les variables du
programme. Nous avons identi un problme de latence mmoire sur les accs aux tableaux
M23, C23
et
V23.
M,
Ce problme est d l'utilisation de tableaux de pointeurs sur des ottants
en double prcision. Nous avons donc optimis le programme en transformant ces tableaux en
tableaux ottants doubles prcisions (voir gure 3.9). Aprs cette optimisation, nous avons observ une augmentation de prs de 50% des anomalies spciques l'architecture (Traps). Cette
augmentation est plus prcisment situe sur des problmes de conits des accs mmoires. Nous
50
/* Mass matrix */
M = (double **) malloc(ARCHnodes * sizeof(double *))
if (M == (double **) NULL) {
fprintf(stderr, "malloc failed for M")
fflush(stderr)
exit(0)
for (i = 0; i < ARCHnodes; i++) {
M[i] = (double *) malloc(3 * sizeof(double))
if (M[i] == (double *) NULL) {
fprintf(stderr, "malloc failed for M[%d]",i)
fflush(stderr)
exit(0)
for (i = 0; i < ARCHnodes; i++)
for (j = 0; j < 3; j++)
disp[disptplus][i*3+j] += 2.0 * M[i][j] * disp[dispt][i*3+j] (M[i][j] - Exc.dt / 2.0 * C[i][j]) * disp[disptminus][i*3+j] Exc.dt * Exc.dt * (M23[i][j] * phi2(time) / 2.0 +
C23[i][j] * phi1(time) / 2.0 +
V23[i][j] * phi0(time) / 2.0);
Fig. 3.8 Dclaration et procdure
smvp
avons localis ces problmes de conits sur les accs aux fonctions
mme nid de boucle reprsent sur la gure 3.9. La variable
time
phi0, phi1
et
phi2
dans le
tant constante dans le nid de
boucle, nous avons ralis une optimisation scalaire en plaant les appels de fonctions l'extrieur
du nid de boucle. Le problme de conits tait bien prsent avant l'optimisation pour la latence
mmoire mais les anomalies de latence mmoire avaient pour eet de masquer ce problme. Cet
exemple montre que certaines anomalies peuvent tre dissimules par d'autres. Il convient donc
de traiter les anomalies une une an de dmasquer toutes les anomalies et de garantir ainsi la
progression du processus d'optimisation.
M = (double *) malloc(ARCHnodes * 3 * sizeof(double));

if (M == (double *) NULL) {
fprintf(stderr, "malloc failed for M");
fflush(stderr);
exit(0);
for (j = 0; j < 3; j++)
disp[disptplus][i*3+j] += 2.0 * M[i*3+j] * disp[dispt][i*3+j] (M[i*3+j] - Exc.dt / 2.0 * C[i*3+j]) * disp[disptminus][i*3+j] Exc.dt * Exc.dt * (M23[i*3+j] * phi2(time) / 2.0 +
C23[i*3+j] * phi1(time) / 2.0 +
V23[i*3+j] * phi0(time) / 2.0);
Fig. 3.9 Optimisation globale des structures de donnes pour la procdure
smvp
3.4.
51
3.4.3
Annulation des itrations
La rduction d'un problme de performance ne garantit pas toujours un gain de performance.

En eet, nous avons vu dans la section 3.4.2 que la rduction d'un problme de performance
peut dmasquer un nouveau problme de performance. Or, le nouveau problme de performance
tant plus pnalisant que le prcdent, le gain de performance peut tre infrieur 1. Nous
autorisons le processus procder au plus 2 itrations conscutives avec des gains infrieurs
1. En contrepartie, nous autorisons le processus annuler les itrations ayant gnr des gains
infrieurs 1. Par exemple, lors de l'optimisation du programme galgel, nous avons eectu
une fusion de boucle qui nous a permis de rduire un problme de TLB de donnes. Suite
cette optimisation, nous avons observ un gain de 0.97 et une augmentation du problme
de dpendances sur des oprations arithmtiques entires. Nous avons conserv l'optimisation
dgradant le gain et nous avons compos la fusion de boucle avec un dcalage d'itration (shifting )
pour rduire le problme de dpendances. Le gain a atteint la valeur de 1 et nous avons poursuivi
le processus d'optimisation.
Nous avons galement autoris le processus annuler des optimisations ayant des gains suprieurs 1. Dans certains cas, aprs une itration avec un gain positif, le problme de performance
de l'itration suivante ncessite d'eectuer une optimisation qui ne peut tre ralise que si la
premire optimisation est annule. Par exemple, la seconde itration de l'optimisation du programme applu ncessite l'annulation de la premire itration : la fusion de boucle de la seconde
itration ne peut avoir lieu que si le dcalage d'itrations est supprim. En eet, le dcalage
d'itrations cre des dpendances inter-itrations qui inhibent la fusion des boucles.
3.4.4
Comparaison avec un compilateur statique
Le principal avantage d'un tel processus itratif par rapport un compilateur statique est la
exibilit. Il permet de construire de longues squences de transformations dont l'ordre est dni
par la domination des problmes de performance, contrairement aux compilateurs statiques o
l'ordre des transformations est prdni et constant. Par exemple, la gure 3.10 montre une
squence de 7 transformations obtenue pour le programme galgel. L'autre avantage provient
de l'application manuelle des transformations qui permet de dpasser les limites imposes aux
compilateurs statiques par la reprsentation intermdiaire gnralement base sur les structures
d'arbres syntaxiques.
Data
TLB
Loop merging &

Scalar promotion
1.02
Data
TLB
Loop
interchange
1.12
Data
TLB
Loop
merging
0.97
Shifting
Chain of dependent
FP operations
Chain of dependent
FP operations
1.12
Loop merging
& Shifting
1.12
Chain of dependent
INT operations
Unrolling
(disable)
FP FU
resource
1.16 (1.30 gen.)
Register
Blocking
1.30 (1.32 gen.)
Fig. 3.10 Squence de transformations ralise sur le programme galgel
Premirement, un compilateur a gnralement une stratgie d'optimisation prdnie limitant

les variations des compositions de transformations. Par exemple, dans le compilateur ORC [ORC],
les optimisations de fusion et de ssion de boucles peuvent tre rptes et interchanges mais
ce n'est pas le cas des autres transformations. Les compilateurs manquent de exibilit pour
appliquer des squences de transformations variables. Deuximement, chaque transformation de
programmes est gnralement applique syntaxiquement, c'est--dire que pour chaque transformation une nouvelle version de l'arbre syntaxique est gnre. De telles reprsentations sont
52
incompatibles avec de longues squences de transformations. En eet, certaines optimisations

peuvent modier l'arbre syntaxique de telle sorte que plusieurs optimisations ne sont plus applicables l'arbre modi. Des travaux sont en cours [BaCoGi03] sur le dveloppement d'un
outil d'application de transformations de programmes bass sur une reprsentation intermdiaire
compatible avec de longues compositions de transformations.
3.5 Rsultats exprimentaux

Cette section a deux objectifs : le premier est d'illustrer en dtail le processus d'optimisation
au travers de l'optimisation complte d'un programme de la suite SpecFP2000. Le second objectif
est de donner les rsultats exprimentaux obtenus avec l'ensemble des autres programmes. Les
dtails des analyses et des optimisations de trois programmes sont prsents en annexe A.
Les expriences ont t ralises sur une machine HP AlphaServer ES45 dote de 4 processeurs Alpha 21264C (EV68) cadencs 1GHz avec 8 Mga-octets de mmoire cache de second
niveau et 8 Giga-octets de mmoire principale. Nous avons compar les performances des versions optimises des programmes avec les performances Base des SpecFP2000 obtenues avec
une compilation identique pour tous les programmes :
-arch ev6 -fast -O5 ONESTEP,
avec les
compilateurs HP Fortran (V5.4) et C (V6.4). Nous avons galement compar les performances
des versions optimises des programmes avec les performances Peak des SpecFP2000 obtenue
avec des options de compilation particulires pour chaque programme utilisant parfois le prprocesseur KAP Fortran (V4.3) et utilisant parfois les optimisations diriges par des informations
dynamiques. La table 3.4 montre les gains obtenus par compilation en Peak et par le processus
itratif par rapport la compilation en Base. Elle montre galement le gain relatif. Du point de
Compil en
Processus
Gain
Peak
Itratif
Relatif
wupwise
1.20
2.90
2.42
equake
2.01
2.50
1.24
applu
1.47
2.18
1.48
swim
1.00
1.51
1.51
mgrid
1.59
1.45
0.91
facerec
1.04
1.42
1.36
galgel
1.04
1.39
1.34
apsi
1.07
1.23
1.15
mesa
1.12
1.17
1.04
fmad
1.32
1.09
0.82
art
1.22
1.07
0.87
ammp
1.18
1.06
0.88
Tab. 3.4 Gain obtenu par rapport aux performances Base des SpecFP2000
vue des transformations de programmes, le processus gnre des squences structures de transformations qui sont appliques direntes sections de programmes. Pour chaque programme,
nous avons modi 1 3 sections de code sur lesquelles plusieurs transformations sont successivement appliques. En moyenne, nous avons modi 30 lignes de source par programme. La
principale limite aux nombres de modications des programmes est l'application manuelle des
3.5.
53
Rsultats exprimentaux
optimisations.
3.5.1
Optimisation du programme
wupwise
Le temps d'excution du programme wupwise compil en Base est de 232 secondes.
1ire
itration
Les anomalies permettent d'identier un problme de dpendance sur des op-
rations arithmtiques entires, localis sur 4 procdures :
lsame, zaxpy, zgemm
et
zcopy.
Ces
4 procdures appartenant la librairie mathmatique optimise CXML, nous avons choisi de

l'utiliser. Nous avons compil le programme avec l'option permettant au programme d'utiliser
les librairies optimises :
f90 -O5 -ldxml. Le temps d'excution a t rduit 210 secondes. Les
anomalies de dpendances sur des oprations entires ont bien t rduites. En revanche, toutes
les autres anomalies ont augment. L'optimisation tant globale et pouvant avoir un impact important sur l'ensemble du programme, nous ne pouvons pas eectuer d'itrations d'adaptation.
Nous avons donc choisi de commencer une nouvelle itration.
2nde
itration
Le problme dominant est maintenant un problme d'utilisation des units fonc-
tionnelles ottantes. Ce problme est principalement localis dans les procdures
zgemm_small_nn
et
zaxpy.
La procdure
zcopy
zcopy, zgemm,
ne faisant qu'une copie de vecteur sans faire de
calcul, il est normal que les units fonctionnelles ottantes ne soient pas utilises. Cette procdure est appele uniquement par la procdure
gammul.
La procdure
gammul
appelle plusieurs
zcopy et zaxpy dans une squence de structures de contrles (8 instructions

if... then ...) dont les excutions sont exclusives. Un extrait de cette squence est reprsent
fois les procdures
dans la gure 3.11. Les paramtres d'appel aux procdures tant relativement petits, nous avons
IF (MU.EQ.1) THEN
CALL ZCOPY(12, X, 1, RESULT,
CALL ZAXPY( 3, I, X(10), 1,
CALL ZAXPY( 3, I, X( 7), 1,
CALL ZAXPY( 3, -I, X( 4), 1,
CALL ZAXPY( 3, -I, X( 1), 1,
Fig. 3.11 Appels aux procdures
choisi de copier le code des procdures
1)
RESULT( 1),
RESULT( 4),
RESULT( 7),
RESULT(10),
zcopy
zcopy
et
et
zaxpy
zaxpy
1)
1)
1)
1)
dans la procdure
dans la procdure
gammul
gammul
(nous avons
inliner les procdures). Par ailleurs, nous avons compltement droul les boucles gnres par
la copie, ce qui a pour eet de supprimer totalement la copie ralise par
zcopy.
La partie de
programme rsultante est reprsente sur la gure 3.12. Aprs cette optimisation, le temps d'excution a t rduit 191 secondes. L'expansion de codes, elle seule, ne sut pas supprimer la
copie ralise par la procdure
zcopy, elle ne sut donc pas rduire l'anomalie d'utilisation des
units fonctionnelles ottantes. En revanche, cette optimisation est indispensable pour raliser le
droulage complet des boucles qui rduit l'anomalie. Il faut, tout de mme, attribuer une partie
du gain l'expansion de code qui rduit considrablement le nombre d'instructions excutes.
2nde
itration,
1ire
adaptation
Nous avons constat une augmentation du nombre d'ano-
malies de dpendance sur les oprations arithmtiques entires (DEPoO_int). Nous avons localis
54
IF (MU.EQ.1)
RESULT( 1)
RESULT( 2)
RESULT( 3)
RESULT( 4)
RESULT( 5)
RESULT( 6)
RESULT( 7)
RESULT( 8)
RESULT( 9)
RESULT(10)
RESULT(11)
RESULT(12)
Fig. 3.12 Procdure
THEN
= X( 1)
= X( 2)
= X( 3)
= X( 4)
= X( 5)
= X( 6)
= X( 7)
= X( 8)
= X( 9)
= X(10)
= X(11)
= X(12)
gammul
+
+
+
+
+
+
+
+
+
+
+
+
(I * X(10))
(I * X(11))
(I * X(12))
(I * X( 7))
(I * X( 8))
(I * X( 9))
((-I) * X( 4))
((-I) * X( 5))
((-I) * X( 6))
((-I) * X( 1))
((-I) * X( 2))
((-I) * X( 3))
aprs expansion de codes et droulage de boucles
zgemm_small_cn, gammul, zgemm

zgemm_small_nn. Les procdures zgemm_small_cn et zgemm_small_nn sont toutes appeles
partir de l'appel zgemm en fonction des paramtres qui lui sont passs. Les appels zgemm sont
faits uniquement dans la procdure su3mul qui ne fait rien d'autre que l'appel de procdure
zgemm avec des bons paramtres. La procdure su3mul est appele par les procdures muldeo et
muldoe. La procdure muldeo est reprsente sur la gure 3.13. La procdure zgemm tant dj
ces problmes de dpendance principalement sur les procdures

et
DO 100 L=1,N4
LP=MOD(L,N4)+1
DO 100 K=1,N3
KP=MOD(K,N3)+1
DO 100 J=1,N2
JP=MOD(J,N2)+1
DO 100 I=(MOD(J+K+L+1,2)+1),N1,2
IP=MOD(I,N1)+1
CALL GAMMUL(1,0,X(1,(IP+1)/2,J,K,L),AUX1)
CALL SU3MUL(U(1,1,1,I,J,K,L),'N',AUX1,AUX3)
CALL GAMMUL(2,0,X(1,(I+1)/2,JP,K,L),AUX1)
CALL ZAXPY(12,ONE,AUX2,1,AUX3,1)
CALL GAMMUL(3,0,X(1,(I+1)/2,J,KP,L),AUX1)
CALL GAMMUL(4,0,X(1,(I+1)/2,J,K,LP),AUX1)
CALL ZCOPY(12,AUX3,1,RESULT(1,(I+1)/2,J,K,L),1)
Fig. 3.13 Procdure
su3mul
optimise, les problmes de dpendances sont dus au sucre syntaxique des appels de procdures dont font partie de nombreux calculs d'adresses. Nous avons donc choisi d'eectuer une
zgemm, su3mul et gammul ainsi que sur les procdures zaxpy

muldeo. La gure 3.14 montre un rsum de la procdure muldeo
expansion de code sur les procdures

et
zcopy
dans la procdure
3.5.
55
aprs l'expansion de code sur laquelle sont reprsents les codes expanss des premiers appels
gammul et su3mul ainsi que celui de la procdure zcopy. Le temps d'excution
a t rduit 146
secondes.
C
CALL GAMMUL(1,0,X(1,(IP+1)/2,J,K,L),AUXP1)
AUXP1( 1) = X( 1,(IP+1)/2,J,K,L) + (IMA * X(10,(IP+1)/2,J,K,L))
AUXP1( 4) = X( 4,(IP+1)/2,J,K,L) + (IMA * X( 7,(IP+1)/2,J,K,L))
...
C
CALL SU3MUL(U(1,1,1,I,J,K,L),'N',AUXP1,AUXP3)
AUXP3( 1) = U(1,1,1,I,J,K,L) * AUXP1( 1)
%
+ U(1,2,1,I,J,K,L) * AUXP1( 2)
%
+ U(1,3,1,I,J,K,L) * AUXP1( 3)
AUXP3( 2) = U(2,1,1,I,J,K,L) * AUXP1( 1)
%
+ U(2,2,1,I,J,K,L) * AUXP1( 2)
%
+ U(2,3,1,I,J,K,L) * AUXP1( 3)
AUXP3( 3) = U(3,1,1,I,J,K,L) * AUXP1( 1)
%
+ U(3,2,1,I,J,K,L) * AUXP1( 2)
%
+ U(3,3,1,I,J,K,L) * AUXP1( 3)
AUXP3( 4) = U(1,1,1,I,J,K,L) * AUXP1( 4)
%
+ U(1,2,1,I,J,K,L) * AUXP1( 5)
%
+ U(1,3,1,I,J,K,L) * AUXP1( 6)
...
C
ZCOPY(12,AUX3,1,RESULT(1,(I+1)/2,J,K,L),1)
RESULT( 1,(I+1)/2,J,K,L) = AUXP3(1)
...
Fig. 3.14 Procdure
2nde
itration,
2nde
adaptation
su3mul
aprs expansion de code
Aprs cette nouvelle expansion de code, nous avons constat
une forte augmentation de l'anomalie latence mmoire
MEM_LAT
et des anomalies spciques
l'architecture (Traps). Nous nous sommes focaliss sur les anomalies spciques l'architecture
qui ont plus que tripl. Ces anomalies sont plus prcisment rparties entre les anomalies de
conit d'accs au cache et des anomalies de capacit (dbordement de la queue d'instructions de
lecture). Nous avons localis ces anomalies, rvlant deux types de problmes, sur des instructions assembleurs de dbordements (spill code ) dans la procdure
muldeo.
L'expansion de code
agressive, que nous avons ralis, gnre un corps de boucle relativement important pour lequel
le compilateur n'arrive plus optimiser l'allocation des registres et l'ordonnancement des instructions. Par consquent, nous avons optimis le corps de la boucle en remplaant les tableaux
temporaires
AUXP1, AUXP3, AUXM1 et AUXM3 par des variables temporaires scalaires. Nous avons
galement rordonnanc les instructions an de rduire la dure de vie des registres (nous avons
remont les instructions consommatrices des variables temporaires). Le nouveau corps de boucle
est rsum dans la gure 3.15. L'optimisation scalaire et le rordonnancement ont rduit le temps
d'excution 135 secondes. Ces optimisations ont galement rduit l'anomalie de latence mmoire qui avait t augmente par la prcdente adaptation. Comme nous nous y attendions,
le rordonnancement, qui a pour objectif de rduire la dure de vie des registres, a augment
l'anomalie de dpendance ottante (le gain montre que ce compromis est ncessaire). Les autres
56
C
AUXP1_1 = X( 1,(IP+1)/2,J,K,L) + (IMA * X(10,(IP+1)/2,J,K,L))
...
AUXP1_12 = X(12,(IP+1)/2,J,K,L) + ((-IMA) * X( 3,(IP+1)/2,J,K,L))
C
AUXP3_1 = U(1,1,1,I,J,K,L) * AUXP1_1
%
+ U(1,2,1,I,J,K,L) * AUXP1_2
%
+ U(1,3,1,I,J,K,L) * AUXP1_3
RESULT( 1,(I+1)/2,J,K,L) = AUXP3_1
AUXP3_4 = U(1,1,1,I,J,K,L) * AUXP1_4
%
+ U(1,2,1,I,J,K,L) * AUXP1_5
%
+ U(1,3,1,I,J,K,L) * AUXP1_6
AUXP3_7 = U(1,1,1,I,J,K,L) * AUXP1_7
%
+ U(1,2,1,I,J,K,L) * AUXP1_8
%
+ U(1,3,1,I,J,K,L) * AUXP1_9
AUXP3_10 = U(1,1,1,I,J,K,L) * AUXP1_10
%
+ U(1,2,1,I,J,K,L) * AUXP1_11
%
+ U(1,3,1,I,J,K,L) * AUXP1_12
RESULT(10,(I+1)/2,J,K,L) = AUXP3_10
AUXP3_2 = U(2,1,1,I,J,K,L) * AUXP1_1
%
+ U(2,2,1,I,J,K,L) * AUXP1_2
%
+ U(2,3,1,I,J,K,L) * AUXP1_3
AUXP3_5 = U(2,1,1,I,J,K,L) * AUXP1_4
%
+ U(2,2,1,I,J,K,L) * AUXP1_5
%
+ U(2,3,1,I,J,K,L) * AUXP1_6
...
AUXP3_12 = U(3,1,1,I,J,K,L) * AUXP1_10
%
+ U(3,2,1,I,J,K,L) * AUXP1_11
%
+ U(3,3,1,I,J,K,L) * AUXP1_12
...
Fig. 3.15 Procdure
su3mul
anomalies n'ayant pas t augmentes, nous avons arrt les itrations d'adaptations pour cette
itration.
Gnralisation
Pour la premire itration, il n'y avait pas de gnralisation possible puisque
l'utilisation des librairies est dj une optimisation gnrale. Il n'y a pas d'opportunit de g-
zcopy n'est
gammul. En revanche, lors de la premire adaptation de la seconde
itration, nous avons vu que les appels aux procdures su3mul et gammul taient rpartis quitablement entre les procdures muldeo et muldoe. Or, ces deux procdures sont trs similaires,
nous avons donc gnralis la premire et la seconde adaptation la procdure muldoe. Le temps
nralisation de la premire optimisation de la seconde itration car la procdure

appele que dans la procdure
d'excution a t rduit 80 secondes.

Nous avons arrt le processus d'optimisation avec un gain nal de 2.90.
3.5.
57
3.5.2
Association entre anomalies et optimisations
Comme nous l'avons expliqu prcdemment, le processus d'optimisation a t construit

de manire empirique par une succession de tests et d'erreurs, en particulier pour le premier
programme optimis. Nous avons ralis plusieurs itrations par programme dans le but de
trouver les transformations de programmes appropries chaque problme de performance. La
table 3.5 montre l'association entre les problmes de performance correspondant aux feuilles
de l'arbre et les optimisations suggres. La table indique les dirents cas pour lesquels une
optimisation a rduit un problme de performance (la rduction de l'anomalie correspondant au
problme a toujours t au minimum de 5%). Toutes les transformations de programmes n'ont
pas le mme impact ; la table donne le gain moyen pour chaque transformation ainsi que le
Agencement des donnes (Data-layout )

Ordonnancement d'instructions
Fission de boucle
Blocage pour les registres
Expansion de code (Inlining )
Droulage de boucle
Padding(Data-Layout)
Blocage pour le cache
Librairies optimises
Dcalage d'itration (Shifting )
p
p
p
Promotion de variables scalaires

Fusion de boucle
Permutation de boucle
Nombre d'applications
Pr
ob
Pr
Optimisations
lm
ed
ob
lm e ca
c
Pr
ob e de he F
l
P
c
D me ache
d
pe
e b IN
n
D dan and T
ep
pe ces
nd
a
s
u
an
r o ssan
Ut
c
t
ilis
p
es
ra e
a
s
Co tion ur d tion
es
n
s
d
TL its d squ opr otta
a
il
'a
n
B
de ccs ibr tion tes
s
e
do
Ga
nn au c des enti
in
ac
UF re
he
mo es
o s
ye
#
tta
n
d'a
nt
es
pp
lic
at
ion
s
nombre de fois o elle a t utilise.
p
p p p
p
p
p
p
p
p
p
p
p
p p
p
p
p p p
p
p p
p p
p p p
p
p p
2
1.34
1.24
1.21
1.14
1.14
1.11
1.10
1.10
1.10
1.06
1.06
1.05
1.02
Tab. 3.5 Associations entre problmes de performance et transformations de programmes
Pour plusieurs itrations et pour plusieurs programmes, nous n'avons pas appliqu une optimisation mais deux ou trois transformations de programmes simultanment. Nous avons donc
rparti le gain quitablement entre les deux ou trois optimisations ralises.
Les optimisations sont polyvalentes : hormis le dcalage d'itrations qui a t utilis uniquement pour rduire des problmes de dpendance (entire ou ottante), les autres optimisations
ont t utilises pour rduire des problmes de performance varis. Les objectifs d'une mme
optimisation peuvent tre trs dirents contrairement aux heuristiques des compilateurs statiques guidant les optimisations, qui sont gnralement trs orients vers un objectif souvent en
relation avec le ot de donnes et la rutilisation. Par exemple, l'algorithme de Kennedy [Ke00]
58
pour la fusion de boucles est orient uniquement vers la rutilisation. Les optimisations ralises
ici montrent que la fusion de boucles peut tre utilise pour rduire des problmes de conits ou
des problmes d'utilisation d'units fonctionnelles.
3.5.3
Squences d'optimisations
La table 3.6 prsente un rsum des squences d'optimisations ralises lors de l'optimisation
des 12 programmes de la suite SpecFP2000. Pour chaque programme, une ligne de la table
correspond une itration. Chaque optimisation est reprsente par une lettre indiquant si elle
O), dans une phase d'adaptation (A) ou bien dans
a t ralise dans une phase d'optimisation (
une phase de gnralisation ( ). Ces lettres sont suivies d'informations se trouvant entre des
crochets : on trouve le nom de la transformation en haut et le problme de performance que
celle-ci a rduit en bas. Les nombres indiquent la progression du gain.
Comme nous l'avons prcdemment montr dans la section 3.4.4, les gains que nous avons
obtenus avec le processus itratif sont dus la longueur et la diversit des squences d'optimisations. La plupart des optimisations, que nous avons utilises, existent dans les compilateurs optimisants rcents. Cependant, les reprsentations intermdiaires sous forme d'arbres
syntaxiques, les contraintes lies aux analyses de dpendances et les ordres imposs aux phases
d'optimisation limitent leur champ d'application. Certains programmes prsentent des dicults
supplmentaires pour les compilateurs : les optimisations suivent des directions opposes, par
exemple pour le programme apsi, nous avons t amens appliquer une ssion de boucles puis
nous avons fusionn chaque nid de boucle avec deux autres nids de boucles. Pour le programme
galgel, nous avons galement rencontr une opposition avec une optimisation de privatisation
pour permettre la permutation de boucles et une optimisation de promotion de scalaires.
3.6 Conclusions
Nous proposons un processus itratif d'optimisation bas sur une analyse dynamique trs
dtaille. Bien que ce processus soit manuel, il n'en est pas moins systmatique. Nous avons
montr l'application et l'ecacit de ce processus sur un ensemble de programmes de la suite
SpecFP2000.
L'ecacit de ce processus doit tre attribue d'une part l'analyse dynamique trs dtaille qui permet d'identier prcisment les problmes de performance et d'autre part la
nature itrative du processus qui permet de construire, pour chaque programme, des squences
de transformations.
L'arbre de dcision systmatise l'analyse dynamique et formalise l'exprience empirique de
l'optimisation manuelle d'une manire intelligible. L'exprience empirique peut donc tre aisment interprte, diuse et remploye.
Nous avons identi quatre principales catgories d'anomalies pour l'architecture du processeur Alpha-21264 :
les anomalies de dpendances (DEP),
les anomalies d'utilisation des units fonctionnelles (FU),
la latence mmoire (MEM),
3.6.
59
Conclusions
Codes
wupwise
equake
applu
swim
mgrid
facerec
galgel
apsi
mesa
fmad
art
ammp
Squences d'optimisations
Gains
O DEPoO_int

1.21
1.59
1.72
OExpansion/Droulage
IA Expansion/Droulage
IA Promo.Scal./Rord.
IG 2.90
FU_fp
FU_fp
Bande passante

Fusion 1.95
Promo.scal. 2.50
1.70
ORarrange.
MEM_LAT_fp IG 1.92 IA Cache conict IA Cache conict
Promo.scal. 1.04

1.02
ODcalage
IG 1.06
DEPoO_FP IA DEPoO_fp
Rord. 1.20

1.08
OFusion
MEM_LAT_fp IA Bande passante IG 1.48

Droulage (comp.) 1.65

1.51
O Fission
IG 2.18
DEPoO_fp IA FU_fp
Padding/Tiling. 1.20

MERGING 1.51
IA Loop
IA 1.51
MEM_LAT_fp
Bandwidth

0.75
1.27
OFission
IA Fission
FU_fp
Bande passante IG 1.32

Reg. 1.38
OBlocage
IG 1.41
Bande passante
1.00
On/a.
FU_int
Reg. 1.30
OBlocage
DEPoO_fp
1.02
1.12
0.97
1.12
OFusion/Promo.scal.
IG Permutation
IG Fusion/Promo.scal.
IADcalage
Data TLB
Data TLB
Data TLB
DEPoO_int

1.12
(Disactiv) 1.16
IA Fusion/Dcalage
IA Droulage
IG 1.24
DEPoO_fp
DEPoO_int

Reg. 1.30
OBlocage
IG 1.32
FU_fp

Permutation/Promo.scal. 1.11

1.07
1.08
1.22
ORarrange.
IA Fission
IG Permutation/Promo.scal.
Data TLB
Cache conict IA Cache conict
Data TLB
1.22
OFission
Bande passante

1.23
1.23
1.23
OFusion/Expansion
IA Dcalage
IA Dcalage
IG 1.23
FU_fp
DEPoO_fp
DEPoO_fp
1.06
OExpansion
DEPoO_int
Rarrange. 1.13
1.13
ODcalage
DEPoO_int IA Cache conict
1.19
ODcalage
DEPoO_int
Dcalage 1.00
Fission 1.00
Fusion 1.03
1.00
ODcalage
DEPoO_int IG DEPoO_int IA Cache conict IA DEPoO_fp

1.09
OExpansion
Bande passante. I 1.09
1.02
OPermutation/Promo.scal.
MEM_LAT_int

1.07
OFission
MEM_LAT_int I 1.07
1.01
ODcalage
DEPoO_int
1.02
ODcalage
DEPoO_int
1.06
OFusion
FU_fp
1.10
Librairies 1.10
2.90
2.50
1.06
1.48
2.18
1.51
1.32
1.41
1.00
1.30
1.24
1.32
1.22
1.22
1.23
1.06
1.13
1.19
1.03
1.09
1.02
1.07
1.01
1.02
1.06
Tab. 3.6 Rsum des squences d'optimisations
les purges de pipeline dues des comportements spciques l'architecture des composants
(TRAPS).
Pour chaque programme, nous avons accumul ces quatre catgories d'anomalies sur l'ensemble des parties de code traites. Nous avons ensuite normalis ces anomalies an de pouvoir
les confronter et d'identier l'anomalie dominante. La normalisation ne fait perdre aucune information. En contrepartie, l'accumulation des anomalies perd l'information de distribution des
60
anomalies sur le programme. Bien que nous ayons identi et rsolu de nombreux problmes de
performance, certains problmes locaux ont pu tre masqus par l'accumulation.
L'identication des problmes de performance peut tre ane par un examen de la distribution des anomalies sur le programme. Cette modication demande la rorganisation du processus
d'optimisation. En eet, une recherche sur la distribution allie l'identication d'un problme de
performance et sa localisation.
61
Conclusions
La complexit des processeurs augmentant, il est de plus en plus dicile d'intgrer des modles
prcis d'architectures dans les compilateurs. En consquence, l'ecacit des compilateurs dcrot.
La tendance actuelle vise enrichir les compilateurs statiques d'informations dynamiques sur le
comportement de l'architecture la manire des techniques d'optimisation bases sur les proles
d'excution ou des techniques de re-compilation dynamique. Pour le moment, seules quelques
informations lmentaires sur le comportement de l'architecture sont utilises.
Dans le second chapitre, nous avons montr de quelle manire les interactions entre les diffrents composants d'une architecture rendent complexe le comportement d'un programme. Cependant, nous avons galement montr qu'il est possible de capturer cette complexit et d'en
dduire les transformations apporter au programme pour amliorer son comportement.
Dans le troisime chapitre, nous avons tudi une mthode plus systmatique pour adresser
le problme de la complexit ; an de la capturer, nous avons propos un processus itratif d'optimisation manuelle bas sur une analyse dynamique dtaille. Nous avons exprimentalement
montr qu'une telle approche amliore la performance des programmes avec un gain moyen de
1,27 par rapport aux optimisations ralises avec les combinaisons optimales des options du compilateur associes un pr-processeur optimisant et des optimisations diriges par des analyses
dynamiques classiques.
Cette approche est potentiellement une stratgie pour guider de futurs environnements d'optimisation itratifs, mais elle prsente galement des bnces immdiats. Premirement, elle
propose un processus systmatique d'optimisation manuelle qui peut tre utilis par des ingnieurs. Deuximement, l'arbre de dcision formalise l'expertise empirique de l'optimisation manuelle qui peut tre aisment passe des ingnieurs ou des chercheurs. Finalement, l'arbre de
dcision catgorise automatiquement les transformations de programmes suivant les problmes
de performance.
Perspectives
Nous investiguons actuellement plusieurs extensions de ce travail. Premirement, nous essayons d'extraire des compteurs de performance les informations permettant de guider le processus d'optimisation. Deuximement, nous travaillons sur l'implmentation d'un environnement de
transformations de programmes bas sur une reprsentation intermdiaire qui facilite les compositions de longues squences de transformations. Troisimement, nous travaillons sur l'automa-
62
tisation du processus, plus particulirement, nous cherchons remplacer l'inspection manuelle

de programmes par une analyse statique pour trouver toutes les opportunits d'application d'un
ensemble de transformations. Nous laisserons le processus itratif (son analyse dynamique) slectionner les transformations les plus appropries. Finalement, nous souhaitons dvelopper les
arbres de dcision et les associations entre les problmes de performance et les transformations
pour de nouveaux programmes ; nous envisageons notamment de crer des arbres de dcision par
domaine d'application.
63
Table des gures

1.1
Architecture gnrale du processeur Alpha-21264/EV68 . . . . . . . . . . . . . . .
1.2
Pipeline du processeur Alpha-21264/EV68
. . . . . . . . . . . . . . . . . . . . . .
1.3
Promotion de scalaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.4
Droulage de boucles
12
1.5
Permutation de boucles
1.6
Fusion et ssion de boucles
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.7
Dcalage d'itrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.8
Exemple d'un blocage de boucle sur un produit de matrices . . . . . . . . . . . . .
14
1.9
Ordre d'accs aux matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10 Rarrangement des donnes
13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.1
Etape 0 : Programme initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.2
Etape 1 : Blocage sur 2 dimensions . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3
Ordre d'accs aux matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.4
Etape 2 : Blocage sur 3 dimensions . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.5
Conit mmoire
27
2.6
Etape 3 : Permutation de boucle pour la queue des critures
. . . . . . . . . . . .
28
2.7
Ordre d'accs aux matrices aprs blocage sur 3 dimensions . . . . . . . . . . . . .
28
2.8
Etape 4 : Blocage de registres
29
2.9
Compromis entre rutilisation registres/cache
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
30
2.10 Schma d'accs aux matrices avec copies . . . . . . . . . . . . . . . . . . . . . . .
31
2.11 Copie des blocs des matrices

2.12 Etape 7 : prchargements
et
pour rduire les dfauts de TLB
. . . . . . .
31
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2.13 Etape 8 : blocage des boucles
et
pour le cache de second niveau . . . . . . . . .
2.14 Architecture du pipeline du processeur Alpha-21264
34
. . . . . . . . . . . . . . . . .
35
2.15 Insertion des instructions fantmes . . . . . . . . . . . . . . . . . . . . . . . . . .
35
64
TABLE DES FIGURES
3.1
Exemple de graphe de ot de donnes . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.2
Arbre de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.3
Arbre de dcision systmatique
45
3.4
Dpendance sur les instructions de la procdure
3.5
Fission de boucle et dcalage d'itration (procdure
3.6
Modication de la ssion de boucle (procdure
3.7
Gnralisation des optimisations de
3.8
Dclaration et procdure
3.9
Optimisation globale des structures de donnes pour la procdure
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
smvp
blts
. . . . . . . . . . . . . . . .
blts)
. . . . . . . . . . . . . .
47
. . . . . . . . . . . . . . . .
47
. . . . . . . . . . . . . . . . .
48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
blts
sur
blts)
buts
3.10 Squence de transformations ralise sur le programme galgel

3.11 Appels aux procdures
zcopy
et
46
zaxpy
dans la procdure
gammul
smvp
. . . . . .
50
. . . . . . . . . .
51
. . . . . . . . . .
53
3.12 Procdure
gammul
aprs expansion de codes et droulage de boucles
. . . . . . . .
54
3.13 Procdure
su3mul
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.14 Procdure
su3mul
. . . . . . . . . . . . . . . . . . . . . .
55
3.15 Procdure
su3mul
. . . . . . . . . . . . . . . . . . . . . .
56
A.1
Options de compilation utilisant la librairie CXML
A.2
Procdure
A.3
Appels la procdure
A.4
Procdure
A.5
zcopy
. . . . . . . . . . . . . . . . .
72
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
zcopy
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
gammul
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Procdure
gammul
optimise
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
A.6
Procdure
su3mul
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
A.7
Appels la procdure
A.8
Procdure
A.9
su3mul
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
muldeo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
Procdure
muldeo
optimise
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
A.10 Procdure
muldeo
optimise
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
A.11 Appels la procdure

A.12 Procdure
smvp
su3mul
A.13 Code assembleur de la procdure
smvp
. . . . . . . . . . . . . . . . . . . . . . . .
83
. . . . . . . . . . . . . . . . . . . . . . . . . . .
83
A.14 Allocation mmoire du tableau
disp
. . . . . . . . . . . . . . . . . . . . . . . . .
A.16 Nouvelle allocation mmoire du tableau
disp
A.18 Procdure
smvp
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
aprs rarrangemant des donnes
. . . . . . . . . . . . . . . . . .
84
85
85
86
65
Table des figures
A.19 Procdure
main
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .

A.22 Procdure
main
A.23 Procdure
. . . . . . . . . . . . . . . . . . . . . .
aprs rarrangement des donnes
87
88
88
. . . . . . . . . . . . . . . . . .
88
main
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.24 Procdure
main
aprs fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.25 Procdure
main
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
A.26 Code assembleur de la procdure

A.27 Procdure
main
A.28 Procdure
main
. . . . . . . . . . . . . . . . . . . . . . . .
aprs factorisation d'invariants de boucles
92
. . . . . . . . . . . . .
92
blts
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
A.29 Procdure
blts
aprs fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
A.30 Procdure
blts
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
A.31 Procdure
blts
A.32 Procdure
buts
A.33 Procdure
buts
A.34 Procdure
buts
A.35 Procdure
jacu_buts
aprs la fusion des procdures
. . . . . . . . .
101
A.36 Procdure
jacu_buts
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
102
A.37 Procdure
jacu-buts
aprs la promotion de scalaire et le rordonnancement
. . .
103
A.38 Procdure
blts
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
104
A.39 Procdure
jacld-blts
A.40 Procdure
jacld-blts
A.41 Procdure
jacld-blts
aprs la privatisation et la ssion de boucle
A.42 Procdure
jacld-blts
aprs droulage complet
aprs modication de la ssion de boucles
. . . . . . . . . . . . .
96
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
aprs gnralisation de la ssion de boucles
. . . . . . . . . . . .
98
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
100
jacu
et
jacld
buts
et
blts
. . . . . . . .
105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
107
. . . . . . . .
108
. . . . . . . . . . . . . . . . . . .
109
66
Table des figures
67
Liste des tableaux

1.1
Fentre de spculation entire : cycles 4 5
1.2
Fentre de spculation ottante : cycles 5
2.1
Gains moyens pour des matrices de l'ordre de 10
. . . . . . . . . . . .
24
3.1
Anomalies utilises pour identier les problmes de performance . . . . . . . . . .
41
3.2
volution des anomalies de dpendances. . . . . . . . . . . . . . . . . . . . . . . .
47
3.3
Contribution de la gnralisation
49
3.4
Gain obtenu par rapport aux performances Base des SpecFP2000
3.5
Associations entre problmes de performance et transformations de programmes
3.6
Rsum des squences d'optimisations
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
6 lments
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
52
57
. . . . . . . . . . . . . . . . . . . . . . . .
59
A.1
Anomalies globales de wupwise . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
A.2
Anomalies de dpendances de wupwise
. . . . . . . . . . . . . . . . . . . . . . .
71
A.3
Localit des anomalies
. . . . . . . . . . . . . . . . . . . . . . . . . .
72
A.4
72
A.5
Anomalies d'utilisation des units fonctionnelles de wupwise . . . . . . . . . . .
72
A.6
Localisation des anomalies
. . . . . . . . . . . . . . . . . . . . . . . . .
73
A.7
74
A.8
Anomalies de dpendances de wupwise
. . . . . . . . . . . . . . . . . . . . . . .
74
A.9
Localisation des anomalies
. . . . . . . . . . . . . . . . . . . . . . . . .
75
A.10 Anomalies globales de wupwise . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
A.11 Anomalies spciques l'architecture de wupwise
. . . . . . . . . . . . . . . . .
78
. . . . . . . . . . . . . . . . . . . .
78
DEPoO_int
FU_add.
FU_fadd.
A.12 Anomalies mmoires spciques de wupwise

A.13 Localisation des anomalies de
Conit de cache
et de
LQ_FULL.
. . . . . . . . . .
78
A.14 Anomalies globales de wupwise . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
A.15 Anomalies globales de equake
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
A.16 Anomalies de dpendances de equake . . . . . . . . . . . . . . . . . . . . . . . .
81
68
LISTE DES TABLEAUX
A.17 Anomalies de latence mmoire de equake . . . . . . . . . . . . . . . . . . . . . .

A.18 Localit des anomalies
MEM_LAT_fp
MEM_LAT_fp
. . . . . . . . . . . . . . . . . . . . . . . .
dans la procdure
smvp
81
81
. . . . . . . . . . .
82
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
MEM_LAT_fp
MEM_LAT_fp
. . . . . . . . . . . . . . . . . . . . . . . .
dans la procdure
smvp
87
. . . . . . . . . . .
87
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
A.24 Anomalies spciques l'architecture de equake . . . . . . . . . . . . . . . . . .
89
A.25 Anomalies mmoires spciques de equake . . . . . . . . . . . . . . . . . . . . .
89
ORDER
(traps)
ORDER
dans la procdure
. . . . . . . . . . . . . . . . . . . . . . . .
main
89
. . . . . . . . . . . . . . .
89
91
ORDER
ORDER
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
dans la procdure
main
91
. . . . . . . . . . . . . . .
91
93
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
A.34 Anomalies de dpendances de applu . . . . . . . . . . . . . . . . . . . . . . . . .
94
A.33 Anomalies globales de applu
DEPoO_fp
. . . . . . . . . . . . . . . . . . . . . . . . . . .
94
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
95
96
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DEPoO_fp
. . . . . . . . . . . . . . . . . . . . . . . . . . .
97
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
99
DEPoO_fp
. . . . . . . . . . . . . . . . . . . . . . . . . . .
99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
A.45 Augmentation des anomalies de dpendances aprs la fusion . . . . . . . . . . . .
102
103
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MEM_LAT_int
. . . . . . . . . . . . . . . . . . . . . . . .
104
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
106
106
69
Liste des tableaux
DEPoO_fp
. . . . . . . . . . . . . . . . . . . . . . . . . . .
106
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
106
A.53 Anomalies d'utilisation des units fonctionnelles de applu . . . . . . . . . . . . .
106
A.54 Augmentation des anomalies d'utilisation des units fonctionnelles ottantes . . .
107
A.55 Anomalies d'utilisation des units fonctionnelles de applu . . . . . . . . . . . . .
107
FU_fp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
108
70
Liste des tableaux
71
Annexe A
Journaux d'optimisations itratives

Cette annexe a pour vocation de dtailler l'optimisation itrative ralise pour 3 des 11 programmes optimiss. Pour chacun des 11 programmes, nous avons cr un journal d'optimisation
qui a la structure suivante : chaque section correspond une itration du processus, chaque
itration possde une phase d'optimisation ventuellement suivie de phases d'adaptation et de
gnralisation. Pour chaque itration et pour chaque phase, nous donnons le temps d'excution
du programme avant et aprs l'optimisation ou la squence d'optimisations. Chaque phase est
dcompose en trois tapes : l'analyse qui identie le problme de performance partir des
anomalies, la localisation et la transformation.
Les anomalies ncessaires l'identication d'un problme de performance sont prsentes par
des ensembles de deux ou trois tableaux dont le premier correspond aux anomalies globales. Les
/cycle) titre indicatif car l'analyse est base

norme) soit sur les nombres d'anomalies
tableaux donnent le nombre d'anomalies par cycle (
soit sur les valeurs normalises des anomalies par cycle (
absolue).
en valeur absolue (
Les phases d'adaptations prsentent des tableaux avec deux lignes,
chacune montrant les anomalies en valeur absolue avant et aprs la transformation prcdente.
A.1 Journal d'optimisation du programme wupwise
!7 210
Optimisation : 232 7! 210 (sec.)
A.1.1
[Analyse]
Itration 1 :
232
(sec.)
DEPoO_int).
Problme de dpendances sur des oprations arithmtiques entires (
Anomalies
/cycle
norme
DEP_fp DEP_int FU MEM TRAPS

2.62
3.03 1.89 6.67
1.36
-0.44
-0.23 -0.38 -0.76 -0.93
Tab. A.1 Anomalies globales de wupwise
Anomalies
absolue
DEP_int DEPoM_int DEPoO_int

657 M
196 M
461 M
Tab. A.2 Anomalies de dpendances de wupwise
[Localisation]
Problme localis dans les procdures
lsame, zcopy, zaxpy
et
zgemm.
72
A. Journaux d'optimisations itratives
Procedures
lsame
zaxpy
zgemm
zcopy
DEPoO_int
157 M
137 M
100 M
35 M
Tab. A.3 Localit des anomalies
DEPoO_int
f90 -O5 -ldxml

Fig. A.1 Options de compilation utilisant la librairie CXML
[Transformation]
Utilisation des librairies optimises.
Par dnition les programmes de tests de la suite SpecFP2000 ne doivent pas utiliser les
librairies mathmatiques optimises an d'valuer uniquement la performance d'une machine et
de son compilateur. Ici, le problme de dpendances est localis sur quatre procdure appartenant
aux librairies mathmatiques ; nous avons donc choisi d'utiliser celles-ci.
Lors de la validation, nous avons observ une rduction des anomalies de dpendances mais
nous avons galement observ une augmentation de toutes les autres anomalies bien que le temps
d'excution ait diminu.
!7 80
A.1.2
Itration 2 :
[Analyse]
210
(sec.)
FU_fp).
Problme d'utilisation des units fonctionnelles ottantes (
Anomalies
/cycle
norme

3.50
2.26 2.37 7.67
3.39
-0.12
-0.55 0.51 -0.64 -0.41
Anomalies
/cycle
norme
FU FU_fadd FU_fmul FU_L0 FU_U0 FU_L1 FU_U1

2.37
0.27
0.38
0.25
0.62
0.29
0.55
0.51
0.52
0.20
0.63 -0.08
0.68 -0.11
Tab. A.5 Anomalies d'utilisation des units fonctionnelles de wupwise
[Localisation]
zcopy, zgemm, zgemm_small_nn
et
zaxpy.
do i = 1,n
zy(i) = zx(i)
Fig. A.2 Procdure
zcopy
La table A.6 montre qu'il faut analyser en priorit les anomalies localises sur la procdure
zcopy.
La gure A.2 montre que cette procdure ne fait aucun calcul. Cette procdure est prin-
A.1.
73
Procedures
zcopy
zgemm
zgemm_small_nn
zaxpy
zgemm_beta
zgemm_smll_cn
gammul
Absolut FU_add
28.8 M
13.0 M
11.8 M
7.0 M
3.4 M
2.9 M
1.3 M
Tab. A.6 Localisation des anomalies
FU_add.
----------------------------------------------called/total
parents
index %time
self descendents called+self
name
index
called/total
children
----------------------------------------------0.00
0.00
2214016156
matmul_ [19]
0.00
0.00
154214016156
wupwise_ [2]
0.64
0.00 9728000214016156
muldeo_ [8]
0.64
0.00 9728000214016156
muldoe_ [7]
12.78
0.00 194560000214016156
gammul_ [6]
[10]
6.7
14.06
0.00 214016156
zcopy_ [10]
----------------------------------------------Fig. A.3 Appels la procdure
zcopy
IF (MODE.EQ.0) THEN
IF (MU.EQ.1) THEN
CALL ZCOPY(12, X, 1, RESULT, 1)
CALL ZAXPY( 3, I, X(10), 1, RESULT( 1), 1)
CALL ZAXPY( 3, I, X( 7), 1, RESULT( 4), 1)
CALL ZAXPY( 3, -I, X( 4), 1, RESULT( 7), 1)
CALL ZAXPY( 3, -I, X( 1), 1, RESULT(10), 1)
ELSE IF (MU.EQ.2) THEN
CALL ZAXPY( 3, ONE, X(10), 1, RESULT( 1), 1)
CALL ZAXPY( 3, -ONE, X( 7), 1, RESULT( 4), 1)
CALL ZAXPY( 3, -ONE, X( 4), 1, RESULT( 7), 1)
CALL ZAXPY( 3, ONE, X( 1), 1, RESULT(10), 1)
CALL ZAXPY( 3, I, X( 7), 1, RESULT( 1), 1)
CALL ZAXPY( 3, -I, X(10), 1, RESULT( 4), 1)
CALL ZAXPY( 3, -I, X( 1), 1, RESULT( 7), 1)
CALL ZAXPY( 3, I, X( 4), 1, RESULT(10), 1)
CALL ZCOPY( 6, X,
1, RESULT,
1)
CALL ZCOPY( 6, ZERO, 0, RESULT(7), 1)
CALL ZSCAL( 6, TWO, RESULT, 1)
END IF
ELSE IF (MODE.EQ.1) THEN
...
Fig. A.4 Procdure
gammul
74
cipalement appele par la procdure
gammul
(table A.3). La procdure
gammul
est reprsente
sur la gure A.4.
[Transformation]
La procdure
Expansion de code (inlining ) et droulage complet (Full unrolling ).
gammul appelle les procdures zcopy et zaxpy. Or, nous avions galement relev
des problmes d'utilisation des units fonctionnelles dans cette procdure. Nous avons donc choisi
d'optimiser avec de l'expansion de code et du droulage complet appliqu aux procdures
et
zaxpy.
Le code optimis de la procdure
IF (MODE.EQ.0)
IF (MU.EQ.1)
RESULT( 1)
RESULT( 2)
RESULT( 3)
RESULT( 4)
RESULT( 5)
RESULT( 6)
RESULT( 7)
RESULT( 8)
RESULT( 9)
RESULT(10)
RESULT(11)
RESULT(12)
...
gammul
THEN
THEN
= X( 1)
= X( 2)
= X( 3)
= X( 4)
= X( 5)
= X( 6)
= X( 7)
= X( 8)
= X( 9)
= X(10)
= X(11)
= X(12)
Fig. A.5 Procdure
+
+
+
+
+
+
+
+
+
+
+
+
zcopy
est reprsent sur la gure A.5.
(I * X(10))
(I * X(11))
(I * X(12))
(I * X( 7))
(I * X( 8))
(I * X( 9))
((-I) * X( 4))
((-I) * X( 5))
((-I) * X( 6))
((-I) * X( 1))
((-I) * X( 2))
((-I) * X( 3))
gammul
optimise
Adaptation 1 : 191 7! 146 (sec.)

[Analyse] Augmentation
tires (DEPoO_int).
des anomalies de dpendances sur des oprations arithmtiques en-
Anomalies
absolue avant
absolue aprs
DEP_fp DEP_int
FU MEM TRAPS
927 M 598 M 626 M 918 M 898 K
737 M 666 M 574 M 942 M 874 K
Anomalies
absolue avant
absolue aprs

598 M
172 M
425 M
666 M
122 M
543 M
Tab. A.8 Anomalies de dpendances de wupwise
[Localisation] Problme
emm_small_nn.
localis dans les procdures
Etant donn que les procdures
zgemm_small_cn, gammul, zgemm
zgemm_small_cn, zgemm
et
zgemm_small_nn
et
zg-
sont des pro-
cdures de la librairies optimise, nous ne pouvons pas modier le code. Ces procdures sont
A.1.
75
Procedures
zgemm_small_cn
gammul
zgemm
zgemm_small_nn
zaxpy
muldoe
zgemm_beta
Absolut DEPoO_int
193 M
102 M
99 M
84 M
32 M
25 M
2M
Tab. A.9 Localisation des anomalies
FU_fadd.
SUBROUTINE SU3MUL(U,TRANSU,X,RESULT)
...
CALL ZGEMM(TRANSU, 'NO TRANSPOSE',3,4,3,
.
ONE,U,3,X,3,ZERO,RESULT,3)
RETURN
END
Fig. A.6 Procdure
appeles par la procdure
zgemm
su3mul
su3mul
(gure A.6). Cette dernire appelle uniquement la procdure
avec les paramtres qui lui sont passs.
Nous avons dcid d'observer les appels la procdure

la procdure
muldeo
su3mul
(gure A.7), nous observons
(gure A.8).
----------------------------------------------1.52
0.00 58368000/116736000
muldeo_ [8]
1.52
0.00 58368000/116736000
muldoe_ [7]
[15]
1.5
3.04
0.00 116736000
su3mul_ [15]
su3mul
76
DO 100 L=1,N4
LP=MOD(L,N4)+1
DO 100 K=1,N3
KP=MOD(K,N3)+1
DO 100 J=1,N2
JP=MOD(J,N2)+1
DO 100 I=(MOD(J+K+L+1,2)+1),N1,2
IP=MOD(I,N1)+1
CALL GAMMUL(1,0,X(1,(IP+1)/2,J,K,L),AUX1)
CALL GAMMUL(3,0,X(1,(I+1)/2,J,KP,L),AUX1)
CALL GAMMUL(4,0,X(1,(I+1)/2,J,K,LP),AUX1)
100
CALL ZCOPY(12,AUX3,1,RESULT(1,(I+1)/2,J,K,L),1)
CONTINUE
Fig. A.8 Procdure
muldeo
A.1.
77
[Transformation]
Expansion de code (inlining ) et droulage complet (Full unrolling ).
Nous pouvons remarquer que, comme la procdure
zgemm,
la procdure
gammul
a des pro-
blmes de dpendances sur des oprations arithmtiques entires (voir table A.9).
...
DO 100 I=(MOD(J+K+L+1,2)+1),N1,2
IP=MOD(I,N1)+1
IM=I-1
IF(IM.EQ.0) IM=N1
C
AUXP1( 4) = X( 4,(IP+1)/2,J,K,L) + (IMA * X( 7,(IP+1)/2,J,K,L))
...
AUXP1(12) = X(12,(IP+1)/2,J,K,L) + ((-IMA) * X( 3,(IP+1)/2,J,K,L))
C
AUXP3( 1) = U(1,1,1,I,J,K,L) * AUXP1( 1)
%
+ U(1,2,1,I,J,K,L) * AUXP1( 2)
%
+ U(1,3,1,I,J,K,L) * AUXP1( 3)
AUXP3( 2) = U(2,1,1,I,J,K,L) * AUXP1( 1)
%
+ U(2,2,1,I,J,K,L) * AUXP1( 2)
%
+ U(2,3,1,I,J,K,L) * AUXP1( 3)
AUXP3( 3) = U(3,1,1,I,J,K,L) * AUXP1( 1)
%
+ U(3,2,1,I,J,K,L) * AUXP1( 2)
%
+ U(3,3,1,I,J,K,L) * AUXP1( 3)
AUXP3( 4) = U(1,1,1,I,J,K,L) * AUXP1( 4)
%
+ U(1,2,1,I,J,K,L) * AUXP1( 5)
%
+ U(1,3,1,I,J,K,L) * AUXP1( 6)
...
AUXP3(12) = U(3,1,1,I,J,K,L) * AUXP1(10)
%
+ U(3,2,1,I,J,K,L) * AUXP1(11)
%
+ U(3,3,1,I,J,K,L) * AUXP1(12)
C
...
Fig. A.9 Procdure
muldeo
optimise
Nous avons choisi d'utiliser l'expansion de code et le droulage de boucle. Les procdures
zgemm
et
su3mul
sont successivement expanses ainsi que la procdure
optimise. Ensuite, le code expans de la procdure
zgemm
gammul
prcdemment
est compltement droul.
78

[Analyse]
Cache conict)
LSQ/MAF full).
Augmentation des anomalies de conit d'accs au cache (
dement de la queue d'instructions de lecture mmoire (
Anomalies
absolue avant
absolue-aprs
et de dbor-
DEP_fp DEP_int
FU MEM TRAPS
737 M 666 M 574 M 942 M 874 K
899 M 869 M 747 M 2079 M 2781 K
Anomalies
Absolue
TRAPS MEM_TRAPS DTBMISS1 DTBMISS2 ITBMISS MISSPRED

2781 K
2733 K
47 K
0K
0K
0K
Tab. A.11 Anomalies spciques l'architecture de wupwise
Anomalies
Absolue
MEM_TRAPS
CFT ORDER MAF_CFT MAF_FULL SQ_FULL LQ_FULL
2733 K 1058 K 199 K
195 K
0K
323 K
942 K
Tab. A.12 Anomalies mmoires spciques de wupwise
[Localisation]
Problme localis dans le corps de boucle de la procdure
Procedures
zcopy
muldeo
wupwise
gammul
zgemm_small_nn
Absolut CFT Absolut LQ_FULL

487 K
12 K
226 K
312 K
220 K
22 K
118 K
0K
6K
0K
Tab. A.13 Localisation des anomalies de
[Transformation]
muldeo.
Conit de cache
et de
LQ_FULL.
Promotion de scalaires (Scalar promotion ) et rordonnancement d'instructions
(Instruction scheduling ).
A.1.
...
DO 100 I=(MOD(J+K+L+1,2)+1),N1,2
IP=MOD(I,N1)+1
IM=I-1
IF(IM.EQ.0) IM=N1
C
AUXP1_4 = X( 4,(IP+1)/2,J,K,L) + (IMA * X( 7,(IP+1)/2,J,K,L))
...
AUXP1_12 = X(12,(IP+1)/2,J,K,L) + ((-IMA) * X( 3,(IP+1)/2,J,K,L))
C
AUXP3_1 = U(1,1,1,I,J,K,L) * AUXP1_1
%
+ U(1,2,1,I,J,K,L) * AUXP1_2
%
+ U(1,3,1,I,J,K,L) * AUXP1_3
AUXP3_4 = U(1,1,1,I,J,K,L) * AUXP1_4
%
+ U(1,2,1,I,J,K,L) * AUXP1_5
%
+ U(1,3,1,I,J,K,L) * AUXP1_6
AUXP3_7 = U(1,1,1,I,J,K,L) * AUXP1_7
%
+ U(1,2,1,I,J,K,L) * AUXP1_8
%
+ U(1,3,1,I,J,K,L) * AUXP1_9
AUXP3_10 = U(1,1,1,I,J,K,L) * AUXP1_10
%
+ U(1,2,1,I,J,K,L) * AUXP1_11
%
+ U(1,3,1,I,J,K,L) * AUXP1_12
AUXP3_2 = U(2,1,1,I,J,K,L) * AUXP1_1
%
+ U(2,2,1,I,J,K,L) * AUXP1_2
%
+ U(2,3,1,I,J,K,L) * AUXP1_3
AUXP3_5 = U(2,1,1,I,J,K,L) * AUXP1_4
%
+ U(2,2,1,I,J,K,L) * AUXP1_5
%
+ U(2,3,1,I,J,K,L) * AUXP1_6
...
AUXP3_12 = U(3,1,1,I,J,K,L) * AUXP1_10
%
+ U(3,2,1,I,J,K,L) * AUXP1_11
%
+ U(3,3,1,I,J,K,L) * AUXP1_12
...
Fig. A.10 Procdure
muldeo
optimise
79
80
G nralisation : 135 7! 80 (sec.)

[Analyse]
Opportunit de gnralisation des adaptations 1 et 2.
----------------------------------------------1.52
0.00 58368000/116736000
muldeo_ [8]
1.52
0.00 58368000/116736000
muldoe_ [7]
[15]
1.5
3.04
0.00 116736000
su3mul_ [15]
[Localisation]
su3mul
Problme et structure de programme similaires dans la procdure
[Transformation]
muldoe.
Transformation des adaptations 1 et 2 : Expansion de code (inlining ), drou-
lage complet (Full unrolling ), promotion de scalaires (Scalar promotion ) et rordonnancement

des instructions (Instruction scheduling ).
Anomalies
Absolue-avant
Absolue-aprs
DEP_fp DEP_int
FU MEM TRAPS
1063 M 619 M 722 M 1566 M 2460 K
1111 M 509 M 715 M 1745 M 2327 K
Nous avons arrt l'optimisation aprs avoir rduit le temps d'excution de wupwise de 232
80 secondes, soit aprs avoir obtenu un gain de 2,90.
A.2.
81
A.2 Journal d'optimisation du programme equake
!7 116
A.2.1
[Analyse]
Itration 1 :
290
(sec.)
MEM_LAT_fp).
Problme de latence mmoire ottante (
Les anomalies mettent en vidence un problme de dpendances sur des oprations mmoires ottantes (tables A.15 et A.16). La normalisation de l'anomalie de latence mmoire leve
(table A.15) permet d'identier un problme de latence et non un problme de bande passante
(voir l'arbre de dcisions gure 3.2).

9.14
2.92 2.55 21.96
3.35
1.97
-0.27 0.84
-0.42
Anomalies
/cycle
norme
1.12
Tab. A.15 Anomalies globales de equake
Anomalies
absolue
DEP_fp DEPoM_fp DEPoO_fp

6378 M
3617 M
2761 M
Tab. A.16 Anomalies de dpendances de equake
Anomalies
absolue
MEM_LAT MEM_LAT_fp MEM_LAT_int

4151 M
3551 M
571 M
Tab. A.17 Anomalies de latence mmoire de equake
[Localisation]
Problme localis dans la procdure
smvp.
Le code assembleur de la gure A.13 montre que les accs au tableau

d'index dirents (t3,t6 et
t10)
car le tableau
pointeurs. Le problme est similaire sur le tableau
Procedure
smvp
main
phi1
phi0
phi2
A utilisent
des registres
est un tableau de pointeurs de tableaux de
w.
MEM_LAT_fp
2690 M
781 M
32 M
26 M
22 M
MEM_LAT_fp
82
Lignes sources
1212
1208
1207
1213
1214
1209
1199
1200
1201
1219
MEM_LAT_fp
680 M
554 M
430 M
316 M
302 M
245 M
112 M
111 M
109 M
5M
MEM_LAT_fp
dans la procdure
smvp
void smvp(int nodes, double ***A, int *Acol,

int *Aindex, double **v, double **w) {
int i;
int Anext, Alast, col;
double sum0, sum1, sum2;
for (i = 0; i < nodes; i++) {
Anext = Aindex[i];
Alast = Aindex[i + 1];
sum0 = A[Anext][0][0]*v[i][0] + A[Anext][0][1]*v[i][1] + A[Anext][0][2]*v[i][2];
Anext++;
while (Anext < Alast) {
col = Acol[Anext];
1207: sum0 += A[Anext][0][0]*v[col][0] + A[Anext][0][1]*v[col][1] + A[Anext][0][2]*v[col][2];
1212: w[col][0] += A[Anext][0][0]*v[i][0] + A[Anext][1][0]*v[i][1] + A[Anext][2][0]*v[i][2];
1215:
Anext++;
}
w[i][0] += sum0;
w[i][1] += sum1;
w[i][2] += sum2;
}
}
Fig. A.12 Procdure
smvp
A.2.
83
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
1207]
1207]
1208]
1209]
1208]
1212]
1207]
1208]
1207]
1209]
1207]
1207]
1207]
1212]
1212]
1212]
1212]
1213]
1214]
1214]
1212]
1213]
1207]
1207]
0x120011040:
0x120011044:
0x120011048:
0x12001104c:
0x120011050:
0x120011054:
0x120011058:
0x12001105c:
0x120011060:
0x120011064:
0x120011068:
0x12001106c:
0x120011070:
0x120011074:
0x120011078:
0x12001107c:
0x120011080:
0x120011084:
0x120011088:
0x12001108c:
0x120011090:
0x120011094:
0x120011098:
0x12001109c:
8f440000
8d440008
8f780000
8fc70000
8e380008
8c7b0000
8de40010
8e580010
43340644
8c870008
a4840000
8cc40008
8ce40010
5b40145c
5b6b145d
2ffe0000
5bd0144d
59401453
5a4b1442
2ffe0000
5b9d141c
5a2b145d
5946144a
2ffe0000
ldt
ldt
ldt
ldt
ldt
ldt
ldt
ldt
s8addq
ldt
ldq
ldt
ldt
mult
mult
ldq_u
mult
mult
mult
ldq_u
addt
mult
mult
ldq_u
$f26, 0(t3)
$f10, 8(t3)
$f27, 0(t10)
$f30, 0(t6)
$f17, 8(t10)
$f3, 0(t12)
$f15, 16(t3)
$f18, 16(t10)
t11, a4, t3
$f4, 8(t6)
t3, 0(t3)
$f6, 8(t3)
$f7, 16(t3)
$f26,$f0,$f28
$f27,$f11,$f29
zero, 0(sp)
$f30,$f16,$f13
$f10,$f0,$f19
$f18,$f11,$f2
zero, 0(sp)
$f28,$f29,$f28
$f17,$f11,$f29
$f10,$f6,$f10
zero, 0(sp)
Fig. A.13 Code assembleur de la procdure
smvp
/* Stiffness matrix K[ARCHmatrixlen][3][3] */

K = (double ***) malloc(ARCHmatrixlen * sizeof(double **));
if (K == (double ***) NULL) {
fprintf(stderr, "malloc failed for K");
fflush(stderr);
exit(0);
}
for (i = 0; i < ARCHmatrixlen; i++) {
K[i] = (double **) malloc(3 * sizeof(double *));
if (K[i] == (double **) NULL) {
fprintf(stderr, "malloc failed for K[%d]",i);
fflush(stderr);
exit(0);
}
for (j = 0; j < 3; j++) {
K[i][j] = (double *) malloc(3 * sizeof(double));
if (K[i][j] == (double *) NULL) {
fprintf(stderr, "malloc failed for K[%d][%d]",i,j);
fflush(stderr);
exit(0);
}
}
}
Fig. A.14 Allocation mmoire du tableau
84
/* Displacement array disp[3][ARCHnodes][3] */

disp = (double ***) malloc(3 * sizeof(double **));
if (disp == (double ***) NULL) {
fprintf(stderr, "malloc failed for disp");
fflush(stderr);
exit(0);
}
for (i = 0; i < 3; i++) {
disp[i] = (double **) malloc(ARCHnodes * sizeof(double *));
if (disp[i] == (double **) NULL) {
fprintf(stderr, "malloc failed for disp[%d]",i);
fflush(stderr);
exit(0);
}
for (j = 0; j < ARCHnodes; j++) {
disp[i][j] = (double *) malloc(3 * sizeof(double));
if (disp[i][j] == (double *) NULL) {
fprintf(stderr, "malloc failed for disp[%d][%d]",i,j);
fflush(stderr);
exit(0);
}
}
}
disp
A.2.
85
[Transformation]
Rarrangement des structures de donnes (Data-layout optimization ).
Nous avons modi les allocations mmoires des tableaux

procdure
smvp.
K et disp passs en paramtre
la
Ainsi, les lignes de cache contiennent des donnes utiles (et non des pointeurs).
K = (double *) malloc(ARCHmatrixlen * sizeof(double)*9 );

if ( K == (double *) NULL ) {
fprintf(stderr, "malloc failed for K");
fflush(stderr);
exit(0);
}
Fig. A.16 Nouvelle allocation mmoire du tableau
disp = (double **) malloc(3 * sizeof(double *));

if (disp == (double **) NULL) {
fprintf(stderr, "malloc failed for disp");
fflush(stderr);
exit(0);
}
for (i = 0; i < 3; i++) {
disp[i] = (double *) malloc(ARCHnodes * 3 * sizeof(double));
if (disp[i] == (double *) NULL) {
fprintf(stderr, "malloc failed for disp[%d]",i);
fflush(stderr);
exit(0);
}
}
Anomalies
absolue
absolue
disp
DEP_fp DEP_int
FU MEM TRAPS
6378 M 2038 M 1781 M 4174 M 2334 K
2465 M 1376 M 942 M 1985 M 1086 K
86
void smvp(int nodes, double *A, int *Acol,

int *Aindex, double *v, double *w) {
int i;
int Anext, Alast, col;
double sum0, sum1, sum2;
int ANC;
for (i = 0; i < nodes; i++) {
Anext = Aindex[i];
Alast = Aindex[i + 1];
ANC = Anext*9;
sum0 = A[ANC+0*3+0]*v[i*3+0] + A[ANC+0*3+1]*v[i*3+1] + A[ANC+0*3+2]*v[i*3+2];
Anext++;
while (Anext < Alast) {
ANC = Anext*9;
col = Acol[Anext];
sum0 += A[ANC+0*3+0]*v[col*3+0] + A[ANC+0*3+1]*v[col*3+1] + A[ANC+0*3+2]*v[col*3+2];
w[col*3+0] += A[ANC+0*3+0]*v[i*3+0] + A[ANC+1*3+0]*v[i*3+1] + A[ANC+2*3+0]*v[i*3+2];
Anext++;
}
w[i*3+0] += sum0;
w[i*3+1] += sum1;
w[i*3+2] += sum2;
Fig. A.18 Procdure
smvp
aprs rarrangemant des donnes
A.2.
87

[Analyse]
Opportunit de gnralisation de l'itration 1.
[Localisation]
Problme similaire dans la procdure
main.
MEM_LAT_fp
866 M
654 M
34 M
30 M
25 M
Procedure
smvp
main
phi1
phi0
phi2
Lignes sources
477
499
506
479
498
MEM_LAT_fp
MEM_LAT_fp
246 M
142 M
54 M
45 M
42 M
MEM_LAT_fp
dans la procdure
smvp

for (j = 0; j < 3; j++)
disp[disptplus][i*3+j] += 2.0 * M[i][j] * disp[dispt][i*3+j] 477:
(M[i][j] - Exc.dt / 2.0 * C[i][j]) * disp[disptminus][i*3+j] Exc.dt * Exc.dt * (M23[i][j] * phi2(time) / 2.0 +
C23[i][j] * phi1(time) / 2.0 +
V23[i][j] * phi0(time) / 2.0);
Fig. A.19 Procdure
[Transformation]
main
Transformation de l'itration 1 : Rarrangement des structures de donnes
(Data-layout optimization ).
Nous avons modi l'allocation mmoire des tableaux
montre le code modi de l'allocation du tableau
M.
C, M, M23, C23 et V23. Les gures A.21
88
/* Mass matrix */
M = (double **) malloc(ARCHnodes * sizeof(double *));
if (M == (double **) NULL) {
fflush(stderr);
exit(0);
}
for (i = 0; i < ARCHnodes; i++) {
M[i] = (double *) malloc(3 * sizeof(double));
if (M[i] == (double *) NULL) {
fprintf(stderr, "malloc failed for M[%d]",i);
fflush(stderr);
exit(0);
}
}
M = (double *) malloc(ARCHnodes * 3 * sizeof(double));

if (M == (double *) NULL) {
fflush(stderr);
exit(0);
}

for (j = 0; j < 3; j++)
C23[i*3+j] * phi1(time) / 2.0 +
V23[i*3+j] * phi0(time) / 2.0);
Fig. A.22 Procdure
main
aprs rarrangement des donnes
A.2.
89

[Analyse]
Augmentation de l'anomalie de conit d'accs au cache (Cache conict ).
Anomalies
absolue
absolue
DEP_fp DEP_int
FU MEM TRAPS
2465 M 1376 M 942 M 1985 M 1086 K
2222 M 1235 M 932 M 1769 M 1536 K
Anomalies
absolue
absolue
TRAPS MEM_TRAPS DTBMISS1 DTBMISS2 ITBMISS MISSPRED

1086 K
1013 K
72 K
0K
0K
0K
1536 K
1472 K
64 K
0K
0K
0K
Tab. A.24 Anomalies spciques l'architecture de equake
Anomalies
absolue
absolue
MEM_TRAPS CFT ORDER MAF_CFT MAF_FULL SQ_FULL LQ_FULL

1013 K 119 K 594 K
12 K
0K
65 K
212 K
1472 K 88 K 1089 K
7K
0K
54 K
228 K
Tab. A.25 Anomalies mmoires spciques de equake
[Localisation]
Problme localis sur la procdure
main
dans le nid de boucle prcdement opti-
mis.
Les oprations de lecture et d'criture d'un lment du tableau
dans l'ordre par le processus. Le corps du nid de boucle
i,j
disp
doivent tre excutes
tant petit (ligne 519, gure A.23),
ces oprations se retrouvent simultanment en cours d'excution dans le processeur qui gnre
ORDER Traps).
donc des purges partielles de pipeline (
Procedure
main
phi2
phi1
phi0
smvp
MEM_TRAPS ORDER
1340 K 1020 K
35 K
34 K
22 K
20 K
14 K
14 K
59 K
0K
Lignes sources
source line
519
512
511
506
514
ORDER
(traps)
ORDER
MEM_TRAPS ORDER_TRAPS
415 K
415 K
218 K
209 K
129 K
128 K
143 K
110 K
59 K
59 K
ORDER
dans la procdure
main
90

for (j = 0; j < 3; j++)
disp[disptplus][i*3+j] *= - Exc.dt * Exc.dt;
for (j = 0; j < 3; j++)
C23[i*3+j] * phi1(time) / 2.0 +
V23[i*3+j] * phi0(time) / 2.0);
for (j = 0; j < 3; j++)
519:
disp[disptplus][i*3+j] = disp[disptplus][i*3+j] /
(M[i*3+j] + Exc.dt / 2.0 * C[i*3+j]);
for (j = 0; j < 3; j++)
vel[i*3+j] = 0.5 / Exc.dt * (disp[disptplus][i*3+j] disp[disptminus][i*3+j]);
Fig. A.23 Procdure
[Transformation]
main
Fusion de boucles pour augmenter la distance entre les lectures et critures
sur une mme adresse mmoire.

for (j = 0; j < 3; j++)
{
C23[i*3+j] * phi1(time) / 2.0 +
V23[i*3+j] * phi0(time) / 2.0);
(M[i*3+j] + Exc.dt / 2.0 * C[i*3+j]);
}
Fig. A.24 Procdure
main
aprs fusion

[Analyse]
Augmentation de l'anomalie de conit d'accs au cache (Cache conict ).
[Localisation]
Problme localis sur la procdure
prcdement optimis.
main, phi0, phi1 et phi2 dans le nid de boucle
A.2.
91
Anomalies
absolue
absolue

1472 K 88 K 1089 K
7K
0K
54 K
228 K
1382 K 107 K 1159 K
12 K
0K
87 K
12 K
Des oprations de lecture sur une mme adresse s'excutent simultanment et gnrent des
ORDER Traps).
Ces oprations sont dues aux appels de procdures
et
phi2.
ORDER
997 K
127 K
18 K
16 K
0K
Procedure
main
phi2
phi1
phi0
smvp
source line
505
479
502
475
phi0, phi1
ORDER
ORDER_TRAPS
953 K
20 K
16 K
3K
ORDER
dans la procdure
main

for (j = 0; j < 3; j++)
{
505:
C23[i*3+j] * phi1(time) / 2.0 +
V23[i*3+j] * phi0(time) / 2.0);
(M[i*3+j] + Exc.dt / 2.0 * C[i*3+j]);
}
Fig. A.25 Procdure
main
[Transformation] Factorisation d'invariants de boucles (Loop invariant hosting ).

La variable time tant constante sur l'espace d'itration du nid de boucles, nous
toris les appels de procdures et plac leurs rsultats dans des variables temporaires.
avons fac-
92
[quake.c:
[quake.c:
[quake.c:
...
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
...
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
[quake.c:
491] 0x12000d910:
491] 0x12000d914:
503] 0x12000d918:
a71d83d0
8c290000
5ca50410
ldq
ldt
cpys
t10, -31792(gp)
$f1, 0(s0)
$f5,$f5,$f16
504]
504]
505]
505]
503]
505]
501]
513]
520]
487]
487]
520]
503]
0x12000d9c0:
0x12000d9c4:
0x12000d9c8:
0x12000d9cc:
0x12000d9d0:
0x12000d9d4:
0x12000d9d8:
0x12000d9dc:
0x12000d9e0:
0x12000d9e4:
0x12000d9e8:
0x12000d9ec:
0x12000d9f0:
58601443
9c7e0460
8c6dfff8
d34003a0
8c3e0460
58601440
8d5e0458
a43d83d0
a47d83d0
a0be0440
a4fe0448
a61e0450
59211401
mult
stt
ldt
bsr
ldt
mult
ldt
ldq
ldq
ldl
ldq
ldq
addt
$f3,$f0,$f3
$f3, 1120(sp)
$f3, -8(s4)
ra, 0x12000e850(zero)
$f1, 1120(sp)
$f3,$f0,$f0
$f10, 1112(sp)
t0, -31792(gp)
t2, -31792(gp)
t4, 1088(sp)
t6, 1096(sp)
a0, 1104(sp)
$f9,$f1,$f1
520]
521]
520]
520]
520]
520]
487]
0x12000da58:
0x12000da5c:
0x12000da60:
0x12000da64:
0x12000da68:
0x12000da6c:
0x12000da70:
8d830000
8daafff8
584c146c
580d1420
59801440
9c10fff8
f4bfffa7
ldt
ldt
divt
subt
mult
stt
bne
$f12, 0(t2)
$f13, -8(s1)
$f2,$f12,$f12
$f0,$f13,$f0
$f12,$f0,$f0
$f0, -8(a0)
t4, 0x12000d910
Fig. A.26 Code assembleur de la procdure
main
TMP_phi2 = phi2(time) / 2.0;

for (j = 0; j < 3; j++)
{
disp[disptplus][i*3+j] += 2.0 * M[i*3+j] * disp[dispt][i*3+j] (M[i*3+j] - Exc.dt / 2.0 * C[i*3+j]) * disp[disptminus][i*3+j] Exc.dt * Exc.dt * (M23[i*3+j] * TMP_phi2 +
C23[i*3+j] * TMP_phi1 +
V23[i*3+j] * TMP_phi0);
(M[i*3+j] + Exc.dt / 2.0 * C[i*3+j]);
}
Fig. A.27 Procdure
main
aprs factorisation d'invariants de boucles
L'anomalie de latence mmoire a augment dans la procdure

la procdure
main.
smvp mais elle
a diminu dans
L'augmentation est due un eet de bord. Nous avons arrt l'optimisation
A.2.
Anomalies
absolue
absolue

1382 K 107 K 1159 K
12 K
0K
87 K
12 K
490 K 87 K
58 K
9K
0K
138 K
191 K
Anomalies
absolue
absolue
DEP_fp DEP_int
FU MEM TRAPS
2302 M 1270 M 901 M 1752 M 1437 K
2240 M 1007 M 871 M 1966 M 576 K
aprs avoir rduit le temps d'excution de 290 116 secondes, soit aprs un gain de 2,50.
93
94
A.3 Journal d'optimisation du programme applu
!7 294
A.3.1
Itration 1 :
[Analyse]
312
(sec.)
Problme de dpendances sur des oprations arithmtiques ottantes (
Anomalies
/cycle
norme
DEPoO_fp).

5.50
2.49 2.31 14.82
4.22
0.69
-0.48 0.40 0.38 -0.58
Tab. A.33 Anomalies globales de applu
Anomalies
/cycle

5.50
2.23
3.27
Tab. A.34 Anomalies de dpendances de applu
[Localisation]
Procedures
blts
buts
rhs
jacld
blts.
DEPoO_fp
0.47
0.23
0.12
0.06
do k = 2, nz-1
do j = 2, ny-1
do i = 2, nx-1
do m = 1, 5
do l = 1, 5
v( m, i, j, k )
563:
- omega * (
564:
+
565:
+
= v( m, i, j, k
ldz( m, l, i, j,
ldy( m, l, i, j,
ldx( m, l, i, j,
DEPoO_fp
)
k ) * v( l, i, j, k-1 )
k ) * v( l, i, j-1, k )
k ) * v( l, i-1, j, k ) )
Fig. A.28 Procdure
blts
Le problme est localis sur les lignes 563, 564 et 565. En eet, l'opration de multiplication
par
omega
doit attendre les excutions de 2 additions qui, elles-mmes, doivent attendre les
excutions de 3 multiplications.
[Transformation]
Fission de boucle (Loop ssion ) et dcalage d'itrations (Shifting ) (Enable
Transfo. : Privatization ).
Nous avons privatis les calculs intermdiaires pour pouvoir scinder le nid de boucle (m,l).
A.3.
95
do k = 2, nz-1
do j = 2, ny-1
do m = 1, 5
do l = 1, 5
tmpldx(m,l) = ldx( m, l, 2, j, k )
* v( l, 2-1, j, k )
tmpldy(m,l) = ldy( m, l, 2, j, k )
* v( l, 2, j-1, k )
tmpldz(m,l) = ldz( m, l, 2, j, k )
* v( l, 2, j, k-1 )
do i = 2, nx-1
do m = 1, 5
do l = 1, 5
v( m, i, j, k ) = v( m, i, j, k
+ tmpldy(m,l)
+ tmpldx(m,l) )
...
do m = 1, 5
do l = 1,5
tmpldx(m,l) = ldx( m, l, i+1, j,
* v( l, i-1+1, j, k )
tmpldy(m,l) = ldy( m, l, i+1, j,
* v( l, i+1, j-1, k )
tmpldz(m,l) = ldz( m, l, i+1, j,
* v( l, i+1, j, k-1 )
k )
k )
k )
Fig. A.29 Procdure
blts
aprs fusion

[Analyse] Augmentation
tires (DEPoO_int).
des anomalies de dpendances sur des oprations arithmtiques en-
Anomalies
/cylce
/cycle

5.50
2.49 2.31 14.82
4.22
3.78
3.65 2.17 13.27 4.00
Anomalies
/cycle
/cycle

2.49
0.10
2.39
3.65
1.02
2.62
[Localisation]
Problme localis dans les nids de boucle de la procdure optimise
blts.
Le problme est localis sur les lignes 646, 648 et 650. Les oprations d'critures ottantes
sont dans la queue de lancement des instructions entires. Avec l'optimisation prcdente, nous
avons remplac les dpendances entre des oprations arithmtiques par des dpendances entre
des oprations arithmtiques et des oprations d'critures.
96
do k = 2, nz-1
do j = 2, ny-1
do i = 2, nx-1
do m = 1, 5
do l = 1, 5
v( m, i, j, k ) = v( m, i, j, k
+ tmpldy(m,l)
+ tmpldx(m,l) )
...
do m = 1, 5
do l = 1,5
646:
tmpldx(m,l) = ldx( m, l, i+1, j,
* v( l, i-1+1, j, k )
648:
tmpldy(m,l) = ldy( m, l, i+1, j,
* v( l, i+1, j-1, k )
650:
tmpldz(m,l) = ldz( m, l, i+1, j,
* v( l, i+1, j, k-1 )
k )
k )
k )
Fig. A.30 Procdure
[Transformation]
blts
Modication de la ssion de boucle (Loop ssion Modication ).
Nous avons modi la ssion de boucle pour rechercher un compromis entre des deux problmes (
DEPoO_fp
et
DEPoO_int).
do k = 2, nz-1
do j = 2, ny-1
do i = 2, nx-1
do m = 1, 5
do l = 1, 5
v( m, i, j, k ) = v( m, i, j, k )
- omega * tmpldxyz(m,l)
...
do m = 1, 5
do l = 1,5
tmpldx = ldx( m, l, i+1, j, k )
* v( l, i-1+1, j, k )
tmpldy = ldy( m, l, i+1, j, k )
* v( l, i+1, j-1, k )
tmpldz = ldz( m, l, i+1, j, k )
* v( l, i+1, j, k-1 )
tmpldxyz(m,l) = tmpldx + tmpldy + tmpldz
Fig. A.31 Procdure
Anomalies
/cycle
/cycle
blts
aprs modication de la ssion de boucles

3.78
3.65 2.17 13.27
4.00
4.03
3.31 2.15 12.83
3.64
A.3.
97

[Analyse]
Opportunit de gnralisation de l'optimisation et l'adaptation.
[Localisation]
Problme et structure de programme similaire dans la procdure
Procedures
blts
buts
rhs
jacld
buts.
DEPoO_fp
0.47
0.23
0.12
0.06
DEPoO_fp
do k = nz-1, 2, -1
do j = ny-1, 2, -1
do i = nx-1, 2, -1
do m = 1, 5
tv( m ) = 0.0d+00
do l = 1, 5
tv( m ) = tv( m ) +
omega * ( udz( m, l, i, j, k ) * v( l, i, j, k+1 )
+ udy( m, l, i, j, k ) * v( l, i, j+1, k )
+ udx( m, l, i, j, k ) * v( l, i+1, j, k ) )
c***diagonal block inversion
...
c***back substitution
...
Fig. A.32 Procdure
[Transformation]
buts
Transformations identiques : Fission de boucle modie (Loop ssion Modi-
ed ) et dcalage d'itrations (Shifting ).
Anomalies
/cycle
/cycle

4.03
3.31 2.15 12.83
3.64
4.03
3.33 2.14 12.32
3.44
98
do k = nz-1, 2, -1
do j = ny-1, 2, -1
do m = 1, 5
do l = 1, 5
tmpldx = udx( m, l, nx-1, j, k )
* v( l, nx-1+1, j, k )
tmpldy = udy( m, l, nx-1, j, k )
* v( l, nx-1, j+1, k )
tmpldz = udz( m, l, nx-1, j, k )
* v( l, nx-1, j, k+1 )
tldxyz(m,l) = tmpldx + tmpldy + tmpldz
do i = nx-1, 2, -1
do m = 1, 5
tv( m ) = 0.0d+00
do l = 1, 5
tv( m ) = tv( m ) +
omega * ( tldxyz(m,l) )
...
...
do m = 1, 5
do l = 1,5
tmpldx = udx( m, l, i-1, j, k )
* v( l, i+1-1, j, k )
tmpldy = udy( m, l, i-1, j, k )
* v( l, i-1, j+1, k )
tmpldz = udz( m, l, i-1, j, k )
* v( l, i-1, j, k+1 )
tldxyz(m,l) = tmpldx
+ tmpldy
+ tmpldz
Fig. A.33 Procdure
buts
aprs gnralisation de la ssion de boucles
A.3.
99
!7 211
A.3.2
Itration 2 :
[Analyse]
294
(sec.)
MEM_LAT_fp).
Problme de latence mmoire ottante (
Anomalies
/cycle
norme

4.03
3.33 2.11 12.33
3.44
0.08
-0.12 0.07
-0.63
0.02
Anomalies
/cycle

4.03
2.10
1.93
[Localisation]
buts
et
blts.
Le problme de latence mmoire est localis sur les oprations de lectures des tableaux
udy
et
udz.
Procedure
buts
blts
rhs
jacu
Procedures
buts
blts
rhs
jacld
DEP_fp
DEPoM_fp
0.38
0.41
0.33
0.35
0.10
0.09
0.08
0.06
MEM_LAT MEM_LAT_fp
0.40
0.41
0.32
0.31
0.10
0.10
0.08
0.08
[Annulation]
udx,
DEPoO_fp
Annulation des optimisations de la premire itration an de pouvoir appliquer
une nouvelle optimisation.
100
do k = nz-1, 2, -1
do j = ny-1, 2, -1
do m = 1, 5
do l = 1, 5
tmpldx = udx( m, l, nx-1, j, k )
* v( l, nx-1+1, j, k )
tmpldy = udy( m, l, nx-1, j, k )
* v( l, nx-1, j+1, k )
tmpldz = udz( m, l, nx-1, j, k )
* v( l, nx-1, j, k+1 )
tldxyz(m,l) = tmpldx + tmpldy + tmpldz
do i = nx-1, 2, -1
do m = 1, 5
tv( m ) = 0.0d+00
do l = 1, 5
tv( m ) = tv( m ) +
omega * ( tldxyz(m,l) )
...
...
do m = 1, 5
do l = 1,5
(801) tmpldx = udx( m, l, i-1, j, k )
* v( l, i+1-1, j, k )
(803) tmpldy = udy( m, l, i-1, j, k )
* v( l, i-1, j+1, k )
(805) tmpldz = udz( m, l, i-1, j, k )
* v( l, i-1, j, k+1 )
tldxyz(m,l) = tmpldx
+ tmpldy
+ tmpldz
Fig. A.34 Procdure
buts
A.3.
101
[Transformation]
Fusion de procdure et de boucles (Procedure and Loop fusion ).
Les tableaux n'ont aucun potentiel de rutilisation dans le nid de boucles. Nous avons cherch
la partie de programme qui produit ces tableaux pour essayer de rapprocher les producteurs des
consommateurs. Nous avons donc fusionn les procdures
boucles (k,j,i).
C ### Dbut de la procdure Jacu ###

do k = nz-1, 2, -1
do j = ny-1, 2, -1
do i = nx-1, 2, -1
...
a(1,1,i,j,k) = ...
...
c(5,5,i,j,k) = ...
C ### Dbut de la procdure Buts ###
do m = 1, 5
tv( m ) = 0.0d+00
do l = 1, 5
tv( m ) = tv( m ) +
omega * ( c( m, l, i, j, k )
+ b( m, l, i, j, k )
+ a( m, l, i, j, k )
end do
end do
do m = 1, 5
do l = 1, 5
tmat( m, l ) = d( m, l, i, j, k )
do ip = 1, 4
...
...
do m = 1, 5
rsd( m, i, j, k ) = rsd( m, i, j,
end do
C ### END of Buts Core procedure ###
Fig. A.35 Procdure
jacu_buts
jacu
et
buts
ainsi que les nids de
* rsd( l, i, j, k+1 )
* rsd( l, i, j+1, k )
* rsd( l, i+1, j, k ) )
k ) - tv( m )
jacu
et
buts

[Analyse] Augmentation des anomalies de dpendances
(DEPoM_int) (code de dbordement (spill code ).
Anomalies
/cycle
/cycle
sur des oprations mmoires entires

4.03
3.31 2.15 12.83
3.64
3.66
3.55 2.04 11.82 4.99
[Localisation]
jacu-buts.
Problme localis sur la ligne 2425 : les oprations d'critures dpendent des oprations de
102
Anomalies
jacu
buts
jacu_buts
augmentation

149 M
14 M
96 M
842 M
305 M
537 M
1077 M
435 M
641 M
8%
36%
1%
Tab. A.45 Augmentation des anomalies de dpendances aprs la fusion
lectures. Au niveau du code assembleur, on aperoit un problme de code de dbordement (spill
code ).
C ### Dbut de la procdure Jacu ###

do k = nz-1, 2, -1
do j = ny-1, 2, -1
do i = nx-1, 2, -1
...
a(1,1,i,j,k) = ...
...
c(5,5,i,j,k) = ...
C ### Dbut de la procdure Buts ###
do m = 1, 5
tv( m ) = 0.0d+00
do l = 1, 5
tv( m ) = tv( m ) +
omega * ( c( m, l, i, j, k )
+ b( m, l, i, j, k )
+ a( m, l, i, j, k )
end do
end do
do m = 1, 5
do l = 1, 5
(2425) tmat( m, l ) = d( m, l, i, j, k )
do ip = 1, 4
...
...
do m = 1, 5
rsd( m, i, j, k ) = rsd( m, i, j,
end do
C ### END of Buts Core procedure ###
* rsd( l, i, j, k+1 )
* rsd( l, i, j+1, k )
* rsd( l, i+1, j, k ) )
k ) - tv( m )
Fig. A.36 Procdure
[Transformation]
jacu_buts
Promotion de scalaires et rordonnancement d'instructions (Enable transfor-
mations : full unrolling, computation reordering ).

Pour rduire le code de dbordement, nous essayons de rduire la dure de vie des variables.
Pour cela, nous avons compltement droul le nid de boucles qui calcule les lments du tableau
tv,
ce qui a permis de rduire les dures de vie des tableaux
a,b
et
c.
Ensuite, nous avons
remplac ces trois tableaux par des variables scalaires.

L'augmentation des anomalies d'utilisation des units fonctionnelles est lie une diminution
de l'utilisation des units fonctionnelles entires.
A.3.
103
c***form the first

c
a11
a12
a13
a14
a15
tv(
...
block sub-diagonal
= =
=
=
=
1 )
a11
a12
a13
a14
a15
dt * tx1 * dx1
dt * tx2
0.0d+00
0.0d+00
0.0d+00
= tv( 1 ) + 1.0d+00 * (
* rsd(1, i+1, j, k ) +
* rsd(2, i+1, j, k ) +
* rsd(3, i+1, j, k ) +
* rsd(4, i+1, j, k ) +
* rsd(5, i+1, j, k ) )
a21
a22
a23
a24
a25
tv(
= dt
= dt
= dt
= dt
= dt
2 ) =
a21 *
a22 *
a23 *
a24 *
a25 *
b11
b12
b13
b14
b15
tv(
= - dt * ty1 * dy1
=
0.0d+00
= dt * ty2
=
0.0d+00
=
0.0d+00
1 ) = tv( 1 ) + 1.0d+00 * (
b11 * rsd(1, i, j+1, k ) +
b12 * rsd(2, i, j+1, k ) +
b13 * rsd(3, i, j+1, k ) +
b14 * rsd(4, i, j+1, k ) +
b15 * rsd(5, i, j+1, k ) )
...
Fig. A.37 Procdure
* tx2 * ...
* tx2 * ...
* tx2 * ...
* tx2 * ...
* tx2 * c2
tv( 2 ) + 1.0d+00 * (
rsd(1, i+1, j, k ) +
rsd(2, i+1, j, k ) +
rsd(3, i+1, j, k ) +
rsd(4, i+1, j, k ) +
rsd(5, i+1, j, k ) )
jacu-buts
Anomalies
/cycle
/cycle
aprs la promotion de scalaire et le rordonnancement

3.66
3.55 2.04 11.82
4.99
3.75
3.46 2.12 10.96
3.03

[Analyse]
Opportunit de gnralisation de l'optimisation et de l'adaptation.
[Localisation]
Problme et structure de programmes similaire dans la procdure
blts.
104
Procedures
jacu-buts
blts
rhs
jacld
MEM MEM_int
0.35
0.36
0.36
0.62
0.15
0.02
0.09
0.00
do m = 1, 5
do l = 1,5
565
tmpldx(m,l)
* v( l,
567
tmpldy(m,l)
* v( l,
569
tmpldz(m,l)
* v( l,
= ldx( m,
2-1, j, k
= ldy( m,
2, j-1, k
= ldz( m,
2, j, k-1
MEM_LAT_int
l, 2, j, k )
)
l, 2, j, k )
)
l, 2, j, k )
)
Fig. A.38 Procdure
blts
A.3.
105
[Transformation]
Transformations identiques : Fusion de procdure et de boucles (Procedure and
Loop fusion ). Plus, promotion de scalaires et rordonnancement d'instructions (Enable transformations : full unrolling, computation reordering ).
c***form the block daigonal

a11 = - dt * tz1 * dz1
a12 =
0.0d+00
a13 =
0.0d+00
a14 = - dt * tz2
a15 =
0.0d+00
tv(1) = tv(1) + (
a11 * rsd(1, i, j,
a12 * rsd(2, i, j,
a13 * rsd(3, i, j,
a14 * rsd(4, i, j,
a15 * rsd(5, i, j,
k-1
k-1
k-1
k-1
k-1
)
)
)
)
)
+
+
+
+
)
a21 = - dt * tz2 * ...

a22 = - dt * tz2 * ( u(4,i,j,k-1) * tmp1 )
a23 = 0.0d+00
a24 = - dt * tz2 * ( u(2,i,j,k-1) * tmp1 )
a25 = 0.0d+00
tv(2) = tv(2) + (
a21 * rsd(1, i, j, k-1 ) +
a22 * rsd(2, i, j, k-1 ) +
a23 * rsd(3, i, j, k-1 ) +
a24 * rsd(4, i, j, k-1 ) +
a25 * rsd(5, i, j, k-1 ) )
...
C BEGIN BLTS PROCEDURE CORE
rsd(1,i,j,k) = rsd(1,i,j,k) - ( omega * tv(1)
)
)
)
)
)
c***forward elimination
do m = 1, 5
do l = 1, 5
tmat( m, l ) = d( m, l, i, j, k )
end do
end do
Fig. A.39 Procdure
jacld-blts
Anomalies
/cycle
/cycle

3.75
3.46 2.12 10.96
3.03
3.64
3.11 2.05 9.17
2.68
jacld
et
blts
106
!7 143
A.3.3
[Analyse]
Itration 3 :
211
(sec.)
Problme de dpendances sur des oprations arithmtiques ottantes (
Anomalies
/cycle
norme
DEPoO_fp).

3.64
3.11 2.05 9.17
2.68
-0.07
-0.21 -0.10 -0.42 -0.70
Anomalies
/cycle

3.64
1.71
1.93
[Localisation]
Procedures
jacld
jacu
rhs
l2norm
jacld-blts
jacu-buts.
DEPoO_fp
0.45
0.40
0.11
0.02
[Transformation]
et
DEPoO_fp
Fission de boucle avec privatisation.
[Analyse]
FU_fp).
Augmentation des anomalies d'utilisation des units fonctionnelles ottantes (
Anomalies
/cycle
/cycle

3.64
3.11 2.05 9.17
2.68
3.06
2.63 2.13 8.72
2.36
Anomalies
/cycle
/cycle

2.04
0.14
0.20
0.08
0.79
0.13
0.70
2.12
0.17
0.26 0.09 0.78 0.14 0.69
Tab. A.53 Anomalies d'utilisation des units fonctionnelles de applu
[Localisation]
jacld-blts.
Ce problme a t gnr par l'optimisation prcdente qui a cr des nids de boucles ayant
un unique type d'opration.
A.3.
107
do m = 1, 5
do l = 1, 5
tmat( m, l ) = d( m, l, i, j, k )
end do
end do
do ip = 1, 4
tmp1 = 1.0d+00 / tmat( ip, ip )
do m = ip+1, 5
tmp = tmp1 * tmat( m, ip )
do l = ip+1, 5
tmat( m, l ) = tmat( m, l )
2233:
- tmp * tmat( ip, l )
end do
rsd( m, i, j, k ) = rsd( m, i, j, k )
2238:
- rsd( ip, i, j, k ) * tmp
end do
end do
do m = 5, 1, -1
do l = m+1, 5
rsd( m, i, j, k ) = rsd( m, i, j, k )
2251:
- tmat( m, l ) * rsd( l, i, j, k )
end do
rsd( m, i, j, k ) = rsd( m, i, j, k )
/ tmat( m, m )
end do
Fig. A.40 Procdure
604R-Anomalies
ssor
rhs
l2norm
jacu
jacld
FU_fadd FU_fmul
7.8M
1.0M
3.9M
25.9M
0.1M
0.9M
37.5M
50.8M
28.5M
34.3M
jacld-blts
605-Anomalies
ssor
rhs
l2norm
jacu
jacld
FU_fadd FU_fmul
6.4M
1.2M
3.8M
26.9M
0.1M
0.9M
37.4M
50.7M
40.6M
55.4M
Tab. A.54 Augmentation des anomalies d'utilisation des units fonctionnelles ottantes
[Transformation]
Droulage complet.
Pour permettre aux heuristiques du compilateur de rordonnancer les instructions au mieux,

nous avons compltement droul les dirents nids de boucles.
Anomalies
/cycle
/cycle

2.13
0.17
0.26
0.09
0.78
0.14
0.69
2.29
0.12
0.18 0.11 0.88 0.18 0.83
Tab. A.55 Anomalies d'utilisation des units fonctionnelles de applu

[Analyse]
Opportunit de gnralisation de l'optimisation et l'adaptation.
108
do m = 1, 5
do l = 1, 5
tmat( m, l ) = d( m, l, i, j, k )
end do
end do
do ip = 1, 4
tmp1 = 1.0d+00 / tmat( ip, ip )
do m = ip+1, 5
tmp = tmp1 * tmat( m, ip )
do l = ip+1, 5
tmat( m, l ) = tmat( m, l )
2233:
- tmp * tmat( ip, l )
end do
rsd( m, i, j, k ) = rsd( m, i, j, k )
2238:
- rsd( ip, i, j, k ) * tmp
end do
end do
do m = 5, 1, -1
do l = m+1, 5
2249:
ttrsd(m,l) = tmat( m, l ) * rsd( l, i, j, k )
end do
end do
do m = 5, 1, -1
do l = m+1, 5
rsd( m, i, j, k ) = rsd( m, i, j, k )
2258:
- ttrsd(m,l)
end do
rsd( m, i, j, k ) = rsd( m, i, j, k )
2264:
/ tmat( m, m )
end do
end do
Fig. A.41 Procdure
[Localisation]
jacld-blts
aprs la privatisation et la ssion de boucle
Problme et structure de programmes similaire dans la procdure
Procdures
jacu-buts
rhs
jacld-blts
ssor
l2norm
FU_fadd FU_fmul
0.56
0.06
0.28
0.10
0.00
0.51
0.27
0.19
0.01
0.01
[Transformation]
jacu-buts.
FU_fp
Transformations identiques : Droulage complet.
Le programme de la procdure
jacu-buts
est similaire celui de la procdure
jacld-blts
reprsent sur la gure A.42.

Nous avons arrt l'optimisation d'applu aprs avoir rduit le temps d'excution de 312
143 secondes, soit un gain de 2,18.
A.3.
C FULL UNROLLING
C ### ip = 1 ###
C ### m = 2 ###
C ### l = 2 ###
tmp1 = 1.0d+00 / tmat( 1, 1 )

tmp = tmp1 * tmat( 2, 1 )
tmat( 2, 2 ) = tmat( 2, 2 )
- tmp * tmat( 1, 2 )
C ### l = 3 ###
tmat( 2, 3 ) = tmat( 2, 3 )
- tmp * tmat( 1, 3 )
C ### l = 4 ###
C ### l = 5 ###
C ### m = 3 ###
C ### m = 5 ###
C ### ip = 2 ###
tmat( 2, 4 ) = tmat( 2, 4 )
- tmp * tmat( 1, 4 )
tmat( 2, 5 ) = tmat( 2, 5 )
- tmp * tmat( 1, 5 )
rsd( 2, i, j, k ) = rsd( 2, i, j, k )
- rsd( 1, i, j, k ) * tmp
tmp = tmp1 * tmat( 3, 1 )
...
...
...
C FULL UNROLLING
C ### m = 5 ###
rsd( 5, i, j, k ) = rsd( 5, i, j, k )
/ tmat( 5, 5 )
C ### m = 4 ###
...
Fig. A.42 Procdure
jacld-blts
aprs droulage complet
109
110
Bibliographie
111
Bibliographie
[AbToAn00]
Jaume Abella and Sid Ahmed Ali Touati and Alan Anderson and
Carlos Ciuraneta and Josep M. Codina and Min Dai and Christine Eisenbeis and Grigori Fursin and Anotio Gonzlez and Josep Llosa and Michael O'Boyle and Andry Randrianatovina and
The MHAOTEU Toolset
Jesus Snchez and Olivier Temam and Xavier Vera and Gragory
Watts.
In Agent-based simulation, planning
th
and control of the 16 IMACS World Congress, 2000.
[AhSeUl86]
lers Principles, Techniques, and Tools
Alfred V. Aho and Ravi Sethi and Jeffrey D. Ullman.
Compi-
Addison-Wesley, Reading,
Massachusetts, USA, 1986.

[AlCoGr04]
L. Almagor and Keith D. Cooper and Alexander Grosul and Ti-
Finding eective com-
mothy J. Harvey and Steven W. Reeves and Devika Subramanian
pilation sequences
and Linda Torczon and Todd Waterman.
. In Proceedings of the 2004 ACM SIGPLAN/SIGBED
conference on Languages, compilers, and tools, pages 231239. ACM Press,

2004.
[AlKe01]
Optimizing Compilers for Modern
Architectures
Putting Polyhedral Loop Transformation to Work
Randy Allen and Ken Kennedy.
. Morgan Kaufmann Publishers, 2001.
[BaCoGi03]
C. Bastoul and A. Cohen and S. Girbal and S. Sharma and O.

Temam.
. In 10th
International Workshop on Languages and Compilers for Parallel Computing

(LCPC), October 2003.
[BaDuBa00]
namo : a transparent dynamic optimization system
Vasanth Bala and Evelyn Duesterwald and Sanjeev Banerjia.
Dy-
. In Proceedings of
the ACM SIGPLAN 2000 conference on Programming language design and

implementation, pages 112. ACM Press, 2000.
[BaGrSh94]
ler transformations for high-performance computing
David F. Bacon and Susan L. Graham and Oliver J. Sharp.
Compi-
. ACM Computing
Surveys, 26(4) :345420, 1994.

[BrCoKe89]
loring heuristics for register allocation
P. Briggs and K. D. Cooper and K. Kennedy and L. Torczon.
Co-
. In Proceedings of the ACM SIG-
PLAN 1989 Conference on Programming language design and implementation,

pages 275284. ACM Press, 1989.
112
[Ca96]
BIBLIOGRAPHIE
Combining Optimization for Cache and InstructionLevel Parallelism
Steve Carr.
. In Proceedings of the 1996 Conference on Parallel Archi-
tectures and Compilation Techniques (PACT '96), page 238. IEEE Computer
Society, 1996.
[CaFeHu95]
Hierarchical tiling for improved superscalar performance
Larry Carter and Jeanne Ferrante and Susan Flynn Hummel.
In Pro-
ceedings of the 9th International Symposium on Parallel Processing, pages

239245. IEEE Computer Society, 1995.
See also : Hierarchical tiling : a
methodology for high performance. Technical report UCSD, 1996.

[CaGu97]
rated sets
Steve Carr and Yiping Guan.
Unroll-and-jam using uniformly gene-
. In Proceedings of the 30th annual ACM/IEEE international sym-
posium on Microarchitecture, pages 349357. IEEE Computer Society, 1997.

[CaKe94]
Scalar replacement in the presence

of conditional control ow
Exact analysis of the cache behavior of nested
loops
Tile size selection
using cache organization and data layout
Steve Carr and Ken Kennedy.
. Softw. Pract. Exper., 24(1) :5177, 1994.
[ChPaHaLe01]
Siddhartha Chatterjee and Erin Parker and Philip J. Hanlon and

Alvin R. Lebeck.
. In Proceedings of the ACM SIGPLAN 2001 conference on Programming
language design and implementation, pages 286297. ACM Press, 2001.

[CoKi95]
Stephanie Coleman and Kathryn S. McKinley.
. In Proceedings of the ACM
SIGPLAN 1995 conference on Programming language design and implementation, pages 279290. ACM Press, 1995.
[CoLo99]
Feedback Directed Optimization in Compaq's Compilation Tools for Alpha
Robert Cohn and P. Geoffrey Lowney.
. In Proceedings of
the Second Workshop on Feedback-Directed Optimization, held in conjunction

with MICRO-33, pages 312, 1999.
[Cxml]
[DeHiWa97]
Compaq eXtended Mathematic Library Reference Guide

ProleMe : Hardware support for instruction
level proling on out-of-order processors
Itanium Microarchitecture Design
.
J. Dean and J.E. Hicks and C.A. Waldspurger and W.E. Weihl
and G.Z. Chrysos.
In In Proceedings of the
th
30 International Symposium on Microarchitecture, NC, December 1997.
[Epic]
. Microproces-
Harsh Sharangpani.
sor Forum, 1999.
[GhMaMa99]
Cache miss equations : a compiler framework for analyzing and tuning memory behavior
Ecient instruction
scheduling for a pipelined architecture
Somnath
Ghosh
and
Margaret
Martonosi
and
Sharad
Malik.
. ACM Trans. Program. Lang. Syst., 21(4) :703746,
1999.
[GiMu86]
Philip B. Gibbons and Steven S. Muchnick.
. In Proceedings of the 1986 SIG-
PLAN symposium on Compiler contruction, pages 1116. ACM Press, 1986.
113
BIBLIOGRAPHIE
[IPF2]
Intel Itanium2 Processor Reference Manual for Software Development and Optimization
.
http
://developer.intel.com/design/itan-
ium2/manuals.
[Kap]
KAP C/OpenMP for Tru64 UNIX and KAP DEC Fortran for Digital UNIX
Fast greedy weighted fusion
. http ://www.hp.com/techsevers/software/kap.html.
[Ke00]
. In Proceedings of the 14th
Ken Kennedy.
international conference on Supercomputing, pages 131140. ACM Press, 2000.

[KiFr03]
zation : A case study
Thomas Kistler and Michael Franz.
Continuous program optimi-
. ACM Trans. Program. Lang. Syst., 25(4) :500548,
2003.
[KiKnOB00]
Iterative compilation in program optimization
T. Kisuki and P. Knijnenburg and M. O'Boyle and H. Wijshoff.
. In Proc. CPC'10 (Com-
pilers for Parallel Computers), pages 3544, 2000.

[KiKnOB00+]
Combined Selection of Tile Sizes and Unroll Factors Using

Iterative Compilation
Toru Kisuki and Peter M. W. Knijnenburg and Michael F. P.

O'Boyle.
. In IEEE PACT, pages 237248, 2000.
[KKGO00]
The Eect of Cache Models on Iterative Compilation for Combined

Tiling and Unrolling
T. Kisuki and P. Knijnenburg and K. Gallivan and M. O'Boyle.
. In Parallel Architectures and Compilation Techniques
(PACT'00). IEEE Computer Society Press, October 2001.

[KuHiHi04]
Fast searches for
Prasad Kulkarni and Stephen Hines and Jason Hiser and David
eective optimization phase sequences
Whalley and Jack Davidson and Douglas Jones.
. In Proceedings of the ACM SIG-
PLAN 2004 conference on Programming language design and implementation,

[KuZhMo03]
Prasad
Kulkarni
and
Wankang
Zhao
and
Hwashin
Moon
and
Finding eective
Kyunghwan Cho and David Whalley and Jack Davidson and Mark
optimization phase sequences
Bailey and Yunheung Paek and Kyle Gallivan.
. In Proceedings of the 2003 ACM SIGPLAN
conference on Language, compiler, and tool for embedded systems, pages 1223.
ACM Press, 2003.
[LaRoWo91]
The cache performance and optimizations of blocked algorithms
Monica D. Lam and Edward E. Rothberg and Michael E. Wolf.
. In
Proceedings of the fourth international conference on Architectural support for

programming languages and operating systems, pages 6374. ACM Press, 1991.
[McTe96]
of loop nest locality
Kathryn S. McKinley and Olivier Temam.
A quantitative analysis
. In Proceedings of the seventh international conference
on Architectural support for programming languages and operating systems,

114
[MiCaFe97]
BIBLIOGRAPHIE
Quantifying the Multi-level Nature of Tiling In-
Nicholas Mitchell and Larry Carter and Jeanne Ferrante and
teractions
Karin Hogstedt.
. In Languages and Compilers for Parallel Computing, pages 115,
1997.
[MoBo01]
Computer aided hand

tuning (CAHT) : "applying case-based reasoning to performance
tuning"
A
Machine Learning Approach to Automatic Production of Compiler
Heuristics
Antoine Monsifrot and Franois Bodin.
. In Proceedings of the 15th International Conference on Supercom-
puting, pages 196203. ACM Press, 2001.

[MoBoQu02]
Antoine Monsifrot and Franois Bodin and Rene Quiniou.
. In Proceedings of the 10th International Conference on Articial
Intelligence : Methodology, Systems, and Applications, pages 4150. SpringerVerlag, 2002.

[Mu97]
Advanced compiler design and implementation

MOB forms : a
class of multilevel block algorithms for dense linear algebra operations
OProle project
Open Research Compiler
Perfmon project
Register allocation with instruction scheduling
Steven S. Muchnick.
. Morgan Kaufmann Publishers Inc., 1997.
[NaJuLa94]
Juan J. Navarro and Toni Juan and Toms Lang.
. In Proceedings of the 8th international conference on Supercomputing,

[OProle]
[ORC]
[PerfMon3]
[Pi93]
. http ://oprole.sourceforge.net.
. http ://ipf-orc.sourceforge.net.
. http ://www.hpl.hp.com/research/linux/perfmon.
Shlomit S. Pinter.
In Proceedings of the ACM SIGPLAN 1993 conference on Programming lan-
guage design and implementation, pages 248257. ACM Press, 1993.

[RiTs98]
eliminating conict misses
Data transformations for
Gabriel Rivera and Chau-Wen Tseng.
In Proceedings of the ACM SIGPLAN 1998
conference on Programming language design and implementation, pages 3849.

ACM Press, 1998.
[RiTs98+]
for high performance architectures
Eliminating conict misses
. In Proceedings of the 12th interna-
tional conference on Supercomputing, pages 353360. ACM Press, 1998.

[RiTs99]
Tiling Algorithms
A Comparison of Compiler
. In Proceedings of the 8th International Conference on
Compiler Construction, Held as Part of the European Joint Conferences on the

Theory and Practice of Software, ETAPS'99, pages 168182. Springer-Verlag,
1999.
[SmSo95]
superscalar processors
James
E. Smith and
Gurindar
bers.jcom.home.ne.jp/kgoto.
S.
Proceedings
Sohi.
The microarchiture of
of IEEE, 1995.
http
://mem-
115
BIBLIOGRAPHIE
[SrLe98]
Load latency tole-
rance in dynamically scheduled processors
Srikanth T. Srinivasan and Alvin R. Lebeck.
. In Proceedings of the 31st
annual ACM/IEEE international symposium on Microarchitecture, pages 148

159. IEEE Computer Society Press, 1998.
[StAmMaOR03]
Meta optimization : improving compiler heuristics with machine learning

Mark Stephenson and Saman Amarasinghe and Martin Martin and
Una-May O'Reilly.
. In Proceedings of the ACM SIGPLAN 2003
conference on Programming language design and implementation, pages 7790.

ACM Press, 2003.
[TeGrJa93]
To copy or not to
copy : a compile-time technique for assessing when data copying
should be used to eliminate cache conicts
O. Temam and E. D. Granston and W. Jalby.
. In Proceedings of the 1993
ACM/IEEE conference on Supercomputing, pages 410419. ACM Press, 1993.

[TrVaVaAu03]
Compiler optimization-space explo-
Spyridon Triantafyllis and Manish Vachharajani and Neil Vach-
ration
harajani and David I. August.
In Proceedings of the international symposium on Code generation
and optimization, pages 204215. IEEE Computer Society, 2003.

[VoEi00]
ADAPT : Automated
De-Coupled Adaptive Program Transformation
Michael J. Voss and Rudolf Eigenmann.
. In Proceedings of the
Proceedings of the 2000 International Conference on Parallel Processing, page

163. IEEE Computer Society, 2000.
[VoEi01]
gram optimization with ADAPT
Michael J. Voss and Rudolf Eigemann.
High-level adaptive pro-
. In Proceedings of the eighth ACM SIG-
PLAN symposium on Principles and practices of parallel programming, pages

93102. ACM Press, 2001.
[VTune]
Intel VTune Performance Analysers

Vers un environnement et une mthodologie d'optimisation de programmes sur la hirarchie mmoire
Complexity and uniformity of elimination in
Persburger arithmetic
An approach to ordering optimizing
transformations
.
http
://www.intel.com/soft-
ware/products/vtune.
[Wa02]
Gregory Watts.
. PH.D. Thesis,
2002.
[We97]
Volker Weispfenning.
. In Proceedings of the 1997 international symposium
on Symbolic and algebraic computation, pages 4853. ACM Press, 1997.

[WhSo90]
D. Whitfield and M. L. Soffa.
. In Proceedings of the second ACM SIGPLAN symposium
on Principles & practice of parallel programming, pages 137146. ACM Press,

1990.
[WoLa91]
gorithm
Michael E. Wolf and Monica S. Lam.
A data locality optimizing al-
. In Proceedings of the ACM SIGPLAN 1991 conference on Program-
ming language design and implementation, pages 3044. ACM Press, 1991.
116
[ZhCaWh02]
BIBLIOGRAPHIE
Wankang Zhao and Baosheng Cai and David Whalley and Mark
W. Bailey and Robert van Engelen and Xin Yuan and Jason D.
VISTA : a system for interactive code improvement
Hiser and Jack W. Davidson and Kyle Gallivan and Douglas L.

Jones.
. In Procee-
dings of the joint conference on Languages, compilers and tools for embedded
systems, pages 155164. ACM Press, 2002.

Pa 04

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pa 04

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIT de PARIS-SUD

U.F.R. SCIENTIFIQUE d'ORSAY

prsente pour obtenir

soutenue le vendredi 17 septembre 2004 devant le jury compos de :

Universit Paul Sabatier, Toulouse III

Table des matires

Complexit des architectures superscalaires

Architecture gnrale du processeur Alpha-21264 (EV68) . . . . . . . . . .

Pipeline du processeur Alpha-21264 (EV68) . . . . . . . . . . . . . . . . .

Cas particuliers d'excutions

Optimisation du produit de matrices base sur une analyse dynamique dtaille .

Identication des problmes de performance sur une architecture complexe . . . .

Normalisation des anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Construction de l'arbre de dcision

2 Optimisation et Analyse dynamique dtaille

Dcomposition des problmes de performance . . . . . . . . . . . . . . . .

Annulation des itrations

Comparaison avec un compilateur statique . . . . . . . . . . . . . . . . . .

Optimisation du programme wupwise . . . . . . . . . . . . . . . . . . . .

Table des matires

Association entre anomalies et optimisations . . . . . . . . . . . . . . . . .

Journal d'optimisation du programme wupwise

Journal d'optimisation du programme equake

Journal d'optimisation du programme applu

Elle est gnralement ralise par un compilateur ou bien un

le comportement des programmes.

Elle est gnralement ralise lorsque l'optimisation du compilateur

soutenues proches de la performance crte des processeurs.

problmes de performances. L'application de ce processus un ensemble de programmes de la

1.1 Complexit des architectures superscalaires

Architecture gnrale du processeur Alpha-21264 (EV68)

ICache 64KB 2way associative

DCache 64KB 2way associative

Fig. 1.1  Architecture gnrale du processeur Alpha-21264/EV68

Pipeline du processeur Alpha-21264 (EV68)

Etage 0, Chargement des instructions (fetch )

Le prdicteur de branchement combine un

prdicteur local et un prdicteur global en utilisant un prdicteur de slection.

Complexit des architectures superscalaires

Reg Read Execute

Fig. 1.2  Pipeline du processeur Alpha-21264/EV68

Etage 1, Placement des instructions (slot )

A ce cycle, le rsultat de la prdiction de

branchement est disponible et la prdiction de ligne peut tre vrie.

Etage 2, Renommage des registres (rename )

Durant ce cycle, le renommage de registres

Etage 3, Lancement des instructions (issue )

La queue de lancement entire peut lan-

Etage 4, Lecture des registres (reg )

Les instructions, qui viennent d'tre lances, lisent

Etage 5, Excution des instructions (execute )

Les units fonctionnelles commencent les

Etage 6, Accs mmoires (memory )

Dans cet tage, les oprations mmoires accdent au

Etage 7 (non reprsent), Terminaison des instructions (retire )

Dans cet tage, les

Cas particuliers d'excutions

Lancement spculatif des instructions

prcdant la n de l'excution de l'instruction

dpend d'une ins-

est retire de la queue de lancement 2 cycles aprs son lancement. Si

un dfaut de cache alors l'instruction

est annule et reste dans la queue de lancement depuis

laquelle elle sera relance.

Identication des problmes de performance sur une architecture complexe . . . .

Fig. 1.1 Architecture gnrale du processeur Alpha-21264/EV68

Fig. 1.2 Pipeline du processeur Alpha-21264/EV68

branchement est disponible et la prdiction de ligne peut tre vrie.

prcdant la n de l'excution de l'instruction

Tab. 1.1 Fentre de spculation entire : cycles 4 5

Tab. 1.2 Fentre de spculation ottante : cycles 5

Oprations mmoires en conits

que la transformation est lgale, c'est--dire qu'elle ne modie pas la smantique

Les transformations peuvent tre appliques dirents niveaux dans le programme :

Les transformations de simplications

Les transformations spciques la gnration de code

Les transformations spciques aux structures de contrles et aux structures de

Fusion et ssion de boucles

La fusion et la ssion de boucles sont souvent utilises pour

peut tre inhib par des conits de cache entre les

(a) avant fusion ou aprs ssion

(b) aprs fusion ou avant ssion

Fig. 1.6 Fusion et ssion de boucles

Fig. 1.8 Exemple d'un blocage de boucle sur un produit de matrices

Fig. 1.9 Ordre d'accs aux matrices

Le rarrangement de donnes consiste modier les dcla-

qui permet d'viter des conits de cache lorsque les tailles

pour rduire les conits

(WHIRL or global Optimizations ) : cette phase eectue des optimisations gnrales