EP3120243A1 - Procede et dispositif d'aide a l'optimisation et la parallelisation de code - Google Patents

Procede et dispositif d'aide a l'optimisation et la parallelisation de code

Info

Publication number
EP3120243A1
EP3120243A1 EP15709476.4A EP15709476A EP3120243A1 EP 3120243 A1 EP3120243 A1 EP 3120243A1 EP 15709476 A EP15709476 A EP 15709476A EP 3120243 A1 EP3120243 A1 EP 3120243A1
Authority
EP
European Patent Office
Prior art keywords
code
optimized
application
versions
different
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP15709476.4A
Other languages
German (de)
English (en)
Inventor
Alexandre GUERRE
Yves LHUILLIER
Jean-Thomas AQUAVIVA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Publication of EP3120243A1 publication Critical patent/EP3120243A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/443—Optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G06F8/456—Parallelism detection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3428—Benchmarking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G06F16/285—Clustering or classification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/83—Indexing scheme relating to error detection, to error correction, and to monitoring the solution involving signatures

Definitions

  • the invention relates to the field of software engineering for parallel architecture, and in particular that of assistance with optimization and code parallelization.
  • Code optimization typically involves making changes to the code in order to reduce resource requirements, reducing function execution times, or improving power consumption.
  • tools help with code optimization.
  • For sequential architectures it is known to use a description in C language of a sequential algorithm.
  • code optimization requires human intervention.
  • human intervention often introduces a variability in the quality of the codes generated for each of the parallel computing architectures. This variability raises various problems, in particular that related to the comparison of two parallel architectures where the result of the analysis is subjective because strongly dependent on the expertise of the developer of the architectures studied.
  • Another problem is related to the prediction of the performances of a new application code for several target architectures, the prediction can be imprecise because dependent on the human expertise of the
  • the Tanabe patent application US 2009/0138862 A1 proposes a device for aiding parallelization, which performs a dependency analysis to extract the opportunities for parallelization within a program.
  • the parallelization opportunities correspond to the statistically possible parallelizations for a given application. No indication as to the method of parallelizing, nor as to the potential gains, is provided. As such, the expertise related to parallelization is not taken into account.
  • An object of the present invention is to provide a method for synthesizing and formalizing the expertise of developers parallel architectures to allow any developer to be able to estimate the performance and consumption of application codes on various architectures of calculations.
  • the technical advantages of the present invention are to allow an estimation of the performance and the consumption of application codes on various computation architectures, without requiring the intervention of expert developers, nor the porting of codes on the architectures concerned.
  • the device of the present invention makes it possible to assist a developer in the effort of porting a code from a source architecture to a target architecture, starting from a non-optimized application code in a language that can be compiled natively on a network.
  • reference platform such as C, C ++, FORTRAN for example.
  • the device of the invention advantageously comprises a database of existing experimental measurements that can be enriched.
  • the measurements are either made by the process operator or imported from outside experiments.
  • Each experimental measurement consists of evaluating the performance of several reference application codes on several target architectures.
  • Each reference application code is available in a non-optimized and sequential version, allowing direct performance evaluation on a single core of each target architecture.
  • Each reference code is also available in parallelized version and optimized for each target architecture.
  • the invention will find application to make studies on the choice, the implementation, the performance possible for porting applications on new architectures.
  • the invention will apply to the industrial field where the application codes often evolve less rapidly than the parallel computing architectures, and where the problem of porting existing application code to new parallel architectures is crucial.
  • the present invention makes it possible to assist manufacturers in the porting of "business" application codes to advanced parallel architectures whose complexity may be difficult to master.
  • the method of the invention makes it possible to qualify and compare new parallel architectures in order to better understand an offer available on the market.
  • a method of assisting the optimization and code parallelization of an application running on a computer includes the steps of: comparing a portion of code representing a hot spot of an application to a plurality of versions non-optimized code to determine a correlation with at least one non-optimized code version; and - generating from said at least one non-optimized code version, performance predictions for different architectures and different parallel programming models for said hotspot.
  • the comparing step includes calculating a correlation coefficient between said hot spot and the plurality of non-optimized code versions.
  • the comparison step comprises a step of generating a signature for said hot point and comparing the signature with a plurality of signatures associated with the plurality of non-optimized code versions.
  • the comparison step between the signatures is performed according to a principal component analysis (PCA).
  • PCA principal component analysis
  • the signatures associated with the plurality of non-optimized code versions contain at least metrics relating to the stability of a data stream, to a parallelization ratio, to a re-use distance of the data stream and to a volume of data.
  • the plurality of non-optimized code versions are stored in a reference database where each non-optimized code version is a non-optimized code version for a reference platform and is associated with different optimized code versions and parallelized on different architectures and according to different models of parallel programming.
  • the different code versions optimized and parallelized on different architectures and according to different parallel programming models are stored in a porting database and the step of generating predictions consists in extracting porting data for said porting database. non-optimized code version.
  • the method further comprises a step that makes it possible to display the result of the predictions for a user.
  • the result is displayed as Kiviat diagrams.
  • the method may include an initial step of receiving an executable code of an application to be optimized and parallelized and a step of detecting in the executable code of a portion of code representing a hotspot.
  • the invention also covers a device which comprises means for implementing the method.
  • the invention may operate in the form of a computer program product that includes code instructions for performing the claimed process steps when the program is run on a computer.
  • Figure 1 schematically shows a device in which the invention can be implemented
  • Figure 2 shows a sequence of steps of the method of the invention in one embodiment
  • FIG. 3 illustrates in the form of radar diagrams the result of the method of the invention for an example of application.
  • the device of the invention comprises an extraction module (102) able to analyze a non-optimized executable code representative of an application and to extract hot spots from the code.
  • Hot spots are portions of the code that penalize the performance of the application. These portions typically represent the least amount of code line for the greatest run time.
  • Hot spots are unoptimized code portions representing discernable and compact phases of the original application.
  • the executable code entering on the extraction module is a code generated, by a compilation device, from the source code of the application to be analyzed.
  • the executable code can be either a file available in the direct environment of the device (100), stored on an internal disk of a computer implementing the device and operated by a user, either a file from a near or far external source.
  • Executable code can come from a compiler that converts source code into C / C ++ or Fortran.
  • the executable code is executed by an emulator in order to extract the appropriate characteristics.
  • the device (100) performing the analysis of the executable code of this application emulates the execution of the executable code on its dataset.
  • the application dataset is the input image.
  • the extraction module (102) is coupled to a characterization module (104) capable of characterizing the hot spots extracted from the code.
  • the characterization of hot spots consists of calculating a signature for each hot point extracted from the incoming code.
  • the characterization module is also coupled to a database (106) of reference micronuclei.
  • the base (106) is an empirical knowledge base of known optimization and parallelization techniques, either from the process operator or from external sources, consisting of reference micronuclei.
  • the knowledge base contains six reference micronuclei making it possible to cover the algorithmic space of vision as widely as possible.
  • the reference micronuclei are chosen according to several parameters such as the type of data access, for example a linear or random input image path, such as the regularity of the data, for example the fact that the nature of the calculations is predictable before execution or on the contrary if the nature of the calculations depends on the intermediate calculations at the time of execution, such as the complexity of the data, for example the number of different calculations performed on a single datum (on each pixel of an image for example).
  • Each reference micronucleus has a non-optimized code version that corresponds to a basic way of coding on a reference platform and different code versions optimized and parallelized on different architectures.
  • the reference platform is an x86 processor.
  • Input images are generated randomly and measurements are made on different image sizes. The multitude of parameters on the input images makes it possible to characterize the micronucleus algorithm independently of its inputs.
  • the database of measurements that is obtained has four input axes: (1) the target architecture, (2) the micronucleus, (3) the size of the input data set and (4) the type of parallelization relative to different programming models (for example, data-level parallelization or task-level parallelization and optimization.
  • Micronuclei can come from outside sources, provided by or retrieved from developers around the world to accumulate past expertise. The choice of micronucleus is made according to a field of application in order to increase the precision and the relevance of the process.
  • the characterization module (104) calculates a signature for any execution of executable code on an input dataset.
  • the module calculates the signature of each reference micronucleus of the knowledge base on each of its input datasets.
  • the calculation of the signatures of the reference micronuclei is done only once, during the integration of the reference micronucleus into the database, consisting of a calibration process. This calculation is performed before using the device on an input application.
  • the characterization module makes it possible to calculate the signatures of the extracted hot spots by executing the executable code of the input application with its data set.
  • the output of the signature module 104 is coupled to the input of a correlation module (108) which is itself coupled to the base of reference micronuclei.
  • the correlation module makes it possible to establish correlations between the signature of a portion of code extracted from the code of the input application and the signatures of the reference micronuclei of the knowledge base 106.
  • the output of the correlation module is coupled to the input of an extrapolation module (1 10).
  • the extrapolation module is also coupled to a porting database (1 12) which contains the data relating to the porting of reference micronuclei to various parallel architectures.
  • the porting architectures are representative of a panel of existing parallel architectures.
  • the extrapolation module makes it possible, by extracting appropriate data from the porting database 1 12, to make predictions or projections of the performance of the micronuclei extracted from the incoming code on the different architectures and by parallel programming model.
  • the result of extrapolations is then available at the output of the extrapolation module and can be presented to the user in various forms such as that illustrated for example in Figure 3 by Kiviat diagrams.
  • the data contained in the reference database also makes it possible to produce statistical predictions of the performance of the application once it has been parallelized, on measures such as execution times, a number of monopolized resources or, for example, power consumption.
  • Figure 2 illustrates the steps performed by method 200 of the invention in a preferred implementation.
  • the method begins with a step (202) for receiving an executable code representative of the application.
  • the executable code can be in C, C ++ or Fortran language or any other language compilable natively on the reference machine.
  • the code to be analyzed is a non-optimized code.
  • the method makes it possible to search for hot spots in the code.
  • the application kernels that are extracted will be the parts of the code that will be optimized as will be detailed later.
  • the step of extracting application kernels consists in breaking down the code, and searching for long continuous portions of program execution "discernible portions" and involving a minimum number of instructions of the program "compact portions".
  • the extraction step is performed with a tool based on a functional x86 processor emulator.
  • tools performing program hot-spot extraction can be used as well-known profiling and sampling tools such as GProf or Oprofile.
  • the static instructions of the code are extracted to keep only the portions corresponding to the original source code.
  • the method makes it possible to test whether the hot spot found covers a major part of the code of the application.
  • the method repeats the step of searching for and extracting hot spots from the remainder of the code.
  • the step of searching and extracting hot spots is done in the traces of dynamic instructions.
  • the next step (206) allows the characterization of the extracted nuclei by calculating a signature representative of each hot spot.
  • the signature is computed using the same emulator as used for the extraction step, and contains several metrics: (1) the stability of the data stream, (2) the parallelization ratio (3) the reuse distance of the data stream and (4) the data volume.
  • the stability of the data stream is an indicator of the average number of producer locations for each of the instructions. It captures if the calculations follow a fixed data flow circuit or if data is subjected to complex address calculations. In the latter case, continuous architectures such as GPUs would not be effective targets. In addition, poor data flow stability can lead to limited parallelization possibilities because it means that many dependencies are revealed during execution.
  • the parallelization ratio calculates on an ideal data flow graph the ratio between the ideal parallelism width and the number of executed instructions. A high value of this indicator means high parallelization possibilities.
  • the data stream reuse distance gives the average time that one byte of data must be stored before reuse. This measurement is evaluated on an ideal data flow graph and allows to know the ideal locality of data that a kernel contains and to determine if the kernel would favor a large bandwidth or a low latency architecture.
  • the data volume evaluates the total amount of data that the code executes. This information is important because the other signature parameters are independent of the data volume, all being calculated in relation to the number of executed instructions.
  • these metrics are hardware-independent as much as possible in order to measure application-related information rather than architecture-related information.
  • the synthetic metrics in this embodiment come from a richer intermediate representation consisting of a time-folded graph of the set of interactions between the different instructions of the input executable code.
  • an intermediate representation is kept with the signature to allow to quickly recalculate new metrics without having to reproduce step 206.
  • step 206 makes it possible to assign a signature to each application kernel of the non-optimized code version.
  • step (208) is to compare the previously computed signature for an application core with reference micronucleus signatures.
  • the method makes it possible to search, by a signature of a non-optimized code version, in the reference micronucleus database 106 and to correlate a non-optimized application core with a non-optimized reference micronucleus.
  • the correlation calculation between the signatures is performed according to principal component analysis (PCA).
  • PCA principal component analysis
  • the method makes it possible to select for each application core, the closest reference micronucleus by retaining the reference micronucleus presenting with the application core an optimum distance.
  • the next step (212) is for each non-optimized microkernel to extrapolate the performance of the non-optimized code to the target architectures by referring to data in the optimized port database for the selected optimal microkernel.
  • the extrapolated performances are essentially the consumption and the speed of execution of a program, after parallelization and optimization.
  • the extrapolation consists in extracting from the database of ports 1 12 the relevant data for the non-optimized micronucleus studied. Extrapolation allows the estimation of performances based on concrete and empirical portations resulting from the business expertise.
  • the result of the extrapolation (214) can be presented to the user in a variety of forms to enable selection of the appropriate target platform for its constraints.
  • FIG. 3 illustrates results obtained by the method of the invention as part of an analysis of a code relating to an image processing application.
  • the reference micronucleus base (106) is composed of the following six micronuclei:
  • the 'Max 3x3' kernel is well known to those skilled in the art as a 2D memory access filter, which performs more memory access than operations.
  • the 'Deriche Filter' and 'FGL Filter' cores are respectively x8 and x4 1D filters. These filters have horizontal and vertical cross access patterns and their dependencies are causal and anticausal.
  • the 'Quad-tree variance calculation' kernel is an algorithm that partitions the image into a zone of low variance. This algorithm exhibits a recursive behavior by the fact that it partitions more and more finely the areas of the image with strong variance. By construction, this algorithm is also strongly dependent on the data (values of the pixels of the image).
  • the integral image is an algorithm that calculates for each destination pixel, the sum of all the source pixels at the top left of the destination pixel. This algorithm exhibits a diagonal dependency scheme present in many image processing algorithms.
  • the 'Matrix Multiplication' micronucleus is a well-known algorithm that displays a very characteristic 3D access pattern.
  • OpenMP Open Multi-Processing
  • Farming OpenGL (Open Computing Language)
  • CUDA Computer Unified Device Architecture
  • the farming model was developed in C using the PThread library. In this model, the task to be performed is split into many independent subtasks and executed on fewer threads of work.
  • OpenGL and CUDA are standard languages used to program Graphics Processing Units (GPUs).
  • OpenCL is also used for Intel® multiprocessors.
  • the input data set in the example shown corresponds to images whose size is in the range of 256 * 256 up to 2048 * 2048 pixels.
  • the parameters of the reference base used by the method are:
  • a prediction of the performance is performed. This prediction provides insight into the best architecture and programming model to use. Once a 'programming model / architecture' pair is chosen, acceleration measurements (m_speedup) can be extracted from the database. To calculate the final execution time on the target platform (Predicted_time), a sequential performance report (arch_factor) between the reference architecture and the tested architecture is also needed.
  • variable 'Seq_ref_time' represents the sequential execution time of the portions of the application outside the hot spots.
  • the variable 'Seq_kernel_ref_time' represents the sequential execution time of the code portions of the application corresponding to the hot spots.
  • a correlation between the extracted micronuclei provides a confidence coefficient that can be used to determine whether the selected reference nucleus is actually very close to the application core.
  • the method of the invention also makes it possible to perform a correlation between the reference cores and thus to evaluate maximum and average values for the coefficient of confidence, the minimum values being always at zero and corresponding to kernel comparisons with them. same.
  • the selected reference kernels are considered good candidates when their confidence coefficient (in comparison with the application kernels) is below a minimum confidence coefficient of two distinct reference kernels.
  • FIG. 3 shows respectively for each of the four architectures studied, the results obtained by operating the method of the invention according to seven parameters: (302) multi-core performance; (304) Single-core efficiency; (306) Number of hearts; (308) Energy efficiency; (310) Ease of porting; (312) Memory capacity; (314) Regularity of performance. Even without a detailed forecast of application performance, these visual diagrams provide a user with a quick comparison between the four target platforms for these parameters and help select the most promising platform.
  • the illustrated example is essentially for a performance prediction calculation, the method of the invention makes it possible to execute it for other predictions, such as for example latency measurements.
  • the support can be electronic, magnetic, optical, electromagnetic or be an infrared type of diffusion medium.
  • Such supports are, for example, Random Access Memory RAMs (ROMs), magnetic or optical tapes, disks or disks (Compact Disk - Read Only Memory (CD-ROM), Compact Disk - Read / Write (CD-R / W) and DVD).

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Devices For Executing Special Programs (AREA)
  • Stored Programmes (AREA)

Abstract

La présente invention concerne un procédé et un dispositif d'aide à l'optimisation et la parallélisation de code d'une application. Le procédé s'exécute sur un ordinateur et consiste à 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. Puis le procédé permet de générer à partir de la 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.

Description

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 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, 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 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. 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 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 A1 de Tanabe propose un dispositif d'aide à la parallélisation, qui réalise une analyse des 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, 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é « Itérative Compilation and Performance Prédiction for Numerical Applications », 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 Prédiction Using data flow Analysis and Microbenchmarking", publié dans le "1 6th Workshop on Compilers for Parallel Computing (CPC 2012), 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 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 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.
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 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 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 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 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 référence est disponible dans une version non optimisée et séquentielle, permettant l'évaluation directe des performances sur un cœur 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. 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 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 industriels dans le portage de codes applicatifs « métiers », vers des architectures parallèles avancées dont la complexité peut être difficile à maîtriser.
Enfin, le procédé de l'invention permet de qualifier et de comparer des architectures parallèles nouvelles afin de mieux appréhender une 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 é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 - 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 à calculer un coefficient de corrélation entre ledit point chaud et la pluralité de versions de code non optimisées. 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. 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, à 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 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 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 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. 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. L'invention couvre aussi un dispositif qui comprend des moyens pour mettre en œuvre 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 un ordinateur.
Description des figures
Différents aspects et avantages de l'invention vont apparaître 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 :
La figure 1 montre schématiquement un dispositif dans lequel l'invention peut être implémentée ;
La figure 2 montre un enchaînement des étapes de la méthode de 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 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 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 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 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 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 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 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 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 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 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 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é 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 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 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 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 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 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 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. La sortie du module de corrélation est couplée à l'entrée d'un module d'extrapolation (1 10). Le module d'extrapolation est aussi couplé à une base de données de portage (1 12) qui contient les données relatives aux portages des micronoyaux de référence vers diverses 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 1 12, d'établir des 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 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 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 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é. 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. 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 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 GProf ou Oprofile.
Une fois un point chaud trouvé, les instructions statiques du code 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 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 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. 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 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. 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 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 connaître 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. 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 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. 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, 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. 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 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 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 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. L'extrapolation consiste à extraire de la base de données de portages 1 12 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. 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 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 ;
- Filtre de Federico Garcia Lorca (FGL) ;
- Calcul de variance en quad-tree ;
- Calcul d'image intégrale ;
- Multiplication de matrice.
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 1 D. Ces filtres ont des motifs d'accès croisés 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 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). 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 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, OpenGL (Open compting Language) et CUDA (Compute Unified Device Architecture). Le 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. OpenGL et CUDA sont des langages standards utilisés pour programmer les processeurs graphiques (ou Graphics Processing Units GPUs en anglais). OpenCL est également utilisé pour les multiprocesseurs Intel®.
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. 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 ; Des jeux de données d'entrée, de tailles différentes progressives;
Un ensemble de modèles de programmation parallèle.
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 Î7-2600 ; (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 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 plateforme cible (Predicted_time), un rapport de rendement séquentiel (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 pour calculer un temps d'exécution potentiel pour l'application parallélisée :
seq_kernel_re f 'Jime X arch_f aetor
Predictedjiirne = seq_ref_Ume x arch_factor +
m_speecf«p
(1 ) 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_ref_time' représente le temps d'exécution séquentiel des portions de code de l'application correspondant aux points chauds. 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 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 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) Efficacité monocoeur ; (306) Nombre de cœurs ; (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 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. 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 é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 - Read/Write (CD-R/W) and DVD).

Claims

Revendications
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 :
- identifier dans un code exécutable non optimisé d'une application, une portion de code dite « point chaud » pénalisant la performance de l'application ;
- déterminer une corrélation entre ledit « point chaud » et au moins une version de référence de code non optimisé parmi une pluralité de versions de référence de code non optimisé regroupées dans une base de données, la base de données contenant de plus des données de portage relatives à des portages des versions de référence de code non optimisé vers différentes versions de code optimisé et parallélisées sur différentes architectures ;
- extraire de la base de données de portage les données de portage associées à la au moins une version de référence identifiée lors de l'étape de corrélation ; et
- utiliser les données de portage extraites pour générer des prédictions de performances pour différentes architectures et selon différents modèles de programmation parallèle pour la portion de code « point chaud » optimisée.
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.
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.
Le procédé selon la revendication 3 où l'étape de comparaison entre les signatures est effectuée selon une analyse en composantes principales (AGP).
Le procédé selon l'une quelconque des revendications 1 à 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 distance de réutilisation du flot de données et à un volume de données
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 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.
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 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 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.
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 représentant un point chaud.
1 1 . Un dispositif d'aide à l'optimisation et la parallélisation de code d'une application, le dispositif comprenant des moyens pour mettre en œuvre les étapes du procédé selon l'une quelconque des 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 à 10, lorsque ledit programme est exécuté sur un ordinateur.
EP15709476.4A 2014-03-20 2015-03-11 Procede et dispositif d'aide a l'optimisation et la parallelisation de code Withdrawn EP3120243A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1452304A FR3018932B1 (fr) 2014-03-20 2014-03-20 Procede et dispositif d'aide a l'optimisation et la parallelisation de code
PCT/EP2015/055040 WO2015140021A1 (fr) 2014-03-20 2015-03-11 Procede et dispositif d'aide a l'optimisation et la parallelisation de code

Publications (1)

Publication Number Publication Date
EP3120243A1 true EP3120243A1 (fr) 2017-01-25

Family

ID=51303071

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15709476.4A Withdrawn EP3120243A1 (fr) 2014-03-20 2015-03-11 Procede et dispositif d'aide a l'optimisation et la parallelisation de code

Country Status (4)

Country Link
US (1) US20170090891A1 (fr)
EP (1) EP3120243A1 (fr)
FR (1) FR3018932B1 (fr)
WO (1) WO2015140021A1 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2539961B (en) * 2015-07-03 2022-03-02 Fujitsu Ltd Code hotspot encapsulation
JP6953800B2 (ja) 2016-07-08 2021-10-27 富士通株式会社 シミュレーションジョブを実行するためのシステム、コントローラ、方法、及びプログラム
CN107451213A (zh) * 2017-07-17 2017-12-08 广州特道信息科技有限公司 舆情分析方法及装置
EP3908947A1 (fr) 2019-03-25 2021-11-17 Aurora Labs Ltd Génération et signature d'un modèle de comportements et de relations de ligne de code
US11775317B2 (en) * 2021-04-30 2023-10-03 International Business Machines Corporation Locate neural network performance hot spots
FR3122752B1 (fr) * 2021-05-05 2023-09-29 Centre Nat Etd Spatiales Procédé mis en œuvre par ordinateur pour déterminer automatiquement une architecture cible.
CN113852814B (zh) * 2021-07-19 2023-06-16 南京邮电大学 数据级和任务级融合的并行解码方法、装置及存储介质
WO2023234952A1 (fr) * 2022-06-03 2023-12-07 Google Llc Mise en cache de sorties de compilation à l'aide de profils d'optimisation

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2015140021A1 *

Also Published As

Publication number Publication date
FR3018932B1 (fr) 2016-12-09
FR3018932A1 (fr) 2015-09-25
WO2015140021A1 (fr) 2015-09-24
US20170090891A1 (en) 2017-03-30

Similar Documents

Publication Publication Date Title
WO2015140021A1 (fr) Procede et dispositif d'aide a l'optimisation et la parallelisation de code
Qasaimeh et al. Comparing energy efficiency of CPU, GPU and FPGA implementations for vision kernels
EP1704476B1 (fr) Systeme de generation automatique de codes optimises
Nardi et al. Introducing SLAMBench, a performance and accuracy benchmarking methodology for SLAM
Gaburov et al. SAPPORO: A way to turn your graphics cards into a GRAPE-6
Verma et al. Performance evaluation of deep learning compilers for edge inference
EP2805234B1 (fr) Procédé d'optimisation de traitement parallèle de données sur une plateforme matérielle.
GB2555673A (en) Image patch matching using probabilistic sampling based on an oracle
US20210342983A1 (en) Iterative image inpainting with confidence feedback
EP3137993A1 (fr) Combinaison de tâches de calcul pour une unité de traitement graphique
US10754630B2 (en) Build-time code section-specific compiler selection
JP2022537542A (ja) 動的な画像解像度評価
Trümper et al. Performance embeddings: A similarity-based transfer tuning approach to performance optimization
US11443118B2 (en) Word embedding method and apparatus, and word search method
Ortega et al. High performance computing for optical diffraction tomography
Peredo et al. Acceleration of the Geostatistical Software Library (GSLIB) by code optimization and hybrid parallel programming
Saini et al. Bang for the Buck: Evaluating the Cost-Effectiveness of Heterogeneous Edge Platforms for Neural Network Workloads
Li et al. Characterizing the I/O pipeline in the deployment of CNNs on commercial accelerators
Tang TensorRT inference performance study in MLModelScope
Caamaño Fast and flexible compilation techniques for effective speculative polyhedral parallelization
Danopoulos et al. A quantitative comparison for image recognition on accelerated heterogeneous cloud infrastructures
Gouin et al. Threewise: a local variance algorithm for GPU
US20240220571A1 (en) Vectorized sparse convolution
CN117529668B (zh) 用于提供训练数据以使得神经网络能够分析nmr测量中的信号的系统和方法
Zumer et al. Pepid: a Highly Modifiable, Bioinformatics-Oriented Peptide Search Engine

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20160916

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20170717

R17C First examination report despatched (corrected)

Effective date: 20171017

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20201001