FR 3035243 A1 20161021 FR 1553478 A 20150420 3035243 PLACEMENT D'UNE TÂCHE DE CALCUL SUR UN PROCESSEUR FONCTIONNELLEMENT ASYMETRIQUE Domaine de l'invention L'invention concerne les processeurs multi-coeurs en général et la gestion du placement de tâches de calcul sur des processeurs multi-coeurs fonctionnellement asymétriques en particulier. Etat de la Technique Un processeur multi-coeurs peut comprendre une ou plusieurs extensions matérielles, destinées à accélérer des parties de codes logiciels très spécifiques et difficilement parallélisables. Par exemple, ces extensions matérielles peuvent comprendre des circuits pour du calcul en virgule flottante ou du calcul vectoriel. Un processeur multi-coeurs est dit « fonctionnellement asymétrique » quand certaines extensions font défaut à certains coeurs de processeurs, c'est-à-dire quand au moins un coeur du processeur multi-coeurs ne possède l'extension matérielle requise pour l'exécution d'un jeu d'instructions donné. Il existe un jeu d'instruction commun à tous les coeurs et un jeu d'instruction spécifique qui est exécutable uniquement par certains coeurs prédéfinis. En faisant l'union de tous les jeux d'instructions des coeurs composant le processeur multi-coeurs, toutes les instructions (de l'application) sont représentées. Un processeur fonctionnellement asymétrique peut se caractériser par une distribution (ou association) inégale des extensions aux coeurs de processeurs. 2 303 52 43 La gestion d'un processeur multi-coeurs fonctionnellement asymétrique pose plusieurs problèmes techniques. Un de ces problèmes techniques consiste à gérer efficacement le placement des tâches de calcul sur les 5 différents coeurs de processeur. Les applications logicielles utilisent ces extensions matérielles d'une manière dynamique, c'est-à-dire qui varie au cours du temps. Pour une même application, certaines phases de calcul vont utiliser presque à 10 pleine charge une extension donnée (e.g. des calculs sur des données de type virgule flottante) tandis que d'autres phases de calcul l'utiliseront peu voire pas du tout (e.g des calculs sur des données de type entier). Utiliser une extension n'est pas toujours efficace en termes de performance ou d'énergie (« qualité » d'utilisation). 15 Les travaux publiés concernant le placement de tâches de calcul sur des processeurs multi-coeurs fonctionnellement asymétriques ne décrivent pas de solutions satisfaisantes. 20 Le document de brevet W02013101139 intitulé « PROVIDING AN ASYMMETRIC MULTICORE PROCESSOR SYSTEM TRANSPARENTLY TO AN OPERATING SYSTEM » divulgue un système comprenant un processeur multi-coeurs avec plusieurs groupes de coeurs. Le second groupe peut être d'une architecture de jeu d'instructions (ISA) différente 25 du premier groupe, ou bien relever de la même architecture ISA définir mais avec un niveau de puissance et de performance des supports différents. Le processeur comprend en outre une unité de migration qui traite les demandes de migration pour un certain nombre de scénarios différents et provoque un changement de contexte pour migrer dynamiquement un processus à partir d'un second coeur à un premier coeur du premier groupe. Ce changement de contexte matériel 3 3035243 dynamique peut être transparent pour le système d'exploitation. Cette approche comporte des limitations par exemple en matière de flexibilité de placement et de dépendance au jeu d'instructions. Il existe 5 un besoin pour des procédés et systèmes pour la gestion de tâches de calcul sur des processeurs multi-coeurs fonctionnellement asymétriques, les coeurs de processeurs étant associés à une ou plusieurs extensions matérielles. 10 Résumé de l'invention La présente invention concerne un procédé pour la gestion d'une tâche de calcul sur un processeur multi-coeurs fonctionnellement asymétrique, au moins un coeur dudit processeur étant associé à une ou plusieurs 15 extensions matérielles, le procédé comprenant les étapes consistant à recevoir une tâche de calcul associée à des instructions exécutables par une extension matérielle; recevoir des données de calibration associées à l'extension matérielle; et déterminer un coût d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration. Des 20 développements décrivent la détermination des données de calibration notamment par comptage ou par calcul (en ligne et/ou hors ligne) des classes des instructions exécutées, l'exécution d'un ensemble prédéfini d'instructions représentatif de l'espace d'exécution de l'extension, la prise en compte d'aspects énergétiques et de température, la traduction ou 25 l'émulation d'instructions ou le placement de tâches de calcul sur les différents coeurs. Des aspects de système et de logiciel sont décrits. Selon un mode de réalisation, l'invention est implémentée au niveau matériel (« hardware ») et du système d'exploitation. L'invention récupère 30 et analyse certaines informations des derniers quanta d'exécution (temps alloué par l'ordonnanceur à la tâche sur un coeur) et ainsi estime le cout 4 3035243 du futur placement de tâche sur différents types de coeurs. Avantageusement selon l'invention, le placement de tâche est flexible et transparent pour l'utilisateur. 5 Avantageusement, le procédé selon l'invention effectue le placement des tâches de calcul en fonction d'objectifs plus diversifiés et globaux que les solutions connues de l'état de la technique qui s'en tiennent aux seules instructions associées aux tâches de calcul. En effet, selon les solutions 10 connues, le placement des tâches de calcul impliquant l'allumage ou l'extinction d'un ou de plusieurs coeurs est réalisé en considérant seulement l'utilisation « stricte » de l'extension. En effet, un coeur ne comprenant pas d'extensions ne peut pas exécuter des instructions visant une ou plusieurs extensions particulières. Par suite, les solutions 15 actuelles examinent si une extension est utilisée (e.g. placement de l'application sur un coeur avec extension) ou n'est pas utilisée (e.g. placement sur un coeur sans extension). En d'autres termes, les approches connues considèrent la présence d'appel de telles extensions au sein du code source mais procèdent au placement des tâches 20 exclusivement en fonction des instructions de code et ignorent en particulier tout autre critère, notamment énergétique. D'autres approches connues se fondent sur une analyse du code source et de l'emploi planifié d'extensions matérielles, procèdent à des mutations de code, mais sans estimer des critères comprenant par exemple la dégradation de 25 performance ou d'énergie. Avantageusement, l'invention peut répondre aux besoins dits « multiobjectifs » auxquels doit satisfaire un ordonnanceur de tâche tels que a) la performance, b) l'efficacité énergétique et c) les contraintes thermiques 30 (« dark-silicon »). Certains modes de réalisation permettent d'augmenter le nombre de coeurs d'un processeur multi-coeurs, tout en gardant une 5 3035243 efficacité performance/énergie/surface élevée. L'effort de programmation additionnelle reste quant à lui réduit. Avantageusement selon l'invention, la prédiction des coûts et des gains 5 d'exécution d'une tâche donnée sur chacun des différents coeurs d'un système hétérogène peut être effectués de manière dynamique. Avantageusement, le procédé selon l'invention tient compte de critères dynamiques liés à l'exécution d'un programme. Actuellement, 10 l'exploitation d'une extension matérielle par un code logiciel est dictée soit explicitement par le programmeur du code, soit effectuée automatiquement par le compilateur. La compilation d'un logiciel étant le plus souvent faite hors-ligne, le programmeur ou le compilateur, ne peut fonder son choix d'exploiter ou non une extension que sur des critères qui 15 sont liés au logiciel lui-même, et non sur des critères dynamiques à l'exécution du programme. Sans information sur l'environnement d'exécution (charge de travail, ordonnancement instantané des tâches, disponibilité des ressources), il est généralement impossible de déterminer à l'avance s'il faut ou non exploiter une extension matérielle 20 donnée. Le procédé selon l'invention permet de prédire et/ou d'estimer l'utilisation d'une ou de plusieurs extensions matérielles. Avantageusement selon l'invention, il devient possible d'implémenter une stratégie dynamique d'ordonnancement et de placement de tâches, levant 25 différentes contraintes telles que (i) la prédictibilité et l'interopérabilité en utilisation de systèmes hétérogènes contraints (asymétrie fonctionnelle avec base commune) et (ii) l'optimisation au regard d'objectifs globaux du système (e.g. performance, consommation et surface), permise au moyen d'une prédiction rapide, dynamique et transparente de l'exécution d'un 30 code donné sur un coeur donné. 6 3035243 Avantageusement, certains modes de réalisation de l'invention comprennent des étapes de prédiction quant à l'utilisation des extensions, ce qui peut avantageusement optimiser l'efficacité énergétique et optimiser les performances de calcul. Ces modes de réalisation peuvent 5 en particulier laisser une certaine liberté à l'ordonnanceur quant au choix des coeurs sur lesquels exécuter les différentes phases de programme. Avantageusement, des résultats expérimentaux ont montré que, n'étant plus contraint par le jeu d'instruction, la dépendance à la taille de quanta 10 est très réduite. Le pourcentage de temps passé sur un corps basic sont très proches quelques soit la taille de quanta, ce qui permet d'être indépendant d'autres paramètres de l'ordonnanceur. Avantageusement, le procédé selon l'invention permet d'optimiser la 15 consommation énergétique, y compris dans le cas d'une faible utilisation d'une extension. Avantageusement, le procédé selon l'invention permet de placer une tâche sur un processeur, que ce processeur soit associé à une extension 20 matérielle ou non, en fonction de l'implémentation de la tâche (donc avec ou sans exploitation de l'extension). Par suite, un ordonnanceur peut optimiser l'énergie ou la performance dynamiquement sans se soucier de l'implémentation initiale de la tâche. 25 Avantageusement, l'invention permet de prédire ou déterminer dynamiquement l'intérêt de l'utilisation d'une ou plusieurs extensions matérielles et de placer les tâches de calcul (i.e. d'allouer ces tâches aux différents processeurs et ou coeur de processeurs) en fonction de cette prédiction. 30 Avantageusement, le procédé selon l'invention permet de retarder la 7 3035243 décision d'utiliser ou non une extension à l'exécution, donne au programmeur un niveau d'abstraction plus élevé et fournit au logiciel du système une liberté de décision accrue permettant plus d'optimisation en matière d'ordonnancement. Une fois cette flexibilité obtenue, la qualité 5 des décisions du logiciel système devient uniquement en fonction de l'environnement d'exécution. Pour ce faire, le logiciel système mesure les variables pertinentes de l'environnement d'exécution. Avantageusement, de façon transparente pour le programmeur et de 10 manière dynamique pour le compilateur, le procédé selon l'invention permet d'avoir des libertés de migration de tâche et des connaissances accumulées concernant l'environnement d'exécution afin d'optimiser le placement de tâches de calcul sur un ou plusieurs processeurs multicoeurs asymétriquement fonctionnels, et ce en fonction des objectifs 15 globaux de l'ordonnanceur. Avantageusement, le procédé selon l'invention confère de la liberté d'action en matière de placement de tâches de calcul. Une telle liberté d'action permet au système de migrer les tâches (de calcul) sur n'importe 20 quel coeur de processeurs, et ceci malgré les différentes extensions présentes dans chacun de ces coeurs. Les applications logicielles exécutées sur le système sont associées à un espace d'exploration plus continu et plus souple pour atteindre les objectifs (ou multi-objectifs) en termes de puissance (par exemple performances thermiques). 25 Avantageusement, des modes de réalisation de l'invention pourront être implémentés pour des « System-on-Chip » (SoC) pour des applications de type grand public ou électronique embarquée (e.g. téléphones, composants enfouis, desktop, Internet des Objets, etc). Dans ces 30 domaines d'application, l'utilisation de systèmes hétérogènes est fréquente pour optimiser l'efficacité de calcul pour une charge de travail 8 3035243 spécifique. Ces derniers systèmes se complexifiant continuellement (e.g. augmentation du nombre de coeurs et des charges de travail), certains modes de réalisation de l'invention permettent de réduire l'impact de cette complexification, en faisant abstraction de l'hétérogénéité des systèmes. Avantageusement, des résultats expérimentaux (benchmarks mibench, SDVBS) ont démontré des gains de performance et de consommation énergétique par rapport au système et procédé connu de l'état de la technique. Avantageusement, le procédé selon l'invention permet une optimisation dynamique de la performance et de l'énergie grâce à l'estimateur de la dégradation et de l'unité de prédiction. 15 Avantageusement, la mise à l'échelle (« scalability » en anglais) des processeurs multi-coeurs est améliorée. En particulier, la gestion de l'asymétrie de la plate-forme s'effectue de manière transparente pour l'utilisateur, c'est-à-dire n'augmente pas l'effort ou les contraintes de développement logiciel. 20 Avantageusement, une optimisation de l'ordonnancement permet de mieux répondre aux problématiques techniques qui augmentent avec le nombre de coeurs telles que la réduction de la surface et de l'énergie consommée, la priorité des tâches, le dark-silicon (température). 25 Avantageusement, le placement/ordonnancement des tâches selon l'invention est flexible. Par ailleurs, l'ordonnancement s'effectue de manière optimisée et transparente pour l'utilisateur. 30 Avantageusement en comparaison des solutions connues, le procédé selon l'invention prévoit l'emploi d'unités de prédiction (« prédicteur ») 5 10 9 3035243 et/ou d'estimateurs d'intérêt, permettant un placement de tâche optimisé. Les approches connues qui surveillent l'exécution des programmes et tentent d'optimiser le placement des tâches de calcul ne s'intéressent 5 généralement qu'aux différences interne d'un même processeur (e.g. « in- order/out-of-order », différence de fréquences, etc) et ne peuvent pas s'appliquer aux extensions matérielles elles-mêmes (les données, modèles et contraintes sont différentes). 10 Avantageusement selon l'invention, la dépendance au jeu d'instructions est réduite voire supprimée. Les avantages comprennent notamment une efficacité améliorée en matière énergétique et de performance. L'utilisation d'une extension n'apporte pas toujours des gains en performance et énergie. Par exemple une phase de calcul avec une faible 15 utilisation d'une extension permet d'accélérer les calculs (en comparaison d'une exécution conduite sur un coeur sans extension) mais la consommation d'énergie peut être augmentée en raison de l'énergie statique de l'extension (non compensée par le gain en temps d'exécution). De même, en matière de performance, le compilateur peut 20 utiliser une extension en planifiant que cela va accélérer l'exécution, mais à cause du déplacement de mémoire additionnel (e.g. entre l'extension et les registre des coeurs « basic »), la performance va en réalité être dépréciée. 25 Avantageusement, le choix du placement des tâches selon le procédé est flexible. Dans les systèmes actuels, l'objectif du système d'exploitation n'est pas toujours d'optimiser la performance, l'objectif peut être une minimalisation de l'énergie consommée ou un placement optimisant la température des coeurs (« dark silicon »). Du fait de la dépendance au jeu 30 d'instruction, l'ordonnanceur peut être contraint d'exécuter une application en fonction de ses besoins en ressources et non en considérant un 10 3035243 objectif global. Avantageusement selon le procédé, le placement est indépendant d'autres paramètres supervisés par l'ordonnanceur. Un ordonnanceur 5 alloue généralement un quanta de temps à chaque tâche de calcul sur un processeur. Si le calcul d'une tâche n'est pas achevé, un autre quanta lui sera associé. La taille de ces quanta est variable de façon à permettre un partage juste et optimisé des différentes tâches entre les différents processeurs (typiquement entre 0.1 et 100ms). Le dimensionnement des 10 quanta implique une détection plus ou moins fine des phases de type basic. Il peut exister des effets de bord (par exemple, des migrations incessantes). S'en tenir à ces effets de bord réduit in fine la flexibilité de placement et les optimisations. 15 Description des figures Différents aspects et avantages de l'invention vont apparaitre en appui de la description d'un mode préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous : 20 La figure 1 illustre des exemples d'architectures de processeurs ; Les figures 2A et 2B illustrent certains aspects de l'invention en matière d'efficacité énergétique, selon que des extensions matérielles sont 25 utilisées ou non ; La figure 3 illustre des exemples d'architectures et de placement des tâches ; 30 La figure 4 fournit des exemples d'étapes du procédé selon l'invention. 11 3035243 Description détaillée de l'invention L'invention permet généralement un placement optimisé de tâches de calcul sur un processeur multi-coeurs fonctionnellement asymétrique. Un 5 processeur multi-coeurs fonctionnellement asymétrique comprend des éléments programmables ou coeurs de processeur, utilisant des fonctionnalités plus ou moins étendues. Un coeur « étendu » (« full » en anglais, i.e. avec une ou plusieurs 10 extensions matérielles) est un coeur « basique » (ou « basic » en anglais, i.e. sans extension matérielle) augmenté d'une ou plusieurs extensions matérielle. Une « extension matérielle » ou « extension » (« Hardware Extension » 15 en anglais) est un circuit tel qu'une unité de calcul sur données flottantes FPU, une unité de calcul vectoriel, un SIMD, une unité de traitement cryptographique, une unité de traitement du signal, etc. Une extension matérielle introduit un circuit matériel spécialisé accessible ou relié à un coeur de processeur, lequel circuit fournit de hautes performances pour 20 des tâches de calcul spécifiques. Ces circuits spécifiques améliorent les performances et l'efficacité énergétique d'un coeur pour des calculs particuliers, mais leur utilisation intensive peut conduire à réduire la performance en termes de Watt par unité de surface. Ces extensions matérielles associées au coeur de processeur sont fournies avec un jeu 25 d'instruction qui étend le jeu standard ou par défaut (ISA). Les extensions matérielles sont généralement bien intégrées dans le pipeline du coeur, ce qui permet d'accéder efficacement aux fonctions par des instructions ajoutées à l'ensemble « basic » (par comparaison, un « coprocesseur » spécialisé requiert généralement des instructions apparentées à des 30 protocoles spécifiques). 12 3035243 Une tâche de calcul (ou « thread » en anglais) comprend des instructions, lesquelles peuvent être groupées en séquences d'instructions (temporellement) ou en jeux ou classes d'instructions (par nature). L'expression "tâche de calcul" (ou "tâche") désigne un "thread" ou un "fil 5 d'exécution". D'autres dénominations comprennent des expressions comme "processus léger", "unité de traitement", "unité d'exécution", "fil d'instruction", "processus allégé" ou "exétron". L'expression désigne l'exécution d'un ensemble d'instructions du langage machine d'un processeur. Du point de vue de l'utilisateur, ces exécutions semblent se 10 dérouler en parallèle. Toutefois, là où chaque processus possède sa propre mémoire virtuelle, les threads d'un même processus se partagent de la mémoire virtuelle. Par contre, tous les threads possèdent leur propre pile d'appel. Une tâche de calcul n'utilise pas nécessairement une extension matérielle: dans le cas le plus fréquent, une tâche de calcul est 15 exécutée en utilisant des instructions communes à tous les coeurs de processeur. Une tâche de calcul peut (optionnellement) être exécutée par une extension matérielle (qui requiert néanmoins le coeur associé pour « décoder » les instructions). 20 La fonction d'une extension matérielle est d'accélérer le traitement d'un jeu d'instruction spécifique: une extension matérielle peut ne pas accélérer le traitement d'un autre type d'instruction (e.g. virgule flottante versus entier). 25 Un coeur de processeur peut être associé avec aucune (i.e. zéro) ou une ou plusieurs extensions matérielles. Ces extensions matérielles lui sont alors « exclusives » (une extension matérielle donnée ne peut pas être accédée depuis un coeur tiers). Dans certaines architectures, le coeur de processeur comprend la ou les extensions matérielles. Dans d'autres 30 architectures, les circuits physiques d'une extension matérielle peuvent englober un coeur de processeur. Un coeur de processeur est un 13 3035243 ensemble de circuits physiques capables d'exécuter des programmes de façon « autonome ». Une extension matérielle est capable d'exécuter une partie de programme mais n'est pas « autonome » (elle requiert l'association avec au moins un coeur de processeur). 5 Un coeur de processeur peut posséder toutes les extensions matérielles requises pour l'exécution des instructions que contient une tâche donnée. Un coeur de processeur peut aussi ne pas nécessairement posséder toutes les extensions matérielles requises pour l'exécution des 10 instructions comprises dans la tâche de calcul : le problème technique du déplacement et/ou de l'émulation (i.e. de la fonctionnalité ou de l'instruction) - et des coûts associés- se pose. Les extensions matérielles peuvent être de nature différente. Une extension peut traiter un jeu d'instructions qui lui est spécifique. 15 Une extension matérielle est généralement coûteuse en surface de circuit et en énergie statique. Une plateforme asymétrique, comparée à un processeur symétrique, réduit le coût en surface et en énergie, en réduisant d'une part le nombre d'extensions et d'autre part en allumant ou 20 en éteignant des coeurs contenant les extensions que lorsque cela est nécessaire ou avantageux. Concernant la nature de l'association entre les coeurs de processeur et les extensions matérielles: dans un mode de réalisation, un coeur de 25 processeur accède de manière exclusive à une ou plusieurs extensions matérielles qui lui sont dédiées. Dans un autre mode de réalisation, une extension peut être « partagée » entre plusieurs coeurs de processeur. Dans ces différentes configurations, il convient de répartir au mieux la charge de calcul. Par exemple, il est avantageux de ne pas surcharger 30 une extension qui serait partagée. 14 3035243 Le système d'exploitation par le biais de l'ordonnanceur fournit des quanta de temps, chaque quantum de temps étant alloué à une application logicielle donnée. Selon un mode de réalisation de l'invention, l'ordonnanceur (ou « scheduler » en anglais) est de type préemptif (i.e. 5 les quanta de temps sont imposés aux applications logicielles). Il est divulgué un procédé (mis en oeuvre par ordinateur) pour la gestion d'une tâche de calcul sur un processeur multi-coeurs fonctionnellement asymétrique, au moins un coeur dudit processeur étant associé à une ou 10 plusieurs extensions matérielles, le procédé comprenant les étapes consistant à recevoir une tâche de calcul, ladite tâche de calcul étant associée à des instructions exécutables par une extension matérielle associée au processeur multi-coeurs; recevoir des données de calibration associées à ladite extension matérielle; et déterminer un coût 15 d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration. Un ou plusieurs coûts d'opportunité d'exécution peuvent être déterminés. Au moins un coeur de processeur parmi la pluralité des coeurs est ainsi 20 caractérisé par un coût d'opportunité d'exécution de la tâche de calcul reçue. Le procédé selon l'invention considère diverses « opportunités » de placement, i.e. des possibilités ou potentialités, qui sont analysées. Dans un développement, la tâche de calcul comprend des instructions associées à une ou plusieurs classes prédéfinies d'instructions et l'extension matérielle est associée à une ou plusieurs classes prédéfinies d'instructions, lesdites classes étant exécutables par ladite extension. 25 30 Dans un développement, les données de calibration comprennent des 15 3035243 coefficients indicatifs d'un coût unitaire d'exécution par classe d'instruction, lesdits coefficients étant déterminés par comparaison entre l'exécution d'un ensemble prédéfini d'instructions représentatif de l'espace d'exécution de ladite extension sur ladite extension matérielle 5 d'une part et l'exécution dudit ensemble prédéfini d'instructions sur un coeur de processeur sans extension matérielle d'autre part. L'« ensemble prédéfini d'instructions représentatif de l'espace d'exécution » (ER) vise à représenter les différentes possibilités 10 d'exécution des instructions, de manière la plus complète i.e. la plus exhaustive possible. En ce qui concerne la nature des instructions (i.e. les classes ou types d'instructions), une exhaustivité peut être atteinte. En revanche, la combinatoire des enchaînements des différentes instructions étant virtuellement infinie, la représentation est nécessairement 15 imparfaite. Elle peut néanmoins être approchée asymptotiquement. Le principe consistant à exécuter un ensemble d'instructions permet de déterminer des « points de contrôle » du procédé selon l'invention (e.g. des données de calibration efficaces). 20 Expérimentalement, une centaine de « programmes » ont été conduits, chacun contenant des « tests » (des exécutions unitaires) et l'exécution d'applications logicielles en conditions réelles. Les tests unitaires ont visé à exécuter un petit nombre de type d'instructions, principalement en virgule flottante, de contrôle et/ou de mémoire. Différents benchmarks ont 25 été utilisés (par exemple MiBench, SDVBS, WCET, fbench, Polybench). L'exécution d'applications logicielles réelles a visé à représenter les principaux enchainements en matière d'exécution d'instructions. Les applications logicielles ont notamment utilisé des jeux de données différents. 30 Dans un mode de réalisation chaque application logicielle peut être 16 3035243 compilée pour un coeur de processeur avec extension matérielle et également compilée pour un coeur sans extension. Les deux versions de binaires sont alors exécutées sur les différents coeurs. La différence en matière de temps d'exécution est déterminée ainsi que le nombre et la 5 nature des classes d'instructions exécutées. Pour un ensemble assez grand d'applications, il est possible de déterminer un nuage de points représentant l'espace total d'exécution. Par suite, il est possible d'établir une corrélation entre le nombre d'instructions associé à chaque classe d'instructions et la différence du temps d'exécution entre coeurs avec ou 10 sans extension. Pour améliorer la propriété de représentativité de l'espace représentatif (ER), le nombre d'applications logicielles peut être augmenté. Par l'emploi de techniques statistiques, cette représentativité peut être déterminée 15 (utilisation d'instructions aléatoires, seuils, intervalles de confiance, distribution du nuage de points, etc). Par suite, un nombre minimal (ou optimal) d'applications logicielles devant être exécutées en conditions réelles peut être déterminé. En comparant l'exécution d'instructions sur un coeur avec extension et sur un coeur sans extension, certains résultats 20 ont mis en évidence des écarts de l'ordre de 10 à 20% entre les performances telles qu'estimées selon le procédé et les performances réellement mesurées. Cet ordre de grandeur rend compte de la possibilité de mise en oeuvre opérationnelle de l'invention (et ceci sans optimisation additionnelle). 25 Dans un développement, le procédé comprend en outre une étape consistant à déterminer un nombre d'utilisations de chaque classe d'instructions associée à la tâche de calcul par ladite extension matérielle. 30 Dans un développement, l'étape consistant à déterminer le nombre d'utilisations de chaque classe d'instructions comprend une étape 17 3035243 consistant à compter le nombre d'utilisations de chaque classe d'instructions. Dans un mode de réalisation, l'historique i.e. le passé sert à estimer ou évaluer le futur. 5 Dans un développement, l'étape consistant à déterminer le nombre d'utilisations de chaque classe d'instructions comprend une étape consistant à estimer le nombre d'utilisations de chaque classe d'instructions, notamment à partir des utilisations comptées dans le passé. Il est aussi possible d'estimer le nombre d'utilisations à partir 10 d'autres méthodes. Il est également possible de combiner le fait de compter et le fait d'estimer le nombre d'utilisations des classes d'instructions. Dans un développement, le coût d'opportunité d'exécution est déterminé 15 par sommation indexée par classe d'instructions des coefficients par classe d'instructions multipliés par les nombres d'utilisations par classe d'instructions. Dans la présente description, le coût d'opportunité d'exécution est aussi parfois appelé « dégradation » (selon la perspective d'une perte de performances). Symétriquement, il peut aussi s'agir de 20 « gains d'exécution » (« accélérations » ou « bénéfices » ou « améliorations »). Le coût d'opportunité d'exécution peut être déterminé à partir du nombre d'utilisations qui sont donc comptées effectivement et/ou estimées en fonction de l'historique de comptage. 25 Avantageusement, la détermination en amont du « coût d'opportunité d'exécution » (spécifiquement défini par l'invention) permet des optimisations efficaces conduites en aval (telles que décrites ci-après). Le « coût d'opportunité d'exécution » selon l'invention correspond donc à une « grille de lecture » spécifique du processeur et de la gestion des 30 tâches de calcul, c'est-à-dire à la définition d'un « résultat intermédiaire » (d'aide à la décision) permettant par la suite de conduire des étapes de 18 3035243 gestion spécifiques et dépendantes de cette caractérisation. Cette perspective est particulièrement pertinente dans la mesure où elle permet de contrôler efficacement le processeur (des agrégats intermédiaires permettent d'améliorer la contrôlabilité du système). Pour rappel, de 5 manière spécifique, la prise en compte des classes d'instructions et du nombre d'utilisations de ces classes d'instructions permettent la détermination dudit «coût d'opportunité d'exécution ». Dans un développement, les coefficients sont déterminés hors ligne. Il est 10 possible de déterminer les données de calibration une fois pour toute (« offline »). Par exemple les données de calibration peuvent être fournies par le constructeur du processeur. Les données de calibration peuvent être présentes dans un fichier de configuration. 15 Dans un développement, les coefficients sont déterminés en ligne. Les coefficients peuvent être déterminés durant l'exécution d'un programme, par exemple au « reset » de la plateforme. Dans un système ouvert (par exemple cluster ou « Cloud »), dont la topologie est inconnue a priori, il est possible de calibrer chaque extension au démarrage et de déterminer 20 la topologie globalement. Dans un développement, les coefficients sont déterminés par analyse statistique multivariée. Différentes techniques d'analyse statistique multivariée peuvent être utilisées, éventuellement combinées. La 25 régression (linéaire) est avantageusement rapide. L'analyse en composantes principales (ACP) avantageusement permet de réduire le nombre de coefficients. D'autres techniques utilisables comprennent l'analyse factorielle des correspondances (AFC), l'analyse dite factorielle, le partitionnement de données (clustering), le positionnement 30 multidimensionnel (MDS, pour « multidimensional scaling »), l'analyse des similarités entre variables, l'analyse de régression multiple, l'analyse 19 3035243 de la variance ANOVA (bivariée), et sa généralisation multivariée (Analyse de la variance multivariée), l'analyse discriminante, l'analyse canonique des corrélations, la régression logistique (modèle LOGIT), les réseaux de neurones artificiels, les arbres de décision, les modèles d'équations 5 structurelles, l'analyse conjointe etc. Dans un développement, la tâche de calcul reçue est associée à un coeur de processeur prédéterminé et le coût d'opportunité d'exécution de la tâche de calcul est associé à un coeur de processeur autre que le coeur 10 de processeur prédéterminé. Il est généralement considéré (mais ce n'est pas obligatoire) quel serait le coût d'exécution sur le processeur prédéterminé (le cas échéant), i.e. quel serait le coût de « poursuite » d'exécution. Dans les autres cas, les autres coeurs « candidats » sont pris en considération (un, plusieurs ou la totalité des coeurs adressables). 15 Dans un développement, le coût d'opportunité d'exécution de la tâche de calcul est déterminé pour au moins un coeur de processeur autre que le coeur de processeur prédéterminé. Dans un développement, tous les coeurs de processeurs sont considérés chacun à leur tour et l'optimisation 20 du placement consiste à minimiser le coût d'opportunité d'exécution (c'est-à-dire par exemple à sélectionner le coeur de processeur associé au coût d'opportunité d'exécution le plus bas ou le plus faible). Dans certains modes de réalisation, il peut être utilisé une telle fonction 25 « minimum ». Dans d'autres modes de réalisation, des algorithmes spécifiques (séquence d'étapes) et/ou des fonctions analytiques et/ou des heuristiques peuvent être utilisées (par exemple, les coeurs candidats peuvent être comparés par paires et/ou échantillonnés selon diverses modalités, par exemple de manière à accélérer la prise de décision en 30 matière de placement). 20 3035243 De manière complémentaire (c'est-à-dire de manière entièrement facultative) à la prise en compte du coût d'opportunité d'exécution, d'autres critères peuvent être pris en compte pour optimiser le placement de la tâche de calcul. Ces critères peuvent être pris en compte de 5 manière additionnelle (mais dans certains cas peuvent se substituer au critère de coût d'opportunité d'exécution). Ces critères généralement complémentaires peuvent notamment comprendre des paramètres relatifs au temps d'exécution de la tâche de calcul et/ou au coût énergétique associé à l'exécution de la tâche de calcul et/ou la température (i.e. à la 10 conséquence locale de l'exécution considérée). Les différents coûts (opportunités d'exécution, température, énergie, performances, etc) peuvent être comparés entre eux et diverses logiques d'arbitrage peuvent permettre de sélectionner un coeur en particulier en 15 considération de ces différents critères. S'agissant d'optimisation combinatoire ou d'une optimisation multi-objectifs (certains objectifs peuvent être antagonistes), différentes techniques mathématiques sont applicables. La pondération de ces différents critères peut notamment être variable et/ou configurable. Les poids respectifs alloués aux 20 différents critères d'optimisation du placement peuvent par exemple être configurés en ligne ou hors ligne. Ils peuvent être « statiques » ou « dynamiques ». Par exemple, la priorité et/ou le poids de ces différents critères peuvent être variables au cours du temps. Des fonctions analytiques ou des algorithmes peuvent réguler les différentes allocations 25 ou arbitrages ou compromis ou priorités entre critères d'optimisation du placement des tâches de calcul. Dans un développement, la détermination du coût énergétique comprend une ou plusieurs étapes parmi les étapes consistant à recevoir des 30 indications initiales d'utilisation d'une ou de plusieurs extensions matérielles prédéfinies et/ou à recevoir des états de consommation 21 3035243 d'énergie (par exemple DVFS) par coeur de processeur et/ou à recevoir des informations d'asymétrie en performance et une étape consistant à déterminer une optimisation énergétique de type power-gating et/ou clock-gating. 5 Dans un développement, le procédé comprend en outre une étape consistant à déterminer un coût d'adaptation des instructions associées à la tâche de calcul, ladite étape comprenant une ou plusieurs étapes parmi les étapes consistant à traduire une ou plusieurs instructions et/ou 10 sélectionner une ou plusieurs versions instructions et/ou émuler une ou plusieurs instructions et/ou exécuter une ou plusieurs instructions dans une machine virtuelle. L'adaptation des instructions devient nécessaire s'il est déterminé, à la suite des étapes précédentes, un coeur de processeur ne possédant par l'extension matérielle requise (coeur « non-équipé ») 15 Dans un développement, le procédé comprend en outre une étape consistant à recevoir un paramètre et/ou une règle logique d'ordonnancement et/ou de placement. Ce développement souligne les différentes possibilités en matière de « contrôlabilité » du procédé selon 20 l'invention. Des règles logiques (expressions booléennes, logique floue, règles métier, etc) peuvent être reçues de modules tiers. Des valeurs seuils factuelles également, telles que des températures maximales, des plages de temps d'exécution etc. 25 Dans un développement, le procédé comprend en outre une étape consistant à déplacer la tâche de calcul du coeur de processeur prédéterminé au coeur de processeur déterminé. Dans un développement, le procédé comprend en outre une étape 30 consistant à désactiver ou éteindre un ou plusieurs coeurs de processeur. Désactiver ou « couper le signal d'horloge » ou « mettre le coeur dans un 22 3035243 état de consommation réduit » (e.g. diminuer la fréquence d'horloge) ou « éteindre » (« dark silicon ») Dans un développement, le processeur multi-coeurs fonctionnellement 5 asymétrique est un processeur physique ou un processeur virtuel. Le processeur est un processeur tangible ou physique. Le processeur peut aussi être un processeur virtuel, i.e. défini de manière logique. Le périmètre peut par exemple être défini par le système d'exploitation. Un processeur peut aussi être déterminé par un hyperviseur. 10 Il est divulgué un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer une ou plusieurs étapes du procédé. 15 II est divulgué un système comprenant des moyens pour la mise en oeuvre d'une ou plusieurs étapes du procédé. Dans un développement, le système comprend un processeur multicoeurs fonctionnellement asymétrique, au moins un coeur dudit 20 processeur étant associé à une ou plusieurs extensions matérielles, le système comprenant des moyens de réception pour recevoir une tâche de calcul, ladite tâche de calcul étant associée à des instructions exécutables par une extension matérielle associée au processeur multicoeurs; des moyens de réception pour recevoir des données de 25 calibration; et des moyens pour déterminer un coût d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration. Dans un développement, le système comprend en outre des moyens choisis parmi des moyens de placement pour placer une ou plusieurs 30 tâches de calcul sur un ou plusieurs coeurs du processeur; des moyens pour compter l'utilisation de classes d'instructions par une extension 23 303 52 43 matérielle, lesdits moyens comprenant des compteurs logiciels et/ou matériels ; des moyens ou des registres pour sauvegarder le contexte d'exécution d'une tâche de calcul ; des moyens pour déterminer le coût de migration et/ou le coût d'adaptation et/ou le coût énergétique associé à 5 la poursuite de l'exécution d'une tâche de calcul sur un coeur de processeur prédéfini; des moyens de réception d'un ou de plusieurs paramètres et/ou règles d'ordonnancement; des moyens pour déterminer et/ou sélectionner un coeur de processeur; des moyens pour exécuter sur un coeur de processeur sans extension matérielle associée une tâche de 10 calcul prévue initialement pour s'exécuter sur un processeur comprenant une ou plusieurs extensions matérielles; des moyens pour déplacer une tâche de calcul d'un coeur de processeur à un autre coeur de processeur; et des moyens pour désactiver ou éteindre un ou plusieurs coeurs de processeur. 15 La figure 1 illustre des exemples d'architectures de processeurs. Un processeur multi-coeur fonctionnellement asymétrique FAMP 120 est comparé à un processeur multi-coeur symétrique SMP 110 dont chaque coeur contient toutes les extensions matérielles et comparé à un 20 processeur multi-coeur symétrique SMP 130 contenant seulement des coeurs basiques. L'architecture peut-être à mémoire partagée ou distribuée. Les coeurs peuvent parfois être reliés par un NoC (Networkon-Chip). 25 Une architecture FAMP 120 est proche de celle d'un processeur multi- coeurs symétrique SMP 130. L'architecture mémoire reste homogène, mais les fonctionnalités des coeurs peuvent être hétérogènes. Tel qu'illustré à l'exemple de la figure 1, une architecture FAMP 120 peut 30 comprendre quatre types de coeurs différents (avec la même base). La taille du processeur peut donc être réduite. Du fait de la faculté de pouvoir 24 3035243 allumer ou éteindre les coeurs, et par suite de choisir lequel allumer en fonction de besoin de l'application logicielle, différentes optimisations peuvent être effectuées (gain en énergie, réduction de la température des coeurs, etc.). 5 Les figures 2A et 2B illustrent certains aspects de l'invention en matière d'efficacité énergétique, selon que des extensions matérielles sont utilisées ou non. 10 La figure 2A fait référence à un processeur « Full » (ou « étendu », i.e. avec une ou plusieurs extensions matérielles) et « Basic » (sans extension matérielle). La figure illustre l'énergie consommée par un processeur (surfaces 121 et 122) en fonction de la puissance consommée (« Power » en ordonnée 111) pendant une durée d'exécution (temps en 15 abscisse 112) pour une même application ou thread sur les deux types de processeurs. Sur un processeur « Full » avec une puissance énergétique Pf, une tâche de calcul exécutée durant un temps tf consomme une énergie EFull 121. Sur un processeur « Basic » avec une puissance énergétique Pb, une tâche de calcul exécutée durant un temps tb 20 consomme EBasic 122. La puissance Pf est supérieure à la puissance Pb car l'extension matérielle demande plus de puissance. Il est fréquent que le temps d'exécution tb soit supérieur au temps d'exécution tf car ne possédant pas d'extension, un processeur basic exécute moins rapidement la tâche de calcul. 25 Un objectif général consiste à minimiser l'énergie consommée, i.e. l'aire de la surface (temps d'exécution le plus court possible avec une puissance minimale). Dans l'exemple de la figure 2A, le processeur Full est plus efficace. En considérant Pb et Pf comme des constantes, le 30 rapport tb/tf indique l' « accélération » du calcul due à l'extension matérielle. 25 3035243 La figure 2B illustre la variation du gain en énergie (EBasic / EFull) en fonction de l'accélération tb/tf, ce qui indique l'opportunité d'utiliser un processeur étendu avec extension(s) matérielle(s) plutôt que sans. Si le 5 rapport EBasib/EFun est inférieur à 1, cela indique qu'il y a moins d'énergie consommée avec un processeur de type Basic qu'avec un processeur Etendu (le cas échéant, ce domaine d'opération 141 est appelé « slighlty extended » ce qui traduit que l'extension matérielle n'est pas assez utilisée). Si le rapport Esasic/EFun est inférieur à 1 et le rapport 10 d'accélération tb/tf est inférieur à 1, cela traduit un gain à la fois en énergie consommée et en performance de temps de calcul à l'avantage du processeur sans extension matérielle (cette situation peut arriver dans les cas où l'extension mal utilisée). Si le rapport EsasidEFun est supérieur à 1, le processeur étendu consomme moins d'énergie (section 143 « highly 15 extended ») : l'extension accélère le code (i.e. les instructions) et les gains sont obtenus tant en matière d'énergie (elle est moindre) qu'en matière d'accélération (exécution plus rapide). Il peut être noté que lorsque EBasiciEFull égale 1, le ratio tb/tf vaut 20 généralement Pb /Pf (quand les processeurs de type basic et étendu consomment autant d'énergie, l'accélération associée se ramène généralement au rapport des puissances des processeurs). Lorsque tb/tf égale 1 (quand les durées d'exécution sont les mêmes), Esasic/EFun Pf/Pb (i.e. il est en général observé que les rapports de consommation 25 d'énergie et de puissance sont généralement sensiblement égaux) Le domaine d'opération 144 correspond à une accélération des calculs simultanément à une consommation énergétique moindre, à l'avantage d'un processeur étendu avec extension matérielle. Une extension 30 matérielle peut réduire la consommation d'énergie en réduisant le nombre d'étapes requis pour effectuer des calculs spécifiques. Lorsque l'utilisation 26 3035243 de l'extension matérielle est suffisamment intensive, l'accélération du calcul sur l'extension peut compenser l'alimentation additionnelle requise par l'extension elle-même. 5 En comparaison de coprocesseurs, une extension matérielle peut être plus efficace, en raison du fort couplage existant entre extension et coeur. Les extensions matérielles partagent fréquemment une part significative du coeur « basic » et tirent avantage de l'accès direct aux mémoires cache de type L1 et L2. Ce couplage permet notamment de réduire les 10 transferts de données et la complexité de synchronisation. Quand bien même des outils de compilation permettent de maximiser l'utilisation d'une extension matérielle, les utilisations d'extensions matérielles peuvent demeurer anecdotiques en comparaison de la charge 15 globale du processeur. Une extension matérielle implique généralement un coût additionnel en termes de surface et de consommation d'énergie statique. Une extension comprend souvent des registres de taille significative, qui peuvent requérir une bande passante plus étendue ainsi que des transferts de données plus importants que ceux nécessités par le 20 circuit coeur. Si l'utilisation de l'extension matérielle est trop faible, sa consommation d'énergie propre dépassera vraisemblablement les économies d'énergie visée en raison de l'accélération matérielle. Pire, une extension matérielle sous-utilisée peut amener à une réduction de performance de l'exécution d'une application logicielle. Par exemple, dans 25 le cas de transferts de données intensifs entre l'extension matérielle et les registres du coeur, le surcoût du transfert mémoire peut annuler le bénéfice résidant dans l'accélération. Une extension matérielle n'est généralement pas « transparente » pour le 30 développeur d'applications. Par opposition aux fonctionnalités de type super-scalaire, le développeur est fréquemment contraint de gérer de 27 3035243 manière explicite les jeux d'instruction étendus. Par suite, l'emploi d'extensions matérielles peut s'avérer onéreux en comparaison du seul circuit coeur. Par exemple, l'extension NEON/VFP pour processeur ARM compte pour environ 30% de la surface d'un processeur de type Cortex 5 A9 (sans prendre en compte les caches, et 10% en comptant le cache L1). Néanmoins, les extensions matérielles sont critiques et demeurent nécessaires pour adresser certains problèmes techniques, notamment en 10 matière de puissance et de performances requises dans certaines classes d'application (comme par exemple dans les applications multimédias, de cryptographie, de traitement d'images et du signal). Au sein d'une architecture symétrique multiprocesseur (SMP), afin de 15 maintenir une un jeu d'instruction homogène pour les différents coeurs de processeur, des extensions doivent être implémentées dans chaque coeur de processeur. Cette symétrie ISA implique notamment l'emploi d'une surface significative et d'une certaine consommation d'énergie, ce qui à son tour limite les avantages d'accélération matérielle via des extensions. 20 Avantageusement, le procédé selon l'invention permet de (a) distribuer asymétriquement les extensions dans un processeur mufti-coeurs, (b) de savoir quand l'utilisation d'une extension est « utile » d'un point de vue performances et énergie et (c) de déplacer l'application au cours du 25 temps sur différents coeurs, indépendamment de leur besoin de départ (lequel est choisi à la compilation et donc pas nécessairement adéquat avec le contexte d'exécution) La figure 3 illustre des exemples d'architectures et de placement des 30 tâches. La figure montre des exemples d'ordonnancement de tâches sur un SMP, et deux types d'ordonnancement sur un FAMP. L'unité FPU 28 3035243 ajoute des instructions de type FP à un circuit ISA. Dans le premier cas 310 (SMP), chaque quanta de la tâche est exécuté sur un processeur ayant une FPU (Floating Point Unit). Il se trouve que le 5 premier et le dernier quanta ne contiennent pas d'instructions FP. Dans le deuxième cas 320 (« ISA-constrained »), grâce à l'asymétrie de la plateforme, le premier et le dernier quanta peuvent s'exécuter sur un coeur simple (n'ayant pas de FPU), ce qui réduit la consommation 10 d'énergie lors de l'exécution. Or le 3eme quanta contient des extensions FP, mais pas assez pour « valoriser » l'unité FP. Dans le troisième cas 330, le procédé selon l'invention permet au troisième quanta d'être exécuté sur un processeur de type « basic », ce 15 qui permet d'optimiser la consommation énergétique pour exécuter cette tâche de calcul. La figure 4 fournit des exemples d'étapes du procédé selon l'invention. 20 Les étapes se déroulent au sein d'un processeur multi-coeurs, pour lequel un ordonnanceur (en anglais « scheduler ») procède au placement des tâches de calcul durant l'exécution d'un programme. A l'étape 400, qui se déroule en ligne et en boucle, les données relatives 25 à l'utilisation des extensions matérielles sont collectées (par exemple par l'ordonnanceur). L'usage des extensions est surveillé (« monitoring » en anglais). Dans un mode de réalisation, le procédé pour récupérer les données au cours de l'exécution se concentre seulement sur les instructions à destination des extensions matérielles ou hardware. Selon 30 ce mode de réalisation, le procédé est indépendant du processus d'ordonnancement. Lorsque le code est exécuté sur un processeur avec 29 303 52 43 extension (i.e. avec une ou plusieurs extensions), la surveillance peut s'appuyer sur des compteurs matériels. Lorsque le code est exécuté sur un processeur de type « basic », les instructions étendues ne sont plus exécutées nativement. Par exemple le cas échéant, il faut ajouter des 5 routines (par exemple au moment de l'adaptation du code ou dans la fonction d'émulation si applicable) pour compter le nombre d'instructions de chaque classe de l'extension qu'un processeur avec extension aura ou aurait exécuté. En substitution ou en complément, le procédé selon l'invention peut utiliser des compteurs logiciels et/ou des compteurs 10 matériels associés aux dits compteurs logiciels. Un système de « monitoring » peut être très lourd à l'exécution. Dans le cadre de l'invention, les données collectées sont liées aux seules instructions impliquant des extensions, et de fait le ralentissement est 15 négligeable car il peut être fait en parallèle de l'exécution. Dans le cadre d'un processeur de type « basic », le remplissage des compteurs peut être fait séquentiellement pendant l'émulation de la fonctionnalité accélérée par les autres coeurs, ce qui peut rajouter un surcoût en matière de performance. Pour réduire ce surcoût, il est possible de 20 récolter les données de manière périodique, et, le cas échéant, de procéder à une interpolation. A l'étape 410, il est déterminé un évènement de l'ordonnanceur (par exemple la fin d'un quanta), lequel déclenche l'étape 320. 25 A l'étape 420, les données collectées sont lues. Par exemple, l'ordonnanceur récupère les données collectées par le monitor (A.0) (par exemple en lisant les registres hardware ou software). 30 A l'étape 420, une prédiction est effectuée. Grace aux données récupérées, le système de prédiction étudie le comportement de 30 3035243 l'application par rapport à l'utilisation des classes d'instructions étendues. En analysant ce comportement, il prédit le comportement futur de l'application. Dans un mode de réalisation, la prédiction est dite simple, i.e. s'effectue de manière réactive, en posant l'hypothèse que le 5 comportement de l'application dans le prochain quanta va être similaire au dernier quanta exécuté. Dans un mode de réalisation, la prédiction est dite « complexe » et comprend des étapes consistant à déterminer les différents types de phases du programme. Par exemple, ces types de phases peuvent être déterminés en sauvegardant une table d'historique 10 de comportement et en analysant cet historique. Des signatures peuvent être utilisées. Par exemple, l'unité de prédiction peut associer des signatures à des comportements exécutés par la suite. Quand une signature est détectée, l'unité de prédiction peut indiquer le comportement futur i.e. prédire les futures opérations connues et associées à la 15 signature. A l'étape 430, il est procédé à une estimation dite de « dégradation ». (« Basic » versus « Full », i.e. estimation de la dégradation de la performance associée à l'exécution d'une tâche de calcul sur un 20 processeur sans extension matérielle comparée à celle exécutée sur un processeur avec extension matérielle). Une tâche donnée n'est pas testée sur chacun des professeurs mais il est estimé, au moment de l'ordonnancement, le coût que la tâche aurait sur des processeurs différents. Dans un mode de réalisation (e.g. hors ligne « offline »), la 25 totalité du code est simulée, en prenant en compte les particularités complètes du processeur. Ce type d'approche n'est généralement pas utilisable dynamiquement (en ligne). En considérant le cas particulier selon lequel les coeurs de processeur ont tous la même base, toutes les instructions sont exécutées de la même façon dans les différents coeurs 30 (par exemples deux coeurs). Certains effets de bord peuvent apparaître entre les coeurs, par exemple en raison de mises en cache, mais ces 31 3035243 effets restent résiduels et peuvent être pris en compte lors de l'apprentissage du modèle. L'estimation de la dégradation de performances peut s'effectuer de 5 différentes manières. Dans une première approche, il est seulement tenu compte du pourcentage global de l'utilisation de l'extension matérielle. L'estimation de la dégradation peut en effet s'appuyer sur un modèle permettant de 10 calculer ladite dégradation en fonction du pourcentage de chaque classe d'instructions par l'extension. Cette approche ne convient néanmoins pas nécessairement puisque différents types d'instructions peuvent avoir des accélérations très différentes pour une même extension matérielle. 15 Dans une deuxième approche, une estimation de la dégradation de performance peut prendre en compte les classes d'instructions et revêtir une forme selon: dcr crifirt, u bE:e n fy, 20 Selon cette approche pondérée, les valeurs des coefficients de pondération 13 ( « beta ») peuvent être calculées dynamiquement en ligne en procédant à un apprentissage effectué grâce à l'exécution de plusieurs codes sur différents types de processeurs. Ces valeurs peuvent être aussi calculées hors ligne (et stockées dans une table lisible par l'ordonnanceur 25 par exemple). Les données de calibration déterminées à partir de l'exécution de tâches de calcul réelles permettent notamment de prendre en compte le coût d'émulation et les évolutions complexes des coefficients beta. Par 30 exemple ; les valeurs beta peuvent être distinguées pour une plateforme 32 3035243 réelle et pour une plateforme simulée. Au runtime (avant ou durant l'exécution d'une tâche de calcul), les coefficients beta sont utilisés par le scheduler de manière à estimer la 5 dégradation de performances. La calibration doit être réitérée pour chaque implementation d'une extension matérielle. Les étapes de prédiction 430 et d'estimation de la dégradation 440 sont chronologiquement indépendantes. 10 La dégradation peut être estimée (440) à partir des données prédites (430). Alternativement, la dégradation 440 peut être calculée à partir des données récupérées à l'étape 400 et 420, avant que la prédiction 430 se fonde sur la dégradation 440 ainsi calculée. Dans ce cadre là, la future 15 dégradation est prédite (et non les futures instructions des extensions). Les données changent mais le processus de prédiction reste le même. Autrement dit, à l'étape 430, l'objectif est de « prédire » le nombre d'instructions de chaque classe qui sera exécuté à t+1 en fonction du 20 passé (de t, t-1...t-n). A l'étape 440, l'objectif est d' « estimer » le coût d'exécution à t+1 sur les différents types de coeurs. Les étapes 430 et 440 peuvent être effectuées dans un ordre indifférent car il est possible de manière indépendante d'estimer le coût au temps t sur les données récupérées et de prédire le coût au temps t+1 à partir du coût au temps t. 25 Formulé encore différemment, une approche de « prédiction » consiste en une détermination relative du futur à partir des données accessibles au présent. Une « estimation » permet une détermination du présent au moyen des données observées dans le passé. Dans une autre 30 perspective, une « estimation » permet la détermination du passé dans un nouveau contexte à partir d'observations du passé dans un autre 33 3035243 contexte. Selon une implémentation du procédé de l'invention (au « runtime »), un module de surveillance capture les données de calibration et un module 5 d'analyse estime l'accélération associée à l'emploi d'une extension. En matière de surveillance, les données d'entrée doivent être les plus proches possible dans le temps des instructions étendues devant être exécutées au quanta suivant (en faisant une hypothèse de continuité, e.g. utilisation stable d'une unité de calcul en virgule flottante). Un module de 10 prédiction peut alors être utilisé. Cette hypothèse est réaliste quand les programmes possèdent des phases distinctes de comportements stables sur des intervalles de temps suffisamment longs. Dans le cas de comportements plus erratiques, des modules de prédiction plus avancés peuvent être mis en oeuvre. 15 A l'étape 450, il est effectué une étape de décision. Une unité logique de décision par exemple peut prendre en compte les informations de l'estimation de dégradation prédite et/ou les objectifs globaux assignés à la plateforme, les objectifs comprenant par exemple des objectifs en 20 termes de réduction d'énergie, de performance, de priorité et de disponibilité des coeurs. Dans d'autres exemples, la dégradation peut aussi prendre en compte des paramètres tels que le coût de migration et/ou le coût d'adaptation du code. Dans certains cas, le coût de migration et le coût de la station peuvent être statiques (e.g. apprentissage hors 25 ligne) ou bien dynamiques (e.g. apprentissage en ligne ou surveillance temporelle en ligne). A l'étape 460, il peut être procédé à la migration d'un coeur vers un autre (« core-switching »). Les techniques de migration mise en oeuvre peuvent 30 être effectuées avec la sauvegarde du contexte (par exemple avec sauvegarde des registres de l'extension dans des registres logiciels 34 3035243 accessibles depuis l'émulation). A l'étape 470, il est procédé à l'adaptation éventuelle du code. Par exemple, pour exécuter du code avec des extensions sur un processeur 5 de type « basic », il est possible d'utiliser des techniques d'adaptions binaires (e.g. par translation de code), de multi-version de code, ou bien encore d'émulation. La présente invention peut s'implémenter à partir d'éléments matériel 10 et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique ou électromagnétique. 15 20 25 30 REVENDICATIONS1. Procédé mis en oeuvre par ordinateur pour la gestion d'une tâche de calcul sur un processeur multi-coeurs fonctionnellement asymétrique, au moins un coeur dudit processeur étant associé à une ou plusieurs extensions matérielles, le procédé comprenant les étapes consistant à : - recevoir une tâche de calcul, ladite tâche de calcul étant associée à des instructions exécutables par une extension matérielle associée au processeur mu Iti-cceu rs; - recevoir des données de calibration associées à ladite extension matérielle; - déterminer un coût d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration. 2. Procédé selon la revendication 1, la tâche de calcul comprenant des instructions associées à une ou plusieurs classes prédéfinies d'instructions et l'extension matérielle étant associée à une ou plusieurs classes prédéfinies d'instructions, lesdites classes étant exécutables par ladite extension. 3. Procédé selon les revendications précédentes, les données de calibration comprenant des coefficients indicatifs d'un coût unitaire d'exécution par classe d'instruction, lesdits coefficients étant déterminés par comparaison entre l'exécution d'un ensemble prédéfini d'instructions représentatif de l'espace d'exécution de ladite extension sur ladite extension matérielle d'une part et l'exécution dudit ensemble prédéfini d'instructions sur un coeur de processeur sans extension matérielle d'autre part. 4. Procédé selon la revendication 3, comprenant en outre une étape consistant à déterminer un nombre d'utilisations de chaque classe 3035243 36 d'instructions associée à la tâche de calcul par ladite extension matérielle. 5. Procédé selon la revendication 4, l'étape consistant à déterminer le nombre d'utilisations de chaque classe d'instructions comprenant une 5 étape consistant à compter le nombre d'utilisations de chaque classe d'instructions. 6. Procédé selon la revendication 4 ou 5, l'étape consistant à déterminer le nombre d'utilisations de chaque classe d'instructions comprenant une 10 étape consistant à estimer le nombre d'utilisations de chaque classe d'instructions, notamment à partir des utilisations comptées dans le passé. 7. Procédé selon l'une quelconque des revendications 4 ou 6, le coût 15 d'opportunité d'exécution étant déterminé par sommation indexée par classe d'instructions des coefficients par classe d'instructions multipliés par les nombres d'utilisations par classe d'instructions. 8. Procédé selon la revendication 3, les coefficients étant déterminés hors 20 ligne. 9. Procédé selon la revendication 3, les coefficients étant déterminés en ligne. 25 10. Procédé selon la revendication 3, les coefficients étant déterminés par analyse statistique multivariée. 11. Procédé selon l'une quelconque des revendications précédentes, la tâche de calcul reçue étant associée à un coeur de processeur 30 prédéterminé et le coût d'opportunité d'exécution de la tâche de calcul étant déterminé pour au moins un coeur de processeur autre que le coeur 3035243 37 de processeur prédéterminé. 12. Procédé selon la revendication 11, comprenant en outre une étape consistant à déterminer un coeur de processeur parmi la pluralité des 5 coeurs du processeur pour l'exécution de ladite tâche de calcul, ladite étape comprenant les étapes consistant à déterminer le coût d'opportunité d'exécution pour tout ou partie des coeurs de processeur du processeur multi-coeurs et à minimiser le coût d'opportunité d'exécution. 10 13. Procédé selon la revendication 11 ou 12, comprenant en outre une étape consistant à déterminer un coeur de processeur parmi la pluralité des coeurs du processeur pour l'exécution de ladite tâche de calcul, ladite détermination minimisant le temps d'exécution de la tâche de calcul et/ou le coût énergétique et/ou la température. 15 14. Procédé selon la revendication 13, la détermination du coût énergétique comprenant une ou plusieurs étapes parmi les étapes consistant à recevoir des indications initiales d'utilisation d'une ou de plusieurs extensions matérielles prédéfinies et/ou à recevoir des états de 20 consommation d'énergie DVFS par coeur de processeur et/ou à recevoir des informations d'asymétrie en performance et une étape consistant à déterminer une optimisation énergétique de type power-gating et/ou clock-gating. 25 15. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à déterminer un coût d'adaptation des instructions associées à la tâche de calcul, ladite étape comprenant une ou plusieurs étapes parmi les étapes consistant à traduire une ou plusieurs instructions et/ou sélectionner une ou plusieurs 30 versions instructions et/ou émuler une ou plusieurs instructions et/ou exécuter une ou plusieurs instructions dans une machine virtuelle. 3035243 38 16. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à recevoir un paramètre et/ou une règle logique d'ordonnancement et/ou de placement. 5 17. Procédé selon la revendication 16, comprenant en outre une étape consistant à déplacer la tâche de calcul du coeur de processeur prédéterminé au coeur de processeur déterminé. 10 18. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à désactiver ou éteindre un ou plusieurs coeurs de processeur. 19. Procédé selon l'une quelconque des revendications précédentes, le 15 processeur multi-coeurs fonctionnellement asymétrique étant un processeur physique ou un processeur virtuel. 20. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du 20 procédé selon l'une quelconque des revendications 1 à 19, lorsque ledit programme est exécuté sur un ordinateur. 21. Système comprenant des moyens pour la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 19. 25 22. Système selon la revendication 21 comprenant un processeur multicoeurs fonctionnellement asymétrique, au moins un coeur dudit processeur étant associé à une ou plusieurs extensions matérielles, le système comprenant: 30 - des moyens de réception pour recevoir une tâche de calcul, ladite tâche de calcul étant associée à des instructions exécutables par une extension 3035243 39 matérielle associée au processeur mufti-coeurs; - des moyens de réception pour recevoir des données de calibration; - des moyens pour déterminer un coût d'opportunité d'exécution de la tâche de calcul en fonction des données de calibration. 5 23. Système selon la revendication 21 ou 22 comprenant en outre des moyens choisis parmi : - des moyens de placement pour placer une ou plusieurs tâches de calcul sur un ou plusieurs coeurs du processeur; 10 - des moyens pour compter l'utilisation de classes d'instructions par une extension matérielle, lesdits moyens comprenant des compteurs logiciels et/ou matériels ; - des moyens ou des registres pour sauvegarder le contexte d'exécution d'une tâche de calcul ; 15 - des moyens pour déterminer le coût de migration et/ou le coût d'adaptation et/ou le coût énergétique associé à la poursuite de l'exécution d'une tâche de calcul sur un coeur de processeur prédéfini; - des moyens de réception d'un ou de plusieurs paramètres et/ou règles d'ordonnancement; 20 - des moyens pour déterminer et/ou sélectionner un coeur de processeur; - des moyens pour exécuter sur un coeur de processeur sans extension matérielle associée une tâche de calcul prévue initialement pour s'exécuter sur un processeur comprenant une ou plusieurs extensions matérielles; 25 - des moyens pour déplacer une tâche de calcul d'un coeur de processeur à un autre coeur de processeur; - des moyens pour désactiver ou éteindre un ou plusieurs coeurs de processeur. 30