FR 3027419 A1 20160422 FR 1459967 A 20141016 PROCEDE DE DETERMINATION D'UNE FREQUENCE OPTIMALE POUR L'EXECUTION D'UNE APPLICATION LOGICIELLE DOMAINE DE L'INVENTION L'invention est relative à l'exécution d'une application logicielle sur un système de traitement de l'information. Elle concerne plus particulièrement la détermination de la fréquence optimale d'exécution de l'application logicielle par exemple sur une ferme de calcul. CONTEXTE DE L'INVENTION Certains dispositifs de traitement de l'information permettent le choix, lors du lancement d'une application logicielle, de la fréquence du ou des microprocesseurs (ou CPU pour « Central Processing Unit ») à laquelle elle doit être exécuté. De ce choix dépend le temps d'exécution de l'application : plus la fréquence est élevée et plus le temps d'exécution sera court. Mais le choix de la fréquence d'exécution influe également sur la consommation énergétique. En effet, plus la fréquence est élevée et plus la consommation énergétique instantanée (c'est-à-dire par quantum de temps) est élevée. De façon générale, l'utilisateur d'une application logicielle souhaite minimiser à la fois le temps d'exécution et la consommation énergétique. Dans le cas de fermes de calcul, ou grappes d'ordinateurs, notamment sur le « cloud », les utilisateurs sont facturés en fonction de l'accès aux services de calcul. La facturation se base typiquement sur le temps d'utilisation mais aussi, de plus en plus, sur la consommation énergétique, c'est-à-dire sur la consommation électrique utilisée par la ferme de calcul pour exécuter l'application logicielle du client. Pour cette raison aussi, il est important pour l'utilisateur de pouvoir minimiser ces deux critères : temps d'exécution et consommation énergétique. Toutefois, ceux-ci ont des rapports de proportionnalités opposés par rapport à la fréquence d'exécution. Augmenter la fréquence permet de diminuer le temps d'exécution de l'application, mais en même temps augmente la consommation énergétique : la détermination d'une fréquence optimale, permettant de concilier les deux critères, pose donc un problème. Une solution connue consiste à exécuter des applications de test à différentes fréquences et de mesurer le temps d'exécution et la consommation énergétique. Toutefois une telle approche n'est pas satisfaisante pour plusieurs raisons. Elle oblige à de nombreuses exécutions, dans la mesure où le nombre de fréquences possibles peut être assez élevé. Ces nombreuses exécutions représentent un coût tant en terme de temps d'exécution globale (le temps d'exécution de l'application se voit prolonger de ces exécutions de tests), qu'en terme de consommation énergétique. Dans le cas où l'utilisateur se voit facturer l'accès à la ferme de calcul, ces nombreuses exécutions représentent en outre un coût financier. RESUME DE L'INVENTION Le but de la présente invention est de fournir une solution palliant au moins partiellement les inconvénients précités. A cette fin, la présente invention propose un procédé pour déterminer une fréquence optimale pour l'exécution d'une application logicielle sur un système de traitement de l'information, comportant Une première exécution de ladite application à une fréquence déterminée fo, permettant de déterminer un temps d'exécution global et une consommation énergétique globale; Une seconde exécution de ladite application à ladite fréquence déterminée fd, à l'aide d'un outil de mesure, permettant de déterminer des mesures n1,TI*0,T: sur l'exécution de ladite application ; Une étape de détermination d'une première loi fournissant un temps d'exécution t(f) en fonction de la fréquence f, et d'une seconde loi fournissant une consommation énergétique E(f) en fonction de la fréquence f; Une étape de détermination de ladite fréquence optimale fo comme fréquence optimisant un critère C(f) combinant ledit temps d'exécution et ladite consommation énergétique, en fonction de la fréquence. Suivant des modes de réalisation préférés, l'invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles : lesdites mesures T* comprennent des mesures T/*0 sur les entrées- sorties de ladite application logicielle. lesdites mesures T* comprennent des mesures n, sur les appels au système de gestion et de communication. lesdits appels sont effectués via une interface de passage de messages, MPI, et dans lequel les mesures sur lesdits appels comprennent des temps relatifs aux fonctions MPI Init, MPI wait, MPI Barrier. ledit critère est de la forme C(f) = w t(f)+wE - E(f), dans laquelle wt et wE sont deux poids prédéterminées. ladite fréquence optimale fo est déterminée en calculant les valeurs dudit critère C(f) pour plusieurs valeurs de fréquence et en recherchant la valeur minimale dudit critère parmi les valeurs calculées. la valeur dudit critère C(f) est calculée pour chaque valeur possible de ladite fréquence f. ladite première loi s'exprime sous la forme Tgo T dans laquelle T =g -T et a= fd-(Tg T* g ladite seconde loi s'exprime sous la forme E(f )= P(f )- t dans laquelle p(f) représente la puissance dudit système de traitement de l'information en fonction de la fréquence. ledit système de traitement de l'information est une ferme de calcul. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d'un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés. BREVE DESCRIPTION DES DESSINS La figure 1 représente très schématiquement un système de traitement de l'information, selon un mode de réalisation de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION La figure 1 illustre de façon très schématique et haut-niveau un système de traitement de l'information S, comportant de façon typique Une première couche C, matérielle, formée des microprocesseurs et autres circuits de calcul. Une seconde couche M, logicielle, formée d'un système d'exploitation (OS pour « Operating System » en langue anglaise) et éventuellement d'une plateforme de communication de type « middleware ». Une troisième couche A, également logicielle, contenant les applications Al. Ces couches peuvent représenter une vue abstraite dans la mesure où le système de traitement de l'information peut être réparti sur une pluralité de machines de traitement. C'est notamment dans le cas d'une ferme de calcul qui interconnecte un grand nombre d'ordinateurs, localisés en un ou plusieurs sites. La couche intermédiaire permet, entre autres fonctionnalités, de rendre l'infrastructure matérielle transparente pour les applications Al. Elle permet également d'assurer les communications entre applications et les interactions entre les applications et le monde extérieur, c'est-à-dire à gérer les entrées-sorties. La couche intermédiaire peut comprendre un système de gestion et de communication présentant, par exemple, une interface de passage de messages, ou MPI pour « Massage Passing Interface » en langue anglaise. MPI est une norme basée sur le système d'exploitation Unix définissant des fonctions utilisables par les applications logicielles pour exploiter les fonctionnalités des plateformes de traitement multi-ordinateur et/ou multiprocesseurs via un mécanisme de passage de messages. L'invention vise à déterminer une fréquence optimale fo comme fréquence optimisant un critère C(f) combinant le temps d'exécution et la consommation énergétique, en fonction de la fréquence d'exécution de l'application Al. Selon l'invention, cette fréquence optimale est déterminée spécifiquement pour l'application Ai: en fonction des caractéristiques et du comportement spécifique de chaque application, une fréquence optimale fo différente peut être déterminée. Selon l'invention, afin de déterminer cette fréquence optimale fo, on exécute deux fois l'application logicielle Al. Chacune de ces exécutions permet de déterminer un sous-ensemble de paramètres, dans la mise en commun permet dans une étape ultérieur de déterminer cette fréquence optimale fo. Une première exécution est effectuée à une fréquence déterminée fd. Elle permet de déterminer un temps d'exécution global Tg et une consommation énergétique globale Eg. Une seconde exécution est effectuée à la même fréquence déterminée fd, mais cette fois-ci à l'aide d'un outil de mesure, permettant de déterminer des mesures n, , T/*0 , T: sur l'exécution de l'application. L'ordre dans lequel a lieu les deux exécutions est indifférent. En outre, il n'est pas important que les deux exécutions s'enchaînent : elles peuvent avoir lieu à des moments différents, notamment en fonction de l'ordonnancement imposé par la charge du système de traitement de l'information. La valeur de la fréquence fd est elle-aussi sans importance, mais elle doit être la même pour les deux exécutions. Le temps d'exécution global Tg et la consommation électrique Eg peuvent être déterminés à l'aide d'outils d'ordonnancement de tâches dit « batch scheduler » ou « job scheduler ». Ces outils permettent entre autres fonctionnalités d'enchainer des lancements d'applications et, pour certains, d'enregistrer dans un journal (ou « log » en anglais), des informations sur ces lancements, notamment les dates, les erreurs éventuelles, etc. Un exemple d'un tel outil peut être SLURM (pour « Simple Linux Utility Resource Management »). Le temps d'exécution global Tg est déterminé facilement en comparant la date de début d'exécution de l'application logicielle Al et la date de fin d'exécution. Ces dates peuvent s'obtenir aisément à partir du journal de l'outil d'ordonnancement. De la même façon, la consommation énergétique Eg peut être déterminée par un outil par consultation du journal. La consommation énergétique est typiquement exprimée en joules et représente l'énergie consommée par les ressources matérielles utilisées pour l'exécution de l'application logicielle Al. Différents mécanismes peuvent être mis en oeuvre par les outils d'ordonnancement pour déterminer cette consommation énergétique Eg. Par exemple : - Une première mise en oeuvre consiste à utiliser des compteurs matériels accessibles en lecture et placés au sein des microprocesseurs eux-mêmes. Ces compteurs peuvent être de type RAPL (pour « Running Average Power Limit »), un mécanisme disponible sur les microprocesseurs du fabriquant Intel. Une seconde mise en oeuvre consiste à faire usage de sondes observées par un contrôleur d'administration distante sur la carte mère et accessibles via le protocole IPMI (pour « Intelligent Platform Management Interface » en langue anglaise). Cette interface IPMI permet la gestion d'un système de traitement de l'information en utilisant une interface réseau et sans passer par le système d'exploitation. L'outil de mesure utilisé pour la seconde exécution peut être un outil de profilage de code. Le profilage de code (ou « code profiling » en anglais) consiste à analyser l'exécution d'un logiciel afin de connaitre son comportement à l'exécution. Le profilage de code permet de contrôler lors de l'exécution d'un logiciel : la liste des fonctions appelées et le temps passé dans chacune d'elles ; l'utilisation processeur ; l'utilisation mémoire. Le profilage du code est implémenté par instrumentation du code source en rajoutant des instructions au code source originel qui permettent de mesurer le comportement du logiciel lors de l'exécution. Ensuite, un scénario d'utilisation est défini et exécuté sur le logiciel instrumenté. Les données de profilage sont récoltées et analysées à la fin de l'exécution. A titre d'exemples d'outils de profilage, on peut citer l'outil BullxProf de la société Bull, l'outil Allinea Map, de la société Allinea, Gprof, qui est un outil sous licence GNU, etc. Grâce à cette seconde exécution, on peut déterminer des mesures T1 , T/*0 , T: sur l'exécution de l'application logicielle, et plus spécifiquement Un temps d'exécution global à l'aide de l'outil logiciel T. . Du fait de l'utilisation de cet outil qui intervient dans le comportement de l'application logicielle, ce temps T: est nécessairement plus long que le temps d'exécution global Tg sans outil. Un temps T/*0 correspondant aux entrées-sorties de l'application logicielle. Chaque entrée-sortie (c'est-à-dire, accès à une périphérique externe, à la mémoire de masse, etc.) coûte un lapse de temps. Le temps mesuré T/*0 correspond au cumul de ces lapses de temps sur toute la durée de l'exécution de l'application logicielle Un temps n, sur les appels au système de gestion et de communication, notamment via une interface MPI. Il s'agit là aussi d'une mesure correspondant au cumul de différents lapses de temps passé en communication tout au long de l'exécution de l'application logicielle. Selon un mode de réalisation de l'invention, une sélection est effectuée parmi les différentes fonctions de l'interface MPI. Des séries d'expériences ont été entreprises afin de déterminer le sous-ensemble de fonctions donnant les résultats optimaux. Selon ce mode de réalisation, les fonctions prises en compte pour la mesure du temps n, sont les fonctions MPI Init, MPI wait et MPI _B arrier. La fonction MPI Init initialise l'environnement d'exécution de l'interface MPI. La fonction MPI Wait attend qu'une requête à l'interface MPI soit terminée. La fonction MPI Barrier bloque l'exécution jusqu'à que tous les processus aient atteint ce point. Le temps n, passé pour l'exécution de ces trois fonctions forme une bonne estimation du temps passé pour les appels au système de gestion et de communication. Le procédé selon l'invention peut ensuite mettre en oeuvre une étape de détermination d'une première loi fournissant un temps d'exécution t(f) de l'application en fonction de la fréquence f, et d'une seconde loi fournissant une consommation énergétique E(f) en fonction de la fréquence (f). Selon une mise en oeuvre de l'invention, cette première loi peut s'exprimer sous la forme r(f)= c±+T f - T* dans laquelle Too =g* -T et a = fd -(Tg -T00) Tg T* peut représenter le cumul entre le temps T/*0 lié aux entrées-sorties et le temps n, lié aux appels au système de gestion et communication : T*, T/*0 + n, Too représente un temps « incompressible » de l'application logicielle, c'est-à-dire le temps d'exécution théorique avec une fréquence infinie. Il s'agit d'un paramètre propre au comportement de l'application logicielle, de même que le paramètre «a ». Afin de déterminer complétement cette loi, les deux paramètres « a » et Too doivent donc être déterminées. Ces déterminations peuvent être faites T par les expressions Too = -T et a = fd - (Tg TJ puisque toutes les g quantités Tg, T, T* et fd sont connues à ce stade. T* La première relation Too = -T suppose que la proportion du temps g T* liés aux entrées sorties et aux communications par rapport au temps d'exécution total est la même avec et sans l'outil de profilage : on peut donc estimer ce paramètre Too à partir de ce temps cumulé T*. Une fois ce paramètre Too , le second paramètre, «a », peut être déduit facilement par l'expression a = fd -(Tg -T00). Selon l'invention, on détermine également une seconde loi fournissant l'énergie consommée E(f) en fonction de la fréquence f. Selon un mode de réalisation de l'invention, cette seconde loi peut s'exprimer sous la forme : E(f )= P(f )- t dans laquelle p(f) représente la puissance du système de traitement de l'information en fonction de la fréquence. La puissance P(f) peut être préalablement déterminée pour différentes valeurs de la fréquence Par exemple, dans la mesure où le nombre de fréquences possibles peut être limité, par exemple 8 valeurs différente, une étape préalable peut être de lancer l'exécution d'une application de test à chacune de ces valeurs de fréquence, et de mesurer l'énergie consommée E(f) et le temps d'exécution. 11 est alors aisé de déduire la puissance p(f) pour chacune de ces fréquences. 11 est également possible, notamment si le nombre de valeurs possibles est plus important, de n'effectuer cette exécution et ces mesures que sur un nombre limité de valeurs, et d'effectuer une interpolation pour les valeurs intermédiaires. L'application de test doit idéalement être une application logicielle effectuant peu d'entrées-sorties et d'appels au système de gestion et de communication, mais effectuant beaucoup d'appels au microprocesseur. Une telle application de test peut par exemple être le test de performances « Linpack ». Ce test sert notamment à classer les plus puissants superordinateurs du monde dans le TOP500. Créé par Jack Dongarra, il mesure le temps mis par un ordinateur pour résoudre un système de n équations à n inconnues dense, la solution étant obtenue par une utilisation partielle du pivot de Gauss, par 2/3-n3 + n2 opérations à virgule flottantes. La performance est ensuite calculée en divisant le nombre d'opérations par le temps mis, donc en FLOPS. Connaissant la puissance du système de traitement de l'information p(f) pour l'ensemble des valeurs de la fréquence f, il est alors possible de déterminer la seconde loi pour déterminer l'énergie consommée E(f) par l'application logicielle en fonction de la fréquence f. L'invention comprend ensuite une étape de détermination de la fréquence optimale fo comme fréquence optimisant un critère C(f) combinant le temps d'exécution et la consommation énergétique, en fonction de la fréquence. Ces temps d'exécution et consommation énergétique sont bien évidemment déterminés par les premières et secondes lois respectivement. Selon un mode de réalisation de l'invention, ce critère est de la forme : C(f ) = w, -t(f)+ wE - E(f), dans laquelle wt et wE sont deux poids prédéterminées. Le choix de ces deux poids peut être fourni par l'utilisateur de l'application logicielle en fonction de ce qu'il souhaite privilégier et aussi en fonction de la politique de tarification de l'opérateur du système de traitement de l'information. Si le nombre de valeurs de fréquence possibles n'est pas trop élevé, il est possible de calculer la valeur du critère C(f) pour chacune des valeurs de la fréquence f, et de rechercher la valeur minimale de ce critère C(f) parmi ces valeurs. La fréquence optimale fo est la fréquence correspondant à cette valeur minimale du critère C(f). Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. REVENDICATIONS1. Procédé pour déterminer une fréquence optimale (fo) pour l'exécution d'une application logicielle sur un système de traitement de l'information, comportant Une première exécution de ladite application à une fréquence déterminée (fd), permettant de déterminer un temps d'exécution global (Tg) et une consommation énergétique globale (Eg) ; Une seconde exécution de ladite application à ladite fréquence déterminée (fd), à l'aide d'un outil de mesure, permettant de déterminer des mesures (n, ,I , T: ) sur l'exécution de ladite application ; Une étape de détermination d'une première loi fournissant un temps d'exécution (t(f)) en fonction de la fréquence (f), et d'une seconde loi fournissant une consommation énergétique (E(f)) en fonction de la fréquence (f) ; Une étape de détermination de ladite fréquence optimale (fo) comme fréquence optimisant un critère (C(f)) combinant ledit temps d'exécution et ladite consommation énergétique, en fonction de la fréquence. 2. Procédé selon la revendication précédente, dans lequel lesdites mesures (T*) comprennent des mesures ( T/*0 ) sur les entrées-sorties de ladite application logicielle. 3. Procédé selon la revendication précédente, dans lequel lesdites mesures (T*) comprennent des mesures (n,) sur les appels au système de gestion et de communication. 4. Procédé selon la revendication précédente, dans lequel lesdits appels sont effectués via une interface de passage de messages, MPI, et dans lequel les mesures sur lesdits appels comprennent des temps relatifs aux fonctions MPI Init, MPI wait, MPI Barrier. 5. Procédé selon l'une des revendications précédentes, dans lequel ledit critère est de la forme C(f) = w, -t(f)+ wE - E(f), dans laquelle wt et wE sont deux poids prédéterminées. 6. Procédé selon la revendication précédente, dans lequel ladite fréquence optimale (fo) est déterminée en calculant les valeurs dudit critère (C(f)) pour plusieurs valeurs de fréquence et en recherchant la valeur minimale dudit critère parmi les valeurs calculées. 7. Procédé selon la revendication précédente, dans lequel la valeur dudit critère C(f) est calculée pour chaque valeur possible de ladite fréquence (f). 20 8. Procédé selon l'une des revendications 2 à 6, selon lequel ladite première loi s'exprime sous la forme T dans laquelle T =g -T et a = fd - (Tg - Too) T* g 25 9. Procédé selon l'une des revendications précédentes dans lequel ladite seconde loi s'exprime sous la forme E(f )= P(f )- t 15dans laquelle p(f) représente la puissance dudit système de traitement de l'information en fonction de la fréquence. 10. Procédé selon l'une des revendications précédentes, dans lequel ledit système de traitement de l'information est une ferme de calcul.