Etude du contrôle adaptatif de processus dynamiques dans les systèmes multimédia interactifs

Master 2 ATIAM M´ emoire de Stage

Etude du contrˆ ´ ole adaptatif de processus dynamiques dans les syst` emes multim´ edia

interactifs

Auteur Sous la direction de

Samuel Bell-Bell Dimitri Bouche Jean-Louis Giavitto

Equipe Repr´ ´ esentations Musicales

Institut de Recherche et de Coordination Acoustique / Musique

2 F´ evrier 2016 - 2 Aoˆ ut 2016

TABLE DES MATI ` ERES TABLE DES MATI ` ERES

Table des mati` eres

1 Pr´ eambule et remerciements 2

2 Introduction 5

3 M´ edia temporel 7

3.1 M´ edias temporels pr´ esentation . . . . 7

3.2 Interaction . . . . 7

3.3 Informatique musicale . . . . 8

3.3.1 Informatique musicale . . . . 8

3.3.2 Historique . . . . 9

3.3.3 Dualit´ e temps diff´ er´ e et temps r´ eel . . . . 11

3.3.4 Les environnements de programmation visuelle . . . . 11

3.3.5 Les langages musicaux temps r´ eel . . . . 11

3.3.6 Vers une mixit´ e de la CAO et des syst` emes temps r´ eel . . . . . 11

3.4 Pr´ esentation de OpenMusic . . . . 12

3.5 Antescofo . . . . 13

4 Ordonnancement 15 4.1 Principe de l’ordonnancement . . . . 15

4.2 Technique d’ordonnancement . . . . 19

4.3 Ordonnancement dans les logiciels de CAO . . . . 21

5 Environnement du stage et d´ eveloppement 22 5.1 Vers un logiciel de CAO r´ eactif . . . . 22

5.2 Statistiques dans OM . . . . 23

5.3 Vers un moteur multithread . . . . 24

5.4 Donn´ ees r´ ecolt´ ees . . . . 25

5.5 D´ ependances entre tˆ aches . . . . 27

6 R´ esultats par l’observation 29 6.1 Notions pour l’observation . . . . 29

6.2 Observations . . . . 29

6.2.1 Lib´ eration p´ eriodique de m´ emoire . . . . 29

6.2.2 Nombre de threads optimal . . . . 30

6.2.3 Variation et fr´ equence . . . . 31

6.3 Etude : Tˆ ache de calcul . . . . 31

6.4 Acc´ es m´ emoire p´ eriodique . . . . 38

7 Conclusion et Perspectives 43

Bibliographie 45

Annexes 48

1 PR ´ EAMBULE ET REMERCIEMENTS

1 Pr´ eambule et remerciements

“Le principe de l’´ evolution est beaucoup plus rapide en informatique que chez le bip` ede.” Jean Dion.

“D’une fa¸ con g´ en´ erale, composer un morceau consiste ` a ´ ecouter la musique que l’on a en soi.” Bert Jansch

Je remercie en premier lieu Jean-Louis Giavitto et Dimitri Bouche sans qui cette belle exploration et cette ´ etude n’auraient pas pu ˆ etre possible. Leur encadre- ment et leur altruisme ont ´ et´ e des plus int´ eressants, des plus agr´ eables et des plus efficaces tout au long de ce projet, tout en me laissant une grande ind´ ependance.

Je remercie Jean Bresson pour ses conseils concernant ce rapport de stage et pour m’avoir prˆ et´ e son bureau tout au long de mon stage alors qu’il ´ etait ` a l’´ etranger.

Je remercie J´ erˆ ome Nika, H´ eliante Caure et Dimitri d’avoir partag´ e avec moi le bureau A107 dans une ambiance conviviale et ` a la fois s´ erieuse.

Je souhaite aussi remercier Carlos Agon et Philippe Esling pour leurs conseils, pendant l’ensemble de mes ´ etudes sup´ erieures.

Je remercie les ´ equipes p´ edagogique et administrative du Master 2 ATIAM pour faire de ce M2 un parcours d’exception et passionnant.

Je remercie les enseignants-chercheurs du Master STL de l’UPMC qui m’ont appris ` a m’adapter ` a de nouveaux langages rapidement lors de mon M1 et je remercie l’ensemble des enseignants de Paris VI qui m’ont permis de r´ ealiser toutes sortes de programmes durant l’enseignement qui m’a ´ et´ e dispens´ e.

Je remercie l’IRCAM et l’ensemble des personnes y travaillant de partager leur passion pour la musique ` a travers la recherche et la composition, et de faire vivre cet institut dans une atmosph` ere accueillante.

Je remercie mes camarades de la promotion 2015/2016 ATIAM d’avoir par- tag´ e cette ann´ ee pleine d’enseignements et de d´ efis avec autant de ferveur.

Je remercie ma famille et mes amis de m’avoir soutenu tout au long de ces

ann´ ees.

1 PR ´ EAMBULE ET REMERCIEMENTS

R´ esum´ e

Les syst` emes multim´ edias modernes, du fait de leur caract` ere de plus en plus interactif, rendent difficile le rendu en temps r´ eel des donn´ ees qu’ils contiennent.

En effet, les interactions avec ces donn´ ees peuvent les modifier en temps r´ eel, ce qui rend l’ordonnancement statique des actions du syst` eme non adapt´ e. Cepen- dant, les m´ ethodes d’ordonnancement dynamique ne permettent pas d’utiliser au mieux les ressources car elles n’utilisent aucune connaissance a priori.

L’´ etude effectu´ ee lors de ce stage concerne la possibilit´ e d’adapter en temps r´ eel ces environnements grˆ ace ` a un outil d’analyse. Les logiciels de Composi- tion Assist´ ee par Ordinateur (CAO) permettent d´ esormais le calcul de processus compositionnels en temps r´ eel. Leurs sorties prennent l’aspect de partitions mu- sicales interactives pouvant ˆ etre amen´ ees ` a communiquer avec d’autres logiciels.

Il faut aussi prendre en compte le fait que ces logiciels cohabitent avec des pro- grammes en cours d’ex´ ecution dans le mˆ eme ordinateur.

La recherche de strat´ egies d’ordonnancement pour de tels syst` emes ´ evolue.

Les strat´ egies d’ordonnancement na¨ıves des actions de ces syst` emes sont peu efficaces. Elles doivent respecter des contraintes du temps r´ eel lors du rendu des donn´ ees qui peuvent d´ eclencher des calculs longs venant du domaine du temps diff´ er´ e. Le tout devant coexister dans un mˆ eme contexte.

Nous proposons un outil d’observation du comportement de tels syst` emes.

L’utilisation de d´ eductions ` a partir de statistiques ´ emises par cet outil ouvre la voie ` a de nouvelles strat´ egies adaptatives.

Mots-cl´ es : CAO, OpenMusic, API de mesure et statistique, ordonnan- cement, multim´ edia, syst` eme interactif, adaptabilit´ e, processus, multithreading, DAG.

Abstract

The modern multimedia system by their characterization more and more in- teractive, make it difficult to render in real-time data they contain. In fact, these interaction can modify data in real time, that make the static scheduling una- dapted. However, dynamic scheduling methods don’t ensure the best use of the available resource because they don’t use a priori knowledge.

The study carried out at this stage is the possibility of adapting these real-

time environments with an analysis tool. Computer Aided Composition software

(CAC) now allow the calculation of compositional processes in real-time. Their

outputs have the appearance of interactive musical scores which can be brought

to communicate with other programs. We must also take into account the fact

1 PR ´ EAMBULE ET REMERCIEMENTS

that these software products coexists with running programs in the same com-

puter. The research of scheduling strategies for such systems evolve. The naive

scheduling strategies of actions by these systems are weak. They must respect the

constraints of real-time when they rendering data that can trigger long calcula-

tions from the field of deferred time. All of this must coexist in the same context .

We offer an observation tool for the behavior of such systems. Using infe-

rences from statistics issued by this tool opens the door to new adaptive strategies

Keywords : CAC, OpenMusic, measurement and statistical API, scheduling,

multimedia, interactive systems, adaptability, thread, multithreading, DAG.

2 INTRODUCTION

2 Introduction

