Multicœurs et Manycœurs - IME-USP

CRI’2013
Multicœurs et Manycœurs
Une Analyse de la Performance et l’Efficacité Énergétique
d’une Application Irrégulière
Márcio Castro*—Emilio Francesquini* + —Thomas Messi Nguélé* - —
Jean-François Méhaut* x
*Nanosim - Laboratoire Informatique de Grenoble – Université de Grenoble, France
Email: [email protected]
+Institute of Mathematics and Statistics – Université de São Paulo, Brésil
-LIRIMA-UMMISCO, Département d’Informatique, Université de Yaoundé 1, Cameroun
xCEA/DRT/LETI, France
RÉSUMÉ. Les études sur la performance et l’efficacité énergétique sont nombreuses dans le cas
des multicœurs mais rares dans le cas des manycœurs. Contrairement à ces études, dans cet ar-
ticle, nous analysons un problème NP-complet irrégulier bien connu, le problème du voyageur de
commerce. Nous étudions deux aspects de cette application sur un processeur multicœur et un pro-
cesseur manycœur: d’abord l’adaptation du code à un manycœur (MPPA-256), puis l’analyse des
performances de calcul et la consommation d’énergie. Nos résultats montrent que les applications ca-
pables d’utiliser pleinement les ressources d’un manycœur peuvent avoir de meilleures performances
comparées à celles d’un processeur généraliste tout en consumant environ 10 fois moins d’énergie.
ABSTRACT. Research on the performance and the energy efficiency of numerical kernels on multi-
cores are common but studies in the context of manycores are scarce. Unlike these works, in this
paper we analyze a well-known irregular NP-complete problem, the Travelling-Salesman Problem
(TSP). We investigate two aspects of the application on multi and manycore processors. First we
concentrate on the adaptation of the application to a manycore (the MPPA-256 processor) then we
analyze its performance and energy consumption. Our results show that applications able to fully use
the resources of a manycore can have better performance than a general purpose processor and at
the same time consume 10 times less energy.
MOTS-CLÉS : Processeurs Multicœurs, Processeurs Manycœurs, Performance de calcul, Efficacité
Énergetique, TSP
KEYWORDS : Multicore Processors, Manycore Processors, Performance, Energy Efficiency, TSP

1. Introduction
La demande en processeurs de plus en plus performants pousse les fabricants de puces
à combiner les approches telles que l’augmentation de la taille des caches, du parallélisme
d’instructions et de la fréquence des processeurs. Cependant, ces approches semblent
avoir atteint un point où elles ne suffisent plus pour maintenir la croissance de la per-
formance prédite par la loi de Moore et attendue par les consommateurs [6]. Une aug-
mentation exponentielle de la puissance consommée liée à une augmentation linéaire de
la fréquence d’horloge [2] et une grande complexité de conception des nouveaux pro-
cesseurs a changé le cours du développement de ces nouveaux processeurs. La puissance
consommée est devenue un aspect essentiel pour le développement des systèmes à petite
et grande échelle. Ceci peut justifier les études actuelles sur l’usage de processeurs de
faible puissance dans la prochaine génération des systèmes HPC. Par exemple, le projet
européen Mont-Blanc a été créé pour évaluer l’usage de ces types de composants dans un
environnement HPC [8]. Bien que n’offrant pas les mêmes performances de calcul que
leurs homologues généralistes, ces multicœurs de faible puissance offrent généralement
de meilleurs résultats quand on compare l’énergie dépensée pour trouver une solution
(energy-to-solution).
Les processeurs parallèles actuels vont même encore plus loin, avec des centaines
voire des milliers de cœurs, tout en ayant une consommation efficace d’énergie. Certains
de ces manycœurs comme Tilera Tile-Gx [12] et Kalray MPPA-256 [3] ont des cœurs
autonomes qui supportent le modèle d’exécution threads POSIX (PThreads) et pouvant
ainsi faire la parallélisation des données et des tâches. Ceci peut faciliter le passage d’une
application parallèle des multicœurs aux manycœurs, car plusieurs applications parallèles
développées pour les multicœurs s’appuient sur ce modèle. Par contre, les GPUs (Gen-
eral Processing Units) suivent une autre approche basée sur le modèle SIMD (Single
Instruction, Multiple Data) qui s’appuie sur des APIs comme CUDA et OpenCL. Un ef-
fort considérable peut donc être nécessaire pour adapter le code parallèle développé d’un
multicœur vers un GPU.
Les recherches sur l’efficacité énergétique et les performances de calcul des pro-
cesseurs généralistes et des processeurs de faible puissance sont assez fréquentes [9, 11].
Cependant, dans le cadre de ces travaux, nous nous intéressons à l’analyse du passage des
multicœurs aux manycœurs en utilisant un problème irrégulier et NP-complet bien connu :
le problème du voyageur de commerce. Avec une instance assez grande (20 villes), sa so-
lution peut être parallélisée et faire usage d’un nombre arbitraire de threads assurant l’util-
isation complète des plates-formes choisies. Bien que ce problème soit très parallélisable,
il soulève des questions importantes liées au déséquilibre de charge et à l’irrégularité.
Le reste de cet article est organisé comme suit. La Section 2 décrit les plates-formes
évaluées. Une description de haut niveau du problème choisi ainsi que ses algorithmes
sont présentés dans la Section 3. Ensuite, la Section 4 aborde les défis rencontrés lors du
passage des multicœurs au manycœur MPPA-256. La Section 5 présente les évaluations
de perfomance de calcul et d’efficacité énergétique. Enfin, nous discutons des travaux
connexes dans la Section 6 et concluons dans la Section 7.
2. Plates-formes
Dans cette étude nous avons utilisé deux plate-formes. La première est composée d’un
processeur multicœur généraliste et la deuxième est composée d’une puce manycœur à
basse consommation. Nous les présentons ci-dessous.

