HAL Id: tel-03012450
https://hal-uphf.archives-ouvertes.fr/tel-03012450
Submitted on 18 Nov 2020HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are
pub-L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non,
Optimisation des performances et de la consommation
de puissance électrique pour architecture Intel
ltanium/EPIC
Jamel Tayeb
To cite this version:
Jamel Tayeb. Optimisation des performances et de la consommation de puissance électrique pour archi-tecture Intel ltanium/EPIC. Informatique [cs]. Université de Valenciennes et du Hainaut-Cambrésis, 2008. Français. �NNT : 2008VALE0037�. �tel-03012450�
Numéro d'ordre : 08/40
Optimisation des performances et de la
consommation de puissance électrique pou
r
architecture Intel ltanium/EPIC
THÈSE
Présentée et soutenue publiquement le : 25 novembre 2008 pour l'obtention du
Doctorat de l'université de Valenciennes et du Hainaut-Cambrésis
Spécialité Automatique et Informatique des Systèmes Industriel
s et H
umains
Rapporteurs :
Dr. Alb
ert COHEN
,
Pr. W
illiam JALB
Y
,
Examinateurs :
Discipline : Informatique
par
JamelTAYEB
INRlA, Éc
ole Po
lytechnique de Paris
Université de Versaill
es-Saint-
Quentin-en-Y
v
elines
Pr. Jean-Luc DEKEYSER
,
Pr. Pierre MANNEBAC
K
Laboratoire d'Informatique Fondamentale
à
Lille
Faculté P
o
lytechnique de M
ons
,
Belgique
Invité:
M
.
Gwenol
é
BEAUCHESNE
,
I
ngénieur
,
Mandriva S.A
.
Paris
Directeur:
Pr
.
Sm ai
l
N
IAR,LAMIH
,
Université de
V
alenciennes
Remerciements
Merci tout d'abord à Smail Niar qui il y a tous juste quatre ans m'a offert, en plus de son amitié, l'opportunité d'effectuer ma thèse au sein du laboratoire LAMll-1. Je le remercie pour cette chance inespérée, de la confiance et de son soutien de tous les moments, les plus heureux comme les plus difficiles. Son aide et ses conseils rn 'ont aidé à garder le cap.
J'exprime ma profonde gratitude à Albert Cohen et William Jalby qui m'ont fait l'honneur
d'être rapporteurs de cette thèse et pour avoir pris le temps de rédiger un rapport sur celle-ci. Je les remercie pour 1' intérêt sincère qu'ils ont porté à mon travail. Je tiens à remercier ici les examinateurs :
Jean-Luc Dekeyser et Pierre Manneback qui m'ont fait le plaisir d'examiner ce travail et de faire
partie du Jury. Merci enfin à Gwenolé Beauchesne qui m'a fait le plaisir de sa présence et que je retrouve à cette occasion avec plaisir.
Je remercie Lakshmi Talluru et Adarsh Saga/ qui chacun à leur façon ont consenti des efforts inattendus en me donnant des moyens afin que je puisse mener à bien mes recherches en parallèle de notre exigent travail de tous les jours.
Merci aussi à mes amis qui m'ont- plus que de coutume- supporté, écouté et motivé lorsqu'il m'arrivait de perdre courage. Merci à vous Stanislas Odinot, Dan Zimmerman, Jean-Laurent Philippe
et Christopher Meredith. Merci à Sandrine Charbonnier pour tous cela et aussi pour son aide
précieuse et indispensable lors de la rédaction de ce mémoire.
Je remercie de tous mon cœur mes parents pour leur amour inconditionnel et pour m'avoir
toujours poussé à aller de l'avant. Merci à mon épouse, Danika Hercha, qui m'a toujours encouragé à
poursuivre mes rêves. Son amour et son soutien m'ont été particulièrement importants au cours de
cette difficile année.
Enfm, je remercie du fond du cœur mon père et mon grand-père maternel qui n'auront pas la chance de lire ces lignes, et pourtant sans lesquels je n'aurais jamais entrepris cette aventure. Merci à
vous d'avoir su éveiller ma curiosité et mon amour pour la science et la découverte. Je dédie mon travail à votre mémoire.
Résumé
En fondant sa nouvelle génération de processeurs sur l'architecture Very Long Instruction
Word, Intel Corporation a introduit une famille de processeurs à la fois novateurs et généralistes,
en ce sens que nous les retrouvons aussi bien dans le segment des calculateurs scientifiques que dans celui des serveurs d'entreprise. Les choix architecturaux retenus et la mise à la disposition du programmeur, désormais seul maitre à bord, d'importantes ressources matérielles, nous ont conduit à entreprendre l'étude d'utilisations alternatives de certaines d'entre-elles. Parmi les ressources que nous avons ainsi étudiées, nous trouvons les piles des registres que nous avons optimisés pour l'exécution de machines à piles. Notre choix c'est naturellement porté sur le système FORTH, archétype des machines à pile s'il en est. Après une implémentation logicielle d'un système FORTH pour Itanium, nous avons introduit un ensemble d'amendements matériels à l'architecture Explicit Parallel Instruction Computer afin de compenser certaines limitations de notre implémentation initiale. Nous avons ainsi mis en place une pile matérielle dont le contrôle échoit explicitement au logiciel.
Cette première approche, si elle est bien adaptée au système FORTH montre toutefois ses limites lorsqu'il s'agit d'implémenter des langages évolués ayant connu un succès commercial et d'estime plus important. Bien entendu, ces deux langages ont des différences techniques fondamentales, dont la plus importante dans le cadre de cette étude est la nature fortement typée de la pile d'évaluation de .NET, là où la pile FORTH n'a aucune forme de typage. Nous avons repensé en conséquence notre approche initiale et nous avons proposé une pile matérielle dont le contrôle est assuré cette fois-ci implicitement par le matériel. Il en résulte une plus grande facilité d'implémentation de langages tels que le Microsoft Intermediate Language de .NET ou Java, tout en limitant l'ampleur des modifications requises à son emploi. L'utilisation de cette pile permettant une traduction directe et à faible coût du MSIL en binaire. Le second avantage de la méthode est d'être« implémentable »quasi-directement dans les processeurs Itanium.
Dans une seconde partie, nous nous sommes attelés à l'étude et à l'optimisation de l'efficacité énergétique des applications serveurs destinées à cette nouvelle famille de processeurs. Nous avons développé dans un premier temps des outils de mesure et d'analyse de la consommation d'énergie. Nous avons ensuite dégagé un corpus de règles qui permettent aux développeurs d'applications de rendre leurs logiciels plus économes et d'adapter leur consommation énergétique en fonction d'un niveau de performance requis ou décidé dynamiquement.
Table des matières
REMERCIEMENTS ...••.•••...•.••.••...•...••...•...••.... 111
RESUME ...•...•...•..••...•...••.•••.•.•••.•.•..•...•.... V TABLE DES MATIERES ... VIl INTRODUCTION ....•..••..•.••..•...•.••••••...•....•.••..•.••..•..••.••.•••.•...••.•...•.•.•...•...•..••...••...•••.... 1 1. INTRODUCTION GENERALE ... 1 2. LA REPONSE EPIC ... 3 3. LA REPONSE CMP ... 6 4. LA REPONSE VIRTUALISATION ... 10 S. STRUCTURE DU DOCUMENT ... 12 6. REFERENCES ... 13
CACHE DE PILE POUR ARCHITECTURE EPIC ... 17
RESUME ... 17
1. INTRODUCTION ... 17
2. TRAVAUX CONNEXES ... 18
3. CODE DE REFERENCE ET UTILISATION DE LA PILE DE REGISTRES ... 27
4. CODE OPTIMISE ET MODIFICATION DE LA MACHINE VIRTUELLE ... 29
S. ACCES INDEXES AUX REGISTRES ... 3S 6. IMPLEMENTATION SIMPLIFIEE ... 40
7. CONCLUSIONS ... 42
8. REFERENCES ... 42
UNE PILE VIRTUELLE POUR L'ARCHITECTURE EPIC ... 47
RESUME ... .47
1. INTRODUCTION ... 47
. 2. TRAVAUX CONNEXES ... .48
3. TERMINOLOGIE .NfT ... S2 4. LA PILE MATERIELLE ... SS a. La pile typée dynamique ... 56
b. Opérations sur la pile virtuelle ... 65
s.
TRADUCTION DE CIL VERS EPIC ... 7S 6. RESULTATS EXPERIMENTAUX ... 81a. Méthodologie de tests ... Bl b. Analyse des données ... 85
c. Analyse de benchmorks ... 89
7. CONCLUSIONS ... 96
8. REFERENCES ... 96
OPTIMISATION DE L'EFFICACITE ENERGETIQUE ... 101
RESUME ... 101
1. INTRODUCTION ... 101
2. MESURE DE L'ENERGIE ET DE L'EFFICACITE ENERGETIQUE ... 104
3. LES OPTIMISATIONS ENERGETIQUES ... 106
b. Transformations de code ... 110
c. Transformations du premier groupe ... 112
d. Transformations du second groupe ... 122
4. CONCLUSIONS ... 126 5. REFERENCES ... 127 CONCLUSIONS ET PERSPECTIVES ... 129 1. CONCLUSIONS ... 129 2. PERSPECTIVES ... 131 ANNEXES ... 133
1. APERÇU DE L'ARCHITECTURE EPIC ... 133
a. Parallélisme d'instructions ... 133
b. Pipeline ... 134
c. EPIC à la croisée du super scalaire et du VLIW ... 135
d. Micro architecture du processeur ltanium2 ... 136
e. Registres ... 138
f Aperçu du jeu d'instructions du processeur ltanium 2 ... 142
g. F'ormat des instructions ... 148
2. STRUCTURES ET MECANISMES FONDAMENTAUX DE FORTH ... 151
a. Les interpréteurs FORTH ... 152
b. Le compilateur FORTH ... 158
3. MESURE DE L'ENERGIE CONSOMMEE ... 161
a. Compteurs matériels et logiciels ... 162
b. Recherche des points énergétiques ... 166
c. Instrumentaliser les applications ... 171
d. Autorégulation des performances ... 172
Introduction
1.
Introduction générale
L'industrie du semi-conducteur vit depuis plus de quarante ans au rythme de la loi de
Gordon Moore. Enoncée en 1965 (Moore 1965) elle peut se résumer par l'assertion suivante:
«
le nombre de transistors par circuit de même taille doublera tous les 18 à 24 mois ». Cette loi
s'applique au processeur précurseur- ou lead microprocessor- qui intègre pour la première fois
une nouvelle micro architecture, par opposition aux améliorations induites par les nouvelles techniques de lithographie - ou compaction microprocessor. Une finesse de gravure accrue
permet d'augmenter la densité des transistors gravés sur le silicium, mais, pour un microprocesseur donné, cela n'augmente pas pour autant leur nombre.
1
1
·- lo.IIIIO.CIOQ.II
·-IIXI.Ilœ,ClCI(I
Figure 1 -Graphique montrant l'évolution du nombre des transistors pour chaque processeur précurseur introduit par Intel Corporation. Source : Intel Corporation.
Ainsi, la surface des processeurs précurseurs a été augmentée d'environ 14% tous les deux ans. En dix ans, la technologie de gravure est passée quant à elle de 1 J.U11 à 0,18 J.U11 (les industriels les plus en pointe produisent certaines de leurs puces en 45 nm et prévoient des circuits en 32 nm d'ici 2009 et 22 nm en 2011). La fréquence d'horloge a été multipliée pour sa part par cinquante (50x) dans le même temps. La performance des processeurs a subi un accroissement de ~ 75x, dont malheureusement seulement ~6x sont dus à des innovations micro architecturales. La question qui se pose est donc la suivante : « quelle est la signification de la loi
de Moore pour la performance? ».En effet, en dix ans, les avancées micro architecturales telles
que les pipelines, le super scalaire, les cœurs à exécution désordonnée - ou Out Of Order
execution engine (000) -ou encore l'exécution spéculative des instructions ont multiplié les
performances d'un- petit- facteur six !
Pour étudier l'augmentation de la performance, nous devons recourir à la formulation de
Pollack. Fred J. Pollack- Intel Fe/law et Directeur du Microprocessor Research Labs - a
observé que pour le même procédé de fabrication, le processeur précurseur offre en moyenne un gain de performance de ~ 1 ,4x pour un doublement de la surface par rapport au processeur de génération précédente (Ronen, et al. 1999). Pollack observe ainsi que le gain de performance décline avec les générations successives et évolue comme la racine carrée de l'accroissement de la surface de la die du processeur. En d'autres termes, bien que les physiciens permettent d'augmenter la densité de transistors et que les usines peuvent fabriquer ces mêmes transistors à grande échelle selon la prévision de Moore, il faut impérativement introduire des modifications radicales dans les microarchitectures pour assurer les gains de performance escomptés - ou du moins significatifs. Autrement dit encore, l'industrie du microprocesseur s'est trouvée à la croisée des chemins entre 2000 et 2003. Ceci a été illustré par les difficultés rencontrées par l'architecture NetBurst à offrir le niveau de performance attendu par les consommateurs. Il était dès lors clair qu'il n'était plus possible de s'en remettre à la seule recette du passé, à savoir augmenter la fréquence d'horloge. En outre, cette montée en fréquence pose clairement le problème de la consommation d'énergie. Les projections donnaient en effet des consommations de l'ordre de 10 000 Watts pour le processeur à l'horizon 2010-2015 si rien ne changeait (Borkar 1999). Cette projection a agi comme un coup de semonce et a forcé l'ensemble des acteurs de l'industrie informatique à reconsidérer sérieusement les solutions privilégiées jusqu'à lors et à amender leurs plans de recherche et de développement.
Malheureusement, la montée en fréquence a des arguments de poids. Premièrement, augmenter la fréquence se traduit par un gain de performance quasi-linéaire pour les processus légers- ou threads- des applications. En d'autres termes, ce qui rend ce modèle très apprécié par les fondeurs et les éditeurs de logiciels, c'est qu'il ne demande aucun effort particulier de la part de ces derniers, et qu'il est simple à expliquer aux clients des premiers. A présent que le modèle est brisé - du moins, si les coûts de développement et de production en volume sont pris en considération - il ne reste plus qu'une seule variable à explorer pour assurer les gains de performances promis et attendus. Et la solution retenue par l'industrie pour résoudre ce problème se résume en un seul mot: parallélisme. Paral1élisme à gros grain tout d'abord via la virtualisation, parallélisme de données ensuite avec le calcul vectoriel ou SIMD (Single
Instruction Multiple Data), mais aussi parallélisme au sens premier du terme avec des
technologies telles que le multi-flots (SMI' Simultaneous Multi Threading), le multiprocesseurs sur puce ou multi-cores (CMP Chip Mu/ti Processor), ou plus fondamentalement le MIMD
La réponse EPIC
(Multiple Instruction Multiple Data) d'EPIC (Explicit Paral/el Instruction Computer). Nous
présenterons dans la suite de cette introduction comment chacune de ces technologies tente de répondre au problème de la performance - et à celui de la densité de puissance qui en est le corolaire. Nous souhaitons ainsi mettre notre travail en perspective, en le situant dans cette période propice au développement d'idées nouvelles que nous avons la chance de vivre.
2.
La réponse
EPIC
Développée conjointement par Hewlett-Packard et Intel Corporation, l'architecture EPIC se retrouve implémentée au cœur des processeurs de la famille Itanium. Elle offre plusieurs aménagements matériels inédits, qui utilisés conjointement avec des logiciels correctement conçus, permettent de passer outre certaines barrières de performances difficilement franchissables par les architectures traditionnelles (Reduced Instruction Set Computer et
Complex Instruction Set Computer essentiellement). Comme nous le verrons tout au long de ce
document, la composante logicielle de l'architecture EPIC est essentielle. Elle l'est à un tel point, que le compilateur fait intégralement partie de l'architecture. Ce n'est plus un simple outil destiné aux programmeurs d'applications, mais fait partie d' EPIC. Avec son support, EPIC autorise principalement 1' augmentation du degré de parallélisme des instructions ou d' ILP
(Instruction Leve! Parallelism). Rappelons que jusque-là, l'expression d'un ILP élevé était échue
aux cœurs à exécution désordonnée- Out of Order. Ainsi, le duo formé par le compilateur et un processeur EP IC peut espérer absorber les latences d'accès aux données et d'exécution des instructions.
Pour utiliser pleinement les capacités de l'architecture EPIC, les logiciels doivent littéralement coopérer avec le processeur. Si cette interaction est souhaitable pour n'importe quelle architecture pour obtenir le meilleur niveau de performance possible, cela est encore plus vrai pour l'architecture EPIC. En effet, prendre le code source d'un logiciel-le porter pour gérer un adressage sur 64-bit si nécessaire- et le recompiler n'offre pas toujours le meilleur résultat. Cela est d'autant plus vrai que le compilateur utilisé n'intègre qu'un nombre limité de technologies d'optimisation ou est en retard sur l'état de l'art. En effet, il faut constamment garder à l'esprit que le compilateur est un composant fondamental de l'architecture EPIC et qu'il a pour vocation de permettre l'évolution de l'architecture tout en retardant le besoin de modifier sa composante matérielle.
Mais comme tout outil, aussi évolué soit-il, le compilateur n'est hélas pas en mesure de réaliser des miracles sur tous les codes, et particulièrement sur les plus mal conçus. En effet, puisque le processeur ne prend plus en charge la recherche de l' ILP et exécute les instructions dans l'ordre exact dans lequel le compilateur les a programmées (à l'exception des lectures en mémoire générées lors de la résolution des défauts de cache de second niveau qui sont, elles, réordonnées), les erreurs de conception algorithmiques et d'implémentation s'expriment de façon patente. Les techniques d'optimisation sont nombreuses et ne seront pas couvertes dans ce document (Niar et Tayeb 2005).
Comme nous le verrons plus loin, l'architecture EPIC, avec les dernières moutures du processeur Itanium, profite aussi des technologies SMT et CMP. Il nous semple intéressant de
présenter une technologie intermédiaire puisqu'elle permet aux applications de bénéficier de certains avantages du parallélisme sans pâtir de la difficulté de mise en œuvre. Des recherches menées par Intel Corporation utilisent le phénomène de pré-chargement- prefetch - induit par la technologie SMF (Wang, et al. 2004). L'idée repose sur la création d'un thread délinquant
(delinquent thread) pour épauler un thread de calcul (worker thread) en induisant le
pré-chargement des données dans les mémoires caches. Cela s'applique aux constructions logicielles qui mettent quasi-systématiquement en défaut les algorithmes des unités de pré-chargement matérielles. Il s'agit par exemple des indirections multiples, qui peuvent être isolées dans un
thread délinquant par le compilateur, et dont l'exécution est programmée en amont de celui du thread de calcul. Les accès en mémoire ainsi isolés seront fautifs - ce qui est recherché ici - et
initieront le pré-chargement des données. Pendant l'exécution du programme, le thread de calcul et son thread délinquant sont liés aux processeurs logiques d'un même processeur physique. Avec le processeur ltanium -la plateforme de cette étude-, la méthode est rendue possible grâce à la présence des PAL- Processor Abstraction layer- et SAL- System Abstraction layer. Le
PAL et le SAL sont normalement associés aux mécanismes de détection, de confmement, de
correction et de publication d'erreurs matérielles. Ils permettent également la configuration des processeurs- sans intervention du système d'exploitation (SE). Ainsi, un mécanisme ultra-rapide de changement de contexte a été implémenté dans le PASISAL du processeur Itanium 2. Là où le
SE requiert environ 500 cycles d'horloge (variable en fonction de la latence de la mémoire
centrale) pour effectuer un changement de contexte, l'implémentation expérimentale procède à l'entrée et à la sortie du nouveau contexte en 32 cycles d'horloge. Le prototype améliore ainsi les performances des applications testées (SGBDR essentiellement) de l'ordre de 8-20%. Cela est possible, rappelons-le, sans exiger la modification du SE. Le PAL et le SAL s'avèrent être des auxiliaires précieux pour l'ajout de nouvelles fonctionnalités, comme pour la fonction de
lock-step des cœurs du processeur Montecito qui permet l'exécution simultanée du même flot
d'instructions par deux cœurs (Figure 3).
L'ensemble des travaux que nous avons effectué dans le cadre de cette étude a été conduit sur des processeurs ltanium 2 de première génération (9 Mo de mémoire cache de troisième niveau, cadencés à 1,8 GHz). Pour autant, et pour conclure ce rapide survol de l'architecture EPIC, nous allons donner un aperçu de la feuille de route de la famille Itanium. Ainsi, la prochaine mouture de l' Itanium (nom de code Tukwi/a- Figure 2) devrait normalement être disponible lorsque vous lirez ces lignes. En plus des fonctionnalités introduites avec
Montecito, (la technologie Pellston pour invalider dynamiquement des lignes de cache
défectueuses; la technologie Foxton offrant des fonctions d'économie d'énergie avancées; le
Lock-stepping des cœurs déjà citée), Tukwila bénéficiera de la technologie d'interconnexion QPI (Quick-Path Interconnect). Celle-ci permet le remplacement des bus frontaux partagés et
d'offrir, en conjugaison de contrôleurs mémoire intégrés, la bande passante mémoire et inter-processeurs qui font aujourd'hui défaut à ce processeur. Nous avons mis en annexe une présentation détaillée de l'architecture EPIC. Le lecteur pourra s'y référer pour y trouver les explications que nous avons éliminées du corps du texte pour en faciliter la lecture.
La réponse EPIC
Figure 2- Sur cette image de la die du processeur Tukwila, nous voyons clairement les quatre cœurs symétriques, ainsi quel 'arbitre d'accès au bus en position centrale. Nous voyons nettement la prédominance des mémoires cache (30 Mo au total- 2 milliards de transistors). Source : Intel Corporation.
Figure 3 -En comparaison, le processeur ltanium ::! avec 9 Mo de mémoire cache de
second niveau semble ... petit. Il n 'intèf:,rre pourtant pas moins de -/.10 millions de transistors, là
où le Montecito embarque 1 Î20 000 000 transistors (gravé en 90 mn). Source :Intel Corporation.
3.
réponse CMP
Là où l'architecture EP IC n'a pas rencontré le succès commercial escompté en dehors de son marché de niche (remplacement des serveurs RISC), la technologie du Chip Mu/ti Processor ( CMP - aussi désigné par les noms Mu/ti-Core et Afany-Core) remporte un franc succès. En effet, CMP nous semble être LA réponse retenue par 1' industrie du semi-conducteur pour résoudre le problème décrit par Pollack. Il s'agit d'utiliser le budget de transistors d'un projet de développement de microprocesseur, non plus pour la conception d'une puce monolithique, mais plutôt de le fragmenter pour graver plusieurs cœurs plus ou moins simplifiés et spécialisés
-La réponse CMP
qui sont interconnectés par un un-core. Le tout étant fait de façon modulaire pour apporter un
maximum de flexibilité et répondre ainsi rapidement et de façon économique aux besoins de performance et de fonctionnalité de chaque segment visé.
Ainsi, la prochaine génération de processeurs fondus par Intel Corporation - nom de
code Nehalem - intègrera quatre cœurs et un un-core essentiellement composé d'interfaces
d'interconnexion QPI et des contrôleurs de mémoire dédiés (Figure 7). En réutilisant certains de
ces mêmes composants, les processeurs Dunnington seront composés de six cœurs tout en
conservant la précédente technologie d'interconnexion de bus partagés (Figure 6). Comme nous l'avons évoqué plus tôt, la famille des processeurs Itanium bénéficie également de la technologie
CMP, notamment depuis l'introduction du Montecito (Figure 2 et Figure 3). Tukwila offrira
quatre cœurs physiques et huit cœurs logiques avec l'usage du SMI'.
La technologie CMP va se développer considérablement dans les années à venir. Ainsi, le véhicule de développement Tera-Scale d'Intel Corporation (FIGURE 4) intègre quatre-vingt processeurs élémentaires (PE) fonctionnels dans la même puce (10 x 8). Tera-Scale n'a pas pour
vocation de devenir un produit commercial, mais permet d'étudier et d'explorer les problèmes posés par l'interconnexion des cœurs. En effet, la topologie retenue pour assurer les communications entre les cœurs a une influence importante sur les performances. La topologie retenue utilise un réseau de routeurs. Chaque routeur a cinq ports : quatre ports pour assurer la connexion avec les routeurs voisons (N, S, E, 0) et un cinquième port pour envoyer ou recevoir les données vers 1 ou duPE (Vangal, et al. 2007).
Figure 4- Au centre de cette image nous voyons les quatre-vingt cœurs du véhicule de développement Tera-Scale. Source : Intel Corporation.
Le futur processeur graphique d'Intel Corporation (nom de code Larrabee) utilisera pour sa part un anneau d'interconnexion pour assurer l'échange des données entre ses cœurs (Abrash 2008). Ceux-ci, dont le nombre n'est pas officiellement arrêté - et sera très probablement variable -, sont des processeurs de la classe Pentium (P6) augmentés d'unités vectorielles spécialisées. Ils disposent également de la technologie SM!' et sont privés de la logique d'exécution désordonnée (Figure 5). Ce dernier point est remarquable, car non seulement cela permet d'adapter l'architecture du processeur aux spécificités des traitements requis par le
pipeline graphique, mais en plus, cela permet de réduire considérablement la quantité d'énergie
consommée par le processeur de l'ordre de 25%- à l'instar du processeur Atom (Gerosa, et al. 2008). En comparaison des circuits graphiques spécialisés classiques, Larrabee innove en reprenant l'ISA x86 et permet l'exécution des threads des programmes sur n'importe lequel de ses cœurs.
Figure 5 - Topologie en anneau pour l'interconnexion des cœurs du processeur Larrabee. Source : Intel Corporation.
Avec un nombre de cœurs croissants et des topologies d'interconnexions variables, les programmeurs vont faire face à de nouveaux problèmes. En plus des difficultés de parallélisassions évidents -que nous couvrirons plus loin - ils auront à faire face au problème de la qualité de service (QoS). En effet, à l'instar des réseaux, il sera nécessaire d'instaurer des priorités au sein du trafic de données inter-cœurs. Par exemple, pour assurer la fluidité de 1' affichage de séquences vidéo, Larrabee lui réserve une fraction de la bande passante de l'anneau d'interconnexion. Si cette solution est statique, le problème se pose de façon plus aigüe avec les architectures plus généralistes. Ainsi, Ravi Iyer et Al. (Iyer, et al. 2007) explorent la mise en place au niveau de la logique des mémoires caches et du réseau d'interconnexion d'un mécanisme de QoS fondé sur un mécanisme complexe de défmition de la priorité, des ressources requises et de la performance ciblée pour chaque tâche.
La réponse CMP
Figure 6 - Sur cette image de la die du processeur Dunnington, nous voyons les trois groupes de deux cœurs. Source : Intel Corporation.
Figure 7-Sur cette image de wafer de processeurs Nehalem, nous voyons les quatre
4.
La réponse Virtualisation
La virtualisation des processeurs et du matériel plus généralement a été introduite dès les
années soixante par IBM pour ses mainframes de la série 360. L'objectif était de multiplexer l'utilisation du matériel qui était très coûteux. Cependant; la virtualisation est un terme générique qui désigne des concepts très variés. Si nous devions dégager un dénominateur commun à toutes ces technologies, ce serait l'abstraction (Tayeb 2008) Dès lors, il est aisé de comprendre pourquoi le mot virtualisation peut légitimement s'utiliser dans une vaste palette de concepts. Prenons quelques exemples de virtualisation couramment utilisés. Le premier niveau d'abstraction- et probablement le plus important- est celui du système d'exploitation (SE). En effet, l'une des définitions possibles pour le SE est: «Une couche logicielle qui permet l'abstraction du matériel et offre une interface standard aux logiciels applicatifs ». En effet, le programmeur n'a au final que peu d'intérêts pour les registres matériels à utiliser pour piloter un modèle spécifique de disque dur par exemple. Ce qui leur importe en revanche, c'est de pouvoir effectuer leurs entrées-sorties avec leur langage de programmation de prédilection et que le matériel se comporte comme cela est spécifié par les standards. Cela s'applique aussi aux librairies qui peuvent accéder aux routines de bas niveau proposées par le SE. Ce dernier dispose d'ailleurs de sa propre couche d'abstraction matérielle (HAL- Hardware Abstraction Layer).
Les développeurs sont d'ailleurs rompus au concept d'abstraction. Dès le début des années soixante-dix, le langage de programmation Pascal a démocratisé le concept de P-Code,
un pseudo-code généré par le compilateur puis exécuté par un runtime. Celui-ci n'est autre qu'une machine virtuelle dont le P-Code est le langage machine - qui utilise une pile d'évaluation - et qui est traduit en binaire natif à la volée sur la plate-forme d'exécution. L'avantage de cette technique est d'isoler le frontal ainsi que le générateur de code du compilateur du matériel, rendant le portage de Pascal d'une plate-forme à une autre trivial. Seul
le runtime devant être réécrit C'est cette même technologie qui est à l'œuvre dans les
environnements de développement Java de Sun Jvficrosystems et .NET de ,\!icrosoft Corporation.
Ainsi, un langage de programmation et un environnement de développement standardisé sont utilisés pour concevoir des applications qui sont interprétées ou compilées dans un langage intermédiaire. Ce code intermédiaire est alors exécuté par une machine virtuelle (la machine virtuelle de Java - JVA1 -, le Common Language Runtime - CLR - ou encore Parrot) .. NET
pousse l'abstraction un degré plus loin en autorisant les compilateurs de différents langages de programmation à générer du code pour la CLR en ciblant le langage intermédiaire de Microsoft
Corporation (lv!SIL). L'écriture d'un compilateur devient par ce biais une tâche elle aussi
abstraite.
Supposons à présent que nous disposions déjà d'un binaire natif pour une architecture donnée- l'ISA et le SE. Supposons aussi que nous voulions l'exécuter avec un couple !SA/SE
différent de celui pour lequel il a été généré. Pour ce faire, nous devons normalement recompiler le code source de l'application - ce qui peut exiger des efforts considérables en termes de portage et d'optimisation des performances. Si cela s'avère être impossible, alors l'autre solution qui s'offre à nous consiste à utiliser un traducteur binaire. Un tel traducteur décodera le binaire et en traduira à la volée les instructions vers le jeu d'instructions du processeur cible. Il existe plusieurs traducteurs binaires, dont les plus connus sont l'IA32EL, l'Aries Binary Translator,
La réponse Virtualisation
QEMU, QuickTransit ou Wabi. Signalons que l'IA32EL, conçu à l'origine par Intel Corporation
et mis à la destination des vendeurs de SE pour exécuter le code IA-32 sur les processeurs
Itanium- ce qui a également permis de supprimer le décodeur d'instructions /A-32 du processeur
et de le simplifier par la même occasion.
En poussant le concept un peu plus loin il est possible de réduire encore la taille du problème. En effet, il est possible d'ajouter au couple abstrait /SA/SE le BJOS (Basic
Input-Output System), la mémoire vive, les ROMs (Read-Only Memory), etc. Le traducteur binaire
devient alors émulateur. Par exemple, l'Ersatz-Il (DBIT 2008) ou le REV/VER-11 S (Commware Technical Services 2008) sont des émulateurs de systèmes PDP-11 complet sous Windows et
Linux. Les émulateurs sont disponibles pour pratiquement tous les systèmes - particulièrement
pour les plus anciens et dont la production a cessé. Grâce à l'évolution des performances du matériel, celui des émulateurs dépasse largement celui des systèmes originaux. Bien entendu, il existe de nombreuses solutions d'abstractions qui ont en guise de point commun celui de vouloir offrir aux programmeurs d'atteindre l'objectif énoncé par Sun Microsystems lors du lancement de son système Java d'« Écrivez une fois, exécutez n'importe où». Lorsque nous parlerons de virtualisation dans la suite de notre document, c'est à cette acceptation du terme que nous nous réfèrerons.
Nous ne détaillerons pas ici les technologies de support matériel pour la virtualisation. Toutefois, il nous semble important d'en présenter rapidement le concept puisque ces technologies deviennent de facto synonymes de virtualisation pour le grand-public (Neiger, et al. 2006). En effet, ces technologies (chez Intel Corporation VT-x et VT-i pour la virtualisation du processeur et VT-d pour la virtualisation des entrées-sorties) introduisent de nouveaux modes de fonctionnement du processeur- pour résoudre le problème de l'aliasing de ring-, de nouvelles structures internes dont la plus importante est la VMCS (Virtual Machine Control Structure), ainsi que de nouvelles instructions pour faciliter la mise au point de machines virtuelles.
Il est important de considérer la virtualisation comme une piste d'avenir pour au moins deux raisons. La première de ces raisons est purement mécanique. La majorité des développeurs et ingénieurs en informatique sont aujourd'hui formés en utilisant des langages de la classe de
Java. Ainsi, il est quasiment impossible de trouver de jeunes développeurs à même de concevoir
des programmes en langage C, sans même parler de l'assembleur ou du langage FORTRAN. Il s'agit là d'un alignement naturel sur les attentes du marché, puisque les entreprises d'édition de logiciels ont rapidement vu les nombreux avantages qu'ils pouvaient en tirer à juste titre. Autre indice de cette omniprésence, le nombre croissant de projets de validation de machines virtuelles
Java dans des segments jusque-là dominés par le langage C. Parmi ceux-ci, nous pouvons citer
les systèmes embarqués haute performance, les télécommunications et les services financiers. En plus d'exiger des machines virtuelles et des compilateurs dynamiques de plus en plus performants - responsabilité qui échoit aux éditeurs de machines virtuelles et aux fondeurs de processeurs-, ces segments ont un autre point en commun: celui d'avoir des contraintes fortes sur les temps de latences. En plus d'être courts, ces temps de latences doivent être déterministes, une prouesse dont les machines virtuelles de première génération sont bien incapables. Nous voyons ainsi apparaître par exemple des ramasse-miettes (garbage collector) déterministe chez les principaux vendeurs de machines virtuelles (BEA Systems, IBM, etc.) ainsi que le regains
d'intérêt et de projets pour l'optimisation des architectures de processeurs pour l'exécution efficace des machines virtuelles.
La seconde raison qui justifie, à notre avis, l'intérêt porté à la virtualisation est que les éditeurs de logiciels peinent à tirer profit du degré de parallélisme accru qui est offert par les plates-formes modernes. Et ce, d'autant plus que le parallélisme est devenu le choix premier pour les fondeurs afin d'augmenter les performances des processeurs tout en restant fidèles à la loi de
Moore. Ceci est actuellement le problème majeur que l'industrie du logiciel doit impérativement
résoudre. En effet, si jusqu'à présent un programmeur pouvait se contenter de ne littéralement
rien faire pour optimiser la performance de son logiciel, avec des fréquences d'horloge stables,
voire en régression, ils leur est impossible de répondre aux attentes des utilisateurs avec les recettes du passé. En effet, les clients ont étés habitués à constater 1' augmentation automatique des performances avec celui la fréquence d'horloge. Les logiciels doivent donc être parallélisés. Si cela est souvent le cas pour des secteurs très particuliers comme ceux du calcul scientifique ou celui des serveurs de bases de données, ils n'en restent pas moins l'exception qui confirme la règle. Les programmeurs doivent êtres formés à cet effet, mais plus encore, de nouvelles technologies doivent êtres développées - comme les mémoires transactionnelles- et produites en masse pour permettre la transition entre le modèle de la performance d'un thread unique à celui assuré par une multitude de threads. En attendant que cela se produise, la virtualisation (au sens émulateur) reste la seule planche de salut vraiment disponible. Ainsi, en multipliant les machines virtuelles sur les plates-formes multi-cœurs et multiprocesseurs, il est possible de pallier au manque de parallélisme de la plupart des applications sans nécessité de modifications aux codes existants. En outre, en ayant recours à la consolidation de serveurs -l'un des modèles d'usage de la virtualisation qui connait le plus grand succès à ce jour - il est aussi possible d'améliorer considérablement l'efficacité énergétique des centres de calculs.
5.
Structure du document
La suite du document est composée de quatre chapitres et d'une annexe. Le premier chapitre est consacré à la présentation de notre cache de pile pour l'architecture EPIC. Nous y introduisons notre première implémentation qui permet de conserver à même les registres des processeurs ltanium tout ou partie de la pile opérationnelle d'une machine à pile. Ainsi, pour notre démonstration, nous avons utilisé le langage FORTH qui représente selon nous le canon de la machine à pile. En plus de cette première implémentation du cache de pile qui utilise la translation binaire, nous introduisons notre première proposition de support matériel du cache de pile. Ce support a la spécificité de donner le contrôle du cache de pile matériel explicitement au seul lcgiciel, par exemple au gestionnaire de machine virtuelle ou au système FORTH comme dans notre exemple.
Dans le second chapitre, nous étendons le concept de cache de pile pour introduire notre pile matérielle et son implémentation pour l'architecture EPJC. Contrairement au cache de pile, le contrôle de la pile matérielle est implicite et échoit au seul matériel. En limitant certaines caractéristiques bien choisies de la pile matérielle, nous proposons une implémentation réaliste qui s'avère être très peut intrusive au niveau architectural. En offrant un contrôle implicite de la pile matérielle, nous pouvons l'utiliser telle-quelle avec des langages et des environnements de
Références
programmation évolués tel que le MSIL (Microsoft Intermediate Language) de l'infrastructure
.NET. En guise d'illustration, nous introduisons et évaluons notre traducteur binaire de MSIL
vers du code machine Itanium en simple passe dans le but de simplifier l'implémentation d'une machine virtuelle .NET.
Le troisième chapitre concerne la consommation de puissance. Le travail réalisé dans ce chapitre est indirectement relié aux deux chapitres précédents. Il correspond à une demande de plus en plus grande chez les utilisateurs - dont les administrateurs de centres de calculs et d'hébergement - et les administrations nationales. En effet, les processeurs qui équipent les serveurs d'entreprises et en particulier les membres de la famille Itanium ont une Thermal
Design Power (TDP - qui désigne la puissance maximale que chacun des composants du
système est autorisé à dissiper) comprise entre 75 et 104 Watts. Ceci pour les modèles de dernière génération. Nos modèles de tests ont une TDP de 130 Watts. Avec des TDP de cet ordre, il nous a semblé important d'étudier l'impact du logiciel sur la consommation d'énergie de la plate-forme. Ainsi, dans le troisième chapitre, nous présentons l'état d'avancement de cette recherche dont l'objectif principal est d'étudier et de proposer des techniques de transformation de code pour réduire la consommation énergétique des applications. Pour mener à bien nos mesures, nous introduisons une interface standard- en cours d'étude pour adoption par le Green
Grid (The Green Grid Consortium 2008) -pour instrumenter les logiciels d'entreprise. Enfin,
différentes techniques de transformation de code sont évaluées. Nous menons actuellement cette tâche dans le cadre d'un projet de recherche interne à Intel Corporation.
Dans le dernier chapitre de ce mémoire, nous présentons un bilan général des différents travaux que nous avons réalisés dans le cadre de cette thèse. Ce chapitre est l'occasion de les mettre en perspective et de décrire les projets que nous souhaitons mener à bien au cours des prochaines années. En particulier, nous présenterons les derniers développements autours de notre participation au comité du Green Grid, une tâche que nous poursuivrons de concert avec
Intel Corporation.
Notre annexe propose pour sa part deux sections. La première est destinée à la présentation détaillée de 1' architecture EP IC et des processeurs Itanium 2. Le rôle de cette section est d'apporter les précisions nécessaires à la lecture de ce document sans pour autant en encombrer le corps du document. La seconde section de l'annexe présente pour sa part les fondamentaux de la machine - virtuelle - FORTH en détaillant le rôle et le mode de fonctionnement de ses interpréteurs et de son compilateur.
6.
Références
Abrasb, Michael. «Larrabee: A Many-Core x86 Architecture for Visual Computing.»
International Conference on Computer Graphies and Interactive Techniques archive. Los
Angeles, California: ACM SIGGRAPH, 2008. Article No. 18.
Commware Technical Services. Commware Technical Services. 8 Septembre 2008. http://www.comwaretech.com/PDP-11/PDP-11-emulator.html (accès le Septembre 8, 2008). DBIT. DBIT. 8 Septembre 2008. http://www.dbit.com/ (accès le Septembre 8, 2008). Domeika, Max, et Jamel Tayeb. Software Development for Embedded Multi-core Systems: A Practical Guide Using Embedded Intel Architecture. Elsevier, 2008.
Gerosa, Gianfranco, et al. <<A Sub-I W to 2W Low-Power lA Processor for Mobile Internet Deviees and Ultra-Mobile PCs in 45nm Hi-K Metal Gate CMOS.» IEEE International
Solid-State Circuits Conference. 2008.
Iyer, Ravi, et al. «QoS policies and architecture for cache/memory in CMP platforms.» (ACM SIGMETRICS Performance Evaluation Review) 2007.
Moore, Gordon E. « Cramming more components onto integrated circuits. » (Electronics) 38, no. 8 (1965).
Neiger, Gil, Amy santoni, Felix Leung, Dion Rodgers, et Rich Uhlig. «Intel Virtualization Technology: Hardware Support for Efficient Processor Virtualization. »(Intel technology Journal) 10, n° 3 (2006).
Niar, Smail, et Jamel Tayeb. Les processeurs Itanium: Programmation et optimisation.
Paris: Eyrolles, 2005.
Ronen, Ronny, A vi Mendelson, Konrad Lai, Shih-Lien Lu, Fred J. Pollak, and John P. Shen. « Microarchitecture challenges in the coming generations of CMOS process
technologies. » 32rd Annual International Symposium on Microarchitecture - MICR0-32. 1999. 2.
Tayeb, Jamel. « Virtualization and Partitionning.» Dans Software Development for Embedded Multi-core Systems: A Practical Guide Using Embedded Intel Architecture», de Domeik.a Max, Chapter 9. Elsevier, 2008.
The Green Grid Consortium. The Green Grid. 8 Septembre 2008. http://www.thegreengrid.org/home (accès le September 8, 2008).
Vangal, Sriram, et al. «An 80-Tile 1.28TFLOPS Network-on-Chip in 65 nm CMOS. »
IEEE International So/id-State Circuit Conference. 2007.
Wang, Perry H., et al.« Helper Threads via Virtual Multithreading On An Experimental ltaniumr. » (ACM SIGOPS Operating Systems Review) 38, no 5 (2004).
Cache ·de pile pour architecture
EPIC
Résumé
Dans ce chapitre, nous étudions une utilisation novatrice des registres du processeur
Itanium 2 pour optimiser les performances des machines virtuelles. Ainsi, nous montrons qu'il est possible de cacher les piles d'évaluation des machines virtuelles à même les registres du processeur pour en améliorer sensiblement les performances. Nos expériences, menées sur notre implémentation du système FORTH, montrent des gains de performances moyens de l'ordre de 7x. Pour autant, notre implémentation purement logicielle souffre de certaines pénalités que nous proposons d'éliminer par l'ajout d'un support matériel pour accélérer l'accès indexé aux registres du processeur. Après l'étude d'une approche systématique du problème, mais difficilement implémentable de façon réaliste, nous présentons une version simplifiée mais très peu intrusive.
1.
Introduction
La virtualisation - au sens large - s'est avérée être un moyen efficace et peu couteux pour exploiter le budget de transistors toujours croissant depuis les années 70. Nous pouvons à ce titre considérer la virtualisation comme une parallélisation à très forte granularité. Ainsi, de nouvelles technologies, avec leur cohorte de nouvelles instructions, font leur apparition dans les architectures généralistes avec pour unique objectif d'améliorer les performances des machines virtuelles (R. Uhlig, et al. 2005). En multipliant le nombre des machines virtuelles, il est possible d'exploiter facilement les ressources massives des plates-formes les plus récentes. A titre d'exemple, un serveur multiprocesseurs grand public au goût du jour n'offre pas moins de 24
cœurs physiques et 48 cœurs virtuels ! Le problème essentiel est que les logiciels pouvant tirer profit d'un tel niveau de parallélisme sont extrêmement rares.
Mais les machines virtuelles amènent leur propre lot de problèmes, notamment en termes de performances. Au final, la performance d'une machine virtuelle, qui se résume à un moteur d'interprétation bâti autour d'une pile d'évaluation, dépend avant tout de son interaction avec l'architecture du processeur sous-jacent. La recherche et l'industrie explore plusieurs domaines d'investigation en ce sens. L'un d'entre eux est la mise au point de circuits spécialement conçu pour gérer directement certaines machines virtuelles (Michael O'Connor et Tremblay 1997) (Schoeberl 2005) (Imsys 2008).
Dans ce chapitre nous allons montrer qu'il est possible d'utiliser l'architecture généraliste
EPIC - Explicit Para/le/ Instruction Computer - pour arriver à un résultat comparable et
combler ainsi l'écart théorique qui sépare les circuits spécialisés et le processeur Itanium 2- un
processeur généraliste- pour ce même exercice. Nous avons fait le choix d'utiliser le processeur
Itanium 2 car il représente selon nous un bon candidat potentiel pour exécuter le code d'une
machine virtuelle efficacement. En plus des avantages intrinsèques de son architecture VLIWVery Long Instruction Word qui tend à relever le défi de l'exploitation optimale de l' ILP
-Instruction Leve! Parallelism- (Schlansker, et al. 1997), le processeur Itanium 2 intègre un vaste
champ de registres que nous utilisons de façon originale. La dernière raison de ce choix est notre expérience personnelle de plusieurs années au sein du groupe Software & Solutions d'Intel Corporation, de ce type de système.
Enfin, et en guise de machine virtuelle de référence pour cette étude, nous avons choisi le système FORTH, qui malgré son ancienneté, est l'archétype de la machine virtuelle. Le langage
ou le système FORTH - nous reviendrons sur cette distinction plus tard - a été inventé par Charles H Moore pour satisfaire ses propres besoins informatiques (Rather, Colbum et Moore
1993).
2.
Travaux connexes
La communauté FORTH a exploré les gains en termes de performance que peuvent offrir
les circuits spécialisés ou ASIC -Application Specifie Integrated Circuits. Bien que chaque
développement aie un cahier de charges spécifiques, nous pouvons toutefois dégager trois caractéristiques fondamentales pour l'ensemble des projets que nous avons répertoriés. Ces caractéristiques se retrouvent systématiquement dans les circuits dédiés les plus aboutis et les plus performants.
La première de ces caractéristiques fondamentales est l'intégration à même le processeur d'au moins deux mémoires dédiées pour conserver les deux piles essentielles de l'interpréteur
FORTH, à savoir la pile d'évaluation et la pile des retours (P. Koopman 1987) (Hayes et Lee
1988) (Schelisiek 2004) 1• Le nombre, le rôle et l'implémentation des piles intégrées au processeur est variable d'un circuit à un autre. Ainsi, le Stack Frame Computer (P. Koopman
1987), conçu pour exécuter essentiellement du code FORTH mais aussi du code généré par un
compilateur C, intègre plusieurs piles. La première implémentation proposée dispose ainsi de cinq piles. Le circuit dispose de deux bus. Le premier accède à la mémoire centrale (MEUS) et le second est dédié à l'interconnexion des piles (SBUS). Ces bus sont multiplexés et ils offrent la possibilité de lire simultanément les instructions depuis la mémoire et les données depuis les piles. L'ALU- Arithmetical and Logical Unit- dispose d'un unique registre de sommet de la
pile - TOS ou Top Of the Stack - qui agit sur la pile utilisée par l'instruction en cours
d'exécution. C'est au programmeur de s'assurer de la gestion des piles puisque le composant n'offre pas de support particulier à cet effet. Le résultat de toutes les opérations effectuées par
l'ALU est conservé dans le registre TOS qui agit comme un tampon. Le second registre de l'ALU (ALUI- ALU Input) peut recevoir sa donnée depuis l'un des deux bus (Figure 8). Parmi les huit
types de piles qu'il est possible de connecter au SBUS, les piles G et S (Global Stack et Stack)
correspondent à des piles d'évaluation. La pileR (Return) correspond à la pile de retour utilisée
pour le contrôle de flux. Le rôle des autres piles est très spécifique (L pour le compteur de
1 Nous présenterons dans la section suivante les mécanismes et les structures fondamentales du langage
Travaux connexes
boucles, P pour le compteur ordinal - utilisé pour sauvegarder les adresses de sous-programmes,
etc.). PROGRAM ME MORY .OODRESS DATA MBUS 1
...
1 1
1
CONTROl PROGRAM TOS AlUI
lOGIC COUNTER L--. ~_. &IR
"'
+
"'
AlU/
C "STACK P"STACK• SBUS,
~,
,
1 "STACK"'s
FR
l
GSTACK STACK STACK STACK STACK
VO
DEVICESFigure 8- Diagramme du Stack Frame Computer 1. Source : Stack Computers: the new wave© Copyright 1989, Philip Koopman.
La seconde caractéristique fondamentale est la présence de quelques registres dédiés à la gestion des piles. Le minimum étant un pointeur de sommet de la pile-TOS- pour chacune des
piles (d'évaluation et de retours), intégrées ou pas au processeur. Pour permettre un accès rapide aux données enfouies dans une pile, des registres supplémentaires peuvent être proposés. Généralement, en y écrivant une valeur, le matériel peut générer l'adresse de n'importe quel élément de la pile. C'est 1 'approche retenue par: les microcontrôleurs de la famille HS-RTX (Rand
,..-1 TOP : ,..-INTE RRUPT
en
..
STACK en TIMERICOUNTERS" ' T ALU
/
MEMORY PAGE REGS MULTIPLIERL A SIC BUS DEVICES
f
l
G 256WORD"'' DATArom-a _
u..._1
DATA STACKs
-
1"
••
.1 NEXT-
-
"1 1L
·-T BYTE SWAP/ 1--DATA PROGRAM y
B ... PASSTHROUGH 1 .orA ME MORY B u u
s
t
ADDRESSs
1 IR lL
1 11
1
1 +1 PC 1 1 11
r-...
.1 1 1.--
1 1r-1 -1
1 DATA RETURN DATA
256WOFm STACK
1 1
-
l SR, MD , CR l ..__Figure 9- Diagramme du HS-RTX-2000. Source : Stack Computers: the new wave© Copyright 1989, Philip Koopman.
La troisième et dernière des caractéristiques fondamentales est la faible latence d'exécution des instructions. Le plus souvent, celle-ci est d'un cycle d'horloge. Cette optimisation spécifique permet l'implémentation efficace des primitives du langage FORTH. Différentes approches sont possibles pour atteindre ce résultat. Par exemple, les premiers niveaux de la pile peuvent être cachés dans des registres directement reliés aux ALU. C'est l'approche retenue par le Writable Instruction Set Computer (P. Koopman 1987). Une autre technique consiste à combiner et superposer des cycles d'accès aux bus comme le font le
Minimum Instruction Set Computer et le FORTH Reduced Instruction Set Computer. Ce dernier
utilise des bus dédiés pour accéder dans le même cycle d'horloge au sommet de la pile et à n'importe lequel des quatre premiers éléments de la pile d'évaluation et de retour (Figure 10).
Travaux connexes
r--DATA PRO GRAM
DATASTACK
POINTER ME MORY
& CONTROL
ADDREsSI ADDRESS
L
16 W'ORDS INSTRUCTIONDATASTACK REGISTER
DATA ~
BUFFER LITE RAL FIELD
f-41
T DATAI IDATA Bu
: LATCH 1 LATCH:.._
s
-1
ZERO 1f
LSHIFT-1
B J "\._ A ALU/
A B Fl BITf
CDND Bu
...
1u
+
s
: RSHIFTI 1 LATCH~
s
RETURN STACK PO~TER & CONTROL ADDRESS' 161,/0RDS DATA RETURN STACK DATA BUFFER DATA 4USER REGISTERS PC ...._ L-.Figure 10- Diagramme du FORTH Reduced Instruction Set Computer. Source : Stack Computers: the new wave© Copyright 1989, Philip Koopman.
Le projet Open Source MicroCore est une des implémentations les plus récentes d'un microcontrôleur dédié pour le langage FORTH. Signalons cependant que le MicroCore permet l'exécution de code écrit avec d'autres langages de programmation comme le C. Cependant, c'est avec le FORTH que ce microcontrôleur se distingue, puisqu'il utilise ce langage en guise d'assembleur (Figure 11). Il intègre une pile d'évaluation et de retour et implémente directement 25 mots FORTH dont la plupart s'exécutent en un cycle d'horloge (Schelisiek 2004).
uCore
Program Me mory Retum Data Stack Memory TOR r--+---tl...- iodata Data Stack 1--...__.,..._ ioaddr -<Il- exception -<Il- intemrpt www.microcore.orgFigure 11- Diagramme du MicroCore. Source : microcore.org.
Bien que le processeur 4Stack ne soit pas implémenté (Paysan 2000), il est intéressant d'en présenter le concept dans le cadre de nos travaux. En effet, il s'agit d'une architecture VLIW - Very Large Instruction Word- qui intègre à même le processeur quatre piles d'évaluation. Il s'agit de 32 registres de 32 bits organisés en quatre groupes. Chaque groupe de registres est une pile LIFO- Last-In, First-Out (Figure 12). Chaque pile est connectée à une ALU et chaque ALU peut accéder, via un cross-bar, à n'importe quel sommet des autres piles. En revanche l'accès aux autres niveaux d'une pile n'est possible que depuis l'ALU qui lui est relié. Enfm, chaque pile dispose de son circuit de spill et de son circuit de jill dédiés pour gérer les débordements vers la mémoire centrale. Certaines opérations peuvent êtres exécutées en parallèle avec des opérations de gestion de pile, ce qui permet théoriquement au compilateur de les programmer pour une exécution simultanée pour absorber la latence de la gestion de la pile.
Contrairement aux autres processeurs spécifiques que nous avons présentés jusqu'ici,
4Stack n'a pas pour vocation d'exécuter préférentiellement le langage FORTH. Cela est bien
entendu possible, faille-t-il encore réécrire le système FORTH. Cela est essentiellement dû au fait que pour exploiter le parallélisme de l'architecture VLIW, il faut utiliser les quatre piles simultanément. D'une façon générale - et à l'instar d'autres architectures VLIW - la responsabilité d'extraire des instructions indépendantes depuis le code source des applications échoit ici aussi aux compilateurs. Cette tâche, bien qu'ardue, n'est pas insurmontable. Mais avant tout, il faudrait défmir ce que peut apporter le parallélisme d'instruction- ILP (Instruction Leve!
Parallelism) - au langage FORTH, sujet qui n'est pas couvert par les concepteurs de cette
Travaux connexes
1
1
~ou 11 Al.;,
1l Al.:;;-
1l Alçq
00 1l
DA-r"" DA17!Hob
: : !NsmuCTlON DECode : ;
--- ----:---:---
___ , , __---:---
--~---, 1 1 1 1 1!--:_-_-_-_-_-_-_-.---
:_-_----~---_-_-_-_-_-_-_-_-_-_-_-:_-_-_-_-:_-_-_-_-_-_-_-_-_-_-_-:_---~-------.
~-1 1 ' ' ' ' ' 1 , 1 r: : :+1__ FPLATCH FPAOD FPI..ATCH ~ : l
1 L 1
l
1 : : DSPUNJT : :l
~-----.
:--- ---{
l
1~
i _ l l _ i
~~
1 ' 1 S4 'x
1 RO N l F RO N l F DATA R1 N L F UNITO R2 N L F R3 N l F lFILli J.sPIU til )> ::tl FllLJ 1SPIUJ UNIT 1 DATA R2 N L F R1 N L F
R3 N L F ~ ~
.
'TT
1 ' ' '---·
=
1~'"~
r----1---<t--' --- _________ j ____ .!._ __ \!
-<---- ____
s,...
~ FPlATCH DSP UNIT 1 FPMUL DATA CACHE "'Figure 12 -Diagramme du processeur 4Stack
1 1 ' '
·---FPLA TCH_jE-~~~
V:
li 12MIIT Îi
: O-BUS ~!
- - - --i-----t'---i
! 1Pour conclure notre présentons des circuits spécialisés, il nous faut nécessairement introduire la famille des microcontrôleurs MuP21 d' UltraTechnology. Cette architecture a été
conçue par Moore et Chen-hanson Ting (Ting et Moore 1995). Le microcontrôleur F21, la dernière génération de la famille MuP21 intègre en plus du processeur FORTH un circuit de
génération de signal vidéo et un circuit d'entrée-sortie série et parallèle (
Figure 13). La pile d'évaluation de la dernière mouture dispose de 18 niveaux. La pile de retour dispose pour sa part de 1 7 niveaux. Les codes d'opérations sont encodés sur 5 bits, ce qui permet de regrouper 4 instructions par mot et découpler ainsi l'exécution des instructions des accès en mémoire. Les instructions ne sont pas exécutées en parallèle mais bien de façon sérielle. Le registre Test Je TOS dont Je contenu est empilé dans S. L'ALU opère pour sa part sur les registres Tet S. Le processeur dispose enfin d'un compteur ordinal et d'un registre d'adresse (les adresses étant codées sur 20 bits - plus 1 bit pour la retenue et 1 ou la sélection de page
d'adresses). La Table 1 résume les principaux avantages et les inconvénients de ces circuits spécialisés. Ni No Ai Ao Vi Vo RG Ci ++++++++++++++ ... 1
Para.llel Port I/0 8 to 14 Digital bits
1
Data Control
-
~
N otwmldn 1 CouoldoM> Clook 1 !control 1~
• N etwork out DMA
f+
Routex: INetwol:k CPU Interrupt 1
-i-l A/DS-bitllcountdownClock 1 icontroll
~
~
•
D/AS-bitl1 CPU Interruptlnstx:uction 1
-i-l AID4-bitll Video Clock 1 icontroll ~
..
•
D/A4-bit 1T
1B ~ CPU lnt.errupt Instx:uction
1 Real Tim.e Clock 1 1 Echo T im. er 1
T t -t s Rse CPU 'PC
:::;
A R...
1PARAMETER STACK REGISTERS ( 16)
1
1
RETURN STACK REGISTERS (16)
1 1 ON CHIP ROM 1 Hemory Control Homepaqe Speed DP.AH RAS .. CAS,. WE * SP.AH/ FLASH/ ROH SRAM .. ROM,. Addre:ss Data AO-A19 ... DO-D19"'
Figure 13 -Diagramme du processeur F21. Source : ultratechnology. co m.
1+
...
1+
...
1+
...
..
~Parallèlement à la conception de circuits spécifiques, la communauté FORTH a également cherché à optimiser l'exécution du langage sur des processeurs généralistes. Bien qu'il s'agisse cette fois-ci d'optimisations logicielles, le principe fondamental reste identique. Il consiste à cacher un nombre plus ou moins important de niveaux de la pile d'évaluation et éventuellement de retour dans les registres du processeur. Cette mise en cache peut se faire de façon statique ou dynamique lors de l'exécution du code (Ertl et Gregg 2004). Bien que l'efficacité de ces techniques dépende de la nature des codes exécutés, les auteurs obtiennent des gains de performance de l'ordre de 4x en moyenne. En revanche, il est intéressant de constater