Ce m´ emoire r´ esume le stage r´ ealis´ e dans le cadre Master 2 ATIAM 2015/2016. Ce master est une formation pluridisciplinaire aux sciences de la musique (Acoustique, Traitement du signal, Informatique, Appliqu´ e ` a la Mu- sique) est propos´ e par l’Universit´ e Pierre et Marie Curie. De plus ce master est organis´ e en collaboration avec l’IRCAM (Institut de Recherche et Coordination Acoustique/Musique) et T´ el´ ecom ParisTech qui accueillent l’enseignement.

L’´ equipe Repr´ esentations Musicales propose d’encadrer ce stage. Il est r´ ealis´ e ` a l’occasion d’une ´ etude relative au contrˆ ole adaptatif de processus dynamiques dans les syst` emes multim´ edias interactifs.

Le logiciel de composition OpenMusic (OM) appartient ` a la famille des logiciels de CAO. Il s’agit de l’environnement o` u le stage se d´ eroule. L’´ etude r´ ealis´ ee int´ eresse aussi l’´ equipe MuTant dans le cadre du d´ eveloppement d’An- tescofo qui est un logiciel de suivi de partition. En effet, malgr´ e la granularit´ e temporelle plus pr´ ecise dans Antescofo que dans OM, le comportement du syst` eme face ` a diff´ erents travaux reste a priori le mˆ eme (les ex´ ecutions en temps r´ eel restant al´ eatoires).

OM permet la r´ ealisation d’id´ ees musicales sous forme de processus pro- duisant des r´ esultats en temps diff´ er´ e. Ces r´ esultats sont issus d’une phase de calcul et sont consid´ er´ es comme “statiques” puisqu’on ne peut pas interagir avec eux lors de leurs ex´ ecutions.

De r´ ecents travaux dans OM et dans Antescofo ouvrent la CAO au temps r´ eel. Ces travaux ont notamment entrain´ e une ´ evolution interne du langage OM grˆ ace au d´ eveloppement d’un paradigme de programmation r´ eactive.

Ce paradigme vise ` a conserver la coh´ erence de l’ensemble d’un programme en propageant les modifications d’une source r´ eactive (modification d’une variable, entr´ ee utilisateur, etc.) aux ´ el´ ements d´ ependants de cette source. Ainsi OpenMusic se doit d’ˆ etre plus performant pour r´ epondre aux nouvelles attentes.

Suite ` a ces travaux, le contenu des partitions obtenues via OM devient dy- namique. Remarquons que ces partitions sont donc des processus dynamiques.

Leur lecture doit toujours respecter un ensemble de r` egles pour r´ ealiser leur rendu sonore sans pour autant figer leur contenu. Ces partitions en cours de lecture se traduisent par l’ex´ ecution de s´ equences d’actions dat´ ees ` a laquelle s’entremˆ elent des calculs venant ` a la modifier. Ces calculs sporadiques dont on ignore la dur´ ee ne permettent donc pas d’anticiper l’ordonnancement des tˆ aches pour assurer un rendu d´ eterministe.

Le d´ eveloppement de OM est r´ ealis´ e via LispWorks ¹ . Il s’agit d’un environ- nement de d´ eveloppement pour langage Common Lisp respectant les normes

1. http ://www.lispworks.com/documentation/lw70/LW/html/lw.htm

2 INTRODUCTION

CLOS (Common Lisp Object Syst` eme). De plus le travail est effectu´ e dans l’environnement d’une machine “grand public”. Il y a diff´ erentes couches dans un syst` eme, au niveau logiciel (la couche la plus haute), le contrˆ ole devient de plus en plus inaccessible vers les couches les plus basses. Ces couches influent sur le comportement global du syst` eme tout en ´ etant difficile ` a observer. Voici un r´ esum´ e pr´ esentant ces couches sous forme de niveau :

— Niveau 1 : Nous pouvons g´ erer notre propre notion de tˆ ache (appel´ e threads dans la suite) grˆ ace ` a notre propre ordonnancement,

— Niveau 1.5 : Nous n’avons pas de contrˆ ole ni sur l’ordonnancement ni sur le ramasse-miettes ² de LispWorks. Le travail s’´ etant fait sur un or- dinateur 64-bit nous avons fait les tests sur l’environnement LispWorks 64-bit. Le ramasse-miettes de cet environnement semble bien optimis´ e (ce niveau n’est pas pr´ esent pour tous les environnements logiciels, et est dˆ u ` a l’environnement de programmation LispWorks) ³ ,

— Niveau 2 : Nous n’avons pas de contrˆ ole sur les threads syst` eme (threads noyau),

— Niveau 3 : Nous n’avons pas de contrˆ ole sur les m´ ecanismes de cache et de “context switch” entre processeurs.

L’objectif du stage est de proposer des pistes de r´ eflexion sur le contrˆ ole adaptatif d’un tel logiciel. L’utilisation d’un outil d’analyse produisant des statistiques est donc requis. Ces statistiques permettent d’analyser l’ex´ ecution de tˆ aches faites par un syst` eme informatique. Dans le cadre d’OM nous avons de plus d´ evelopp´ e un nouveau moteur d’ex´ ecution ` a groupe d’unit´ e d’ex´ ecution (appel´ e dans la suite moteur multithread) rempla¸ cant un moteur ` a une unit´ e d’ex´ ecution (appel´ e dans la suite moteur monothread).

In fine, cela permettra d’augmenter la faisabilit´ e de partition interactive ex´ ecut´ ee en temps r´ eel. En r´ esum´ e, une analyse de ces statistiques permettra d’adapter le contexte d’ex´ ecution en fonction de la charge de travail du syst` eme.

2. Gestionnaire de m´ emoire qui g` ere automatiquement la lib´ eration de m´ emoire d´ ej` a utilis´ e, ne servant plus au programme aussi appel´ e garbage collector.

3. ` A propos de la gestion du garbage collector dans l’environnement 64-bit voir

http ://www.lispworks.com/documentation/lw70/LW/html/lw-74.htm#pgfId-886617.

3 M ´ EDIA TEMPOREL

3 Informatique musicale et m´ edia temporel

3.1 Pr´ esentation des m´ edias temporels

L’´ etude r´ ealis´ ee au cours de ce stage porte sur les m´ edias temporels. Il s’agit par exemple de buffers audio potentiellement interactifs. Nous parlerons de m´ edia temporel en gardant la notion d’interactivit´ e implicite.

Un m´ edia temporel exige un rendu de l’information. Ce rendu peut se traduire par une lecture du m´ edia se faisant en temps r´ eel. Cette lecture n’est pas dissociable de l’environnement o` u elle est effectu´ ee et doit coexister avec d’autres processus pr´ esents dans cet environnement. La “mise en temps”

du temps diff´ er´ e (calcul des compositions ou productions) vers le temps r´ eel (lecture des compositions et productions) peut donc ˆ etre perturb´ ee. Le taux de charge de travail d’un ordinateur influe sur la qualit´ e du rendu de ces partitions.

Les m´ edias temporels sont omnipr´ esents dans la CAO. L’informatique mu- sicale dans son ensemble utilise les m´ edias temporels que ce soit dans la com- position ou la performance. Actuellement, les syst` emes informatiques musicaux sont amen´ es ` a travailler dans un contexte o` u la composition et la performance s’entremˆ elent. Les repr´ esentations de donn´ ees (par exemple la partition) et les syst` emes (par exemple un syst` eme de suivi de partition) sont conduits ` a ´ evoluer dans ce sens.

3.2 M´ edia temporel et interaction

L’interaction avec les m´ edias temporels demande une fragmentation entre le temps diff´ er´ e et temps r´ eel. En effet les processus compositionnels norma- lement en temps diff´ er´ e doivent s’int´ egrer dans un contexte temps r´ eel. Ainsi l’ordinateur se retrouve ` a effectuer du calcul en mˆ eme temps que la lecture des m´ edias rendue par le calcul pr´ ealable. Par cons´ equent si un calcul ayant lieu pendant la lecture prend trop de temps son r´ esultat sera rendu en retard.

N’utilisant pas de machine d´ edi´ ee ⁴ totalement ` a ce type de travail, nous nous retrouvons dans un contexte Best-Effort (la machine doit faire de son mieux pour assurer que les r´ esultats aient lieu avant une date butoir ou dead- line). Lors de la “mise en temps” d’une composition de nombreux processus divers sont pr´ esents ce qui les rend difficiles ` a g´ erer. En effet le contexte de lecture d’une tˆ ache est perturb´ e par d’autres tˆ aches qui sont prioritaires au sein du syst` eme.

Pour se rendre compte des difficult´ es de la r´ ealisation de ces interactions nous proposons une ´ echelle en degr´ es d’interactivit´ e. En fonction du degr´ e, la

4. Les ordinateurs “grand public” ne permettent pas de maˆıtriser l’allocation des ressources

pour nos tˆ aches.

3 M ´ EDIA TEMPOREL 3.3 Informatique musicale

gestion de l’interaction est de plus en plus complexe dans les contextes temps r´ eel :

— degr´ e d’interactivit´ e nul ou quasi nul : par exemple le fait de cliquer sur un bouton “lecture” ou “pause” d’un logiciel envoie ` a la machine un signal. La machine d´ emarre ou stoppe le rendu du m´ edia s´ electionn´ e,

— degr´ e d’interactivit´ e moyen : par exemple un jeu video, qui peut ˆ etre mod´ elis´ e comme une suite d’actions et de r´ eactions du joueur et de la machine,