Xeon E5.Le processeur Intel Xeon E5 est un processeur x86-64 64-bit. Dans cette
étude, nous avons utilisé une puce Xeon E5-4640 Sandy Bridge-EP, qui dispose de 8
cœurs (16 threads avec l’Hyper-Threading activé) cadencée à 2.40GHz. Chaque cœur
dispose de deux caches L1 (un d’intructions de 32Ko et autre de données de 32 Ko) et
d’un cache L2 de 256Ko. Tous les 8 cœurs partagent un cache L3 de 20 Mo et la plate-
forme a 32 Go de mémoire DDR3.
MPPA-256.Le MPPA-256 [1, 3] est un processeur manycœur développé par Kalray
qui intègre 256 cœurs utilisateurs et 32 cœurs système dans une technologie CMOS de
28nm. Ces cœurs sont répartis sur 16 clusters de calcul et 4 sous-systèmes d’E/S (cluster
d’E/S) qui communiquent à travers deux NoCs (Networks-on-Chip) de données et de
controle.
Figure 1. Une vue simplifiée de l’architecture du MPPA-256.
La Figure 1 montre l’architecture générale du MPPA-256. Il possède deux types de
cœurs : PE (Processing Elements) et RM (Resource Managers). Les PEs et les RMs sont
regroupés au sein des clusters de calcul et les clusters d’E/S. Chaque cluster de calcul
comporte 16 PEs, 1 RM et une mémoire locale partagée de 2 Mo. Les applications par-
allèles s’exécutant sur MPPA-256 suivent habituellement le modèle maître/esclaves. Le
processus maître fonctionne sur un RM du cluster d’E/S et il est responsable de la créa-
tion des processus esclaves. Ces processus sont ensuite exécutés sur des clusters de calcul
et chaque processus peut créer jusqu’à 16 threads POSIX, un pour chaque PE.
3. Étude de Cas : Le Problème du Voyageur de Commerce
Le problème du voyageur de commerce (Traveling-Salesman Problem, TSP), consiste
à trouver l’itinéraire d’un voyageur de commerce qui doit se déplacer dans nvilles. Un
tel itinéraire doit être le plus court possible, passant une seule fois dans chaque ville et
se terminer par la ville d’origine. C’est un problème NP-complet très bien étudié. Le
TSP pourrait être modélisé avec un graphe non orienté complet G= (V, E),|V|=noù
chaque arête (i, j)∈Ea un coût c(i, j)≥0représentant la distance entre les villes i
et j. Le but est de trouver un cycle hamiltonien avec un coût minimal. Il existe plusieurs
approches de la résolution de ce problème [5]. Ici, nous utilisons un algorithme de force
brute exact, basé sur une heuristique très simple.

