Brevet FR3018932A1 — publié le 20150925

PROCEDE ET DISPOSITIF D'AIDE A L'OPTIMISATION ET LA PARALLELISATION DE CODE Domaine de l'invention L'invention concerne le domaine du génie logiciel pour architecture parallèle, et en particulier celui de l'aide à l'optimisation et la parallélisation de code. Etat de la Technique Le domaine du génie logiciel est souvent décomposé en sous-domaines qui incluent : - l'analyse et le profilage d'un code applicatif pour son optimisation ; - l'évaluation et la comparaison des performances de vitesse d'exécution et de consommation électrique de différentes architectures de calculs, domaine connu sous l'anglicisme « benchmarking » ; - la modélisation et la prédiction des performances d'un code applicatif ciblant plusieurs architectures de calculs variées ; et - l'aide au portage, à la parallélisation et à l'optimisation d'un code sur une architecture cible. L'optimisation de code consiste en général à apporter des modifications sur le code dans le but de diminuer les besoins en ressources, en réduisant les temps d'exécution de fonctions ou en améliorant la consommation électrique. Selon le type d'architecture séquentielle ou parallèle sur laquelle le code opère, il existe des outils 2 3018932 d'aide à l'optimisation de code. Pour les architectures séquentielles, il est connu d'utiliser une description en langage C d'un algorithme séquentiel. Cependant, pour les architectures parallèles qui nécessitent une grande expertise, l'optimisation de code passe par une intervention humaine. Or, 5 l'intervention humaine introduit bien souvent une variabilité dans la qualité des codes générés pour chacune des architectures de calcul parallèle. Cette variabilité soulève différents problèmes, en particulier celui lié à la comparaison de deux architectures parallèles où le résultat de l'analyse est subjectif car fortement dépendant de l'expertise du développeur des 10 architectures étudiées. Un autre problème est lié à la prédiction des performances d'un nouveau code applicatif pour plusieurs architectures cibles, la prédiction peut être imprécise car dépendante de l'expertise humaine des développeurs impliqués dans le portage du code. 15 Enfin, il est souvent difficile de synthétiser l'expertise des développeurs concernant les architectures parallèles, car elle est souvent répartie sur plusieurs développeurs à travers le monde. Il devient de fait encore plus difficile de réutiliser cette expertise entre développeurs. Parmi les solutions connues d'aide à l'optimisation ou d'aide à la 20 parallélisation de code, certaines intègrent à des degrés divers une approche de la synthèse de l'expertise, telles les solutions décrites dans les documents suivants. La demande de brevet US 2009/0138862 Al de Tanabe propose un dispositif d'aide à la parallélisation, qui réalise une analyse des 25 dépendances pour extraire les opportunités de parallélisation au sein d'un programme. Dans ce dispositif, les opportunités de parallélisation correspondent aux parallélisations statistiquement possibles pour une application donnée. Aucune indication quant à la méthode de paralléliser, 3 3018932 ni quant aux gains potentiels, n'est fournie. A ce titre, l'expertise métier relative à la parallélisation n'est pas prise en compte. Le document de thèse de Grigori G. Fursin, intitulé « Iterative Compilation and Performance Prediction for Numerical Applications », 5 2004 propose une synthèse de l'expertise dans l'aide à l'optimisation. Cependant cette expertise n'est pas utilisée pour l'aide à la parallélisation. L'article d'Eric Petit et al. intitulé «Computing-Kernels Performance Prediction Using data flow Analysis and Microbenchmarking", publié dans le "16th Workshop on Compilers for Parallel Computing (CPC 2012), 10 Padova, Italy (2012)" présente une méthode pour accumuler et réutiliser une expertise relative à l'optimisation de code à grain fin et pour des architectures séquentielles. La parallélisation n'est donc pas prise en compte. Cependant, aucune approche connue ne propose d'établir un lien 15 entre la caractérisation d'une application, c'est-à-dire la reconnaissance et la décomposition en sous problèmes connus, et une base de données de technique de parallélisation. Ainsi, il n'existe pas de solution connue permettant de programmer de manière générique et portable un ensemble d'architectures parallèles 20 sans intervention humaine. Il existe alors le besoin de fournir un dispositif et un procédé d'optimisation de code qui inclut une synthétisation et une formalisation de l'expertise des développeurs d'architectures parallèles. 25 Résumé de l'invention Un objet de la présente invention est de proposer un procédé permettant de synthétiser et de formaliser l'expertise des développeurs 4 3018932 d'architectures parallèles afin de permettre à tout développeur de pouvoir procéder à une estimation des performances et de la consommation de codes applicatifs sur des architectures de calculs variées. Les avantages techniques de la présente invention sont de 5 permettre une estimation des performances et de la consommation de codes applicatifs sur des architectures de calculs variées, sans nécessiter l'intervention de développeurs experts, ni le portage des codes sur les architectures visées. Avantageusement, le dispositif de la présente invention permet 10 d'assister un développeur dans l'effort de portage d'un code d'une architecture source vers une architecture cible, en partant d'un code applicatif non optimisé dans un langage compilable nativement sur une plateforme de référence, tels les langages C, C++, fortran par exemple. Le dispositif de l'invention comprend avantageusement une base 15 de données de mesures expérimentales existantes qui peut être enrichie. Les mesures sont soit réalisées par l'opérateur du procédé soit importées d'expérimentations extérieures. Chaque mesure expérimentale consiste en l'évaluation des performances de plusieurs codes applicatifs de référence sur plusieurs architectures cibles. Chaque code applicatif de 20 référence est disponible dans une version non optimisée et séquentielle, permettant l'évaluation directe des performances sur un coeur unique de chaque architecture cible. Chaque code de référence est également disponible en version parallélisée et optimisée pour chaque architecture cible. 25 Avantageusement, l'invention trouvera application pour faire des études sur le choix, l'implémentation, les performances envisageables en vue d'un portage d'applications sur de nouvelles architectures. En particulier, l'invention s'appliquera au domaine industriel où les codes applicatifs évoluent souvent moins rapidement que les 5 3018932 architectures de calculs parallèles, et où le problème du portage d'un code applicatif existant sur de nouvelles architectures parallèles est crucial. Avantageusement, la présente invention permet d'assister les 5 industriels dans le portage de codes applicatifs « métiers », vers des architectures parallèles avancées dont la complexité peut être difficile à maitriser. Enfin, le procédé de l'invention permet de qualifier et de comparer des architectures parallèles nouvelles afin de mieux appréhender une 10 offre disponible sur le marché. Pour obtenir les résultats recherchés, un procédé, un dispositif et un produit programme d'ordinateur sont proposés. En particulier, un procédé d'aide à l'optimisation et la parallélisation de code d'une application s'exécutant sur un ordinateur comprend les 15 étapes de : - comparer une portion de code représentant un point chaud d'une application à une pluralité de versions de code non optimisées pour déterminer une corrélation avec au moins une versions de code non optimisée ; et 20 - générer à partir de ladite au moins une version de code non optimisée, des prédictions de performance pour différentes architectures et selon différents modèles de programmation parallèle pour ledit point chaud. Dans un mode de réalisation, l'étape de comparaison consiste à 25 calculer un coefficient de corrélation entre ledit point chaud et la pluralité de versions de code non optimisées. 6 3018932 Dans une variante, l'étape de comparaison comprend une étape de générer une signature pour ledit point chaud et de comparer la signature avec une pluralité de signatures associées à la pluralité de versions de code non optimisées. 5 Avantageusement, l'étape de comparaison entre les signatures est effectuée selon une analyse en composantes principales (ACP). Toujours avantageusement, les signatures associées à la pluralité de versions de code non optimisées contiennent au moins des métriques relatives à la stabilité d'un flot de données, à un ratio de parallélisation, à 10 une distance de réutilisation du flot de données et à un volume de données. Dans une implémentation, la pluralité de versions de code non optimisées est stockée dans une base de données de référence où chaque version de code non optimisée est une version de code non 15 optimisée pour une plateforme de référence et est associée à différentes versions de code optimisées et parallélisées sur différentes architectures et selon différents modèles de programmation parallèle. Dans un mode de réalisation, les différentes versions de code optimisées et parallélisées sur différentes architectures et selon différents 20 modèles de programmation parallèle sont stockées dans une base de données de portage et l'étape de génération de prédictions consiste à extraire des données de portage pour ladite version de code non optimisée. Avantageusement, le procédé comprend de plus une étape qui 25 permet d'afficher le résultat des prédictions pour un utilisateur. Dans un mode de réalisation, le résultat est affiché sous forme de diagrammes de Kiviat. 7 3018932 Le procédé peut comprendre une étape initiale de réception d'un code exécutable d'une application à optimiser et paralléliser et une étape de détection dans le code exécutable d'une portion de code représentant un point chaud. 5 L'invention couvre aussi un dispositif qui comprend des moyens pour mettre en oeuvre le procédé. L'invention peut opérer sous la forme d'un produit programme d'ordinateur qui comprend des instructions de code permettant d'effectuer les étapes du procédé revendiqué lorsque le programme est exécuté sur 10 un ordinateur. Description des figures Différents aspects et avantages de l'invention vont apparaitre en 15 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 : La figure 1 montre schématiquement un dispositif dans lequel l'invention peut être implémentée ; La figure 2 montre un enchainement des étapes de la méthode de 20 l'invention dans un mode de réalisation ; La figure 3 illustre sous forme de diagrammes en radar le résultat du procédé de l'invention pour un exemple d'application. Description détaillée de l'invention 25 8 3018932 Référence est faite à la figure 1 qui montre de manière schématique les modules du dispositif de l'invention. Le dispositif de l'invention (100) comprend un module d'extraction (102) apte à analyser un code exécutable non optimisé représentatif 5 d'une application et à extraire des points chauds du code. Les points chauds sont des portions du code pénalisant la performance de l'application. Ces portions représentent en général le moins de ligne de code pour le plus grand temps d'exécution. Les points chauds sont des portions de code non optimisées 10 représentant des phases discernables et compactes de l'application d'origine. Le code exécutable entrant sur le module d'extraction est un code généré, par un dispositif de compilation, à partir du code source de l'application à analyser. Bien que non montré sur la figure 1, l'homme de 15 l'art comprend que le code exécutable peut être soit un fichier disponible dans l'environnement direct du dispositif (100), stocké sur un disque interne d'un ordinateur implémentant le dispositif et opéré par un utilisateur, soit un fichier provenant d'une source externe proche ou éloignée. Le code exécutable peut ainsi provenir d'un compilateur qui 20 transforme un code source en langage C/C++ ou Fortran. Dans une implémentation, le code exécutable est exécuté par un émulateur afin d'en extraire les caractéristiques adéquates. Dans un exemple concret d'une application prenant une image en entrée et produisant en sortie une image des contours de l'image d'entrée, le dispositif (100) effectuant 25 l'analyse du code exécutable de cette application, émule l'exécution du code exécutable sur son jeu de données. Dans cet exemple, le jeu de données de l'application est l'image d'entrée. Le module d'extraction (102) est couplé à un module de caractérisation (104) apte à caractériser les points chauds extraits du 9 3018932 code. Dans un mode de réalisation, la caractérisation des points chauds consiste à calculer une signature pour chaque point chaud extrait du code entrant. Le module de caractérisation est aussi couplé à une base de 5 données (106) de micronoyaux de référence. La base (106) est une base de connaissances empiriques de techniques d'optimisation et de parallélisation connues, soit en provenance de l'opérateur du procédé, soit en provenance de sources extérieures, constituée de micronoyaux de référence. Dans un mode de 10 réalisation appliqué au domaine du traitement de l'image, la base de connaissances contient six micronoyaux de référence permettant de couvrir le plus largement possible l'espace algorithmique de la vision. Les micronoyaux de référence sont choisis en fonction de plusieurs paramètres comme le type d'accès aux données, par exemple un 15 parcours d'image d'entrée linéaire ou aléatoire, comme la régularité des données, par exemple le fait que la nature des calculs soit prévisible avant l'exécution ou au contraire si la nature des calculs dépend des calculs intermédiaires au moment de l'exécution, comme la complexité des données, par exemple le nombre de calculs différents effectués sur 20 une seule donnée (sur chaque pixel d'une image par exemple). Chaque micronoyau de référence possède une version de code non optimisée qui correspond à une façon basique de coder sur une plateforme de référence et différentes versions de code optimisées et parallélisées sur différentes architectures. Dans l'exemple décrit et illustré 25 par la figure 3, la plateforme de référence est un processeur x86. Les images d'entrées sont générées aléatoirement et les mesures sont faites sur différentes tailles d'image. La multitude de paramètres sur les images d'entrée permet de caractériser l'algorithme du micronoyau indépendamment de ses entrées. La base de données de mesures qui 10 3018932 est obtenue, possède quatre axes d'entrée : (1) l'architecture cible, (2) le micronoyau, (3) la taille du jeu de données en entrée et (4) le type de parallélisation relatif à différents modèles de programmation (par exemple, une parallélisation au niveau des données ou une parallélisation 5 au niveau des tâches) et d'optimisation. L'homme du métier comprendra que la base de données n'est pas limitée dans le nombre de micronoyaux de référence. Les micronoyaux peuvent provenir de sources extérieures, fournis par ou récupérés de développeurs du monde entier pour accumuler l'expertise passée. Le 10 choix des micronoyaux est réalisé en fonction d'un domaine d'application afin d'augmenter la précision et la pertinence du procédé. Le module de caractérisation (104) permet de calculer une signature pour n'importe quelle exécution d'un code exécutable sur un jeu de données d'entrée. Le module permet de calculer la signature de 15 chaque micronoyau de référence de la base de connaissance, sur chacun de ses jeux de données d'entrée. Le calcul des signatures des micronoyaux de référence est effectué une seule fois, lors de l'intégration du micronoyau de référence dans la base de données, consistant en un processus de calibration. Ce calcul est effectué avant une utilisation du 20 dispositif sur une application d'entrée. Lors de l'utilisation pour une application donnée, le module de caractérisation permet de procéder au calcul de signatures des points chauds extraits en exécutant le code exécutable de l'application d'entrée avec son jeu de données. La sortie du module de signature 104 est couplée à l'entrée d'un 25 module de corrélation (108) qui est lui-même couplé à la base de micronoyaux de référence. Le module de corrélation permet d'établir des corrélations entre la signature d'une portion de code extraite du code de l'application d'entrée et les signatures des micronoyaux de référence de la base de connaissance 106. 11 3018932 La sortie du module de corrélation est couplée à l'entrée d'un module d'extrapolation (110). Le module d'extrapolation est aussi couplé à une base de données de portage (112) qui contient les données relatives aux portages des micronoyaux de référence vers diverses 5 architectures parallèles. De manière préférentielle, les architectures de portage sont représentatives d'un panel d'architectures parallèles existantes. Le module d'extrapolation permet par l'extraction de données appropriées de la base de données de portage 112, d'établir des 10 prédictions ou projections des performances des micronoyaux extraits du code entrant sur les différentes architectures et par modèle de programmation parallèle. Le résultat des extrapolations est ensuite disponible en sortie du module d'extrapolation et peut être présenté à l'utilisateur sous diverses 15 formes telle celle illustrée par exemple sur la figure 3 par des diagrammes de Kiviat. Les données contenues dans la base de référence permettent également de produire des prédictions statistiques des performances de l'application une fois parallélisée, sur des mesures comme des temps 20 d'exécution, un nombre de ressources monopolisées ou encore par exemple une consommation électrique. La figure 2 illustre les étapes opérées par le procédé 200 de l'invention dans une implémentation préférentielle. Pour l'analyse d'une application devant être portée sur une 25 nouvelle architecture, le procédé débute par une étape (202) de réception d'un code exécutable représentatif de l'application. Le code exécutable peut être en langage C, C++ ou Fortran ou tout autre langage compilable nativement sur la machine de référence. Le code à analyser est un code non optimisé. 12 3018932 Dans une étape suivante (204), le procédé permet de rechercher des points chauds dans le code. Les noyaux applicatifs qui sont extraits vont être les parties du code qui seront optimisées comme il sera détaillé plus loin. 5 L'étape d'extraction de noyaux applicatifs consiste à décomposer le code, et rechercher de longues portions continues d'exécution du programme « portions discernables » et impliquant un nombre minimal d'instructions du programme « portions compactes ». Dans un mode de réalisation préférentiel, l'étape d'extraction est 10 opérée avec un outil basé sur un émulateur fonctionnel de processeur x86. Cependant, d'autres outils réalisant une extraction de points chauds de programme peuvent être utilisés comme des outils de profilage et d'échantillonnage bien connus tels que G Prof ou Oprofile. Une fois un point chaud trouvé, les instructions statiques du code 15 sont extraites pour ne conserver que les portions correspondant au code source original. Le procédé permet de tester si le point chaud trouvé couvre une majeure partie du code de l'application. Dans le cas contraire, le procédé réitère l'étape de recherche et extraction de points chauds sur le restant 20 du code. Avantageusement, l'étape de recherche et extraction de points chauds est faite sur les traces d'instructions dynamiques. L'étape suivante (206) permet la caractérisation du/des noyaux extraits par le calcul d'une signature représentative de chaque point chaud. Dans un mode de réalisation, la signature est calculée à l'aide du 25 même émulateur que celui utilisé pour l'étape d'extraction, et contient plusieurs métriques : (1) la stabilité du flot de données, (2) le ratio de parallélisation, (3) la distance de réutilisation du flot de données et (4) le volume de données. 13 3018932 La stabilité du flot de données est un indicateur du nombre moyen d'emplacements de producteurs pour chacune des instructions. Il permet de capter si les calculs suivent un circuit de flux de données fixe ou si des données sont soumises à des calculs d'adresse complexes. Dans ce 5 dernier cas, les architectures en continu telles que les GPU ne seraient pas des cibles efficaces. En outre, une stabilité des flux de données pauvres peut conduire à des possibilités de parallélisation limitées, car il signifie que de nombreuses dépendances sont révélées lors de l'exécution. 10 Le ratio de parallélisation calcule sur un graphe de flux de données idéal, le rapport entre la largeur idéale de parallélisme et le nombre d'instructions exécutées. Une valeur élevée de cet indicateur signifie des possibilités de parallélisation élevées. La distance de réutilisation de flot de données donne le temps 15 moyen qu'un octet de données doit être stocké avant de les réutiliser. Cette mesure est évaluée sur un graphe de flux de données idéal et permet de connaitre la localité idéale de données qu'un noyau contient et de déterminer si le noyau privilégierait une large bande passante ou une architecture à faible latence. 20 Le volume de données évalue le volume total de données que le code exécute. Cette information est importante car les autres paramètres de signature sont indépendants du volume de données, étant tous calculés par rapport au nombre d'instructions exécutées. Avantageusement, ces métriques sont indépendantes du matériel 25 autant que possible afin de mesurer de l'information relative à l'application plutôt qu'en rapport à l'architecture. Cependant, l'homme de l'art appréciera que de nouvelles métriques puissent être prises en compte. 14 3018932 Les métriques synthétiques dans ce mode de réalisation proviennent d'une représentation intermédiaire plus riche constituée d'un graphe replié dans le temps de l'ensemble des interactions entre les différentes instructions du code exécutable d'entrée. Avantageusement, 5 une représentation intermédiaire est conservée avec la signature pour permettre de recalculer rapidement de nouvelles métriques sans avoir à reproduire l'étape 206. Ainsi l'étape 206 permet d'attribuer une signature à chaque noyau applicatif de la version de code non optimisée. 10 L'étape suivante (208) consiste à comparer la signature précédemment calculée pour un noyau applicatif avec des signatures de micronoyaux de référence. Avantageusement, le procédé permet de rechercher, par une signature d'une version de code non-optimisée, dans la base de micronoyaux de référence 106 et de corréler un noyau 15 applicatif non-optimisé avec un micronoyau de référence non-optimisé. Dans un mode de réalisation, le calcul de corrélation entre les signatures est effectué selon une analyse en composantes principales (ACP). A l'étape suivante (210), le procédé permet de sélectionner pour chaque noyau applicatif, le micronoyau de référence le plus proche en 20 retenant le micronoyau de référence présentant avec le noyau applicatif une distance optimum. L'étape suivante (212) consiste pour chaque micronoyau non optimisé, à extrapoler les performances du code non optimisé sur les architectures cibles, en se référant à des données de la base de données 25 de portages optimisés relatives au micronoyau optimum sélectionné. Les performances extrapolées sont essentiellement la consommation et la vitesse d'exécution d'un programme, après parallélisation et optimisation. 15 301 893 2 L'extrapolation consiste à extraire de la base de données de portages 112 les données pertinentes pour le micronoyau non optimisé étudié. L'extrapolation permet l'estimation de performances en se basant sur des portages concrets et empiriques issus de l'expertise métier. 5 Le résultat de l'extrapolation (214) peut être présenté à l'utilisateur sous diverses formes, pour permettre de sélectionner la plateforme cible appropriée à ses contraintes. La figure 3 illustre des résultats obtenus par le procédé de l'invention dans le cadre d'une analyse d'un code relatif à une application 10 de traitement de l'image. Dans l'exemple décrit, la base de micronoyaux de référence (106) est composée des six micronoyaux suivants : - Max 3x3 ; - Filtre de Deriche ; 15 - Filtre de Federico Garcia Lorca (FGL) ; - Calcul de variance en quad-tree ; - Calcul d'image intégrale ; - Multiplication de matrice. 20 Le noyau 'Max 3x3' est bien connu de l'homme de l'art comme un filtre d'accès mémoire 2D, qui effectue plus d'accès mémoires que d'opérations. Les noyaux 'Filtre de Deriche' et 'Filtre FGL' sont respectivement des x8 et x4 filtres 1D. Ces filtres ont des motifs d'accès croisés 25 horizontaux et verticaux et leurs dépendances sont causales et anticausales. Le noyau 'Calcul de variance en quad-tree' est un algorithme qui partitionne l'image en zone de faible variance. Cet algorithme exhibe un 16 301 893 2 comportement récursif par le fait qu'il partitionne de plus en plus finement les zones de l'image à forte variance. Par construction cet algorithme est également fortement dépendant des données (valeurs des pixels de l'image). 5 L'image intégrale est un algorithme qui calcule pour chaque pixel destination, la somme de tous les pixels sources en haut et à gauche du pixel destination. Cet algorithme exhibe un schéma de dépendances diagonal présent dans de nombreux algorithmes de traitement de l'image. Le micronoyau 'Multiplication de matrice' est un algorithme bien 10 connu qui exhibe un motif d'accès 3D tout à fait caractéristique. Quatre modèles de programmation ont été utilisés dans l'exemple décrit : OpenMP (Open Multi-Processing) qui est une interface de programmation pour le calcul parallèle, Farming, OpenCL (Open compting Language) et CUDA (Compute Unified Device Architecture). Le 15 modèle « farming » a été développé en C à l'aide de la librairie PThread. Dans ce modèle, la tâche à effectuer est découpée en de nombreuses sous-tâches indépendantes et exécutées sur des threads de travails en nombre moindre. OpenCL et CUDA sont des langages standards utilisés pour programmer les processeurs graphiques (ou Graphics Processing 20 Units GPUs en anglais). OpenCL est également utilisé pour les multiprocesseurs Inte10. Le jeu de données d'entrée dans l'exemple illustré, correspond à des images dont la taille est dans une plage allant de 256*256 jusqu'à 2048*2048 pixels. 25 Ainsi, les paramètres de la base de référence utilisés par le procédé sont : - Un ensemble d'architectures parallèles cibles ; - Un ensemble de micronoyaux de référence ; 17 3018932 - Des jeux de données d'entrée, de tailles différentes et progressives; - Un ensemble de modèles de programmation parallèle. 5 Dans une variante, il est également possible de faire varier le nombre de processeurs utilisés par l'architecture cible, si celle-ci le permet. Revenant à l'exemple de la figure 3, quatre architectures cibles ont été caractérisées dans la base de données : (a) Intel Xeon Core i7-2600; 10 (b) ARM Cortex A9 quadcore ; (c) Tilera TilePro64 et (d) Nvidia Geforce GTX 580. Une fois que le micronoyau applicatif extrait de l'application est associé à un noyau de référence de la base de données, une prédiction de la performance est réalisée. Cette prédiction donne un aperçu sur la 15 meilleure architecture et le meilleur modèle de programmation à utiliser. Une fois qu'un couple 'modèle de programmation / architecture' est choisi, des mesures d'accélération (m_speedup) peuvent être extraites de la base de données. Pour calculer le temps d'exécution final sur la plate-forme cible (Predicted_time), un rapport de rendement séquentiel 20 (arch_factor) entre l'architecture de référence et l'architecture testée est également nécessaire. En utilisant des outils d'extraction, tous les micronoyaux applicatifs extraits ne peuvent pas se chevaucher, les micronoyaux sont alors parallélisés indépendamment. La formule (1) suivante peut être utilisée 25 pour calculer un temps d'exécution potentiel pour l'application parallélisée : (1) 18 3018932 où la variable `Seq_ref_time' représente le temps d'exécution séquentiel des portions de l'application extérieures aux points chauds. La variable `Seq_kernel_reftime' représente le temps d'exécution séquentiel des portions de code de l'application correspondant aux points chauds. 5 Avantageusement, une corrélation entre les micronoyaux extraits fournit un coefficient de confiance qui peut être utilisé pour déterminer si le noyau de référence sélectionné est réellement très proche du noyau de l'application. Le procédé de l'invention permet de plus d'effectuer une corrélation 10 entre les noyaux de référence et ainsi évaluer des valeurs maximales et moyennes pour le coefficient de confiance, les valeurs minimales étant toujours à zéro et correspondant à des comparaisons de noyau avec eux-mêmes. Les noyaux de référence sélectionnés sont considérés comme étant de bons candidats quand leur coefficient de confiance (en 15 comparaison avec les noyaux applicatifs) est en dessous d'un coefficient de confiance minimum de deux noyaux de référence distincts. La figure 3 montre respectivement pour chacune des quatre architectures étudiées, les résultats obtenus en opérant le procédé de l'invention selon sept paramètres : (302) Performance multicoeurs ; (304) 20 Efficacité monocoeur ; (306) Nombre de coeurs ; (308) Efficacité énergétique ; (310) Facilité de portage ; (312) Capacité mémoire ; (314) Régularité de la performance. Même sans une prévision détaillée de la performance d'une application, ces diagrammes visuels offrent à un utilisateur une comparaison rapide entre les quatre plateformes cibles 25 pour ces paramètres et aident à sélectionner la plateforme la plus prometteuse. Bien que l'exemple illustré soit essentiellement pour un calcul de prédiction de performances, le procédé de l'invention permet de l'exécuter pour d'autres prédictions, comme par exemple des mesures de latence. 19 3018932 L'homme du métier considèrera que la présente invention peut s'implémenter à partir d'éléments matériel et/ou logiciel et opérer sur un ordinateur. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut être 5 électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. De tels supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory RAM, Read-Only Memory ROM), des bandes, des disquettes ou disques magnétiques ou optiques (Compact Disk - Read Only Memory (CD-ROM), Compact Disk 10 - Read/VVrite (CD-R/VV) and DVD). 20 REVENDICATIONS1. Procédé d'aide à l'optimisation et la parallélisation de code d'une application, le procédé s'exécutant sur un ordinateur et comprenant les étapes de : - comparer une portion de code représentant un point chaud d'une l'application à une pluralité de versions de code non optimisées pour déterminer une corrélation avec au moins une version de code non optimisée ; et - générer à partir de ladite au moins une version de code non optimisée, des prédictions de performance pour différentes architectures et selon différents modèles de programmation parallèle pour ledit point chaud. 2. Le procédé selon la revendication 1 où l'étape de comparaison consiste à calculer un coefficient de corrélation entre ledit point chaud et la pluralité de versions de code non optimisées. 3. Le procédé selon la revendication 1 ou 2 dans lequel l'étape de comparaison comprend une étape de générer une signature pour ledit point chaud et de comparer la signature avec une pluralité de signatures associées à la pluralité de versions de code non optimisées. 4. Le procédé selon la revendication 3 où l'étape de comparaison entre les signatures est effectuée selon une analyse en composantes principales (ACP). 21 3018932 5. Le procédé selon l'une quelconque des revendications 3 à 4 dans lequel les signatures associées à la pluralité de versions de code non optimisées contiennent au moins des métriques relatifs à la stabilité d'un flot de données, à un ratio de parallélisation, à une 5 distance de réutilisation du flot de données et à un volume de données 6. Le procédé selon l'une quelconque des revendications 1 à 5 dans lequel la pluralité de versions de code non optimisées est stockée 10 dans une base de données de référence où chaque version de code non optimisée est une version de code non optimisée pour une plateforme de référence et est associée à différentes versions de code optimisées et parallélisées sur différentes architectures et selon différents modèles de programmation parallèle. 15 7. Le procédé selon l'une quelconque des revendications 1 à 6 dans lequel les différentes versions de code optimisées et parallélisées sur différentes architectures et selon différents modèles de programmation parallèle sont stockées dans une base de données 20 de portage et où l'étape de génération de prédictions consiste à extraire des données de portage pour ladite version de code non optimisée. 8. Le procédé selon l'une quelconque des revendications 1 à 7 25 comprenant de plus une étape d'afficher le résultat des prédictions pour un utilisateur. 9. Le procédé selon la revendication 8 dans lequel le résultat est affiché sous forme de diagrammes de Kiviat. 22 3018932 10. Le procédé selon l'une quelconque des revendications 1 à 9 comprenant une étape initiale de réception d'un code exécutable d'une application à optimiser et paralléliser et une étape de détection dans le code exécutable d'une portion de code 5 représentant un point chaud. 11. Un dispositif d'aide à l'optimisation et la parallélisation de code d'une application, le dispositif comprenant des moyens pour mettre en oeuvre les étapes du procédé selon l'une quelconque des 10 revendications 1 à 10. 12. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 15 10, lorsque ledit programme est exécuté sur un ordinateur.