Bonjour à tous et merci d'être venus aussi
nombreux aujourd'hui pour m'écouter finalement
raconter pendant une très courte période
de temps ce que j'ai fait
les six dernières années.
(C'est de nouveau en train de s'éteindre.)
Je vais commencer très vite.
À l'agenda : trois points que j'ai envie
de partager avec vous.
La première chose,
c'est dans quel domaine je travaille.
Quel est le problème que j'ai essayé
de résoudre et vous donner une intuition
de l'approche
que j'ai prise pour le résoudre.
Ensuite je vais vous présenter
mes contributions.
Quelques morceaux bien choisis
et la déclaration de ce qu'est réellement
ma thèse de doctorat.
Et vous parler des
directions futures potentielles
de la recherche dans ce domaine.
Commençons directement par le domaine.
Donc :
les ordinateurs.
On les connaît bien, ils ont des écrans :
laptops, PC de bureau, tablettes...
Mais il y en a beaucoup plus
que ce qu'on entend par ordinateur.
Il y en a tout autour de nous.
Ils font partie de notre vie quotidienne,
on interagit avec eux.
Sauf qu'on ne les appelle pas "ordinateur"
parce qu'on ne voit pas l'écran,
le clavier et la souris.
Mais l'ordinateur est "embarqué"
à bord du dispositif et de l'objet.
Ça veut dire que...
On me regarde toujours de travers
quand on me demande :
"Tu travailles dans quoi ?"
- "Dans l'embarqué !"
- "Oui... C'est quoi l'embarqué?"
En fait c'est simple :
ce sont des ordinateurs dans des objets,
qui sont cachés dans des objets.
Le problème que je veux résoudre
par rapport à ces ordinateurs embarqués,
en fait vous le connaissez.
Avec ce logo, tous les jours on a le téléphone,
la batterie qui est plate.
Le laptop, ou la tablette.
Ce problème s'applique non seulement
à l'informatique mobile que vous avez,
mais aussi aux voitures.
Une voiture consomme
une certaine quantité d'énergie
due au nombre de systèmes embarqués
qui sont dans la voiture.
J'ai mis beaucoup de points rouges
sur la voiture.
Enfin Quidos, notre ami
qui a fait cette présentation.
Ça veut dire qu'il y a *beaucoup*
de systèmes embarqués
dans une voiture.
Entre 100 et 200 cartes de ce type.
Ça ressemble à cela,
un système embarqué.
Une carte où sont soudés
des composants électroniques
reliés par des pistes métalliques
avec beaucoup de connectique.
J'ai la version à l'échelle ici,
si vous voulez la faire passer.
C'est sur ce genre de systèmes
qu'on travaille.
Je peux remplacer
la voiture par le téléphone.
Vous démontez votre téléphone,
vous voyez quelque chose de ce genre.
Donc un système embarqué,
on peut de façon "un peu abstraite"
le résumer
à ses composants électroniques :
un processeur qui fait des calculs,
une mémoire
qui sauvegarde le résultat de ces calculs
et les programmes qu'il contient,
des dispositifs d'entrées/sorties
comme un écran ou des boutons...
Et dans le cas des systèmes embarqués
qui sont autonomes : une batterie.
Je vais remplacer ici le téléphone
par la façon applicative de voir les choses.
C'est un système d'exploitation.
C'est une analogie ici.
Je ne travaille pas avec Android
mais Android est un système d'exploitation
qui permet l'exécution d'applications
que vous utilisez tous les jours,
comme les mails, la messagerie,
l'appareil photo.
Chacune de ces applications va solliciter
des composants du matériel.
Que ce soit pour enregistrer
des photos dans la mémoire,
accéder à l'appareil photo,
décompresser une vidéo, c'est un calcul
qui va aller dans le processeur.
Ceci est vrai pour l'informatique mobile,
et aussi pour l'informatique embarquée
où les applications sont des tâches
avec des contraintes temporelles.
Et le système d'exploitation pourrait être
par exemple, HIPPEROS.
Les différentes tâches et le système vont
solliciter les composants matériels.
Ces composants matériels,
chaque fois qu'ils sont sollicités,
ils drainent un peu de batterie.
Ils consomment un peu
de la ressource énergétique à disposition.
Chacun contribue
à la consommation d'énergie.
Jusqu'à arriver à ce moment fatidique
où le dispositif s’éteint
parce qu'il n'y a plus d'énergie.
Ma batterie, je vais quand même
la recharger pour cet exposé.
Et je vais vous demander
le temps de cet exposé
d'imaginer qu'une batterie est un ensemble
de cellules énergétiques
qu'on va pouvoir utiliser
pour réaliser un certain travail.
Donc on prend *une* cellule énergétique.
Elle va permettre d'exécuter
un certain travail
comme par exemple "YouTube",
une vidéo à décompresser,
c'est un travail,
ça demande une certaine énergie
et ça prend un certain temps.
On a donc cet ensemble
de cellules énergétiques.
Et on veut planifier pour voir
si on a assez de ressources
pour exécuter
les travaux qu'on doit exécuter.
Donc on représente le temps
par une flèche : cette abscisse.
En imaginant qu'on a un curseur
qui en fonction du temps,
progresse sur ce graphe.
On va donc planifier
la dépense énergétique
en fonction du temps de notre batterie.
Donc ici,
les deux premières unités de temps
j'ai décidé de dépenser
une cellule d'énergie
pour exécuter un travail qui correspond
à une unité de travail.
Troisième instant, je veux exécuter
un peu plus de travail.
Donc je dois aller plus vite
et consommer plus d'énergie.
L'idée étant :
plus on consomme de l'énergie
plus on est capable d'exécuter du travail
rapidement.
Ici trois, deux, on redescend, pendant un
instant on décide de s'éteindre
parce qu'on a rien à faire.
Et on remonte.
On a dépensé tout notre budget énergétique
pour effectuer ces deux travaux ici
qu'on peut voir sur le slide.
On a donc défini plus ou moins
ce qu'est un *travail*.
Dans mon domaine, on lie beaucoup
les travaux à des échéances.
C'est-à-dire que soit on dit :
"Je fais mon travail,
je fais du mieux que je peux,
j'irai au plus vite
mais je ne vous dis pas quand j'aurai fini."
Ou on dit : "J'aurai fini dans 10 jours,
10 heures, 10 minutes, 10 millisecondes."
On représente les travaux
par ces petits carrés
de cellules énergétiques,
et les échéances par ces croix rouges.
On va simplement se demander
quelles sont les échéances
des différents travaux qu'on doit exécuter.
Ce premier travail, ici,
quelle est son échéance ?
Je la place sur ma ligne du temps.
Le second travail ?
Je le place également sur ma ligne du temps.
Quand j'ai décidé d'exécuter
ces différents travaux,
je vois qu'ils ont été terminés
avant leur échéance.
Cela veut dire que je suis à temps
et que ma fonctionnalité
est bien correcte (temporellement).
Si on avait décidé d'exécuter
un travail un peu moins vite,
donc ne pas dépenser
trois cellules d'énergie
mais deux,
on aurait été en retard.
Et quand on est en retard,
on rate une échéance.
Dans les systèmes embarqués,
rater une échéance
peut avoir des conséquences
catastrophiques.
Il faut penser aux systèmes
montrés au début,
avec les petites bulles rouges.
Les avions, ils ont tout un système
où ils doivent interagir
avec des phénomènes réels,
donc ils doivent donner leur décision...
Imaginons par exemple un auto-pilote
doit donner sa décision à temps.
Pareil pour l'ABS d'une voiture,
ou l'airbag...
Si l'airbag se déclenche 10 minutes
après l'accident, ça risque de poser
quelques petits soucis de sécurité.
Il faut donc s'assurer qu'on exécute
tout le travail à temps,
avant la fin de l'échéance.
Donc je vous dis : "Si on dépense
toute l'énergie avant... c'est bon."
Cela semble un peu rapide, un peu facile.
Alors pourquoi on ne dépense
pas tout au début.
On dépense le maximum et on est bien à temps,
on peut s'endormir le reste du temps.
Cette technique existe,
ça s'appelle "race-to-idle".
On peut traduire ça par
"la course vers l'oisiveté".
Malheureusement... cela nécessite de déployer
une certaine *puissance*.
Puissance qui est limitée.
Chaque dispositif a une limite,
pourquoi y a-t-il une limite ?
Je représente la limite
par cette barre rouge.
Parce que si on dépense trop d'énergie
à un moment donné, le système va chauffer
et on va avoir des problèmes d'utilisation
ou des problèmes de fonctionnement...
le device peut fondre.
Personne ne veut utiliser un téléphone
qui lui brûle l'oreille.
Ou, il faut penser aussi au chien
avec son collier.
On n'a pas envie non plus
que le pauvre toutou se blesse.
Alors on va utiliser race-to-idle
à la limite,
donc on va essayer de dépenser
un maximum d'énergie
le plus vite possible et terminer le travail.
J'aimerais revenir sur cette question
de "aller plus vite,
dépenser plus d'énergie
pour exécuter plus de travail".
Il faut imaginer qu'à l'intérieur
du système embarqué, on a un levier,
à l'intérieur du processeur,
qui nous permet de dire
en fonction de à quel point
j'actionne ce levier,
je vais travailler de plus en plus vite,
exécuter de plus en plus de travail,
et consommer de plus en plus d'énergie.
On pourrait appeler ce levier "la vitesse",
mais pour des raisons historiques
on a préféré appeler cela "la fréquence".
Quand vous entendez
que votre processeur a une fréquence
à un certain nombre de
MegaHertz ou de GigaHertz,
c'est la vitesse à laquelle
grosso modo il est capable
d'exécuter des programmes.
L'augmentation de la fréquence est donc régie
par cette limite dont je vous parlais.
Mais je n'ai pas été
tout à fait correct avec vous.
J'ai dit que "l'énergie" égale "le travail".
Ça c'est faux.
On peut très bien passer beaucoup d'énergie
à ne faire aucun travail.
Donc je vais représenter le travail
par un autre type de carrés.
Ce sont les carrés jaunes
avec le W pour "work".
Et on va devoir échanger
des cellules d'énergie
contre du travail accompli.
Donc, à gauche l'énergie,
à droite le travail.
C'est plus ou moins la même chose
mais pas tout à fait.
L'énergie c'est le coût,
ce que ça va vous coûter, c'est limité,
vous avez une batterie.
Le travail c'est l'application utile :
ce que vous voulez faire,
ce que l'utilisateur
a envie d'avoir.
Quand on utilise le levier...
c'est ici que ça se complique un peu.
J'utilise le levier pour doubler ma vitesse,
en fait je dois payer
quatre fois plus d'énergie.
Donc, doubler la vitesse demande
un coût quadratique par rapport au travail.
L'énergie coûte le carré du travail.
Ça c'est dans certaines plate-formes,
dans d'autres, c'est encore pire.
Ça peut être le cube.
Donc c'est en fonction du matériel
sur lequel vous vous exécutez,
entre le carré et le cube.
Un exemple, pour fixer les idées.
J'ai un petit exercice.
L'objectif est d'exécuter
dix unités de travail,
on a donc nos blocs jaunes.
En sept secondes.
On remet notre ligne du temps
avec l'échéance
au début de la huitième seconde.
Et on veut minimiser l'énergie consommée
donc utiliser le moins possible
de petites cellules vertes.
Comment on va faire ?
Donc je vais mettre d'un côté le travail
et de l'autre l'énergie.
Donc ils sont connectés.
Chaque barre *verticale*
représente un instant dans le temps.
En haut le travail et en bas l'énergie.
Je place mon échéance sur le travail
pour être sûr que je finis à temps.
Donc la première solution : j'exécute
à la vitesse nominale de ma plate-forme.
Ce n'est pas acceptable, je n'ai pas fini
mon travail avant mon échéance.
Cela me coûte une énergie de 10.
On va supposer que là où on commence
(à la vitesse nominale)
on a une unité de travail
= une unité d'énergie.
Donc je peux doubler : la première solution,
j'utilise mon levier et je double la vitesse.
Donc à chaque instant j'ai dû consommer
quatre cellules d'énergie.
Cela me fait au total une énergie de 20.
Par rapport à la solution précédente
qui était inacceptable,
on a doublé le budget énergétique
de l'application.
Mais on est OK pour notre échéance.
Qu'est-ce qu'on peut faire ?
Il y a deux petits "slots" ici
dans lesquels
on pourrait déplacer du travail...
on a une
certaine flexibilité.
Je peux dire : "Je vais actionner
mon levier dans l'autre sens.
diminuer la vitesse, une fois
que j'aurai exécuté six unités de travail."
Mais comme je freine,
j'aurai récupéré de l'énergie,
et je suis quand même toujours à temps.
J'ai gagné 20% d'énergie.
Pour résumer la première solution
où on utilise tout le processeur
au double de sa vitesse,
on utilise 20 unités d'énergie.
Et dans le cas où on freine un petit peu,
on utilise 16 unités, 20% de moins.
Dans le cas où c'est cubique,
la situation est encore pire,
parce qu'on consomme
40 unités d'énergie dans le premier cas
et 28 dans le second.
On réduit l'énergie consommée de 30%,
avec la même technique.
J'aimerais revenir sur ce levier.
En fait le levier c'est, en pratique,
un programme qui s'exécute
dans le système d'exploitation
de l'ordinateur.
C'est un pilote qui permet de modifier
la fréquence du processeur.
Ça peut s'exécuter dans Android
ou dans HIPPEROS.
C'est une des choses qu'on a dû faire
pour nos expériences,
on a dû écrire un programme
qui change
la vitesse d'exécution du processeur.
Les trente dernières années,
les processeurs...
non pas les trente dernières années
en fait...
Avant les années 2000,
les processeurs étaient mono-cœur.
Ils pouvaient exécuter
un seul programme à la fois.
Le degré de liberté qu'on avait,
c'était ce fameux levier
qui change la vitesse.
Donc on a un travail, on ne peut exécuter
qu'un seul travail à la fois.
Qu'est-ce qu'on fait ? On essaye de tirer
sur ce levier de plus en plus,
de repousser la limite de plus en plus loin.
Mais à un moment, ce n'est plus possible.
Le processeur est trop chaud,
il faut trouver une autre solution.
Donc les concepteurs de processeur
se sont dit :
"OK... on va prendre une autre approche,
on va faire en sorte de pouvoir exécuter
plusieurs programmes en même temps."
Plutôt que de réduire, changer ce levier,
on a un "nouveau levier",
un nouveau degré de liberté qui dit "comment
je vais répartir mes différents programmes
en parallèle sur ma plate-forme".
Et là je peux exécuter
quatre unités de travail en parallèle,
sans que ça ne me coûte...
beaucoup plus en énergie (16).
Donc si je reprends, avec le parallélisme,
le coût énergie-travail est linéaire,
plus ou moins.
C'est plus compliqué que ça en pratique
mais je ne vais pas rentrer dans les détails.
Et si on reprend
le même exercice que précédemment,
on a plus ou moins dix unités d'énergie
qui sont consommées,
pour un travail où on a utilisé
les quatre processeurs (cœurs)
pendant deux unités de temps.
Puis on a exécuté
les deux unités de travail restantes
sur deux processeurs (cœurs).
Vu qu'on a fait cela, maintenant
on peut combiner les deux approches.
On peut tirer sur le levier
dans l'autre sens.
Parce que si on double la vitesse,
ça fait x4 en coût énergétique,
on peut aussi diviser par 2 la vitesse,
et on divise par 4 le coût en énergie.
Donc on arrive à -50% d'énergie consommée
sur cet exemple très simple.
Alors le problème que j'essaye de résoudre,
"théorique" c'est :
étant donné ces deux degrés de liberté,
ces deux leviers,
et une charge de travail qui m'est imposée
par mon utilisateur qui a ses échéances,
je dois trouver la façon
dont je joue avec ces leviers
pour réduire au maximum
la consommation d'énergie.
Donc voilà, j'ai couvert ma thèse, on dirait.
On peut prendre le titre et voir,
est-ce que j'ai tout couvert ?
"Systèmes embarqués" ?
Voilà, des ordinateurs... pas d'écran.
"Hard real-time", donc "temps réel dur":
on veut exécuter, c'est le domaine
où on veut exécuter le travail
avant l'échéance.
Les métriques de performances :
on a des batteries,
on a une certaine vitesse d'exécution.
On utilise du "parallélisme matériel"
parce qu'on utilise
les plate-formes multi-cœur.
C'est de l'optimisation parce qu'on diminue
on a un levier,
on diminue de 20, 30, 50% la consommation.
OK, il manque quelque chose :
"Software parallelism".
C'est à mon sens le plus grand défi.
C'est que les applications
puissent elles-mêmes être écrites
pour s'exécuter simultanément
sur plusieurs cœurs du matériel.
Mais je vais y revenir plus tard.
Voilà donc c'est tout pour l'intuition.
Maintenant je vais parler
de ma thèse et des contributions.
Je vais raffiner parce que jusqu'à présent,
j'ai parlé de travail
de façon abstraite, et d'énergie.
Je raffine un peu.
Maintenant il faut oublier
les blocs de couleur
parce qu'il y a d'autres blocs de couleur.
Donc on a un ensemble de tâches,
qui veulent être exécutées en même temps.
Qui vont générer du travail.
Le travail va être ordonnancé
sur la plate-forme,
par le mécanisme qui se trouve
entre le matériel
et les applications :
c'est le système d'exploitation.
Traditionnellement, un système d'exploitation
contient un ordonnanceur
qui va *séquentiellement*
exécuter le travail.
J'ai un travail de type jaune,
de "tâche jaune",
je l'exécute en entier
sur le premier processeur.
Pareil pour le rouge, l'orange, et le bleu.
Donc on continue, en parallèle, à exécuter
des tâches de natures différentes.
Le but reste de réduire l'énergie consommée.
Et on se rend très vite compte que le fait
qu'on exécute *séquentiellement* limite
les gains d'énergie qu'on peut obtenir
parce qu'on doit toujours être capable
d'exécuter le job le plus gros,
le travail le plus gros.
Etant donné qu'on ne peut pas le diviser
sur les processeurs, on doit au moins donner
la vitesse et la puissance pour exécuter
le plus grand des travaux (à temps).
L'autre idée c'est de permettre le fait qu'on
prenne ces travaux générés par des tâches
et qu'on les exécute en parallèle.
Donc là les unités jaunes,
qui juste quelques slides avant,
étaient sur le même processeur
s'exécutent en même temps
(sur différents cœurs).
Ça permet en tout cas d'augmenter la vitesse
d'exécution des différents travaux,
et peut-être d'avoir
de meilleures contributions
à la consommation d'énergie.
La question de recherche c'est :
"Est-ce qu'on peut mieux réduire ?
Est-ce qu'on peut avoir
de meilleurs gains énergétiques
si on parallélise les tâches ?
Est-ce qu'on peut, du coup conserver
les contraintes temporelles de ces tâches ?"
Donc ma déclaration, ce que je dis moi,
dans ma thèse, c'est :
"Le parallélisme *aide* à faire cela,
il aide à réduire l'énergie consommée,
et il permet tout en diminuant
l'énergie consommée, de garantir
les mêmes contraintes temporelles
qui étaient données à la base.
Voilà, ça semble être un fait comme ça.
Donc le travail,
fait pendant presque six ans,
était de prouver cela de différentes façons.
Donc j'ai choisis
trois types de contributions
dont je veux vous parler aujourd'hui.
La validation théorique de la thèse.
Donc on peut prendre toutes ces notions
de processeur, de temps, de jobs...
mais c'est beaucoup plus simple
si on enlève ces détails d'implémentation,
et qu'on se dit : "En fait,
tout ce que j'ai, ce sont des blocs."
Je prends un bloc qui représente un travail.
Sa hauteur, c'est le nombre de cœurs
sur lesquels il est assigné
et sa longueur,
c'est son temps d'exécution.
Si je décide d'augmenter sa hauteur,
ça va réduire sa longueur,
parce que j'alloue
plus de cœurs au travail.
L'aire de ce rectangle représente
ce qui est nécessaire à exécuter
pour faire mon travail.
Le système d'exploitation peut décider
pendant l'exécution du travail
de changer la hauteur du rectangle
et d'un coup lui dire :
"Voilà je veux t'assigner
plus de processeurs,
moins de processeurs et en fonction de cela,
tu dois être capable de réagir
et d'exécuter
plus ou moins vite les tâches."
Et on a aussi toujours le même levier dont
je vous parlais au début de la présentation
qui permet de dilater les tâches
parce qu'on réduit la fréquence,
donc elle prend plus de temps à s'exécuter
mais consomme moins d'énergie.
Donc avec toutes ces contraintes :
des tâches à deadlines implicites
qui sont sporadiques,
les jobs qui sont malléables
dans tous les sens,
des plate-formes multi-cœurs
desquelles ont peut changer la fréquence,
et un algorithme
d'ordonnancement de la littérature,
on a trouvé un algorithme
qui permet de déterminer
la fréquence minimum telle que le système
reste ordonnançable pour ses tâches
et minimise la consommation de courant.
On a simulé ce modèle mathématique,
sur deux paramètres.
Le nombre de cœurs qu'on a, donc la quantité
de parallélisme qu'on peut mettre.
Et l'utilisation ou la charge
totale applicative qu'on veut exécuter.
On se rend compte
que si on augmente les deux,
en fait on augmente très fort les gains
potentiels qu'on peut avoir.
Donc ça c'est : on a validé l'idée théorique
que ce que je vous raconte
depuis tout à l'heure, est vrai.
Mais on veut encore s'assurer
que si on fait cela sur des vrais systèmes,
une implémentation qui tourne
dans un vrai système embarqué,
ce soit vrai aussi.
Pour ça on a commencé par écrire
un nouveau système d'exploitation.
Pour une chaîne de dépendances,
on se rend compte
que c'est mieux
si on écrit tout par nous même.
Donc si on se remet dans le contexte
en 2006, les OS pour l'embarqué
avaient peu de considération
pour les architectures multi-cœur.
Les noyaux tels qu'ils existaient
ne passaient pas à l'échelle
si on augmentait le nombre de cœurs
et encore moins en terme de prédictibilité.
Ils n'intègrent pas
les contraintes temporelles
et la consommation de l'énergie
de façon où c'est facile d'échanger
(travail et énergie),
en pratique, ce n'était pas le cas.
Et il y a un très grand écart
dans l'ordonnancement
entre ce qui se fait
dans la recherche académique
comme algorithmes avancés
et ce qui est exécuté effectivement
dans les plate-formes
faites dans l'industrie.
Partant de ces quatre constats,
plusieurs chercheurs
se sont mis ensemble à l'ULB.
Un dans le Département Informatique.
L'autre dans BEAMS (polytechnique).
L'un qui est spécialisé en formalisation
de systèmes temps réel.
Et l'autre en conception
d'architectures électroniques.
On va mettre ces connaissances ensemble.
D'un côté la théorie
et de l'autre côté le matériel.
Et on va concevoir
un nouveau système d'exploitation,
incluant l'écriture d'un nouveau noyau.
Là je fais le raccourci... on va se servir
de ce noyau pour la thèse d'Antonio.
L'idée c'est que on a aussi un système
qui peut exécuter des tâches temps réel, etc.
Et on a les mécanismes dont je vous parle
c'est-à-dire le parallélisme,
le fait qu'on peut exécuter
des tâches sur plusieurs cœurs.
Une tâche peut s'exécuter
sur plusieurs cœurs.
Et le levier de changement de fréquence.
Maintenant qu'on a tous les outils en main,
on a validé théoriquement,
on a un OS comme plate-forme.
On peut faire des expériences et vérifier
que ce que je dis s'applique en pratique.
Donc j'ai construit
une plate-forme expérimentale,
qui commence par une carte embarquée
comme j'ai fait passer...
Au dessus de la carte, on exécute un système
d'exploitation avec des bibliothèques
HIPPEROS.
Et sur cet OS,
on fait tourner une application parallèle.
C'est le point challenging
dont je vous parlais au début,
en vous disant "c'est compliqué".
C'est quoi une application parallèle ?
C'est une application
où on ne doit pas écrire
séquentiellement les instructions
mais on accepte
qu'elles s'exécutent potentiellement
en parallèle sur plusieurs cœurs et ça
pose des problèmes de conception
notamment de difficultés à débuguer
son programme.
On a utilisé OpenMP, qui est un ensemble
de librairies et d'interfaces,
qui permet en théorie,
de faire ça simplement.
Un programme OpenMP ressemble à quoi ?
Ça c'est une tâche.
... Qui permet
plus ou moins automatiquement
de générer des threads d'exécution
qui vont s'exécuter en parallèle.
L'avantage ici, c'est qu'on a une boucle.
En fait la boucle représente
un certain travail,
en général, et dans ce cas-ci, elle
représente le gros du travail de cette tâche.
Le fait que cette boucle peut s'exécuter
en parallèle va grandement améliorer
le temps d'exécution
et l'énergie consommée du système.
Donc comment ça se passe en pratique ?
C'est une vue imagée de ce qui se passe.
On commence par un fil d'exécution "maître".
Donc ici.
Qui commence à faire son travail.
Puis on arrive,
dans l'exécution du programme, à la pragma.
A ce moment là, le fil d'exécution
se multiplie... ou se fourchette,
en plusieurs.
Il y a plusieurs "worker threads"
qui sont responsables d'exécuter
les itérations de la boucle.
En particulier, c'est ici qu'on passe
le plus de temps.
Et ensuite on se rejoint.
Il n'y a plus qu'à nouveau que le maître,
qui a survécu, pour finir son exécution.
Ceci est la façon dont dans la thèse on
a implémenté le parallélisme des tâches.
On a écrit plusieurs types de programmes
qui ont la même structure.
Un programme qui calcule Pi,
ça peut toujours être utile.
Un programme qui fait
du chiffrement symétrique AES.
Et un programme
qui fait du traitement d'image,
qui applique un certain filtre sur une image
donnée en entrée.
La plate-forme qu'on a choisie,
c'est celle que j'ai faite passer,
c'est la SABRE Lite...
J'aime bien ce nom.
Elle a une architecture Cortex A9.
La plate-forme est supportée par HIPPEROS.
Il y a quatre cœurs.
Et on a implémenté le programme qui permet
de faire le levier de fréquence.
Donc il y a tout ce qu'il nous faut
pour faire des expériences.
Pour le fameux levier en fait, pour rentrer
un petit peu plus dans les précisions :
il se définit en définissant le voltage
de la plate-forme et sa fréquence.
Pour un certain voltage donné,
on a un maximum de fréquence.
L'ensemble des possibilités se situe en fait
dans les points
qui sont dans le plan jaune ici.
Donc le plus intéressant, c'est de prendre
les points qui sont sur la limite.
Pour chaque point de voltage, on prend
le maximum de la fréquence.
C'est ce qui va effectivement avoir
un impact sur la puissance consommée.
Donc la puissance consommée
est proportionnelle
au carré du voltage
multiplié par la fréquence.
Et en fait ici on retrouve le fameux cube
de tout à l'heure parce que le voltage
est lui-même proportionnel à la fréquence.
Donc c'est le cube dont je vous parlais
au tout début.
On a notre plate-forme expérimentale
mais on veut encore ajouter
des outils de mesure, sinon
comment on va faire pour savoir...
OK on a un système embarqué
qui tourne tout seul,
mais on doit encore savoir
à quel point il exécute
et à quel point il consomme de l'énergie.
On va mettre une petite résistance en série
entre mon système et l'alimentation.
Et on va brancher un oscilloscope.
L'appareil que vous avez vu
et que vous pouvez voir ici.
Et un PC, un laptop avec tout le build system
d'HIPPEROS qui va tourner et contrôler
ce qui se passe autant sur la plate-forme
que sur l'oscilloscope,
pour récupérer les données.
Voilà ce à quoi ça ressemble en pratique.
L'oscilloscope appartient
au Département Informatique.
Ça c'est une pièce du NO3 où j'ai passé
pas mal de temps
à récolter
des résultats d'expériences.
Donc, qu'est-ce qu'on obtient
quand on utilise l'oscilloscope ?
On obtient une trace qui dit :
"Ça c'est le voltage qu'il y avait
autour de la résistance en fonction du temps,
pendant quatre secondes ici."
Donc moi je traduis ce voltage en puissance
consommée, en graphe qui me donne
le nombre de Watts en fonction du temps.
On voit bien ici qu'il y a
un espèce de plateau puis que ça redescend.
Ça veut dire qu'il y avait une tâche
qui s'exécutait, qui a tiré de la puissance
de la plate-forme, et puis quand ça s'est
terminé, le système s'est mis en mode
"basse consommation"
parce qu'on avait terminé le travail.
Donc cet écart ici va représenter
le temps d'exécution de ma tâche.
La hauteur va représenter
le pic de puissance.
Grosso modo à chaque instant,
quelle est la quantité d'énergie consommée.
Donc l'aire sous cette courbe, si j'intègre
va me donner l'énergie totale consommée.
On a fait ça avec des systèmes dont la charge
varie entre 60% et 300%.
On est en multi-cœur
donc on peut faire plus que 100%.
Pour différents degrés de parallélisme.
J'ai accepté 1 thread, 2 threads,
3 threads, 4 threads.
Ce qui m'a permis de voir à quel point
augmenter le parallélisme
dans mes applications va me permettre
de réduire l'énergie consommée.
Le système d'exploitation applique
sa gestion d'alimentation habituelle.
On exécute tous les systèmes
qui sont ordonançables
et on mesure les résultats
avec notre plate-forme expérimentale.
Finalement, voilà un des résultats principaux
de ma thèse.
On voit ici dans la légende...
En ordonnée c'est l'énergie totale consommée
par mon système.
Et en abscisse il y a différentes charges,
donc quand on augmente
la quantité de travail, simplement.
On voit que la version séquentielle,
donc la version traditionnelle
est celle qui dans quasiment tous les cas,
à part ce petit point ici,
consomme plus d'énergie.
Et on voit aussi que plus on diminue...
En tout cas que le maximum
de gains énergétiques
est obtenu quand on parallélise au maximum,
quand on augmente le plus possible
le degré de parallélisme.
Donc sur ce graphe le problème c'est que
c'est très fortement influencé
par la quantité de charge.
On voit que ça augmente très fort.
J'ai repris les mêmes données et je les
ai dessinées de façon relative
à la version séquentielle.
Et là, c'est très net, on arrive jusqu'à
presque -25% d'énergie consommée
pour des systèmes de tâches
générés aléatoirement
avec des caractéristiques aléatoires
et des workloads aléatoires.
Cela peut encore être amélioré si on raffine
le système manuellement.
J'espère que, avec cette présentation,
je vous ai convaincus que le parallélisme
permet effectivement de réduire
l'énergie consommée
tout en maintenant
les contraintes temporelles.
Dernier point, les directions futures.
Voilà, une thèse de doctorat, en théorie
ça dure 4 ans.
Dans mon cas,
c'était un petit peu plus long que ça.
L'avantage c'est que
quand on a plusieurs années,
on peut prendre de l'altitude et réfléchir
au problème qu'on attaque avec plus de recul.
Donc je vais un petit peu partager avec vous
ma vision.
Pour concevoir un système embarqué
ou même un programme qui s'exécute sur le PC,
aujourd'hui, on fait ça :
on écrit pour la machine un code
dans un langage de haut niveau,
comme le C... comparé à l'assembleur.
Et on décrit le fonctionnement attendu
en termes fonctionnels
et pas en termes non-fonctionnels,
pas en terme de contraintes énergétiques
et temporelles.
La communauté "temps réel" travaille depuis
des dizaines d'années
à faire en sorte qu'on puisse spécifier
le comportement temporel des tâches,
donc on dit :
"pour cette tâche utile, finalement, je veux
provisionner maximum 3 millisecondes".
Je dis "ceci doit s'exécuter en maximum
3 millisecondes".
Donc il y a énormément de recherche
qui se fait dans cette direction.
Avec la thèse, j'ai rajouté
une dimension en plus.
J'ai dis : "le 'useful_work'
tu vas l'exécuter
en maximum 3 millisecondes
et en maximum 3 millijoules".
Et si on veut aller encore plus loin, il faut
prendre ce problème de façon on va dire
"vectorielle" c'est-à-dire qu'on peut
spécifier autant de contraintes qu'on veut
sur autant
de dimensions qu'on veut.
Ça c'est la direction future car
je ne me suis pas attaqué au problème
de la température
par des limites de temps.
"Je veux exécuter en 3 millisecondes,
en 3 millijoules
et avec maximum 2 degrés d'augmentation
de la température de la plate-forme
ce 'useful_work'en question".
Donc quand on spécifie ça à un compilateur,
qu'est-ce qui se passe ?
Il va prendre du temps, beaucoup de temps
pour réfléchir si c'est possible.
Puis il va dire OK ça marche,
avec la plate-forme que tu as choisie,
cela va fonctionner.
Ou alors, il va dire "non, ça ne fonctionne
pas, tu dois allouer 2 cœurs supplémentaires
pour que tes contraintes soient satisfaites,
pour que je puisse exécuter ceci
en respectant cela".
Voilà, merci de votre attention,
c'est terminé.
Des questions ?
Yves Roggeman :
Je vais faire un petit message
à destination du public.
Ceci est la soutenance publique
mais nous avons eu tous les membres du jury
l'occasion de lire
des textes, des textes, des textes,
finalement une version finale.
Et aussi d'avoir eu
une très longue après-midi de discussions.
Alors comme nous sommes tous présents
et comme l'un des membres
ne s'exprime pas facilement
en Français,
nous allons faire comme
lors de la soutenance privée:
poursuivre la séance de questions en anglais
pour permettre à chacun
de pouvoir re-dialoguer.
So I will continue in English.
Maybe we shall start with the questions
from the members of the Jury.
- You start ?
- [Juan M. Rivas] OK.
[Juan M. Rivas]
First of all, I congratulate you on your work
but also your presentation today,
I think you are very good
in presenting this kind of complex idea
in very simple ways.
Even myself I understand
with my poor level of French.
I have to congratulate you on that.
[Antonio]
That's the Turing test right?
[Juan M.Rivas]
Oh yeah actually.
I did understand pretty much everything.
So I have two questions basically.
The first one is a little bit technical,
I'm going to ask you.
You didn't talk about this
in this presentation today
but my question is about the kernel,
the master/slave idea in the kernel.
So you have your schedule,
you run the scheduler in the master core,
even when you have
the partitioned schedule.
So when there is no migration
and everything like that.
Why is it beneficial to do that
in this kind of partitioning schedule?
[Antonio] OK. So first of all,
just in order for everyone to understand.
In order to implement the kernel,
we did an asymmetric architecture.
That means that we put on one core
that is dedicated to the scheduling
and the heavy operations.
And the other cores,
that are called the "slave cores"
are actually served by the "master"
when they ask for example a system call,
the master will answer accordingly,
possibly executing the scheduling
and ordering context switches
on the different cores.
So the question was: "why in partitioned
scheduling is this beneficial?".
[Juan M. Rivas] Yes,
or why do that with partitioned scheduling
because you are going to have
some interferences between different cores
that are maybe not necessary.
[Antonio]
So the first obvious reason is that
it is easy to *vary* the scheduling indeed
to go to partitioned to global scheduling
with such a design.
It is part of the cost that you pay
to be able to say
"OK I implement all possible scheduling
policies, but we have some drawbacks".
That said, I am not convinced today
that the symmetric approach,
even for partitioned scheduling
will be more efficient
than the master/slave architecture.
because you will always suffer
from interferences for other things
for example the shared resources
that we have when we access the memory.
That is the kind of things
that you cannot avoid
either in the symmetric
or the master/slave architecture.
[Juan M. Rivas]
Good answer.
You mentioned now that for your thesis
you worked 5.5 years
and I'm sure you had many problems
during these years,
things that you had to solve.
Can you talk about those problems?
The main problems, how did you solve them...
[Antonio]
There are so many!
[Juan M. Rivas]
Also if you had to start your thesis today,
what would you do differently?
[Antonio]
Mmh... differently...
It is not easy because at that time
we didn't have such a knowledge
about kernel architecture
and everything
to be able to do whatever we want.
Ideally now I would take the kernel
as it is and tweak it directly
to have some good benchmarks,
some good measurements.
Start by doing, by building an experimental
stack that would allow me
to iteratively get
a lot of results faster
because here the really difficult thing
is that at the beginning we had nothing.
We had to work, work, work, ... until we get
"something" now we can start to imagine
a paper that is *practical*...
So I think I would go for the iterative flow,
that may be better.
[Yves Roggeman]
So we will continue
with another member of the Jury.
Philippe?
[Philippe Millet]
OK. Thank you.
So first of all I need to congratulate you
also for the work.
Your thesis is very nice to read.
There is a lot of information.
And just like with your presentation,
you can explain very simply complex problems.
And this is a good capability that you have.
So back on the work of your thesis:
you have done a lot of work to show
that it is very difficult
to take into account power management
inside the operating system
at the very beginning
of the design of the operating system.
I would like...
... There are some particularities
to the programming model
with the temperature
and the power consumption.
Do you think there is something more
for the operating system?
What would be the next step, when we solve
the power management problem?
[Antonio] You mean,
when it is done we need to go further.
[Philippe Millet]
Yes.
[Antonio]
Actually I never asked myself that question.
It is always a race, right?
Between application requirements that are
rising and the platform capabilities
we have and the thing is yes it is possible
to do simple systems with complex platforms
but it is harder to do complex systems
with complex platforms
or simple systems with simple platforms.
Because I think the next step would be
to improve the design methodology,
to have designers putting their idea
into code with higher levels of abstraction.
So I am thinking about
maybe the Zynq architecture.
Now we have this marvellous new UltraScale+
module with 4 application cores,
2 real-time cores, a lot of FPGA, ...
But we do not have the work force to use it.
So I think that the missing thing is indeed
technology, languages,
things that computer scientists are good
to work on to help the engineers
to design systems with these platforms.
[Philippe Millet]
So more on programming models...
[Antonio] Higher levels of abstraction
for hardware design, for example.
It should be a nice future direction.
[Philippe Millet]
OK I have a short remaining question.
Because with your thesis,
having this knowledge,
with your 5+ years work on your thesis.
If you had known before,
would you have started it ?
[Antonio]
Ha if I would start it?
Knowing that you don't sleep for...
several days in a row... I think so.
I think it is also about the passion to know
more and to understand more the systems.
I think I will continue doing research
after that
because it is a so nice environment also.
You can work with a lot of people,
it is a very open world so...
yes, totally, I would start again.
But I will not do a second thesis.
[Yves Roggeman]
Laurent?
[Laurent Georges]
Thank you.
I would like also to congratulate you
for your PhD thesis.
It was really interesting.
I must say, there is a lot of information,
also in the way you wrote.
I think your presentation also shows
very good skills
that you have presenting your work.
I would like to maybe ask a general question.
I would like to select
a kind of scheduling attribute.
I want to have a very low consumption.
Should I use global scheduling?
Partitioned scheduling?
Or what would you choose?
What would you suggest?
[Antonio]
I guess... you have the toolbox
and you simulate...
And you see which one is better.
So actually it depends on the load, I think,
on your platform.
It is better to go for safer solution like
partitioned rate monotonic when you have a
small load because you do not need to use
all your platform.
Otherwise, maybe you will need to squeeze
a lot of performance from your platform,
then use more advanced techniques
like global and who knows maybe U-EDF?
I think it's depending on each use case it
is hard to give a deterministic answer.
[Laurent Georges]
Thank you.
Could you give from your understanding
the motivations of a new operating system
like HIPPEROS?
[Antonio]
From *my* perspective, personally?
[Laurent Georges]
Yes, compared to existing operating systems,
what was the expected benefits that you can
have when designing a new operating system?
[Antonio]
I see two ways to answer to that question.
The first, the easy one, is that it is very
challenging and you learn a lot of things,
seen on my very personal side it is better
to build something from scratch
and you understand all the layers
of complexity you have in the system.
Then, I guess your question was more about
"why would you personally choose HIPPEROS
instead of...
I don't know QNX or VxWorks?"
So I need to put my seller hat.
I think it is very... the important thing
is not really the OS but all the...
everything around...
everything you have around
like tools to check offline
that the system is going to execute well,
like I said previously
design frameworks that help,
and the integration
of all of this in a good eco-system.
That's the important things.
The kind of things we work on
in the Tulipp project.
[Laurent Georges]
Last question concerning...
So in your thesis you are basically... you
are working on DVFS solutions.
Do you think that the conclusions
that you reach
that parallelism is always
better than non-parallelism?
Do you think you would reach
the same conclusions
if you would consider the DPM solutions?
[Antonio]
I think that in a way...
So to clarify, DPM is when instead of
changing the frequency of the machine
you just decide to use less cores.
Then the cores that you don't use
are put into sleep
and they consume close to nothing.
I think... we would reach it
but with different...how to say that...
We would reach the same conclusions
but by taking another path.
The heuristics and the scheduling techniques
maybe would be something else.
Selecting a small frequency
would not be the way to go.
But indeed using the "race-to-idle" strategy,
then combining race-to-idle with parallelism,
you will see that you have more sleeping time
and then more energy savings.
So I think that yes, indeed.
[Laurent Georges]
OK, thank you.
[Yves Roggeman]
Gilles?
[Gilles Geeraerts]
Yes so, I will not be very original.
I also want to congratulate you very much
for your PhD thesis.
For the document that you wrote
but also for your presentation
which I believe is a perfect example.
I am very happy that it was recorded,
at least the first part of your presentation,
the one of the problem statement
should be kept and probably reused.
I mean this is for me typically the kind
of presentations that should be used
to motivate people to start a PhD thesis.
... I have two questions
that are linked actually.
So in your thesis you advocate the use
of parallelism on energy.
So my first question is how realistic
is it to say that you will always be able
to stack these blocks?
That you will always be able
to use more parallelism in your applications?
And the second question is
about these "useful_work" slides.
What is the kind of languages that you could
be using to specify this "useful_work"?
Would it be really C or maybe
something more abstract?
Maybe using something more abstract could
help answering my question.
[Antonio]
Yes indeed.
So for the practicality of doing parallelism
until the end.
Indeed it is not infinite.
The thing that was really interesting
in the thesis is that in embedded systems,
most platforms are mono-core.
Are single-core.
And then when you use four cores for example
you see directly huge advantages.
But I guess you will not be able to write
a program that will use two thousands cores
and be in an embedded system.
You will pay at some point
the price of parallelism,
which is documented in the thesis.
I did not speak about that,
I just put approximative equal symbols
to say OK maybe
it is a little bit too complex.
But indeed at some point you are limited
by the fact that you execute instructions
and you will not parallelise one instruction
for a program on maybe 2000 cores,
I don't know.
So the important thing at this point
when you indeed have
many-core platforms
is that you will always have
several tasks to execute.
And each of these tasks can take a subset
of the cores available.
Then indeed using an optimisation procedure
to calculate how do you dispatch
the different threads of the different tasks
on the multiple cores
could be some kind of "Graal"
to optimise your application.
And for the language maybe it is not C.
I put C because everyone knows it
but it's totally maybe not a new language
but something where you can annotate the code
that you will run with performance metrics.
I am not sure what kind of languages...
should be functional.
Also functional languages
ease the parallelism,
the implementation
of "automated" parallelism.
[Gilles Geeraerts]
Thank you.
[Yves Roggeman]
Joël?
[Joël Goossens] OK, congratulations Antonio
you did an excellent work
during these five years.
It is not the first talk I have the pleasure
to listen to.
So I know your ability and today it was
"la cerise sur le gâteau".
During those years I asked a lot of
technical questions about details, etc.
So today I will avoid to do that.
Maybe I have a question
concerning the memory.
So you focus your study on saving the energy
on the CPU but the board you showed us
have Random Access Memory for instance.
Last week I went to a conference and it seems
like a new kind of non-volatile memory
helps to save energy.
I would like to have your idea, your concern
about that aspect
which consumes I think a lot of energy.
[Antonio]
Sure.
The central memory, the RAM needs
to be refreshed constantly,
to keep the information we need
to put a lot of energy.
I think there is a lot of progress
on the hardware side.
I am not sure how much we can influence it
on the software side.
Cache optimisation techniques could help
because the caching
is when you do
the hierarchical memory.
Using well your cache will have an impact
on the way you use the memory.
So applying techniques like Juan is working
on, when you schedule your memory accesses,
allows maybe to have more
predictable patterns of accessing the memory
and then also of energy
consumption.
What could be interesting is to be able
to isolate the energy contribution
of the different components of the chip
but that is very difficult
if you don't have good simulations
and good frameworks to do that.
[Joël Goossens]
Thank you.
[Dragomir Milojevic]
Great.
First of all
thanks a lot for the presentation.
It convinced me that besides many qualities
that you have
you're also a very good teacher
which is a good news probably for my faculty
because we gonna try to hire you
to give lectures.
This is a very good thing.
But now go back to questions.
Now your thesis focuses on multi-cores.
And people are buzzing for quite some time
about many-cores, many-many-many-cores.
The question is: the translation
from the framework we have today
towards this many-many-many-cores,
how will it happen? Will it be hard?
And would you think that the results
that you're observing today with four cores
are gonna be...
Imagine you can parallelise things nicely.
How your framework should change to adapt?
[Antonio]
The first thing is you will always be able
to use less cores
than you have on your platform.
So you can use the framework directly
if you want.
Even if it is not using a large amount,
thousands of cores.
Of course the serious answer to that
is more complicated.
The thing is...for me the challenge is not
at the hardware level.
It is really to convince designers to apply
parallelism in their methodology.
To think about the problem in parallel.
As soon as you can do that you can already
have a lot of gains.
Regarding transition from multi-cores
to many-cores in embedded systems,
I guess that is what you were...
[Dragomir Milojevic]
Embedded or whatever...
[Antonio] I think that we'll have
much more capabilities
and that we will be close to what we do
for servers for example.
[Dragomir Milojevic]
This means the result you have shown
is basically scaling perfectly well
with the number of cores.
[Antonio]
Theoretically... yes.
In practice, it will not.
That's the thing.
What we should do...
[Dragomir Milojevic]
The idea is basically if you code programs
that are orders of magnitude bigger
that what you have today,
what is the quality of the solution... ?
[Antonio]
The quality is this capability to execute
evenly on the different cores.
You will distribute the work and then
the consumption will be less costly.
So this approach will always fit
in multi-core and many-cores
but you will have I think
to be a little bit more fine
in the way you design
your applications.
[Dragomir Milojevic]
So applications.
[Antonio]
Always applications.
[Dragomir Milojevic]
As a Computer Science guy, you accepted
that hardware languages is not our...
*INAUDIBLE, PLEASE CONTACT ME*
I will ask a very quick one.
Now you said that if you re-start your thesis
you would do a lot of benchmarking.
What was the weakest point in your benchmark
in your thesis?
[Antonio]
I think they were too simple.
So it is maybe not convincing enough
for the thesis to have just simple use cases
that all have the same structure.
I would like to have something more complex
in terms of parallelism.
For example, implementing
OpenMP nesting of for loops.
And then you represent your application
with a very complex Directed Acyclic Graph.
And this is more challenging to execute
because we know
that scheduling this is a NP-complete problem
to execute on DAGs,
even when there
is no real-time constraints.
So you have energy, real-time constraints
and DAG... it starts to be a mess...
and many-cores!
Like this you have many data.
[Yves Roggeman]
OK, well I will add some congratulations also
about ... everything we asked you to do,
all aspects.
I have two small questions.
First is about the bridge between the theory
and the practice.
The frequency is modelled by a continuous
function.
In practice you only have a small table of
values you can manage.
So you find the continuous optimal solution
as a continuous value.
Can this be applied to a practical system?
[Antonio]
Not directly, at least.
You will have to do some arrangement to relax
some hypotheses that are done in theory.
Because the optimality of a solution
in a theoretical framework is always defined
by the assumptions that are made.
As soon as you break one
of these assumptions,
in practice you loose the optimality
quite automatically.
[Yves Roggeman]
You think it is a good approximation
in some cases?
You took also some other approximations.
[Antonio]
I was surprised how fine
the approximation was.
When we did frequency scaling, and we did
it on actual programs, we were surprised
that the scaling was indeed linear
between execution time and the frequency.
Maybe one way to see it is
"OK then is good enough".
The other way is to see "OK it is because
we did not do programs complex enough,
and we need to do more and more...".
Then we need to do more research.
[Yves Roggeman] So your experiments
prove that it is a good approximation ?
[Antonio]
Yes.
At least for simple use cases...
[Yves Roggeman]
It's good enough.
[Antonio]
Yes.
[Yves Roggeman]
OK. Now small question.
You describe in your work
that each core in multi-processor
has the same type of structure,
then you have
some very important assumptions:
that you change the frequency of all cores.
Did you try to make experiments
or some kind of modeling
using two sets of cores
with two different frequencies?
[Antonio] I did a little bit at the beginning
in the theoretical framework.
When we went to the practical side,
implementing the DVFS driver
in the SABRE Lite, we were surprised
to see that you don't have this flexibility.
So we cannot fine tune
the speed of each core.
But maybe it's "by design".
"It's not a bug, it's a feature".
Because I think that they want that
you indeed use all the cores simultaneously.
And then when you use all of them,
it makes little sense
to have different frequencies
for different cores.
Because you evenly distributed your workload.
But when you have a clustered architecture
with more cores,
that will make maybe more sense.
[Yves Roggeman] You speak
about multi-processors with multi-cores.
[Antonio]
Yes, indeed.
And then you already have
the literature solution for that:
you apply in a clustered fashion
the frameworks
to the different groups of cores.
[Yves Roggeman]
OK.
Maybe other questions
in the members of the jury?
On change de langue.
Donc maintenant traditionnellement,
on demande au public
s'il souhaite poser des questions
au récipiendaire.
[Nikita Veshchikov]
Tu as parlé de parallélisme
au point de vue plusieurs cœurs.
Mais quand tu regardes un core, à l'intérieur
tu as plusieurs couches de parallélisme.
Notamment tu as le pipeline,
speculative execution.
Tu peux avoir des blocs dédiés
pour une tâche
comme par exemple traitement audio,
chiffrement, etc.
Est-ce que tu as regardé
ce genre de choses ?
Qu'est-ce qu'un producteur de hardware
devrait améliorer, rajouter,
supprimer ou modifier
pour que tu puisses mieux optimiser
de ce point de vue là,
au niveau de l'architecture ?
[Antonio]
OK donc, il y avait plusieurs choses.
Premièrement tu me demandes à propos
des types de parallélisme.
Ça c'est quelque chose qui est quand même
plus ou moins abstrait dans mon manuscrit.
C'est-à-dire que je dis "tu peux implémenter
le parallélisme comme tu veux, l'important
c'est que tu l'implémentes", quelque part.
Le but est d'avoir des gains
en termes de temps d'exécution.
Une fois que tu as ton parallélisme, ton
application va s'exécuter plus rapidement.
Et ça, ça te donne le slack pour récupérer
de l'énergie en appliquant
l'une ou l'autre des politiques.
Donc je me suis intéressé peu aux différents
types de parallélisme en pratique.
Pour ce que tu as dit en termes de matériel,
là par contre
on est en train de travailler
là dessus.
Effectivement ici aujourd'hui j'ai parlé
uniquement de processeurs symétriques.
On a multiplié les processeurs et chacun
est capable de s'exécuter à la même vitesse.
Mais, la tendance actuelle c'est plutôt
de faire des solutions hétérogènes.
On a des unités dédiées, spécialisées
à exécuter certains types de traitement.
On travaille avec ce genre d'architectures,
comme le Zynq qui permet de faire ça.
Donc tu m'as demandé, "à ton avis, comment
tu peux aider les concepteurs de hardware
à choisir les bonnes choses à accélérer ?".
Là je dirais on va devoir appliquer
la loi de Amdahl.
Donc d'essayer d'optimiser
ce que tu fais le plus.
Imagine tu fais une application de traitement
d'images, dans une voiture,
tu veux détecter
des piétons par exemple.
Tu vas devoir créer des unités dédiées
d'intelligence artificielle pour accélérer
ce traitement qui sera fait continuellement
parce que la voiture est tout le temps
être en train d'essayer
de détecter des piétons.
Donc la quantité de travail
et aussi l'opportunité à paralléliser
va devoir guider les concepteurs de hardware
dans leurs prochaines conceptions.
Ce qui a toujours été le cas en fait,
ces dernières années aussi.
...
[Yannick Molinghen]
Quels sont les impacts
des architectures hétérogènes
sur la manière d'ordonnancer des tâches ?
Comment ces architectures impactent-elles
tes résultats ?
[Antonio]
Alors comme je l'ai répondu précédemment,
je pense que ça ne change pas le résultat
en tant que tel, de la thèse,
de dire que ça aide, etc.
Mais je pense que ce sont de nouveau
les moyens pour arriver à prouver cela
qui vont être différents.
Parce que, effectivement, ici tu vas devoir
prendre en compte
d'autres nouveaux types de problèmes,
de nouveaux types de contraintes.
Comme par exemple, le fait que,
si tu utilises...
On pense notamment à l'architecture FPGA
où on peut dédier un certain traitement
à un accélérateur qui va le faire
à ta place (du CPU).
Une fois que tu fais ça, il y a de nouvelles
problématiques de partage de ressources,
parce que plusieurs cœurs peuvent accéder
au même accélérateur,
que tu dois tenir en compte
dans ton scheduling.
Parce que tu ne fais pas cela,
tu peux compromettre tes deadlines,
avoir des inversions de priorité,
et tous ces joyeux problèmes qui apparaissent
dès que tu partages des ressources.
[Raymond Devillers]
Vers la fin de l'exposé, tu as projeté
des graphiques montrant l'intérêt,
au niveau consommation d'énergie,
d'avoir plusieurs cœurs.
Alors on voit effectivement clairement que
c'est uniformément meilleur avec 4 threads.
Par contre tu as des cas où avec 3 threads
c'est moins bon qu'avec 2.
Est-ce que tu as une explication ?
[Antonio]
Oui...
En fait, l'architecture qu'il y a derrière
c'est un processeur 4 cœurs.
Et donc, quand sur un processeur 4 cœurs,
on génère des travaux qui s'exécutent
sur 3 threads, ça pose des petits problèmes
de synchronisation.
On a 3 threads donc un fil d'exécution
est disponible
dans lequel va rentrer probablement
le thread d'un autre programme.
Et donc il y a des effets de superposition...
Comme 2, c'est une puissance de 2, et donc
ça va avec 4.
Tous les programmes qui sont sur 2 threads
vont pouvoir s'exécuter en même temps
et donc ça va très bien se passer.
Par contre 3, on va avoir des anomalies qui
vont commencer à arriver
et ça va très mal s'équilibrer.
Et comme je l'expliquais,
c'est vraiment l'équilibre du travail
qu'on donne au processeur qui permet
de consommer moins d'énergie, d'avoir de
réels gains en termes énergétiques.
... Il y a une remarque spécifique
dans le Chapitre 9 à ce propos.
[Raymond Devillers]
J'ai pas encore eu le temps de le lire.
[Antonio]
Non mais c'est pour information...
[Yves Roggeman]
Un informaticien ne connaît
que les puissances de 2.
[Antonio]
C'est ça.
Donc le 3 est vraiment un bon exemple
de mauvais design.
[Yves Roggeman]
Ça n'existe pas.
[Paul Rodriguez]
J'ai aussi une question...
C'est un peu plus méchant parce que
j'ai quand même participé un peu
à la production de ce graphe.
[Antonio]
Co-auteur hein...
[Paul Rodriguez]
Est-ce que tu penses
que les chiffres seraient différents
si on avait mis multiplié le
nombre d'expériences par 100 ou 1000 ?
Est-ce que ce phénomène de
"3 qui rattrape le 2" apparaît ?
[Antonio]
Tu veux dire le nombre de tâches
ou le nombre d'expériences complètes ?
[Paul Rodriguez]
Des expériences...
des résultats
sur systèmes aléatoires.
[Antonio]
Ce que je n'ai pas dis c'est que ici
ça correspond à 232 expériences...
[Public]
C'est écrit sur le slide.
[Antonio]
Ha oui. Génial.
Je pense que, faire plus d'expériences
n'aurait pas apporté beaucoup.
C'était finalement assez déterministe.
On a généré les systèmes aléatoirement
mais tout ce qui va
dans la suite de la chaîne
est quand même plus ou moins déterministe.
Donc ce sera quand même un peu plus lisse,
mais on aura quand même ce phénomène
où le 3 threads
va être plus mauvais par moment.
Cela va quand même arriver.
Il faudrait essayer...
mais une seule expérience
prend quand même beaucoup de temps.
[François Santy]
*INAUDIBLE, PLEASE CONTACT ME*
...
...
[Antonio]
C'est vrai c'est une très bonne question
mais ça va dépendre très fort
du type d'industrie auquel tu vas t'attaquer.
Tu prends l'avionique,
y a très peu de chances.
Aujourd'hui y a encore des documents plus
ou moins en draft qui disent :
"est-ce qu'on va mettre des multi-cœurs
dans l'avionique ou pas?".
Donc ils en sont pas là.
Par contre, l'automobile,
pour les innovations de ce type,
ce qui permet de récupérer
plus de performances,
ça semble être beaucoup
plus prometteur pour ce genre de techniques.
On voit à leur présence dans les conférences
de recherche
qui sont quand même très théoriques,
très "fondamental"; leur présence montre
leur intérêt pour des nouvelles techniques.
[Manuel Paolillo]
Cela a peut-être été dit implicitement
mais quel est le changement de paradigme que
ça entraîne, plutôt en tant qu'académicien ?
Cela crée un changement de paradigme
aussi auprès des développeurs de software,
d'applications.
Et donc quelles seraient tes recommandations
par rapport à des nouveaux étudiants
qui rentreraient ?
[Antonio]
Ha c'est ça pour l'éducation ?
Oui donc il faut commencer effectivement
très vite à faire du développement
avec des threads, parallèle, etc.
Clairement.
Sinon après 6 mois c'est terminé on a un
paradigme dans la tête impératif, C.
Pour changer, déjà pour aller de l'impératif
au fonctionnel, il y a un grand écart énorme
qui doit être fait, dans l'apprentissage.
Et ici ça va être pareil.
Je pense que ce sont les mêmes structures
d'apprentissage.
Ce serait très intéressant de varier.
Le problème c'est un peu... il faut prendre
le problème quelque part quand on commence.
L'informatique est tellement vaste,
il faut choisir là où on commence.
Tu vas d'office sacrifier d'autres aspects
j'ai l'impression
quand tu commences à enseigner
un aspect, il y aura un autre aspect où on
sera moins bon.
Après je ne suis pas un spécialiste dans
le domaine.
[Hugo Herter]
J'avais aussi une question sur ce graphique-ci.
Je me demandais si la courbe normalement
avait assez de,
si on faisait un peu plus
d'expérimentations
on devrait avoir une courbe plus lisse.
Si les variations qu'on c'est vraiment des
artefacts qui sont liés à la plate-forme,
au système d'exploitation, ...
[Antonio]
Ou des applications elles-mêmes.
Je pense que c'est ça.
Cela aura l'air encore un peu plus lisse,
mais globalement tu vas toujours quand même
avoir un peu de bruit.
[Hugo Herter]
...
*INAUDIBLE, PLEASE CONTACT ME*
[Antonio]
Tu peux répéter ?
[Hugo]
Ton pixel à 2.4 en calcul sequentiel.
Le fait qu'il descende,
est-ce que c'est un artefact
ou quelque chose
de la technique qu'on a faite ?
[Antonio]
Bonne question.
Je pense que ça va se répéter.
En fait ce qui se passe, pourquoi je ne vais
pas plus loin que 2.8 ?
Pour clarifier, c'est qu'après on n'est plus
capable de respecter les échéances
avec la technique d'ordonnancement
qu'on a choisie.
Donc ici on arrive dans une situation où
on commence à augmenter fort
la charge du système
par rapport à ses limites.
Donc il se peut qu'il y ait quand même pas
mal d'aléatoire, de choses qui sont liés
à l'aléatoire derrière les paramètres
des tâches qui sont générées.
Donc à mon avis tu vas avoir quelque chose
de différent si tu fais plus d'expériences.
[Vladimir Svoboda]
Supposons, que tu aies envie
de faire une deuxième thèse.
A la suite de celle-ci, donc tu as parlé
que le track suivant
c'est probablement l'aspect
gérer les questions de température.
Cela prendra peut-être moins de temps,
qu'est-ce que tu ferais d'autre ?
[Antonio]
Etudier les architectures hétérogènes,
qui ont l'air très prometteuses.
Il y a plein de choses aussi où on peut aller
plus loin.
Dans le côté avoir un espèce de... que
l'OS se transforme vraiment en un programme
qui permet de gérer
tes ressources efficacement.
J'ai parlé de langages avec mon exemple,
mais il y a aussi le support run-time.
Il y a aussi, on doit être capable
d'implémenter ça durant l'exécution de l'OS
et faire en sorte qu'en respectant
notre contrat,
on voie que sur les plate-formes,
effectivement, ça se passe bien.
Donc ce serait faire plus d'expériences
dans ces aspects-là.
Puis après tenir en compte les ressources,
relaxer toutes les hypothèses
jusqu'à ce qu'on ait le truc parfait.
Mais là on est partis.
On parle plus de thèse on parle de carrière.
[Olivier Desenfans]
...
*INAUDIBLE, PLEASE CONTACT ME*
Si on utilise, au lieu d'un OS, on utilise
un hyperviseur.
Un hyperviseur c'est un programme qui permet
de faire tourner plusieurs OS en parallèle
sur la même plate-forme.
Comment est-ce que tu implémenterais
ce genre de techniques ?
[Antonio] Les questions du public
sont plus difficiles...
Alors l'hyperviseur le problème c'est qu'on
a maintenant une abstraction,
on n'a plus des cores,
on a des cores virtuels.
Donc on ne sait pas exactement
ce qui se passe.
C'est comme quand on se connecte
sur son serveur Web,
on ne sait pas combien
il y a de cœurs derrière.
Cela devient très difficile et je crois qu'on
a besoin d'un modèle de ce qui se passe
au niveau hyperviseur pour pouvoir gérer
la complexité de la chose.
[Olivier Desenfans]
Il faut refaire la thèse.
[Antonio]
Non, il faut pouvoir combiner une approche,
l'OS qui est fort proche du métal, au final.
Avec la nouvelle abstraction de CPU virtuel
et pouvoir transférer finalement
l'état du modèle entre les composants.
[Olivier Desenfans]
Il faut faire une troisième thèse.
[Antonio]
Voilà c'est ça.
On peut aussi paralléliser,
il y a d'autres ressources.
[Ben Rodriguez]
Est-ce que lorsqu'on augmente
le nombre de cœurs, ne penses-tu pas
que la ressource principale,
ce sont les accès mémoires ?
Et donc il faudrait commencer à envisager
d'ordonnancer des accès mémoires
et moins s'occuper des cœurs.
[Antonio]
Peut-être pas moins s'occuper des cœurs
mais en tout cas
prendre en compte la mémoire.
On a un travail en cours avec Juan
où finalement il y a un scheduling
des tâches sur les cœurs
et il y a aussi un scheduling,
un ordonnanceur des tâches
par rapport aux accès mémoires
qu'elles font,
pour éviter que deux tâches accèdent
à la mémoire en même temps
et qu'il y ait de la contention
qui introduit de l'imprédictabilité
dans le système.
Donc effectivement.
Moi j'aurais plus une approche de faire les
deux scheduling en même temps.
Plutôt que de dire on ne s'occupe plus du
tout des cœurs, parce ça c'est à mon avis
pas réaliste.
[Yves Roggeman]
Bien.
Je crois que je vais pouvoir remercier le
public et pendant le temps nécessaire,
le jury va délibérer.
[Yves Roggeman]
Vu le décret du 7 novembre 2013 définissant
le paysage de l'enseignement supérieur et
l'organisation académique des études.
Ça s'appelle décret paysage.
Nous président(e) - enfin au choix.
SecretaiRE,
et membres du jury chargés de conférer
le grade académique concerné,
déclarons que Antonio Paolillo, né à Uccle
le...
Non ça je vais pas dire.
A obtenu en l'année académique 2018-2019
le grade académique de Docteur en Sciences
après Défense Publique d'une dissertation
originale intitulée
"Optimisation of Performance Metrics
of Embedded Hard Real-Time Systems
using Software/Hardware Parallelism",
en foi de quoi nous lui avons délivré
le présent diplôme...
Qu'il aura quand il aura signé, bien entendu
Et que le recteur aussi aura signé.
Toutes mes félicitations.
Ça claque, pour que le public soit chaud,
plein de questions et tout ce qu'il faut.
Je peux vous dire que, d'expérience,
on n'a pas souvent autant de questions
pour un candidat
qui veut présenter son doctorat
mais j'imagine
que c'était tant la présentation
était bonne
et compréhensible
j'espère pour une bonne
partie de l'auditoire.
Joël je pense que tu...
[Joël Goossens]
Oui, je vais dire un petit mot.
On est encore dans la partie formelle.
Toi tu as écrit formellement
des remerciements,
tu m'as remercié formellement.
Je vais le faire de mon côté.
Et bien écoute, il y a encore 20 minutes,
tu étais un étudiant.
Tu étais un étudiant qui répondait à des
questions d'experts.
Et visiblement quelque chose a changé parce
que maintenant je peux t'appeler
cher confrère.
C'est-à-dire que tu maintenant fais partie
de ces experts
et que tu vas enseigner ton savoir
et continuer à faire de la recherche
et tu as prouvé ton habilité à communiquer
et à faire de la recherche.
C'est un moment important, un peu indicible,
un peu intangible.
Un peu quand on sort de l'enfance
et qu'on devient adolescent
ou quand on passe
à l'âge adulte.
C'est ça qui se passe aujourd'hui.
C'est un moment fort important,
il faut s'en rendre compte.
J'ai eu beaucoup de plaisir
à collaborer avec toi.
Je n'ai pas eu l'impression de travailler.
J'ai pas eu l'impression de travailler
parce que tu comprends vite,
tu te poses les bonnes questions,
tu as des bonnes idées
et tu viens de le démontrer aujourd'hui,
tu vulgarises ton propos avec éclat.
Et j'ai aussi été fort marqué
par ta ténacité,
ta ténacité à atteindre tes objectifs
du moins professionnel,
pour le reste je ne sais pas,
malgré les méandres de la vie.
Je te félicite, sincèrement, bravo.
[Yves Roggeman]
C'est bon ?
[Antonio]
J'ai encore quelques slides
si ça ne vous ennuie pas.
[Yves Roggeman]
Bon nous allons donc passer
à la partie moins formelle de la soirée.
[Antonio]
Oui..
[Yves Roggeman]
Nous pouvons donc tous monter au 8ème étage
du bâtiment NO, vous êtes attendus.
[Antonio]
Mais y a vraiment quelques slides !
[Yves Roggeman]
Alors là...
Là j'ai été eu !
Je ne le croyais pas.
[Antonio]
Alors, c'est pas la fin de mon exposé,
mais y aura moins de concepts.
Je voulais vous remercier tous pour tout ce
que vous avez fait pour moi.
J'ai fait une petite collection de photos.
Le soutien que vous m'avez apporté
était essentiel
sans quoi je ne pourrais pas
être ici aujourd'hui.
Et donc voilà j'ai d'autres photos
d'un peu tout.
J'ai vu que vous étiez nombreux à venir
donc j'ai bien fait gaffe
à ce que tout le monde soit là.
Mais oui donc en plus du travail on a aussi
pendant ces années...
On s'est beaucoup amusé on a fait beaucoup
de sorties dans tous les genres...
Sportives et moins sportives.
J'ai aussi pu collaborer avec des partenaires
dans différents projets,
notamment le projet Tulipp.
On a eu un collaborateur américain.
Et aussi dans les conférences on rencontre
vraiment beaucoup de gens
très très très chouettes.
Et bien sûr la team HIPPEROS.
La dream team de développement.
Sans quoi... on passe aussi énormément
de bons moments
de brainstorms, de trucs...
Ce micro-kernel,
je ne l'ai pas écrit tout seul.
On était toute une team à l'écrire,
on avait le management derrière nous.
Vraiment c'était top.
Je voulais aussi remercier ma famille
qui était là pour me soutenir
dans toutes ces épreuves.
Et un petit moment pour mon papa qui aurait
bien aimé être là aujourd'hui.
Mais bon, malheureusement.
Il est avec nous en pensées.
Et comme ça vous voyez
comment tout a commencé.
Avec mon premier Pentium 166 MHz.
La fréquence !
Et voilà, merci à tous !