— degr´ e d’interactivit´ e total : par exemple les jeux vid´ eo transm´ edia qui se d´ eroulent ` a la fois dans l’environnement r´ eel du joueur (par exemple avec la g´ eolocalisation) et un environnement virtuel (un ´ ecran) o` u des instructions sont donn´ ees au joueur. Ainsi, celui-ci ´ evolue ` a la fois dans le monde physique et le monde virtuel.

Dans un contexte plus musical, on rencontre ces degr´ es d’interactions avec la musique mixte ⁵ :

— degr´ e d’interaction nul ou quasi nul : un musicien ´ ecoute une bande musicale sur une machine. Ici il n’y a donc aucune interaction entre les deux parties,

— degr´ e d’interaction moyen : ici, le musicien interagit avec la bande en pouvant la modifier grˆ ace ` a des effets lanc´ es via un controleur.

— degr´ e d’interaction total : la vitesse de lecture de la bande suit le jeu du musicien (comme dans Antescofo). Avec l’improvisation homme-machine la machine et le musicien se r´ epondent mutuellement en improvisant.

3.3 Informatique musicale : de la programmation vers l’in- teraction

3.3.1 A propos de l’informatique musicale `

L’informatique musicale est par nature multim´ edia car on y manipule des donn´ ees h´ et´ erog` enes (MIDI [19], fichier audio, vid´ eo). Les logiciels d’informa- tique musicale peuvent ˆ etre cat´ egoris´ es comme il suit :

.

— les logiciels/langages de notation (Finale, Sibelius, etc.),

5. La musique mixte est une musique ´ ecrite n´ ecessitant des interpr` etes et des sons

pr´ eenregistr´ es, sur bande magn´ etique dans les ann´ ee 80 et d´ esormais dans des fichiers au-

dio num´ eriques.

3 M ´ EDIA TEMPOREL 3.3 Informatique musicale

— les s´ equenceurs (par exemple Logic Pro, Live, etc.),

— les logiciels de g´ en´ eration et traitement du signal (plugins, langages, etc.),

— les logiciels de synth` ese et composition musicale (Formes),

— les logiciels temps r´ eel (par exemple Max, Pure Data, etc.),

— dans le cadre du stage : les logiciels de CAO (OpenMusic, PWGL, etc.).

3.3.2 Historique

Depuis la gen` ese de l’informatique, la musique a toujours ´ et´ e un des moteurs de son d´ eveloppement grˆ ace ` a la composition et ` a la performance. Ce “moteur”

s’incarne par des g´ en´ erations de logiciels et une augmentation de leurs possi- bilit´ es dans les domaines : de la programmation objet, de l’interactivit´ e, des protocoles de communications, de la notation symbolique, de la repr´ esentation de partition et de la synth` ese sonore. Ce court historique a pour but de le montrer.

HILLER, en 1956, avec l’ordinateur ILLIAC 1 livre la premi` ere oeuvre g´ en´ er´ ee via la CAO : Illiac Suite for String Quartet. Par des r` egles de filtrage stochastique, l’ordinateur accepte ou rejette des pitchs et des rythmes g´ en´ er´ es al´ eatoirements [29]. L’utilisateur se contente de fixer les param` etres du pro- gramme, que l’ordinateur ex´ ecute pour g´ en´ erer la composition.

En 1957 est cr´ e´ e le premier environnement de programmation pour la synth` ese sonore MUSIC I, suivi par ses descendants MUSIC N. Ces langages int` egrent d´ ej` a le principe de la s´ eparation entre l’orchestre ⁶ (oscillateurs) et la partition (programme) [36].

Formes [26] est un logiciel cr´ e´ e ` a l’IRCAM en 1982. Il appartient ` a la cat´ egorie synth` ese et composition musicale. Ce langage utilise le paradigme objet. Il est orient´ e vers la composition et l’ordonnancement temporel d’objets.

Un processus est affect´ e ` a chaque calcul ` a ex´ ecuter tout en pouvant ´ echanger des informations avec les autres processus.

Crime a ´ et´ e d´ evelopp´ e en 1985 par G´ erard Assayag et le compositeur Claudy Malherbe. C’est un environnement de cr´ eation de mod` eles musicaux formels dont le but est de permettre la traduction des notations symboliques musicales (processus) vers la repr´ esentation sous forme de notation (partition).

6. Les instruments cr´ e´ es par des oscillateurs (UGen qui permet d’amplifier, de filtrer et de

g´ en´ erer des enveloppes).

3 M ´ EDIA TEMPOREL 3.3 Informatique musicale

Apr` es cela, en 1986, Miller S. Puckette d´ eveloppe le premier langage temps r´ eel musical MAX/MSP [24] avec un environnement graphique de patching d´ edi´ e ` a la composition et ` a la performance. Il cherche ` a ˆ etre de plus en plus pr´ ecis sur la granularit´ e temporelle pour r´ epondre le mieux possible aux demandes du temps r´ eel.

Dans le mˆ eme temps Csound [34] est d´ evelopp´ e, h´ eritier direct de Music N. Il a lui aussi particip´ e au d´ eveloppement du paradigme objet dans les lan- gages musicaux et au d´ eveloppement de concepts de synth` ese sonore (orchestre).

En 1991, d´ evelopp´ e par Taube, le langage Common Music [32] devient la r´ ef´ erence dans les langages de CAO. Il permet d’´ ecrire des relations de haut niveau par la description du son. Il s’agit d’une boˆıte ` a outils pour la CAO extensible.

SuperCollider [18] est un langage de programmation de synth` ese audio qui red´ efinit le genre en 1996. Il garde les notions de g´ en´ erateur de traitement du signal (audio et contrˆ ole) comme MUSIC N mais entremˆ ele la synth` ese audio et la partition (les ´ ev´ enements musicaux). Cela permet au code d’ˆ etre encore plus expressif. De plus il embarque un paradigme objet, qui permet au d´ eveloppeur non seulement d’´ ecrire des programmes de synth` ese plus facilement, mais aussi de construire des syst` emes interactifs pour la synth` ese sonore, la composition algorithmique et pour la recherche en informatique musicale.

Ensuite vient l’ensemble des langages de CAO modernes (Patchwork [2]

entre 1989-1995, OpenMusic depuis 1998, PWGL [15] depuis 2002) qui sont des environnements de programmation visuels dont nous parlerons dans la section 3.3.4.

Chuck [36] est un langage d´ evelopp´ e depuis 2002, se pr´ etendant dans la lign´ ee indirecte de MUSIC-N. Il permet le contrˆ ole du flux audio avec un mod` ele de programmation concurrente. Il peut de plus modifier du code ` a la vol´ ee. Cela permet de g´ en´ erer ou interagir avec de la musique interactive en temps r´ eel. Ce langage est essentiellement utilis´ e pour faire du “live-coding”. Sa particularit´ e est d’effectuer les traitements du contrˆ ole et de l’audio ` a la mˆ eme granularit´ e : celle de l’´ echantillon. Ainsi le langage se d´ efinit comme “strongly timed”.

Avec le protocole OSC [38] utilis´ e dans Max/MSP et Chuck les orchestres

d’ordinateurs fonctionnent et communiquent plus facilement [33]. Le tout en

mˆ elant le mod` ele de programmation orient´ e agent dans les syst` emes multi-agent