Algorithme séquentiel. La version séquentielle de l’algorithme est basée sur la méth-
ode de séparation et d’évaluation (branch and bound). Cet algorithme prend en entrée
le nombre de villes, et une matrice de coût, et retourne la longueur du chemin mini-
mal (min_path). Il a une complexité de O(n!) dans le pire des cas. Il n’explore pas
les chemins plus long que le meilleur chemin déjà rencontré, il écarte donc les branches
inutiles. Cette technique d’élagage améliore considérablement les performances de l’al-
gorithme mais introduit également des irrégularités dans l’espace de recherche. La pro-
fondeur de la recherche nécessaire pour parcourir une des branches dépend de l’ordre
dans lequel les branches ont été fouillées.
Algorithme multi-threadé. Ici, on a créé une file d’attente de tâches (branches de
recherche) à partir de laquelle chaque thread prend les tâches à exécuter. La génération des
tâches se fait de manière séquentielle car le temps nécessaire pour le faire est négligeable.
Dès qu’un thread se retrouve sans tâche, il prend une nouvelle tâche dans la file d’attente.
Le nombre de tâches qui doivent être générées change en fonction du nombre de threads
et est défini par le paramètre max_hops (le nombre minimum de niveaux de l’arbre de
recherche). Le nombre total t(l, n)de tâches en fonction des niveaux let des nvilles peut
être déterminé par la relation de récurrence suivante : ∀l∈[0, n[,t(l, n) = 1 si l= 0 et
t(l, n) = t(l−1, n)∗(n−l)sinon.
Algorithme distribué. Cet algorithme reçoit comme paramètre supplémentaire le
nombre de postes n_postes à utiliser. Pour chaque poste, n_threads threads sont créés,
donc on a un total de n_threads ∗n_postes threads. Dans chaque poste, l’exécution est
similaire à celle du cas multi-threadé. La seule différence est que, lorsque le min_path
est mise à jour dans un poste, cette mise à jour est diffusée à tous les autres postes afin
qu’ils puissent aussi l’utiliser pour optimiser leur exécution. À la fin de l’exécution, un
des postes imprime la solution. Chaque poste poste_id ne travaille que sur les tâches qui
lui ont été assignées. Pour ce faire, nous définissons le nombre de tâches (regroupées en
partitions) par poste. Lorsque les postes sont à court de tâches, ils demandent d’autres
partitions au poste maître. Pour réduire le nombre de communications, le poste maître en-
voie des partitions de taille décroissante à chaque demande [7]. En effet, comme les tailles
des tâches sont irrégulières, la distribution d’un nombre de plus en plus petit de partitions
vers la fin de l’exécution pourrait réduire le déséquilibre de charge entre les postes. Dans
ce cas, pour chaque demande, le poste maître envoie un ensemble de partitions Set le
poste poste_id travaille sur des tâches telles que task_index mod n_partitions ∈S.
Comme la génération des tâches se fait au niveau local, la quantité de données transférées
peut être minimisée.
4. Adaptation du TSP à une Plate-forme Manycœur
Nous avons présenté dans la section 3 un aperçu des algorithmes de résolution du TSP.
Toutefois, les différences architecturales entre les plates-formes multicœur et manycœur
nous obligent à faire des adaptations du code. Dans cette section, nous discutons des
adaptations effectuées avec le cas particulier du manycœur MPPA-256.
La bibliothèque Pthreads est installée sur les deux plates-formes testées. Dans la ver-
sion multi-threadé du code, min_path est implémenté en utilisant une variable partagée
qui est accessible par tous les threads. Les opérations d’écriture sur cette variable (c.a.d.
quand un thread trouve un chemin plus court) sont protégées par un verrou pour éviter les
situations de compétition. Contrairement aux opérations d’écriture sur cette variable, les
opérations de lecture ne sont pas protégées pour que le parallélisme ne soit pas limité.

Malheureusement, cette solution n’est pas appropriée à la plate-forme MPPA-256, car
les PEs ne possèdent pas des mémoires caches cohérentes. La prise de verrou par le PE qui
réalise la mise à jour de min_path a comme effet secondaire l’invalidation de sa mémoire
cache. Toutefois, les lignes de cache des autres PEs du même cluster qui stockent cette
variable ne sont pas invalidées. Ainsi, les threads s’exécutant sur les autres PEs utilisent
l’ancienne valeur stockée dans min_path pendant une longue période de temps et perdent
du temps sur des branches stériles de l’arbre de recherche.
Pour corriger cela, nous avons utilisé des instructions spécifiques de la plate-forme
(__builtin_k1_lwu et __builtin_k1_swu) qui permettent un accès direct à la mé-
moire locale du cluster, contournant ainsi la mémoire cache. Ce mode de lecture coûte
nettement plus cher que d’utiliser la valeur stockée dans les caches (l’accès à la mémoire
locale coûte 8 cycles alors que l’accès à la mémoire cache coûte 2 cycles). Toutefois,
l’amélioration des performances due à un bon élagage de l’arbre de recherche l’emporte
largement sur ce coût supplémentaire. Du fait de la non existence d’une mémoire glob-
ale partagée entre clusters de calcul, nous avons utilisé la version distribuée du TSP. Les
échanges de messages asynchrones entre clusters prennent la forme d’opérations d’écri-
ture sur une mémoire distante. En raison du temps nécessaire pour diffuser une nouvelle
valeur de min_path, certains threads peuvent utiliser une valeur erronée pour un laps de
temps jusqu’à ce que l’émission soit terminée.
5. Résultats Expérimentaux
Dans cette section, nous présentons l’évaluation des performances de calcul et de l’-
efficacité énergétique des plates-formes lors de l’exécution des versions parallèles et dis-
tribuées du TSP. Nous commençons par présenter notre méthodologie de mesure ainsi que
les métriques utilisées pour analyser les résultats (Section 5.1). Ensuite, nous comparons
les performances énergétiques et de calcul des processeurs (Section 5.2).
5.1. Méthodologie de Mesure
Nous utilisons deux indicateurs pour comparer les performances énergétiques et de
calcul des deux processeurs : time-to-solution et energy-to-solution. La métrique time-
to-solution désigne le temps passé pour trouver une solution à un problème donné. Dans
notre cas, il s’agit du temps global d’exécution du TSP parallèle/distribuée. La métrique
energy-to-solution est la quantité d’énergie dépensée pour parvenir à résoudre un prob-
lème. Elle peut être calculée en multipliant la puissance moyenne (en watts) consommée
lors de l’exécution de l’application par la métrique time-to-solution.
La puissance consommée par chaque processeur a été obtenue en utilisant deux ap-
proches bien similaires. Le Xeon E5 a une microarchitecture Intel Sandy Bridge, qui a des
capteurs d’énergie RAPL (Running Average Power Limit). Cela nous permet de mesurer
la consommation d’énergie au niveau des composants du processeur à travers des reg-
istres spécifiques de la machine (en anglais Machine-Specific Registers, MSRs). Nous
avons utilisé cette approche pour obtenir la consommation d’énergie de l’ensemble du
package CPU, c.a.d., l’ensemble des cœurs et la mémoire cache. La puissance moyenne
consommée par le Xeon E5 a été de 68,6W. Les mesures de puissance à l’aide de cette
approche sont très précises, comme indiqué dans [10, 4]. De même, le MPPA-256 com-
porte des capteurs pour mesurer la puissance électrique consommée de la puce entière,
c.a.d., 16 clusters de calcul ainsi que les 4 sous-systèmes de clusters d’E/S. La puissance
moyenne consommée par le MPPA-256 a été de 10.7W