(ce mod` ele ressemble ` a la programmation objet mais poss` ede des entit´ es adapta-

tives, autonomes capables de communiquer facilement entre elles et d’organiser

leurs actions).

3 M ´ EDIA TEMPOREL 3.3 Informatique musicale

3.3.3 Dualit´ e temps diff´ er´ e et temps r´ eel

Remarquons que lorsqu’un compositeur ´ ecrit une oeuvre, le temps repr´ esent´ e dans la partition est diff´ erent de celui qui s’´ ecoule lors de l’´ ecriture. Le temps

´ ecrit (celui de la partition) est ce que l’on appelle le temps diff´ er´ e. Le musicien quant ` a lui s’approprie le temps diff´ er´ e en lisant la partition. Lorsqu’il joue celle-ci en temps r´ eel, il effectue une mise en temps de ce qui est ´ ecrit dans la partition.

3.3.4 Les environnements de programmation visuelle

Les environnements de CAO offrent des outils autour de la repr´ esentation musicale (rythme, partition, harmonie) avec des approches calculatoires. Le temps musical s’y repr´ esente comme une dimension spatiale, ce qui permet un grand pouvoir d’abstraction. Le pionnier de ce type de logiciel est Patchwork [2]. On peut citer BACH [1] une biblioth` eque de MAX permettant de faire de la CAO dans une logique temps r´ eel.

OpenMusic est l’h´ eritier direct du langage PatchWork. PWGL s’inspire

´ egalement des bases propos´ ees par PatchWork. Ces environnements visuels simplifient et rendent abordable la programmation ` a l’aide de la notion “pat- ching”. Le “patching” consiste ` a connecter des boˆıtes entre elles. Ces boˆıtes peuvent ˆ etre des op´ erateurs ou des objets. Le r´ esultat est une vision graphique du programme pour l’utilisateur.

3.3.5 Les langages musicaux temps r´ eel

A la diff´ ` erence des logiciels CAO, les logiciels de temps r´ eel entremˆ elent l’ex´ ecution du programme et les calculs en temps born´ e. Ces applications sont cr´ e´ ees pour une utilisation en concert. C’est pourquoi les programmes doivent r´ eagir continuellement aux donn´ ees re¸ cues en entr´ ee du syst` eme (signaux audio, metronome, ´ ev´ enements). La r´ eaction ` a ces entr´ ees entraine des sorties qui doivent respecter au mieux certaines contraintes temporelles.

Max et PureData [25] sont des langages graphiques ayant un flux de donn´ ees r´ eactif. Ils permettent de traiter le signal en temps r´ eel, ce qui fait de ces logiciels de bons outils pour la performance et la cr´ eation d’applications interactives. Ceux-ci sont en revanche incapables d’ex´ ecuter et de repr´ esenter des structures compositionnelles complexes en temps r´ eel de par leur limitation en complexit´ e de calcul. D’autre part, ces logiciels ne poss` edent pas de vision ` a long terme.

3.3.6 Vers une mixit´ e de la CAO et des syst` emes temps r´ eel

L’opposition entre la composition et le performance (opposition temps

diff´ er´ e et temps r´ eel) au fur et ` a mesure des progr` es techniques, devient de

3 M ´ EDIA TEMPOREL 3.4 Pr´ esentation de OpenMusic

plus en plus floue. Cela se traduit par de nouveaux champs d’applications comme dans le Jeux Video et dans les syst` emes d’improvisation automatique (Improtek) [22].

De nouveaux outils se d´ eveloppent pour la programmation live en concert (live-coding) avec Chuck. Ce langage utilise des structures complexes de trai- tement sonore en temps r´ eel. Un autre outil moderne est le suivi de partition avec Antescofo.

3.4 Pr´ esentation de OpenMusic

OpenMusic (OM) est un logiciel de programmation visuel s’appuyant sur le langage de programmation Common Lisp Object System (CLOS). Ce langage est ` a la fois fonctionnel et orient´ e objet.

OM est d´ evelopp´ e par l’´ equipe Repr´ esentation Musicale (RepMus) de l’IRCAM depuis plus d’une vingtaine d’ann´ ees. L’interface visuelle se pr´ esente en deux vues principales :

— Les patchs ⁷ qui sont constitu´ es d’objets graphiques musicaux connect´ es entre eux. Ces connexions repr´ esentent les liaisons entre les objets (les d´ ependances de calculs).

Figure 1 – Exemple de patch dans OM 6.9.

7. Programmes visuels.

3 M ´ EDIA TEMPOREL 3.5 Antescofo

— Les maquettes ⁸ se repr´ esentent sous forme de patch compl´ et´ e par une timeline ⁹ (voir figure 2). De plus, la cr´ eation de connexions entre patch ` a l’int´ erieur de la maquette permet d’exprimer des contraintes temporelles directement entre objets temporels. On peut mettre en relation ces ma- quettes d’OM avec les partitions Iscore [17] un s´ equenceur OSC, qui ne permet que le contrˆ ole.

Figure 2 – Exemple de maquette de OM 6.9.

3.5 Antescofo un logiciel multim´ edia interactif

A titre d’exemple de syst` ` eme informatique musical tr` es interactif et n´ ecessitant des ordonnancements dynamiques de tˆ aches devant satisfaire ` a des relations temporelles complexes, nous d´ ecrivons bri` evement le logiciel Antescofo.

Antescofo (2008) est un logiciel de suivi de partition d´ evelopp´ e depuis 8 ans par l’´ equipe Mutant dans l’unit´ e Repr´ esentation Musical de l’IRCAM. Il s’agit d’un module logiciel sous forme de biblioth` eque pouvant se connecter avec MAX ou PureData.

Ce logiciel couple un syst` eme de suivi de partition avec un langage temps r´ eel r´ eactif et temporis´ e. Antescofo est utilis´ e principalement dans un contexte de performances mˆ elant des instruments de musique r´ eels ` a des dispositifs ´ electroniques de production de sons. On parle de pi` eces mixtes

´ electroniques-instrumentales

. L’objectif d’Antescofo est de permettre ` a la partie ´ electronique de r´ eagir en temps r´ eel au jeu du musicien humain, ` a partir de la d´ etection du tempo et de la position d’un interpr` ete sur une partition

8. Patch contenant des m´ edias temporels et des patchs ordonn´ es dans le temps.

9. R` egle temporelle horizontale permettant de lier la position des objets ` a une date pr´ ecise.

3 M ´ EDIA TEMPOREL 3.5 Antescofo

pendant qu’il joue.

Grˆ ace ` a la d´ etection en temps r´ eel du tempo de l’instrumentiste, le compo- siteur peut ´ ecrire les parties ´ electroniques de sa pi` ece en utilisant des notations temporelles musicales traditionnelles. Diff´ erentes strat´ egies de synchronisation et de rattrapage d’erreurs peuvent ˆ etre choisies par le compositeur, suivant le contexte musical, pour les actions duratives. Antescofo permet aussi de conditionner des actions ` a certaines caract´ eristiques comme l’interpr´ etation (acc´ el´ eration, pr´ esence ou non d’une certaine note. . . ), afin que la machine produise un r´ esultat

sous le contrˆ ole de l’interpr` ete

, dans le cadre par exemple d’

œuvres ouvertes

ou semi-improvis´ ees. Ainsi, le compositeur peut laisser ` a l’interpr` ete une certaine libert´ e, par exemple sur l’ordre d’ex´ ecution des passages, des r´ ep´ etitions, etc.

L’impl´ ementation des contraintes temporelles entre les actions sp´ ecifi´ ees par

un programme Antescofo n´ ecessite des strat´ egies d’ordonnancement complexes

et dynamiques, capables de g´ erer plusieurs ´ echelles de temps allant de la milli-

seconde (buffer audio) ` a l’heure (contrˆ oles ` a larges ´ echelles pour un op´ era par

exemple).

4 ORDONNANCEMENT

4 Ordonnancement

L’ordonnancement se d´ eroule dans un contexte d’ex´ ecution qui peut ˆ etre en temps r´ eel ou en temps diff´ er´ e. Dans ce stage, nous ne cherchons pas

`

a ordonnancer les actions en fonction des ressources disponibles mais ` a les ordonnancer dans le respect des dates butoirs que nous appellerons deadlines dans la suite. Dans cette partie nous nous concentrerons sur l’ordonnancement dans les syst` emes temps r´ eel.

Nous pr´ esentons ici quelques principes d’ordonnancement provenant de l’´ etat de l’art sur ce sujet, ainsi qu’une technique d’ordonnancement utilis´ ee dans le contexte du temps diff´ er´ e et le contexte du temps r´ eel que nous lions avec les probl` emes d’ordonnancement rencontr´ ees dans la “CAO interactive”.

4.1 Principe de l’ordonnancement

Nous avons besoin de formaliser quelques notions d’ordonnancement avant de nous attaquer ` a la suite. Dans [3] l’ordonnancement est d´ ecrit comme deux

´ etapes successives :

— Dans un premier temps le s´ equencement : consiste ` a construire un plan d’ex´ ecution selon la mani` ere de choisir la prochaine tˆ ache,

— Dans un second temps l’ordonnancement : consiste ` a choisir ` a quel moment envoyer vers un moteur d’ex´ ecution une tˆ ache en fonction de sa dur´ ee de compl´ etion.

On mod´ elise le traitement des ex´ ecutions par des tˆ aches. Une tˆ ache peut ˆ etre d´ ecrite par la loi d’arriv´ ee temporelle s´ eparant deux activations du groupe d’instructions ` a effectuer.

Soit τ = {τ 1 ...τ n } o` u τ i repr´ esente une tˆ ache et τ un ensemble de tˆ aches. Il existe trois lois d’arriv´ ee de tˆ aches :

— Tˆ ache ` a loi d’arriv´ ee p´ eriodique : la tˆ ache a une dur´ ee constante et une arriv´ ee p´ eriodique de valeur T _i . Ce type de tˆ ache est souvent utilis´ e pour des actions qui doivent ˆ etre appel´ ees avec r´ egularit´ e. Par exemple la lecture de buffers audio est p´ eriodique,

— Tˆ ache ` a loi d’arriv´ ee sporadique : le temps s´ eparant les deux tˆ aches poss` ede une borne inf´ erieure tel que tempsMin ≥ T i . Ce sont des

´

ev´ enements irr´ eguliers. Par exemple les tˆ aches de contrˆ ole sur les buffers audio (effets sur les buffers),

— Tˆ ache ` a loi d’arriv´ ee ap´ eriodique : mˆ eme chose mais sans borne

inf´ erieure (voir figure 3).

4 ORDONNANCEMENT 4.1 Principe de l’ordonnancement

Figure 3 – Rendu des lois d’arriv´ ees de tˆ ache.

La dur´ ee d’ex´ ecution d’une tˆ ache n’´ etant pas fixe, la pire dur´ ee d’ex´ ecution de la tˆ ache not´ ee WCET (Worst-Case Execution Time) est aussi un bon indicateur qui permet de faire une m´ ethode de validation de syst` emes temps r´ eel. Le WCET ` a la dur´ ee d’ex´ ecution la plus pessimiste d’une tˆ ache lors de son ex´ ecution par le syst` eme.

On mesure le WCET ` a l’aide d’une analyse statique du code qui analyse le flot d’ex´ ecution et les chemins d’ex´ ecution ` a emprunter. Le WCET va de pair avec le meilleur cas d’ex´ ecution not´ e BCET (Best Case Execution Time).

Cela permet de cr´ eer un ´ etalement des temps d’ex´ ecution entre ces deux bornes.

Par contre dans les syst` emes “grand public” actuels, le WCET a une tr` es grande valeur ¹⁰ . De plus le WCET arrive rarement et donc ne d´ enote pas d’un ph´ enom` ene tr` es r´ ealiste dans ces syst` emes. Ainsi on pr´ ef´ erera de nouvelles techniques de calcul de WCET statistique propos´ ees dans [12].

Il existe deux types d’ordonnancements diff´ erents d´ ependant des mod` eles d’invocation de l’ordonnanceur :

— Event Driven : ce type d’ordonnancement est aussi appel´ e ordonnan- cement asynchrone. Il consiste ` a invoquer l’ordonnanceur lors de la r´ eception d’un nouvel ´ ev´ enement ¹¹ . Une technique usuelle est de faire se- lon la tˆ ache ayant la plus grande priorit´ e (Hightest Priority First ou HPF)

— Time Driven : les invocations de l’ordonnanceur sont ind´ ependantes des

´

ev´ enements re¸ cus. Ce type d’ordonnanceur utilise l’horloge interne de la machine et peut par exemple demander un ordonnancement p´ eriodique (tick scheduler ) des travaux dans le temps.

Le nombre de tˆ aches n’est pas statique dans un syst` eme temps r´ eel . L’ajout de tˆ aches d´ eclench´ ees par des ´ ev´ enements au cours du temps n´ ecessite de faire

10. Cette grande valeur est due ` a l’apparition de r´ ecents processeurs plus complexes, du multicoeurs et de l’utilisation des caches.

11. Par exemple une nouvelle activation de tˆ ache.

4 ORDONNANCEMENT 4.1 Principe de l’ordonnancement

de l’ordonnancement dynamique.

Bien que nous ne sachions pas forc´ ement si une action doit avoir lieu, la dur´ ee des tˆ aches peut ˆ etre d´ eterministe. C’est le cas dans les syst` emes “hard real-time”. En ayant au pr´ ealable optimis´ e l’ordonnancement du syst` eme en question, il doit absolument assurer le respect des deadlines impos´ ees. Dans l’autre cas, “soft real-time” nous ne pouvons pas assurer une dur´ ee ex´ ecution fixe. Les dur´ ees d’ex´ ecution suivent des distributions statistiques que nous souhaitons rendre observables par un outil de mesure.

Ainsi dans le contexte temps r´ eel il existe plusieurs types de deadline que nous d´ efinissons ci-apr` es :

— hard deadline : si les deadlines ne sont pas respect´ ees peuvent entrainer une “catastrophe”,

— soft deadline : par exemple un rendu audio en retard n’est pas tr` es grave, la machine fait de son mieux pour rendre les r´ esultats au moment voulu (best-effort),

— firm deadline qui entraine l’abandon de la tˆ ache si la deadline est outrepass´ ee, cela sans catastrophe, mais diminue consid´ erablement la qualit´ e du rendu. Se r´ ef´ erer ` a la figure 4 provenant de [3].

Figure 4 – Fonction de coˆ ut des diff´ erents types de deadlines temps r´ eel.

Il existe de nombreuses m´ etriques pour mesurer l’efficacit´ e des ordonnance- ments r´ ealis´ es :

— i repr´ esente une tˆ ache donn´ ee,

— C i repr´ esente la date de compl´ etion de i,

— d i repr´ esente la date d’´ ech´ eance ou deadline de i,

— L i := C i − d i repr´ esente le retard ou lateness de i,

— E i := max (0, d i − C i ) repr´ esente l’avance ou le earliness de i,

— T i := max (0, C i − D i ) repr´ esente la lenteur ou le tardiness de i,

4 ORDONNANCEMENT 4.1 Principe de l’ordonnancement

— D i := |C i − d i | repr´ esente la d´ eviation absolue de i,

— S i := √

C i − d i repr´ esente la d´ eviation au carr´ e de i,

— U i :=

0 si C i ≤ D i

1 sinon repr´ esente la p´ enalit´ e unitaire de i,

— P i repr´ esente la p´ eriode d’arriv´ ee de i (cas p´ eriodique),

— P min i repr´ esente la p´ eriode minimale d’arriv´ ee de i (cas sporadique),

— O i repr´ esente l’oisivet´ e entre deux tˆ aches i et i+1 sur le mˆ eme proces- seur ¹² ,

— T ois _k

repr´ esente l’oisivet´ e entre deux tˆ aches (i et i+1) au sein d’un mˆ eme thread k et de la i-` eme tˆ ache appartenant ` a un pool de thread.

Ainsi, on peut raffiner notre d´ efinition d’une tˆ ache :

— τ est constitu´ e du triplet {C i , D i , P i } dans le cas p´ eriodique,

— τ est constitu´ e du triplet {C i , D i , P min i } dans le cas sporadique.

Les processus (aussi appel´ es threads) sont des programmes permettant d’ex´ ecuter des travaux (fonctions ` a ex´ ecuter). Ces processus peuvent dans les cas les plus simples avoir les ´ etats suivants :

— un thread “prˆ et” est en attente du CPU,

— un thread “bloqu´ e” est en attente d’un ´ ev´ enement ext´ erieur,

— un thread “´ elu” est entrain d’utiliser le CPU.

Figure 5 – La vie des processus : sch´ ema de la vie d’un thread.

Les syst` emes d’exploitation modernes multi-coeurs et multitˆ aches ´ etant pr´ eemptifs <sup>13</sup> ont une meilleure r´ eactivit´ e. Par contre en situation de comp´ etition o` u une tˆ ache poss` ede la priorit´ e sur les autres ils ne sont pas tr` es efficaces car le syst` eme continue ` a partager ses efforts sur l’ensemble des tˆ aches.

Pour simplifier l’´ etude nous consid´ ererons que la migration (pr´ eempter la tˆ ache et transf´ erer son contexte vers un autre coeur) a un coˆ ut temporel nul.

12. Appel´ e “idle time” dans l’´ etat de l’art.

13. Ceux-ci ont la capacit´ e de stopper une tˆ ache planifi´ ee en cours et de la reprendre ` a son

point d’interruption sur le mˆ eme coeur ou sur un autre s’il y a eu une migration.

4 ORDONNANCEMENT 4.2 Technique d’ordonnancement

Dans ce stage, ´ etant au niveau logiciel nous n’avons pas de contrˆ ole au niveau du noyau qui g` ere les coeurs de l’environnement.

Dans les cas des syst` emes “grand public”, les threads permettent l’ex´ ecution de tˆ aches au niveau logiciel. Ces threads les transmettent au noyau du syst` eme d’exploitation qui les utilise ensuite pour ex´ ecuter les travaux ` a r´ ealiser. Dans le cas des syst` emes d’exploitation les plus r´ ecents : les threads sont pratiques pour le “multi-tˆ aches” ¹⁴ .

L’utilisation d’un logiciel/syst` eme en temps r´ eel, impose des fluctuations temporelles des dur´ ees d’ex´ ecution des tˆ aches en raison de :

— la gestion non d´ eterministe des interruptions (pr´ eemption),

— un partage ´ equitable entre processeurs g´ er´ es au niveau du noyau,

— des micro-ex´ ecutions cr´ eant des fluctuations temporelles dues au m´ ecanisme de gestion des caches m´ emoire,

— la gestion de l’horloge interne,

— les optimisations d’utilisation des ressources.

Il existe deux mani` eres d’ex´ ecuter un plan dans un contexte d’ordonnance- ment dynamique :

— dynamic planning-base approaches : consiste ` a regarder au moment de l’ex´ ecution si le syst` eme temps r´ eel peut assurer le respect des deadlines cela en v´ erifiant la faisabilit´ e du plan avec un contrˆ ole d’admissibilit´ e des tˆ aches en fonction de leurs deadlines et de leurs priorit´ es,

— dynamic best-effort approaches : le syst` eme fait de son mieux pour respecter les deadlines rencontr´ ees sans v´ erifier la faisabilit´ e avant la fin suppos´ ee de la tˆ ache.

4.2 Une technique d’ordonnacement : Earliest Deadline First

Dans [31] nous est pr´ esent´ e un ensemble d’algorithmes du type Earliest Deadline First (EDF). Ces algorithmes doivent ex´ ecuter en premier la tˆ ache ayant son ´ ech´ eance avant les ´ ech´ eances des autres cela par rapport ` a l’ensemble des tˆ aches ` a effectuer.

Dans l’exemple ci-apr` es, nous avons l’arbre de d´ ependance des tˆ aches (voir figure 6) soumis ` a un l’algorithme d’ordonnancement EDF dans un cadre statique. Les tˆ aches propos´ ees respectent les dates d’´ ech´ eances ainsi que les

14. Pouvoir ex´ ecuter plusieurs programmes en mˆ eme temps.

4 ORDONNANCEMENT 4.2 Technique d’ordonnancement

dur´ ees pr´ esent´ ees dans le tableau suivant :

tˆ aches dur´ ee deadline

T1 3 3

T2 2 9

T3 4 7

T4 3 13

T5 3 15

Nous pr´ esentons une mani` ere graphique de repr´ esenter la planification ´ emise par le syst` eme avec un diagramme de Gantt, celui-ci permet de repr´ esenter la planification des diff´ erentes tˆ aches ` a effectuer (voir figure 7).

Figure 6 – Exemple de diagramme de tˆ aches d´ ependantes.

Figure 7 – Exemple de diagramme de Gantt pour l’exemple EDF.

Dans le cadre du temps r´ eel, EDF est largement utilis´ e car il est optimal dans diff´ erents cas. L’ajout dynamique de tˆ ache entraine une replanification de la s´ equence de travaux. Dans ce cas la figure 7 serait identique mais avec une barre de lecture qui en atteignant des instants pr´ ecis, d´ eclencherait l’arriv´ ee d’´ ev´ enements.

On s’assure que la replanification est correcte via “la r` egle de Jackson” : dans les cas o` u il n’y a pas pr´ eemption, toute s´ equence est optimale si les travaux sont ordonn´ es dans un ordre non d´ ecroissant des deadlines.

Dans les cas pr´ eemptifs avec appel synchrone p´ eriodique de tˆ ache cela se v´ erifie si et seulement si le facteur d’utilisation du processeur U est inf´ erieur ou

´ egal ` a 1 tel que U = P n i=1

C

T

≤ 1 [16]

4 ORDONNANCEMENT 4.3 Ordonnancement dans les logiciels de CAO

— EDF est optimal pour l’ordonnancement des tˆ aches sporadiques ou p´ eriodiques pr´ eemptives [23],

— EDF est optimal pour l’ordonnancement de tˆ aches sporadiques ou p´ eriodiques non pr´ eemptives non concr` etes [14],

— l’optimalit´ e n’est plus garantie pour des tˆ aches p´ eriodiques concr` etes non pr´ eemptives [14].

Les algorithmes EDF pour des tˆ aches ind´ ependantes dans un cas d’ordon- nancement fixe d´ efini au niveau des tˆ aches (Fixed Priority at Job Level (FPJL)) ont pour but d’assurer la faisabilit´ e des tˆ aches ainsi que leur optimalit´ e dans les cas de test sur des mat´ eriaux monoprocesseurs. De plus en cas de surcharge du syst` eme, l’algorithme EDF est soumis ` a un “effet avalanche”. Les ´ ech´ eances ne sont pas respect´ ees en raison du retard cumul´ e.

4.3 Probl´ ematique de l’ordonnancement dans les logiciels multim´ edia modernes de type CAO

Les logiciels multim´ edia modernes doivent souvent jouer ` a la fois sur les

´ echelles du temps r´ eel et du temps diff´ er´ e. C’est le cas de la CAO o` u les nouvelles techniques d’ordonnancement des tˆ aches qui lui sont transmises sont

`

a d´ evelopper. En fonction des ´ ev´ enements re¸ cus par le syst` eme, des mises ` a jour du plan ¹⁵ sont n´ ecessaires et demandent une phase de r´ e-ordonnancement ¹⁶ .

Dans [21] un exemple propos´ e d’ordonnancement dynamique est la modi- fication de la s´ equence d’accords faite par ImproteK dans le futur, selon des r´ eactions ` a des changements de param` etres ext´ erieurs. Pour le syst` eme d’or- donnancement cela se traduira par des changements ` a faire en ligne de la suite d’accords. Il modifie son plan sur la prochaine fenˆ etre de temps (voir figure 8 inspir´ e de [21]).

Figure 8 – Rendu de changement dynamique de suite d’accords.

15. S´ equence d’op´ eration ordonn´ ee dans le temps ` a ex´ ecuter.

16. Devoir reconstruire un plan d’ex´ ecution.

5 ENVIRONNEMENT DU STAGE

5 Environnement du stage et d´ eveloppement

Cette partie a pour objectif de pr´ esenter l’environnement de programmation du stage et les travaux r´ ealis´ es au sein d’OpenMusic 7 (OM7). La description du logiciel OpenMusic dans 3.4 concerne OpenMusic 6.9 et ses ancˆ etres. OM7 est r´ eactif, nous le pr´ esentons ci-apr` es.

5.1 Vers un logiciel de CAO r´ eactif

Les avanc´ ees r´ ecentes dans le d´ eveloppement de OpenMusic ont introduit des capacit´ es r´ eactives pour le langage visuel [10] [8]. Ces d´ eveloppements s’int` egrent dans une optique d’homog´ einisation de l’ensemble des travaux de la CAO au cours du projet EFFICAC(e) [9].

Figure 9 – Aper¸ cu de l’environnement OM7 : Maquette, Patches g´ en´ erant des s´ equences MIDI. Dans cet exemple le dernier patch n’a pas encore ´ et´ e calcul´ e.

Le concept de r´ eactif va de pair avec la notion d’´ ev´ enement. Lorsqu’un nouvel ´ ev´ enement arrive le syst` eme doit r´ eagir. Un nouveau syst` eme d’or- donnancement dynamique dans OM7 a ´ et´ e d´ evelopp´ e [7]. En effet, OM joue d´ esormais ` a la fois dans le contexte hors-ligne (composition) et dans le contexte en-ligne (performance) en mˆ elant leurs techniques de traitement des donn´ ees.

Les processus musicaux de composition et de performance s’unissent ` a pr´ esent

dans un mˆ eme cadre, toutes interactions deviennent partie int´ egrante de ce

cadre. Qu’ils soient g´ en´ eratifs pour la composition ou transformatifs pour la

performance.

5 ENVIRONNEMENT DU STAGE 5.2 Statistiques dans OM

Un processus compositionnel dans un syst` eme se divise en trois ´ etapes :

— Le calcul (par le “moteur de calcul”) consiste ` a transformer une s´ equence d’instructions en objets musicaux,

— L’ordonnancement (par l’ordonnanceur) consiste ` a transformer les objets musicaux en s´ equences temporelles d’actions appel´ ees plan,

— La restitution (par le r´ epartiteur) consiste ` a d´ eclencher les actions du plan en temps voulu (voir figure 10).

Figure 10 – Fonctionnement de l’ordonnancement dans OM7.

L’ordonnancement est ici “demand-driven” et peut r´ eordonnancer le plan, ce qui est n´ ecessaire car les donn´ ees musicales peuvent r´ eagir ` a un ´ ev´ enement.

Notons que ces ´ ev´ enements sont g´ er´ es uniform´ ement, qu’ils proviennent de l’environnement ext´ erieur ou du syst` eme lui mˆ eme.

L’outil de mesure cr´ e´ e au cours de ce stage a pour but d’aider la machine ` a produire des r´ esultats en temps et en heure voulue en l’adaptant au contexte d’utilisation. Cela est possible par l’observation du temps de calcul d’une mˆ eme tˆ ache appel´ ee p´ eriodiquement, par exemple la tˆ ache de lecture des buffers audio utilis´ es dans un logiciel. Dans cette optique nous pouvons adapter l’horizon ¹⁷

`

a la charge de travaux demand´ es.

5.2 Statistiques sur l’environnement OM

Afin d’avoir plus d’informations sur le d´ eroulement des programmes dans le syst` eme nous avons impl´ ement´ e une API de statistique des temps d’ex´ ecution.

17. Jusqu’o` u regarder dans le futur pour produire un plan d’ex´ ecution.

5 ENVIRONNEMENT DU STAGE 5.3 Vers un moteur multithread

Ainsi, nous r´ ecup´ ererons le temps de commencement d’une tˆ ache, le temps de fin d’une tˆ ache et l’instant o` u est cens´ e commencer la tˆ ache. Grˆ ace ` a ces mesures, nous pourrons r´ ecup´ erer le temps d’ex´ ecution d’une tˆ ache (debut−f in) et le retard d’une tˆ ache (debut − debutSuppose). Dans la mˆ eme lign´ ee nous r´ ecup´ erons les temps d’ex´ ecution des op´ erations de l’ordonnanceur.

En d´ efinitive, nous r´ ecup´ erons la moyenne de la dur´ ee d’une tˆ ache, sa m´ ediane, sa variance, son ´ ecart max (appel´ e aussi range) et ` a partir de cela un histogramme de distribution.

— La moyenne se d´ efinit par ¯ x = _n ¹ P n i=1 x i ,

— la m´ ediane satisfait l’´ egalit´ e : P(X ≤ m) ≥ ¹ ₂ et P(X ≥ m) ≥ ¹ ₂ ,

— la variance est d´ efinie par Var(X ) ≡ V (X ) ^def = E

(X − E [X]) ² . ,

— l’´ ecart type se caract´ erise par σ X = p

Var(X).

Voici les ´ etapes du “protocole” de prise d’informations et d’affichage pour chaque ex´ ecution.

— I : La prise d’information se fait ` a partir d’une maquette d’OM.

D` es que la lecture est lanc´ ee les donn´ ees sont int´ egr´ ees en temps r´ eel (mise ` a part la fr´ equence mise ` a jour a posteriori) dans une structure de donn´ ees.

— II : On r´ ecup` ere ensuite les donn´ ees qui nous int´ eressent. Puis nous les enregistrons dans des fichiers par types de donn´ ees.

— III : Enfin on affiche les r´ esultats automatiquement via une com- mande ouvrant les fichiers sur Gnuplot ^a sous forme de graphes et d’histogrammes

a. Traceur permettant d’afficher des fonctions sur un graphe 2D ou 3D..

5.3 D’un moteur de calculs monothread vers un moteur multithread

Dans l’ancienne architecture d’OM le moteur de calcul ´ etait monothread.

Nous avons d´ ecid´ e durant ce stage de r´ ealiser un pool de threads fonctionnant

de la fa¸ con d´ ecrite dans la figure 11.

5 ENVIRONNEMENT DU STAGE 5.4 Donn´ ees r´ ecolt´ ees

Figure 11 – Fonctionnement du pool de threads.

A l’´ ` etape (1), nous demandons au thread de prendre les tˆ aches. D` es qu’une nouvelle tˆ ache est envoy´ ee dans la file de tˆ ache, on signale ` a tous les threads qu’ils peuvent se servir. L’´ etape (2) consiste ` a ex´ ecuter le calcul demand´ e et envoyer le r´ esultat en sortie.

5.4 Sauvegarde des donn´ ees r´ ecolt´ ees

Suite ` a l’ex´ ecution d’une maquette, nous enregistrons dans des fichiers textes les donn´ ees r´ ecolt´ ees (temps d’ex´ ecution, retard, etc.). Ces donn´ ees sont tri´ ees en fonction d’un thread pr´ ecis ou du nombre de threads actifs au moment du calcul. Le nombre de threads actifs permet de se rendre compte de la charge de travail demand´ ee. En effet, le nombre de threads actifs repr´ esente le nombre de threads en cours d’ex´ ecution dans les processeurs. Avec un MacBook Pro (mi-2015) poss´ edant un processeur Intel Core i7, nous pouvons observer :

— de 1 ` a 4 thread : occupation des coeurs physiques de la machine,

— de 3 ` a 8 thread : distribution de plus en plus ´ elev´ ee dans les coeurs logiques (avec l’hyperthreading ¹⁸ ),

— 8 et + : saturation en cas de surcharge ¹⁹ de l’ensemble des coeurs lo- giques. Se r´ ef´ erer ` a la figure 12.

Nous visualisons les r´ esultats via Gnuplot pour obtenir des graphes bidi- mensionnels et tridimensionnels o` u nous pouvons effectuer des observations.

18. Un coeur physique de la machine cr´ ee deux processeurs logiques agissants comme un coeur (propres registres, pr´ eemption individuelle.)

19. Il n’y a pas d’oisivet´ e du processeur.

5 ENVIRONNEMENT DU STAGE 5.4 Donn´ ees r´ ecolt´ ees

Figure 12 – Activit´ e des processeurs en fonction du nombre de threads occup´ es pour une mˆ eme tˆ ache de calcul.

Ces donn´ ees r´ ecolt´ ees peuvent ˆ etre pond´ er´ ees par la fr´ equence du CPU obtenue via Intel(R) Power gadget. L’outil d’Intel permet d’observer le comportement de l’horloge interne de la machine. En effet pour des raisons de performance de la machine et du mat´ eriel, les processeurs ne tournent pas ` a plein r´ egime en permanence. Par cons´ equent la fr´ equence du CPU oscille et permet d’´ eviter la surchauffe de la machine, se r´ ef´ erer ` a la figure 13.

Nous analysons trois types d’ex´ ecutions utiles dans la CAO et qui de- mandent des actions diff´ erentes au syst` eme :

— l’ex´ ecution et le calcul d’op´ erations simples unitaires qui modifie des zones m´ emoire,

— l’allocation m´ emoire qui demande au syst` eme de r´ eserver de la place dans la m´ emoire,

— les calculs et la lecture de buffers audio qui doivent chercher en m´ emoire les donn´ ees afin de les lire.

Ces observations permettent de mieux comprendre le comportement du syst` eme en fonction du contexte o` u il se trouve. L’op´ eration de r´ e-ordonnancement du plan en fonction du contexte construira des “plans adaptatifs” . Par cons´ equent les observations de statistiques concernant les types d’ex´ ecutions seront utiles

`

a la cr´ eation de plans adaptatifs. De plus, en fonction de l’horizon choisi, le

nombre d’actions r´ ecup´ er´ ees par le r´ epartiteur devient plus important ou plus

5 ENVIRONNEMENT DU STAGE 5.5 D´ ependances entre tˆ aches

Figure 13 – Vue de l’interface graphique d’Intel(R) Power gadget qui permet d’observer le changement de fr´ equence des coeurs. Dans le travail nous utilisons le fichier de log qui permet de tracer ces changements.

faible. L’horizon est la distance temporelle d’acquisition d’actions par rapport

`

a la barre de lecture dans le plan.

5.5 Gestion des d´ ependances entre tˆ aches

Nous avons ensuite g´ en´ eralis´ e cette construction ` a la forme de “directed acycled graph” (DAG) pour permettre des interd´ ependances entre branches, ce qui n’est pas possible avec des arbres (voir figure 14).

Figure 14 – Repr´ esentation d’arbre de d´ ependance k-aire en forme binaire et

DAG.

5 ENVIRONNEMENT DU STAGE 5.5 D´ ependances entre tˆ aches

Cette structure a ´ et´ e r´ ealis´ ee dans le but de pouvoir repr´ esenter les tˆ aches d´ ependantes au sein d’OM. Un groupe des boˆıtes connect´ ees entre elles ´ equivaut

`

a une telle structure. Ces connexions montrent la d´ ependance d’une boˆıte dont l’entr´ ee d´ epend du r´ esultat de la sortie de l’autre.

Figure 15 – Gestion de tˆ aches d´ ependantes dans le moteur d’ex´ ecution d’OM.

Dans la figure 15, les ´ etapes (1) et (2) sont les mˆ emes que dans la figure 11, l’´ etape (3) signifie qu’une fois le calcul de la tˆ ache termin´ e, on d´ ecr´ emente le compteur du/des parent(s) de la tˆ ache qui vient d’ˆ etre ex´ ecut´ ee. Une fois que le compteur d’une tˆ ache en attente est ` a z´ ero, on passe ` a l’´ etape (4) qui consiste

`

a mettre la tˆ ache dans la file de tˆ aches. Si elle aussi elle a un/des p` ere(s) elle

devra le(s) d´ ecr´ ementer.

6 R ´ ESULTATS PAR L’OBSERVATION

6 R´ esultats par l’observation

En effectuant des observations sur le “Niveau 1” des couches de contrˆ ole du syst` eme (cf partie 2), nous esp´ erons pouvoir faire des d´ eductions sur le com- portement des niveaux sup´ erieurs dans le but de permettre l’adaptativit´ e du syst` eme notamment dans des contextes de surcharge de travail ou perturbation du syst` eme. Dans cette partie nous ´ emettons un certain nombre d’hypoth` eses que l’on esp` ere retrouver par l’observation dans des cas pratiques.

6.1 Notions pour l’observation

— le nombre de threads actifs est le nombre de threads occup´ es au cours d’une ex´ ecution,

— les tˆ aches d´ ependantes sont repr´ esent´ ees par un DAG,

— les tˆ aches en attentes sont des tˆ aches d´ ependantes contenues dans une structure DAG. Ces tˆ aches attendent que leurs fils finissent d’ˆ etre ex´ ecut´ es, afin que leur compteur soit d´ ecr´ ement´ e jusqu’` a z´ ero pour ˆ etre ex´ ecut´ ees ` a leur tour,

— l’epsilon pourcentage permet de calculer le pourcentage de variation par rapport ` a un temps nominal d’une tˆ ache,

— la fr´ equence dont on parlera d´ esigne la fr´ equence ` a laquelle tourne le CPU ` a un moment donn´ e,

— la r` egle des 10% : la distribution des dur´ ees des ex´ ecutions des tˆ aches varie majoritairement autour de la moyenne des dur´ ees des ex´ ecutions plus ou moins 10%. Nous avons la majorit´ e des temps relev´ es dans cette

“tranche”,

— un logiciel est dans un contexte de surcharge si l’oisivet´ e T ois _k

(se r´ ef´ erer

`

a 4.1) de tous les threads k du pool de threads pour toutes les tˆ aches i d’un groupe de tˆ aches sont nul. Autrement dit, le contexte de surcharge d’un logiciel a lieu quand un groupe de tˆ aches est calcul´ e sans interruption,

— un environnement multiprocesseur est en situation de surcharge si l’oi- sivet´ e des processeurs est proche de 0 pendant une certaine dur´ ee. On calcule l’oisivet´ e total en pourcentage avec : O total = 100 − C total o` u C total est le taux de charge en pourcentage qui ´ equivaut ` a la charge de l’ensemble des processeurs.

6.2 Observations

6.2.1 Lib´ eration de m´ emoire p´ eriodique dans LispWorks

Plusieurs conclusions ont ´ et´ e possibles ` a partir de l’observation des temps

d’ex´ ecution. Par exemple, sur un long test de fonction allouant de la m´ emoire,

on peut s’apercevoir du passage du ramasse-miettes (garbage collector) de Lisp-

Works . On observe que le temps d’ex´ ecution augmente soudainement de fa¸ con

p´ eriodique. En effet l’allocation m´ emoire marche par g´ en´ erations de segments

6 R ´ ESULTATS PAR L’OBSERVATION 6.2 Observations

m´ emoires ²⁰ . Pour r´ esum´ e, le passage p´ eriodique du ramasse-miettes influe sur la dur´ ee des ex´ ecutions.

6.2.2 Nombre de threads optimal dans le pool de threads

Sur la figure 16, on peut observer qu’entre 4 et 8 threads, nous sommes ` a une vitesse optimale. On utilisera plutˆ ot 8 threads en vue de pr´ evenir certains cas o` u des threads peuvent ˆ etre bloqu´ es trop longtemps et se retrouve “moins productifs”. Par exemple dans les cas :

— d’une attente d’un appel syst` eme,

— ou d’une attente pour retrouver un ´ el´ ement dans la m´ emoire. ²¹

Figure 16 – Une fonction repr´ esentant le temps total d’ex´ ecution d’une ma- quette avec une fonction allouant de la m´ emoire et une fonction calculatoire en fonction du nombre de threads du pool.

20. Voir : http ://www.lispworks.com/documentation/lw70/LW/html/lw-78.htm#pgfId- 889356

21. Parcours de m´ emoire hi´ erarchique, sur plusieurs pages m´ emoire, ce qui peut ˆ etre tr` es

long.

6 R ´ ESULTATS PAR L’OBSERVATION 6.3 Etude : Tˆ ache de calcul

Dans le cadre de l’adaptation dynamique ces r´ esultats nous int´ eressent. Dans le pool de threads, il est possible d’ajouter ou de retirer dynamiquement des threads. Cela peut s’av´ erer pratique dans les cas de transition entre un cas de surcharge de tˆ aches et un cas de non surcharge.

6.2.3 La variation d´ epend de la fr´ equence

Au cours du stage nous avons pu ´ etablir une supposition importante : la dispersion des temps d’ex´ ecution est d´ ependante de la fr´ equence du CPU au moment de l’ex´ ecution. Ainsi si nous pond´ erons les temps d’ex´ ecution par fr´ equences au sein de cette ex´ ecution. Le r´ esultat est la diminution de la va- riance par rapport au cas classique.

6.3 Etude de cas : tˆ ´ ache de calcul ` a travers les statistiques

Nous donnons ici un panel de statistiques et d’interpr´ etations ` a propos d’une tˆ ache de calcul <sup>22</sup> . On comparera deux cas, le cas o` u seul le programme demande de la puissance de calcul du CPU, et le cas o` u on sature les bus d’informations du syst` eme avec un autre logiciel ²³ , tout en ex´ ecutant la maquette. Le nombre de threads pr´ esents dans le pool de threads est un param` etre ` a prendre en compte. Parmi les nombreux fichiers g´ en´ er´ es, voici une s´ election avec des commentaires.

Figure 17 – “is-premier”, 1 thread, dur´ ee d’ex´ ecution et son histogramme.

La figure 17 v´ erifie l’hypoth` ese des 10%. En effet la fonction de distribution (` a une exception pr` es) des ex´ ecutions se trouvent entre 50000 et 60000 avec une moyenne de 55000 microseconde (µs) environ (99.5% des valeurs se trouve

22. La tˆ ache de calcul utilis´ ee pendant toute cette ´ etude de cas porte sur la tˆ ache “is- premier” appel´ ee toutes les 20 millisecondes (ms). Cette fonction cherche na¨ıvement si 25000 est premier en passant en revue s’il est divisible ou non par les nombres le pr´ ec´ edant.

23. de mani` ere ` a utiliser un maximum de coeur.

6 R ´ ESULTATS PAR L’OBSERVATION 6.3 Etude : Tˆ ache de calcul

dans cette ´ ecart). L’´ ecart max du fait de l’exception entraˆıne que le coefficient

“variance/ecartmax” est assez haut. De plus l’allure de l’histogramme est une distribution gaussienne.

L’´ etape suivante est donc de v´ erifier si notre hypoth` ese quant aux fr´ equences variant dans le CPU lors de l’ex´ ecution est un facteur d’instabilit´ e. Toutes les 20ms (le pas minimal propos´ e par l’outil intel) les fr´ equences sont mesur´ ees au cours de l’ex´ ecution. On obtient la figure 18.

Figure 18 – “is-premier”, 1 thread, fr´ equence du CPU lors de son ex´ ecution et son histogramme.

On observe donc que la fr´ equence oscille de quelque giga hertz (Ghz). Grˆ ace

`

a l’outil d’Intel nous avons aussi les dates o` u ont lieu les mesures de fr´ equences.

En pond´ erant les temps d’ex´ ecution par les fr´ equences sur chaque sous-partie

de la mani` ere d´ ecrite dans la figure 19 :

6 R ´ ESULTATS PAR L’OBSERVATION 6.3 Etude : Tˆ ache de calcul

Figure 19 – Repr´ esentation de l’horodatage de la tˆ ache et prise de valeur de fr´ equence de l’ordinateur.

En suivant la formule :

(t f1 − t debut−task )/f0 + (t f2 − t f1 )/f 1 + ... + (t f n − t f n−1 )/f n − 1 Le temps d’ex´ ecution pond´ er´ e ainsi permet d’obtenir la figure 20 :

Figure 20 – “is-premier”, 1 thread, dur´ ee d’ex´ ecution pond´ er´ ee par fr´ equence et son histogramme.

On peut observer que le coefficient “variance/ecartmax” est pass´ e de 14.08 en observant l’ex´ ecution normale ` a 8.86 en observant les temps d’ex´ ecution pond´ er´ es par les fr´ equences du CPU. Cela d´ emontre que la fr´ equence instaure une hausse de l’ind´ eterminisme au sein du syst` eme.

Dans la figure 17 sur les ex´ ecutions sans pond´ eration, remarquons que la

dur´ ee d’une ex´ ecution dure en moyenne 55ms alors que la fonction est appel´ ee

tous les 20ms, ainsi nous devons ajouter un certain nombre de threads pour

diminuer le retard (voir figure 21).

6 R ´ ESULTATS PAR L’OBSERVATION 6.3 Etude : Tˆ ache de calcul

Figure 21 – “is-premier”, 1 thread, retard cumul´ e au cours de l’ex´ ecution de la maquette.

On observe que le retard cumul´ e croˆıt de fa¸ con lin´ eaire. Pour faire baisser ce retard nous utilisons donc le moteur multithread en lui affectant non pas un mais plusieurs threads (nous avons vu pr´ ec´ edemment que le nombre de threads optimal se situe entre 4 et 8 threads)(voir figure 22).

Figure 22 – “is-premier”, 4 et 8 threads, retard cumul´ e.

On observe que le retard cumul´ e croˆıt bien moins vite que dans les cas monothread. De plus les retards cumul´ es finaux (le dernier point par threads de chaque graphe) paraissent tr` es proches dans les cas “multithread´ es”.

L’allure des graphiques au niveau du cumul de retard de chaque thread se

ressemble. Ainsi on peut conjecturer que l’ordinateur traite ´ equitablement les

demandes de chaque thread.

6 R ´ ESULTATS PAR L’OBSERVATION 6.3 Etude : Tˆ ache de calcul

De plus, comme il y a du retard cela implique que les threads sont tous actifs durant l’ex´ ecution sauf au d´ ebut et ` a la fin (voir figure 23).

Figure 23 – “is-premier”, 8 threads, en terme de temps d’ex´ ecution par threads actifs.

De plus le temps d’oisivet´ e des threads doit ˆ etre faible (voir figure 24).

Figure 24 – “is-premier”, 8 threads, en terme de temps d’oisevet´ e par threads.