WO2010049317A1 - Procédé de réalisation d'un appel d'une instance d'une fonction, dispositif, et programme d'ordinateur correspondant. - Google Patents

Procédé de réalisation d'un appel d'une instance d'une fonction, dispositif, et programme d'ordinateur correspondant. Download PDF

Info

Publication number
WO2010049317A1
WO2010049317A1 PCT/EP2009/063761 EP2009063761W WO2010049317A1 WO 2010049317 A1 WO2010049317 A1 WO 2010049317A1 EP 2009063761 W EP2009063761 W EP 2009063761W WO 2010049317 A1 WO2010049317 A1 WO 2010049317A1
Authority
WO
WIPO (PCT)
Prior art keywords
function
instance
software module
execution
data
Prior art date
Application number
PCT/EP2009/063761
Other languages
English (en)
Inventor
François Bodin
Original Assignee
Caps Entreprise
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 Caps Entreprise filed Critical Caps Entreprise
Priority to EP09736975A priority Critical patent/EP2342636A1/fr
Priority to US13/126,938 priority patent/US20110271290A1/en
Publication of WO2010049317A1 publication Critical patent/WO2010049317A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions
    • G06F9/44542—Retargetable

Definitions

  • the present invention relates to the field of software application deployment.
  • a hardware platform such as a personal computer PC, is composed of many elements: one or more processors, one or more graphics card, data link buses (serial local bus, parallel bus), management interfaces volatile memory (RAM) as well as mass memory management interfaces. While respecting substantially identical communication techniques, such hardware platforms can be profoundly different.
  • computational node a set of heterogeneous or homogeneous multicore processors organized around a main memory. This memory is not necessarily shared by all the processors, the data transfers can also be implemented by DMA (from the English “Direct Memory Access” for “Direct Access Memory”) etc.
  • Each computing core can have a local memory of its own, as is the case in some multicore architectures. 2 SOLUTIONS OF THE PRIOR ART
  • the performance of an application is influenced by a large number of factors: the hardware elements available on the computation node: a computation node is the set of processors -multiculators or not- and hardware accelerators: for example GPU, ("Graphie Processing Unnit") or FPGA, (Field Programmable Gault Arrays or "programmable logic networks”) sharing a common physical memory; the possible priority given to each application; the datasets the applications are working on; - the applications already running and the use of resources by it.
  • GPU Graphics Processing Unnit
  • FPGA Field Programmable Gault Arrays or "programmable logic networks”
  • the installation component has detected that the platform has a graphics card of a certain type, or a certain brand (NVidia TM or ATI TM for example)
  • this information is transmitted to the compiler who realizes a compilation of functions and procedures using the graphics card according to these parameters (type of graphics processor, memory available on the card, etc.).
  • This technique of compilation at installation, during deployment has the advantage of providing a set of instances of functions or instances of procedures compiled according to the platform on which the application is installed, and therefore adapted to operate with the components of this platform.
  • Another technique is to compile functions or procedures as needed to generate instances of functions or functions. procedures at least partially adapted to the execution context. These techniques create the instance of the function when it is called.
  • the invention overcomes these disadvantages of the prior art.
  • the invention relates to a method of making a call of an instance of a function present within at least a first software module and required by a second software module, said calling software module.
  • such a method comprises: a step of obtaining a current execution context, said current execution context depends on at least one execution situation of said calling software module and includes execution data; a step of selecting said function instance, from at least two available instances, based on said execution data of said current execution context.
  • the invention makes it possible to solve the problems related to the consideration of multiple software architectures by selecting, at the time of execution of the calling software module, the instance of a function that is best able to provide data. results faster.
  • the calling software module may be the main application currently running, whereas the first software module may be a dynamic link library or a dynamically loaded library at the beginning of the execution of the application.
  • said selection step further comprises, when said search is unsuccessful, a step of selecting a default call instance.
  • the invention overcomes the absence of a context in the data structure associated with said function.
  • a default function instance can be implemented to allow the application to continue anyway. This default instance might not be the best instance of performance against the execution context, but it ensures that the application runs without error.
  • said current execution context furthermore comprises data relating to: a hardware architecture of a hardware platform on which said calling software module executes; a current workload of said hardware platform on which said calling software module executes.
  • said at least one execution situation of said calling software module comprises a problem size (n), said problem size (n) being a parameter of said selected function instance.
  • the invention makes it possible to select the function instance to be called according to the problem to be solved by the function.
  • the invention makes it possible to select an instance according to the call parameter of this function.
  • a function whose parameter is an integer "i”.
  • the execution context will include the value of this integer "i” so that, for example, if the value of "i" is less than one thousand, a first function instance will be called and if the value of "i" is greater than equal to one thousand and less than or equal to two thousand, a second instance of function will be called.
  • said data structure is in the form of a decision tree, in which each node of said decision tree corresponds to a decision to be made as a function of at least one of said data. executing said current execution context.
  • the leaves of said decision tree comprise at least one function instance identifier to be called.
  • a function instance identifier is found to indicate to the calling software module (1).
  • application is the instance of the function that should be used
  • the invention increases the overall performance of the application drastically because this dynamic compilation step (also called "JIT") is only used as a last resort, when the decision identify a suitable function instance.
  • the invention also relates to a method for calculating a decision tree. According to the invention, such a method makes it possible to obtain a decision tree which is subsequently used in a method of making a call of a function instance as described above.
  • the invention also relates to a method for constructing a selection structure of a function instance to be called when a first software module, called the calling software module, requires the execution of a function with a second software module.
  • said method of construction comprises, for a given function: a step of compiling a plurality of function instances, each instance being configured to present a probable performance as a function of at least one context of determined performance; a step of analyzing the actual performance of said instances of said plurality of function instances delivering performance indices; a step of constructing said data structure associating a a function instance identifier to a data set of an execution context so that said decision structure makes it possible to decide which function instance to call based on said delivered performance indices.
  • the invention also relates to a device for making a call of an instance of a function present in at least a first software module and required by a second software module, called the calling software module.
  • such a device comprises: means for obtaining a current execution context, said current execution context depends on at least one execution situation of said calling software module and comprises data of execution; means for selecting said function instance, from at least two available instances, based on said execution data of said current execution context.
  • the invention also relates to one or more computer programs comprising instructions for the implementation of an embodiment of a call of a function instance and / or a construction method respectively, as previously described.
  • programs are downloadable from a communication network and / or stored on a computer readable medium and / or executable by a processor. 4 LIST OF FIGURES
  • FIG. 1 presents the general principle of the invention
  • Figure 2 shows a decision tree according to the invention
  • Figure 3 illustrates the process of creating a decision tree according to the invention.
  • the invention implements pre-calculated data structures that are embedded in an executive that instantiates the decision to run an application.
  • the instantiation of the decision is to decide that it is the instance of the function that is used to increase performance.
  • the decision to use one instance rather than another is therefore made at runtime.
  • an instance is a version of a function, presenting itself in an executable form, making it possible to provide a result based on a set of input parameters.
  • This parameter set may be empty.
  • a function is a set of instructions, written in a programming language, performing a certain task and providing a result.
  • a function that returns no result is a procedure.
  • the term function (and also the term codelet thereafter) is used to refer to both functions and procedures.
  • a data structure is used to decide which function instance to use, at the time of execution of the application.
  • This data structure uses a current execution context (also called current call context) to identify a function instance to use.
  • the execution context includes more parameters and data than the data needed to execute the function instance.
  • the invention thus relates to a method of making a call of an instance of a function (first, second or nth instance) present within at least a first software module (for example a library that contains the instances ) and required by a second software module, called the calling software module (the application).
  • a first software module for example a library that contains the instances
  • the calling software module the application
  • this method comprises: a step of obtaining a current execution context, which depends on at least one execution situation of said calling software module (this is the calling software context) and includes execution data; a step of selecting said function instance, from at least two available instances, according to the current execution context.
  • the first software module and the second module software will be included within the application, so that the application will contain the instances of functions: the first and second software modules are loaded at startup and are accessible from the executive.
  • the invention makes it possible, for example, in one case to execute a function on the central processor of the platform (the multi-core processor for example using the appropriate instance) and in another case, a little later during execution. the application on the graphics card (using the appropriate instance to run on the graphics card).
  • the data structure does not issue an instance identifier to be used, for example if the data of the current execution context does not lend itself to identification of an instance, to select an instance called by default to allow the continuation of the execution.
  • the method of the invention implements a step of compiling on the fly of an instance function adapted to the current execution context.
  • This on-the-fly compilation can be implemented in combination with the execution of a default instance.
  • the default instance is run on one core, to allow the application to continue running while a particular instance is compiled on another core to satisfy the context of current execution. So, at the first appearance of the context In the current application, the default instance is used and a usable instance for the current context is compiled and possibly inserted in a dynamic library listing the function instances.
  • the data structure listing the instances associated with the execution contexts is then updated to insert the identifier of the compiled instance on the fly. This new instance can then be used again (without compilation) when a future execution context references it.
  • a function "fcod" 10 is written in a programming language (for example C ++). For example, it contains a code, in pseudo computer code, of the type:
  • This function 10 is compiled
  • test 20 can be written in pseudo computer code as follows:
  • the implementation of the method of the invention is presented in a multi-core architecture.
  • the use of multicore architectures assumes that the application code has previously been partitioned into sequential sections and parallel sections.
  • a master code executing on a "master” core initiates the execution of instruction sequences on the other compute resources.
  • codelets these sequences of instructions, which are instances of functions according to the invention. These instances of functions are executed on a heart different from the master heart.
  • a codelet is a particular function which respects the following constraints: the sizes of the data passed in parameter are known (it is for example the length of the chain or the table passed in parameter, which define a size of problem); pointer and table parameters are not aliased (they are not passed by reference); it does not have direct access to global variables (these variables, if they are necessary, are passed as parameters); the codelet does not produce input / output (by displaying or waiting for feedback from the user); - the calculation of the codelet (the result) is identical for all values of identical parameters (i.e. including the areas pointed by the parameters tables and pointers).
  • codelets exist possibly in multiple executable versions in order to take into account the heterogeneity of the architecture (it is a first category of instance).
  • executable codelet versions specially optimized for some of the input data this is a second instance category: these executable versions, specially optimized for some input data, all implement the same features, but can for example be written differently depending on the size N of the input problem. If, for example, a codelet is in charge of sorting an array of size N, the source code of the codelet may be different depending on the size of the array: for an array of size N less than 100, a first source code will be used for compilation of a first instance whereas when the size N is greater than 100, a second source code will be used for the compilation of a second instance.
  • the execution context of an executable codelet is called a set comprising at least some of the following data: the hardware configuration of a computation node (calculation, storage, connection components); the size of the input data of the codelet (the size of the parameters); the occupation of computing cores (memory and computing units); the data available in the local memory cores; the rights to use the components of the nodes.
  • the description of an implemented codelet may include numerous executable instances, as already mentioned, characterized by: call constraints of the instance (acceptable parameters); target architecture of the instance and target parameter (number of cores for example); performance profile of the instance.
  • the call constraints of the instance describe the acceptable input data from the point of view of a correct execution.
  • an instance may be implemented for a fixed data size and may be incorrect in all other cases.
  • the usual constraints that instances are subjected to are: data size interval; absence or necessary presence of a parameter; range of values of some parameters; - value correlation between parameters.
  • the target architectures of the instance are the mutlicoeurs (or part of the mutlicoeurs) that can execute it correctly if the call constraints are respected.
  • the target architectures are described in two parts:
  • the performance profile of the instance is typically a table (or other suitable description method) that indicates the performance level achieved (for example in Gigaflops) based on the value of certain input parameters (typically those indicating the complexity of the problem) according to the allocated execution resources.
  • this table could have the following content: for an instance with a N parameter, each performance corresponds to a single executable instance or several that reach the performance level indicated in the cells:
  • the invention introduces a new technique for implementing the new functions instances that have been defined previously.
  • the function instances are selected, at the time of execution of the application, using a data structure whose characteristic is to allow the application of decide which instance to execute based on the execution context.
  • This data structure may for example be in the form of a decision tree, but it is not mandatory.
  • it is highly desirable that the structure used allow a rapid identification of the instance to be used so that one of the benefits provided by the invention, namely the introduction of a function instance contextuality, be realized faster than compilation on the fly.
  • hash tables or n-dimensional tables can be used, where n is the number of constraints of the execution context.
  • the decision trees are used.
  • a decision tree in the context of the use of heterogeneous or homogeneous mutlicoeur architectures makes it possible, according to the invention, to select during the execution of an application the instance of a codelet which will provide the best performance taking into account execution context, target architectures, and call constraints.
  • the decision tree is built according to the performance profile and a set of available hardware resources.
  • decision tree (not necessarily binary) is in the following form (described in connection with Figure 2).
  • Circles represent selectors while leaves (squares) represent instances to use.
  • a selector chooses the thread of the node to use.
  • the child is a sheet, the corresponding instance is called to execute the instance of the codelet, whose identifier (the reference) is written in the sheet.
  • An instance will be used if the set of selectors defines the path from the root to the instance. For example, based on the performance profile example in the previous section, assuming that: - Vi is the reference for implementing the codelet on the Proc XY 3Ghz with 2 cores;
  • V 2 is the reference for implementing the codelet on the Proc XY 3Ghz with 4 cores
  • V3 is the reference for the implementation of the codelet on Proc XY 3Ghz with 2 cores;
  • V 4 is the reference for the implementation of the codelet on the ZZ GPU.
  • the selectors could be the following ones: - If is worth: left son if N is lower than 10000 otherwise right son; 5 2 is: left son if GPU ZZ is not available otherwise right wires;
  • the instance V 4 will be used to implement the codelet (the identifier of the instance is accessible in the leaves of the tree).
  • decision trees can be implemented manually or automatically from the performance profiles. This part is conducted, according to the invention, before the construction of the application's binary that brings together the different instances either in the binary or libraries (static or dynamic) of the application. The latter possibility is preferable insofar as it allows the application to be independent of the instances that can themselves be the subject of successive optimizations and be installed for example during updating operations of the application. application.
  • a decision tree, built for each codelet, is inserted in the application code in place of the call of the codelet. At runtime, the decision tree redirects execution to the most appropriate instance of the execution context.
  • the execution context is provided by the application (parameter values, for example the size of the problem or an array of input parameters) and by the executive (and / or operating system) support for the application. execution of the application. For example, the executive keeps track of the occupation of material resources and authorizes or not the attribution of a resource to a given codelet.
  • the code of the BIN application is executed (316); if a codelet call is encountered, the decision tree is interpreted or traveled (317); the instance determined after the interpretation in the decision tree is called (318); - the instance is executed and the control is returned to the application (319).
  • the invention introduces the notion of executive decision-making. This is the application manager that can globally allocate resources and select the appropriate codes.
  • a decision executive aims to separate the use of decision trees from the binary code of the application. This makes it possible to adapt the process a posteriori after distribution of the applications and to adapt it to new execution contexts that did not exist when the application was broadcast.
  • the decision executive can be distributed in the form of software updates that are performed automatically.
  • the decision executive identifies the configuration of the execution node; 5. the decision-making executive determines the codelets present in the application;
  • the decision-making executive determines the embedded decision trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

L'invention concerne un de réalisation d'un appel d'une instance d'une fonction présente au sein d'au moins un premier module logiciel et requise par un second module logiciel, dit module logiciel appelant. Selon l'invention, un tel procédé comprend : une étape d'obtention d'un contexte d'exécution courant, ledit contexte d'exécution courant dépend d'au moins une situation d'exécution dudit module logiciel appelant et comprend des données d'exécution; une étape de sélection de ladite instance de fonction, parmi au moins deux instances disponibles, en fonction desdites données d'exécution dudit contexte d' exécution courant.

Description

Procédé de réalisation d'un appel d'une instance d'une fonction, dispositif, et programme d'ordinateur correspondant. 1 DOMAINE DE L'INVENTION
La présente invention se rapporte au domaine du déploiement d'applications logicielles.
La présente invention se rapporte plus particulièrement à l'appel de fonction dans des applications informatiques destinées à être exécutées sur des plateformes matérielles qui ne sont pas homogènes.
Une plateforme matérielle, telle qu'un ordinateur personnel de type PC, est composée de nombreux éléments : un ou plusieurs processeurs, une ou plusieurs carte graphique, des bus de liaisons de données (bus local série, bus parallèle), des interfaces de gestion de la mémoire volatile (RAM) ainsi que des interfaces de gestion de la mémoire de masse. Bien que respectant des techniques de communications sensiblement identiques, de telles plateformes matérielles peuvent être profondément différentes.
De manière générale, des applications informatiques, mises en œuvre par un code (ou programme) applicatif, requièrent des puissances de calculs de plus en plus importante afin d'apporter à l'utilisateur rapidité et fonctionnalités. Ces codes mettent en œuvre des algorithmes qui mélangent des phases de calculs séquentiels et parallèles de complexité diverse.
L'utilisation des architectures multicoeurs, que l'on retrouve dans de très nombreuses plateformes matérielles, est fondée sur l'exploitation des phases parallèles de calculs des codes applicatifs. Ces codes se doivent d'utiliser au mieux les ressources matérielles (composants, carte graphique, processeurs et mémoire) de la manière la plus efficace et ce quelques soit l'architecture de la plateforme matérielle en question.
De plus, chaque application doit prendre en compte les ressources utilisées par les autres applications afin de ne pas créer une compétition dommageable aux performances globales du système. Dans la suite nous dénommons « nœud de calcul » un ensemble de processeurs multicoeurs hétérogènes ou homogènes organisés autour d'une mémoire principale. Cette mémoire n'est pas nécessairement partagée par l'ensemble des processeurs, les transferts de données peuvent aussi être mis en œuvre par DMA (de l'anglais « Direct Memory Access » pour « Accès Direct en Mémoire ») etc.
Chaque cœur de calcul peut disposer d'une mémoire locale qui lui est propre, comme cela est le cas dans certaines architectures multicoeurs. 2 SOLUTIONS DE L'ART ANTERIEUR Dans l'état actuel des techniques, La performance d'une application est influencée par un nombre important de facteurs : les éléments matériels disponibles sur le nœud de calculs : un nœud de calcul est l'ensemble des processeurs -multicoeurs ou pas- et les accélérateurs matériels : par exemple GPU, (« Graphie Processing Unnit ») ou FPGA, (Field Programmable Gâte Arrays o u « réseaux logiques programmables ») se partageant une mémoire physique commune ; la priorité éventuelle donnée à chaque application ; les jeux de données sur lesquelles les applications travaillent ; - les applications déjà en cours d'exécution et l'utilisation des ressources par celle-ci.
Dans la suite, de tels facteurs sont regroupés sous l'expression « contexte d'exécution ».
De nombreuses techniques, notamment basées sur l'utilisation en parallèle des processeurs des architectures multicoeurs, visent à répondre à de telles problématiques. Leur objectif est d'offrir une des performances maximum en utilisant au mieux les ressources disponibles. Les difficultés rencontrées viennent, comme cela a été évoqué, de la multitude de composants différents qui peuvent composer une plateforme et du fait que l'utilisation optimum de ces composants n'est pas aisée. Pour augmenter les performances, des techniques de compilation d'applications logicielles ont été proposées. Elles mettent en œuvre deux grands principes : une adaptation statique permettant de conformer l'application à la plateforme sur laquelle elle est installée. Cette adaptation statique peut être réalisée au moment de l'installation du logiciel sur la plateforme. Ainsi, lors de l'installation de l'application sur l'ordinateur, le composant logiciel chargé de l'installation obtient un certain nombre de paramètre de l'ordinateur et effectue une compilation, d'au moins certains composants de l'application en fonction de ces paramètres. Par exemple, si le composant d'installation a détecté que la plateforme dispose d'une carte graphique d'un certain type, ou d'une certaine marque (NVidia™ ou ATI™ par exemple), cette information est transmise au compilateur qui réalise une compilation des fonctions et procédures utilisant la carte graphique en fonction de ces paramètres (type de processeur graphique, mémoire disponible sur la carte, etc.).
Cette technique de compilation à l'installation, lors du déploiement, présente l'avantage de fournir un ensemble d'instances de fonctions ou d'instances de procédures compilées en fonction de la plateforme sur laquelle l'application est installée, et donc adaptées à fonctionner avec les composants de cette plateforme.
Elle présente l'inconvénient de ne pas prendre en compte les paramètres de l'exécution de l'application : lors de l'exécution de l'application si la carte graphique est surchargée et qu'elle n'est pas à même de réaliser le traitement demandé, le fait que l'instance de la fonction qui doit réaliser le traitement est adaptée au composant ne change rien au fait que les performances de l'application sont dégradées, au moins le temps que la carte graphique soit déchargée. En d'autres termes, cette technique ne prend pas en compte l'intégralité du contexte d'exécution de l'application.
Une autre technique consiste à réaliser une compilation des fonctions ou procédures en fonction du besoin pour générer des instances de fonctions ou de procédures au moins partiellement adaptée au contexte d'exécution. Ces techniques permettent de créer l'instance de la fonction au moment de l'appel de celle-ci.
Cette technique est appelée JIT (de l'anglais « Just In Time » pour « Juste à temps »). Elle est également appelée compilation à la volée. Lors de l'exécution de l'application, si une fonction doit être appelée, on vérifie si cette dernière a déjà été compilée et s'il existe une instance de fonction qui peut être utilisée. Si ce n'est pas le cas, on réalise une compilation à la volée en fonction de paramètres récupérés dynamiquement pour créer une instance de fonction exécutable. Ce type de technique JIT est idéal lors d'opérations de débogage d'applications et pour la génération de code en fonction du contexte (pile d'appel, mais indépendamment de l'occupation des ressources matérielles) de l'appel de la fonction qui est compilée à la volée. . La compilation à la volée n'est cependant pas une technique utilisable, en l'état, pour des applications temps réel demandant des ressources importantes à la plateforme sur laquelle elle s'exécute. En effet, bien que le code source d'origine de la fonction à compiler ne soit pas directement employé pour la compilation (la compilation à la volée utilise un code intermédiaire qui a fait l'objet d'une précompilation et d'optimisation de manière statique), la phase de compilation JIT est tout de même consommatrice de temps, de sorte que la phase de compilation à la volée n'aura pas pour effet de réduire le temps d'exécutuion. Elle aura même l'effet inverse, c'est-à-dire qu'elle consommera plus de temps d'exécution que si une fonction déjà compilée avait été utilisée. 3 RESUME DE L'INVENTION
L'invention permet de pallier ces inconvénients de l'art antérieur. En effet, l'invention concerne un procédé de réalisation d'un appel d'une instance d'une fonction présente au sein d'au moins un premier module logiciel et requise par un second module logiciel, dit module logiciel appelant. Selon l'invention, un tel procédé comprend : une étape d'obtention d'un contexte d'exécution courant, ledit contexte d'exécution courant dépend d'au moins une situation d'exécution dudit module logiciel appelant et comprend des données d'exécution ; une étape de sélection de ladite instance de fonction, parmi au moins deux instances disponibles, en fonction desdites données d'exécution dudit contexte d'exécution courant. Ainsi, l'invention permet de résoudre les problèmes liés à la prise en compte de multiples architectures logicielles en sélectionnant, au moment de l'exécution du module logiciel appelant, l'instance d'une fonction qui est la mieux à même de fournir des résultats plus rapidement. Le module logiciel appelant peut par exemple être l'application principale en cours d'exécution, tandis que le premier module logiciel peut être une bibliothèque de liaison dynamique ou une librairie chargée dynamiquement au début de l'exécution de l'application.
Selon un mode de réalisation particulier de l'invention, ladite étape de sélection de ladite instance de fonction comprend : une étape de chargement, au sein d'un environnement d'exécution dudit module logiciel appelant, d'une structure de données préalablement construite associée à ladite fonction et à une pluralité de contexte d'exécution ; une étape de recherche, au sien de ladite structure de données, d'une référence à ladite instance de fonction à sélectionner en fonction desdites données d'exécution dudit contexte d' exécution courant, délivrant un identifiant d'instance ; une étape d'identification, parmi lesdites au moins deux instances dudit premier module logiciel, de ladite instance de fonction à sélectionner à l'aide dudit identifiant d'instance. Ainsi, l'invention permet de réaliser une identification d'une instance de fonction à appeler en fonction d'une structure de données, qui a fait l'objet d'une construction préalable. Cette construction préalable consiste en la création de la structure de données en fonction de contextes d'exécution préalablement déterminés. Ces contextes d'exécution prédéterminés servent ensuite durant l'exécution du module logiciel appelant, pour déterminer qu'elle est l'instance de la fonction à laquelle il convient de faire appel.
Selon un mode de réalisation particulier de l'invention, ladite étape de sélection comprend en outre, lorsque ladite de recherche est infructueuse, une étape de sélection d'une instance d'appel par défaut.
Ainsi, l'invention permet de pallier l'absence d'un contexte dans la structure de données associée à ladite fonction. Ainsi, lorsque le contexte courant d'exécution de la fonction ne correspond pas à un contexte précalculé, une instance de fonction par défaut peut être mise en œuvre pour permettre à l'application de se poursuivre malgré tout. Cette instance par défaut peut ne pas être la meilleure instance en termes de performances par rapport au contexte d'exécution, mais elle assure que l'application se déroule sans erreur.
Selon une caractéristique particulière de l'invention, ledit contexte d'exécution courant comprend en outre des données relatives à : - une architecture matérielle d'une plateforme matérielle sur laquelle ledit module logiciel appelant s'exécute ; une charge de travail courante de ladite plateforme matérielle sur laquelle ledit module logiciel appelant s'exécute.
Ainsi, l'invention permet de prendre en compte de multiple situation d'exécution pour déterminer de manière optimale le contexte courant d'exécution et de ce fait sélectionner l'instance de la fonction qui sera le mieux à même de correspondre au contexte d'exécution courant.
Selon une caractéristique particulière de l'invention, ledit contexte d'exécution courant est matérialisé sous la forme de données d'exécution dépendantes dudit module logiciel appelant et de ladite plateforme matérielle sur laquelle ledit module logiciel appelant s'exécute.
Selon une caractéristique particulière de l'invention, ladite d'au moins une situation d'exécution dudit module logiciel appelant comprend une taille de problème (n), ladite taille de problème (n) étant un paramètre de ladite instance de fonction sélectionnée. Ainsi, l'invention permet de sélectionner l'instance de fonction à appeler en fonction du problème à résoudre par la fonction. En d'autre terme, l'invention rend possible la sélection d'une instance en fonction du paramètre d'appel de cette fonction. Pour illustrer cette caractéristique, on suppose une fonction dont le paramètre est un entier « i ». Le contexte d' exécution intégrera la valeur de cet entier « i » de sorte que par exemple, si la valeur de « i » est inférieure à mille, une première instance de fonction sera appelée et si la valeur de « i » est supérieure ou égale à mille et inférieure ou égale à deux mille, une deuxième instance de fonction sera appelée. Si la valeur de « i » est supérieure à deux mille, une instance d'appel par défaut peut être mise en œuvre. La taille du problème n'est cependant pas limitée à cet exemple particulier. Le problème par exemple peut se présenter sous la forme d'un ensemble de paramètres, par exemple sous la forme d'un tableau. La sélection d'une instance particulière peut alors être réalisée en fonction de la taille des différents problèmes des paramètres ou de la taille globale de l'ensemble de paramètres.
Selon un mode de réalisation particulier de l'invention, ladite structure de données se présente sous la forme d'un arbre de décision, dans lequel chaque nœud dudit arbre de décision correspond à une décision à prendre en fonction d'au moins une desdites données d'exécution dudit contexte d'exécution courant. Selon une caractéristique particulière de l'invention, les feuilles dudit arbre de décision comprennent au moins un identifiant d'instance de fonction à appeler.
Ainsi, à l'issue du parcours de l'arbre, lors de l'étape de recherche de l'instance de fonction la plus appropriée à être exécutée, un identifiant d'instance de fonction est trouvé pour indiquer au module logiciel appelant (l'application), qu'elle est l'instance de la fonction qu'il convient d'utiliser
Selon une caractéristique particulière de l'invention, lorsqu'une feuille dudit arbre de décision ne comprend pas d'identifiant d'instance de fonction à appeler, ledit procédé comprend une étape de sélection d'une instance de fonction utilisée par défaut. Selon une caractéristique particulière de l'invention, lorsqu'une feuille dudit arbre de décision ne comprend pas d'identifiant d'instance de fonction à appeler, ledit procédé comprend une étape de compilation dynamique d'une instance de fonction à utiliser en fonction d'au moins certaines données dudit contexte d'exécution courant. Ainsi, l'invention permet de pallier efficacement l'absence d'instance de fonction adaptée au contexte d'exécution courant en compilant, lors de l'exécution du module logiciel appelant, une instance de fonction. On note que, à la différence des technique des l'art antérieures pour lesquelles cette compilation juste à temps est réalisée quelque soit le contexte d'exécution courant de l'application, l'invention permet d'augmenter les performances générales de l'application de façon drastique car cette étape de compilation dynamique (également appelée « JIT », de l'anglais « Just In Time ») n'est mise ne œuvre qu'en dernier recours, lorsque l'arbre de décision n'a pas permis d'identifier une instance de fonction convenable. Selon un autre aspect, l'invention concerne également un procédé de calcul d'un arbre de décision. Selon l'invention, un tel procédé permet d'obtenir un arbre de décision qui est par la suite utilisé dans un procédé de réalisation d'un appel d'une instance de fonction tel que décrit précédemment.
Selon un autre aspect, l'invention concerne également un procédé de construction d'une structure de données de sélection d'une instance de fonction à appeler lorsqu'un premier module logiciel, dit module logiciel appelant, requiert l'exécution d'une fonction auprès d'un second module logiciel.
Selon l'invention, ledit procédé de construction comprend, pour une fonction donnée : - une étape de compilation d'une pluralité d'instances de fonction, chaque instance étant configurée pour présenter une performance probable en fonction d'au moins un contexte d'exécution déterminé ; une étape d'analyse de la performance réelle desdites instances de ladite pluralité d'instance de fonctions délivrant des indices de performances ; - une étape de construction de ladite structure de données associant un identifiant d'instance de fonction à un ensemble de données d'un contexte d'exécution de sorte que ladite structure de décision permettent de décider de l'instance de fonction à appeler en fonction desdits indices de performances délivrés. Selon un autre aspect, l'invention concerne encore un dispositif de réalisation d'un appel d'une instance d'une fonction présente au sein d'au moins un premier module logiciel et requise par un second module logiciel, dit module logiciel appelant,
Selon l'invention, un tel dispositif comprend : - des moyens d'obtention d'un contexte d'exécution courant, ledit contexte d'exécution courant dépend d'au moins une situation d'exécution dudit module logiciel appelant et comprend des données d'exécution ; des moyens de sélection de ladite instance de fonction, parmi au moins deux instances disponibles, en fonction desdites données d'exécution dudit contexte d'exécution courant.
L'invention concerne également un ou plusieurs programmes d'ordinateur comportant des instructions pour la mise en œuvre d'un de réalisation d'un appel d'une instance de fonction et/ou d'un procédé de construction respectivement, tels que décrits précédemment. Par exemple, de tels programmes sont téléchargeables depuis un réseau de communication et/ou stockés sur un support lisible par ordinateur et/ou exécutables par un processeur. 4 LISTE DES FIGURES
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente le principe général de l'invention ; la figure 2 présente un arbre de décision selon l'invention ; la figure 3 illustre le processus de création d'un arbre de décision selon l'invention. 5 DESCRIPTION DETAILLEE DE L'INVENTION
5.1 Rappel du principe de l'invention
Comme cela a déjà été présenté, l'efficacité d'exécution d'une application dépend fortement des décisions prises à l'exécution qui guide le choix des ressources à utiliser et de la version de code qui utilisera ces ressources. Ces décisions sont complexes car elles font entrer un grand nombre de paramètres. En d'autres termes les décisions si l'on cherche à calculer la décision (ou le mécanisme de décision) à l'exécution, cela est très coûteux en temps et ressources matérielles. Par exemple, on ne peut pas demander à un compilateur JIT de produire des versions de code pour un processeur graphique (GPU), un processeur monocœur, un bicœur et ensuite de sélectionner la meilleure version en fonction du contexte, car une telle solution est inefficace car beaucoup plus gourmande en temps d'exécution.
Afin de guider l'exécution d'une application en fonction du contexte d'exécution courant (la situation dans laquelle se trouve l'application par rapport à la plateforme ainsi que les paramètres nécessaires à l'exécution de la fonction), l'invention met en œuvre des structures de données pré-calculés qui sont intégrées dans un exécutif qui instancie la décision à l'exécution d'une application.
L'instanciation de la décision consiste à décider qu'elle est l'instance de la fonction que l'on utilise pour augmenter les performances. La décision d'utiliser une instance plutôt qu'une autre est donc réalisée à l'exécution.
Il s'agit bien, selon l'invention, d'une instance différente d'une même fonction : si une fonction rend un résultat « r », ce résultat « r » sera rendu à l'identique par toutes les instances de ces fonctions. Seules les performances pour fournir ce résultat seront différentes d'une instance à l'autre. L'objet de l'invention n'est pas de décider, à l'exécution, d'utiliser une fonction plutôt qu'une autre, mais bien une instance différente d'une même fonction, qui se différencie par les ressources matérielles utilisées et leur temps d'exécution.
On rappelle qu'une instance, selon l'invention, est une version d'une fonction, se présentant sous une forme exécutable, permettant de fournir un résultat en fonction d'un ensemble de paramètres d'entrée. Cet ensemble de paramètre peut être vide. Une fonction est un est un ensemble d'instructions, rédigées dans un langage de programmation, réalisant une certaine tâche et fournissant un résultat. Une fonction qui ne renvoie aucun résultat est une procédure. Pour plus de commodité, le terme fonction (et également le terme codelet par la suite) est utilisé pour désigner à la fois des fonctions et des procédures.
Selon l'invention, on utilise une structure de données pour décider de l'instance de fonction à utiliser, au moment de l'exécution de l'application. Cette structure de données utilise un contexte d'exécution courant (également appelé contexte d'appel courant) pour identifier une instance de fonction à utiliser. Le contexte d'exécution comprend plus de paramètres et de données que les données nécessaires à l'exécution de l'instance de fonction.
Ainsi, ce n'est pas seulement les données d'entrée de l'instance de la fonction qui servent à déterminer l'instance à utiliser. Les données d'entrée de l'instance de la fonction peuvent être appelées « problème » et ce problème peut avoir une taille. On verra par la suite qui la décision d'utiliser telle ou telle instance peut dépendre de la taille du problème (comme par exemple la longueur des paramètres d'entrée). L'invention porte ainsi sur un procédé de réalisation d'un appel d'une instance d'une fonction (première, deuxième ou nième instance) présente au sein d'au moins un premier module logiciel (par exemple une bibliothèque qui contient les instances) et requise par un second module logiciel, dit module logiciel appelant (l'application). Selon l'invention, ce procédé comprend : - une étape d'obtention d'un contexte d'exécution courant, qui dépend d'au moins une situation d'exécution dudit module logiciel appelant (c'est le contexte logiciel d'appel) et comprend des données d'exécution ; une étape de sélection de ladite instance de fonction, parmi au moins deux instances disponibles, en fonction du contexte d'exécution courant. Dans de nombreux cas, le premier module logiciel et le deuxième module logiciel seront compris au sein de l'application, de sorte que l'application contiendra les instances de fonctions : le premier et le deuxième module logiciels sont chargé au démarrage et sont accessibles à partir de l'exécutif.
La sélection de l'instance à utiliser est, selon l'invention, réalisée lors de l'exécution de l'application et non pas préalablement lors de la compilation de l'application. La solution de l'invention est donc adaptative dans la mesure où les décisions d'exécution ne sont pas figées à la compilation de l'application ou en fonction de choix d'architectures.
L'invention permet par exemple dans un cas d'exécuter une fonction sur le processeur central de la plateforme (le processeur multicoeurs par exemple en utilisant l'instance appropriée) et dans un autre cas, un peu plus tard au cours de l'exécution de l'application sur la carte graphique (en utilisant l'instance appropriée à l'exécution sur la carte graphique).
Selon l'invention, il est également possible, dans le cas ou la structure de données ne délivre pas un identifiant d'instance à utiliser, par exemple si les données du contexte d'exécution courant ne se prêtent pas à l'identification d'une instance, de sélectionner une instance dite par défaut pour permettre la continuation de l'exécution.
Dans un autre mode de réalisation, il peut être astucieusement prévu de combiner l'approche de l'invention à une compilation à la volée en cas d'absence d'instance de fonction disponible pour un contexte d'exécution courant.
Ainsi, selon ce mode de réalisation, quant à l'issue du parcours de la structure de donnée, aucune instance de fonction n'est identifié, le procédé de l'invention met en œuvre une étape de compilation à la volée d'une instance de fonction adaptée au contexte d'exécution courant. Cette compilation à la volée peut être mise en œuvre en combinaison à l'exécution d'une instance par défaut. Par exemple, dans le cas d'une architecture multicoeurs, l'instance par défaut est exécutée sur un cœur, pour permettre à l'application de continuer son exécution pendant qu'une instance particulière est compilée sur un autre cœur pour satisfaire au contexte d'exécution courant. Ainsi, lors de la première apparition du contexte d'application courant, l'instance par défaut est utilisée et une instance utilisable pour le contexte courant est compilée et éventuellement insérée dans une bibliothèque dynamique répertoriant les instances de fonctions.
La structure de données répertoriant les instances associées aux contextes d'exécution est alors mise à jour pour insérer l'identifiant de l'instance compilée à la volée. Cette nouvelle instance peut alors être utilisée à nouveau (sans compilation) lorsqu'un prochain contexte d'exécution y fera référence.
On décrit, en relation avec la figure 1, le principe général de l'invention.
Une fonction « fcod » 10 est écrite dans un langage de programmation (par exemple du C++). Elle contient par exemple un code, en pseudo code informatique, du type :
Void fcod(int n, ...) {
} Elle permet de réaliser une tâche donnée. Cette fonction 10 est compilée
(11) pour produire une instance de fonction 12 (cpu.exe) destinée à être exécutée sur un processeur multicoeurs généraliste. Elle est également compilée (13) pour produire une instance de fonction 14 (gpu.exe) destinée à être exécutée sur un processeur graphique. Ces deux instances de fonction sont ensuite insérée (15) dans un outil de test de performance 16 qui calcul un arbre de décision (17). L'outil de test de performance 16 procède à des exécutions successives des instances en modifiant les paramètres d'entrée de celles-ci et établit un graphe de performance en fonction des contextes d'exécutions des tests. Ces mesures de performances permettent de calculer l'arbre de décision (17), représenté ici sous la forme d'une fonction « fcod decision » qui permet de prendre la décision de la fonction à utiliser en fonction du contexte d'exécution. La fonction « fcod decision » est par exemple écrite, en pseudo code informatique, comme ceci :
Void fcod_decision (int n, ...) { If (n<1000) { utiliser cpu.exe avec 1 cœur } elseif ( nombre cœurs libre >= 4 ) { utiliser cpu.exe avec 4 cœurs } elseif (gpu type == GT8800) { utiliser gpu . exe
}
} Lors de l'exécution de l'application, l'arbre de décision est chargé (18).
Lorsque la fonction « fcod » doit être appelée (19 : appel de « fcod » avec le paramètre 2000), c'est en fait la fonction « fcod decision » qui est appelée, laquelle renvoie l'instance à utiliser (12, 14) en fonction du contexte d'exécution. Préalablement à l'appel de « fcod decision », un test (20) est réalisé pour savoir si cette fonction « fcod decision » existe. Si ce n'est pas le cas, l'instance par défaut est utilisée.
Le test 20 peut s'écrire, en pseudo code informatique, de la façon suivante :
If ( ! exist (fcod_decision) ) { fcod(2000,...) ; } else { fcod_decision (2000, ...) }
Le remplacement de l'appel de la fonction « fcod » par la fonction
« fcod decision » est possible car postérieurement à la création de l'arbre de décision (17), le code d'origine de l'application a été modifié pour remplacer l'appel et une nouvelle phase de compilation de l'application a été réalisée.
Par la suite, on présente notamment le cas de la mise ne œuvre du procédé de l'invention à une architecture multicoeurs. Il est clair cependant que l'invention ne se limite pas à cette application particulière.
5.2 Description d'un mode de réalisation
On présente, dans ce mode de réalisation, la mise en œuvre du procédé de l'invention dans une architecture multicoeurs. L'utilisation des architectures multicoeurs suppose que le code de l'application a préalablement été partitionné en sections séquentielles et en sections parallèles.
Un code principal s'exécutant sur un cœur « maître » lance l'exécution de séquences d'instructions sur les autres ressources de calculs. Dans la suite nous dénommons « codelets » ces séquences d'instructions, qui sont des instances de fonctions selon l'invention. Ces instances de fonctions sont exécutées sur un cœur différent du cœur maitre.
Une codelet est une fonction particulière qui respecte les contraintes suivantes : les tailles des données passées en paramètre sont connues (c'est par exemple la longueur de la chaine ou du tableau passé en paramètre, qui définissent une taille de problème) ; les paramètres pointeurs et tableaux ne sont pas aliasés (ils ne sont pas passés par référence) ; elle ne dispose pas d'accès direct à des variables globales (ces variables, si elles sont nécessaires, sont passées en paramètre) ; la codelet ne produit pas d'entrée/sortie (par d'affichage ou d'attente de retour de la part de l'utilisateur) ; - le calcul de la codelet (le résultat) est identique pour toutes valeurs de paramètres identiques (i.e. y compris les zones pointées par les paramètres tableaux et pointeurs).
Ces codelets existent éventuellement en multiples versions exécutables afin de prendre en compte l'hétérogénéité de l'architecture (c'est une première catégorie d'instance). Par ailleurs, ils existent des versions de codelets exécutables spécialement optimisées pour certaines des données d'entrée (c'est une seconde catégorie d'instance) : ces versions exécutables spécialement optimisées pour certaines données d'entrées implémentent toutes les mêmes fonctionnalités, mais peuvent par exemple être écrites différemment en fonction de la taille N du problème d'entrée. Si par exemple une codelet est en charge du tri d'un tableau de taille N, le code source de la codelet pourra être différents selon la taille du tableau : pour un tableau de taille N inférieure à 100, un premier code source servira à la compilation d'une première instance tandis que lorsque la taille N sera supérieure à 100, un deuxième code source sera utilisé pour la compilation d'une deuxième instance. II y a donc dans ce mode de réalisation plusieurs niveaux d'instances des fonctions. On dénomme contexte d'exécution d'une codelet exécutable un ensemble comprenant au moins certaines des données suivantes : la configuration matérielle d'un nœud de calcul (composants de calculs, de mémorisation, de connexion) ; la taille des données en entrée de la codelet (la taille des paramètres) ; l'occupation des cœurs de calcul (mémoire et unités de calcul); les données disponibles dans les mémoires locales cœurs ; les droits d'utilisation des composants des nœuds. Ainsi, la description d'une codelet mis en œuvre peut comporter de nombreuses instances exécutables, comme cela a déjà été mentionné, caractérisées par : des contraintes d'appel de l'instance (paramètres acceptables) ; architecture cible de l'instance et paramètre de la cible (nombre de cœurs par exemple) ; profil de performance de l'instance.
Les contraintes d'appel de l'instance décrivent les données d'entrée acceptables du point de vue d'une exécution correcte. Par exemple, une instance pourra être mise en œuvre pour une taille de donnée fixée et être incorrecte dans tous les autres cas. Les contraintes usuelles auxquelles les instances sont soumises sont les suivantes : intervalle de tailles des données ; absence ou présence nécessaire d'un paramètre ; intervalle de valeurs de certains paramètres ; - corrélation de valeur entre paramètres.
Les architectures cibles de l'instance sont les mutlicoeurs (ou une partie des mutlicoeurs) pouvant l'exécuter correctement si les contraintes d'appel sont respectées. Les architectures cibles sont décrites en deux parties :
Qualitative : le type de jeux d'instructions nécessaires ; - Quantitative : le nombre de ressources minimum ou maximum des ressources nécessaires. Ces ressources sont des unités de calculs ou des unités de mémorisation.
Le profil de performance de l'instance est typiquement une table (ou tout autre méthode de description appropriée) qui indique le niveau de performance atteint (par exemple en Gigaflops) en fonction de la valeur de certains paramètres d'entrée (typiquement ceux indiquant la complexité du problème) en fonction des ressources d'exécution allouée. Par exemple cette table pourrait avoir le contenu ci-dessous : pour une instance ayant un paramètre N, chaque performance correspond à une seule instance exécutable ou plusieurs qui atteignent le niveau de performance indiqué dans les cellules :
Figure imgf000019_0001
Dans la suite on décrit, selon l'invention, les deux techniques qui mettent en œuvre les instances telles que définies précédemment 5.3 Structure de données d'allocations de ressources et d'instances associées
L'invention introduit une nouvelle technique de mise en œuvre des nouvelles instances de fonctions qui ont été définies précédemment. Dans un mode de réalisation particulier de l'invention, les instances de fonctions sont sélectionnées, au moment de l'exécution de l'application, à l'aide d'une structure de données dont la caractéristique est de permettre à l'application de décider de l'instance à exécuter en fonction du contexte d'exécution. Cette structure de données peut par exemple se présenter sous la forme d'un arbre de décision, mais ce n'est pas obligatoire. Il est en revanche hautement souhaitable que la structure utilisée permette une identification rapide de l'instance à utiliser pour qu'un des bénéfices apportés par l'invention, à savoir l'introduction d'une contextualité d'utilisation d'instance de fonction, soit réalisé plus rapidement qu'une compilation à la volée. Ainsi, à la place d'un arbre de décision, des tables de hashage ou des tableaux à n dimensions peuvent être utilisés, dans lesquels n est le nombre de contraintes du contexte d'exécution.
Dans ce mode de réalisation, les arbres de décision sont utilisés. Un arbre de décision dans le cadre de l'utilisation des architectures mutlicoeurs hétérogènes ou homogènes permet, selon l'invention, de sélectionner pendant l'exécution d'une application l'instance d'une codelet qui fournira la meilleure performance en prenant en compte le contexte d'exécution, les architectures cibles et les contraintes d'appel. L'arbre de décision est construit suivant le profil de performance et un ensemble de ressources matérielles disponibles.
Typiquement l'arbre de décisions (pas nécessairement binaire) se présente sous la forme suivante (décrite en relation avec la figure 2).
Les cercles représentent des sélecteurs tandis que les feuilles (carrés) représentent les instances à utiliser. Un sélecteur choisit le fils du nœud à utiliser. Lorsque le fils est une feuille, l'instance correspondante est appelée pour exécuter l'instance de la codelet, dont l'identifiant (la référence) est inscrit dans la feuille.
Une instance sera utilisée si l'ensemble des sélecteurs définisse le chemin de la racine à l'instance. Par exemple, sur la base de l'exemple de profil de performance de la section précédente, si l'on suppose que : - Vi est la référence de la mise en œuvre de la codelet sur le Proc XY 3Ghz avec 2 cœurs ;
V2 est la référence de la mise en œuvre de la codelet sur le Proc XY 3Ghz avec 4 cœurs ;
V3 est la référence de la mise en œuvre de la codelet sur Proc XY 3Ghz avec 2 cœurs ;
V4 est la référence de la mise en œuvre de la codelet sur le GPU ZZ.
Par ailleurs on suppose que au moins deux cœurs sont toujours disponibles (allocation des ressources au démarrage de l'application).
Les sélecteurs pourraient être les suivants : - Si vaut : fils gauche si N est inférieur à 10000 sinon fils droit ; 52 vaut : fils gauche si GPU ZZ n'est pas disponible sinon fils droit ;
53 vaut : fils gauche si 4 cœurs sont disponibles sinon fils droit.
Avec cet arbre de décision, si le paramètre N (qui représente ici la taille/complexité du problème) est supérieur ou égal à 1000 et que le GPU ZZ est disponible, l'instance V4 sera utilisée pour implémenter le codelet (l'identifiant de l'instance est accessible dans les feuilles de l'arbre).
Comme on peut le voir sur la base de cet exemple, de nombreuses versions de l'arbre de décisions sont possibles à partir du profil de performance utilisé.
5.3.1 Construction et utilisation des arbres de décisions La construction des arbres de décisions peut être mise en œuvre manuellement ou automatiquement à partir des profils de performances. Cette partie est conduite, selon l'invention, avant la construction du binaire de l'application qui réunit les différentes instances soit dans le binaire ou dans des bibliothèques (statiques ou dynamiques) de l'application. Cette dernière possibilité étant préférable dans la mesure où elle permet à l'application d'être indépendante des instances qui peuvent-elles mêmes faire l'objet d'optimisations successives et être installées par exemple lors d'opérations de mise à jour de l'application.
Un arbre de décision, construit pour chaque codelet, est inséré dans le code de l'application à la place de l'appel de la codelet. A l'exécution, l'arbre de décisions redirige l'exécution sur l'instance la plus appropriée au contexte d'exécution. Le contexte d'exécution est fourni par l'application (valeur des paramètres, par exemple la taille du problème ou un tableau de paramètres d'entrée) et par l'exécutif (et/ou le système d'exploitation) de support à l'exécution de l'application. Par exemple, l'exécutif garde trace de l'occupation des ressources matérielles et autorise ou non l'attribution d'une ressource à une codelet donné.
Ce processus est décrit en relation avec la figure 3, pour une codelet donné : En phase de création de l'application (30) : des mesures de performance sur les diverses cibles matérielles (Ci à Cn) sont effectuées (301) ; un profil de performance est construit (302) ; à partir du profil de performance l'arbre de décisions est construit (303) ; - l'arbre de décision est intégré dans l'application par insertion des tests correspondant dans le code source (phase de préprocessing - 304) ; le code résultant est compilé pour produire un code exécutable BIN (avec les instances nécessaires à la mise en œuvre de la codelet) (305) ;
En phase d'exécution de l'application (31) : - le code de l'application BIN est exécuté (316) ; si un appel de codelet est rencontré, l'arbre de décision est interprété ou parcouru (317) ; l'instance déterminée à l'issue de l'interprétation dans l'arbre de décision est appelée (318) ; - l'instance est exécutée et le contrôle est retourné à l'application (319).
Ainsi, l'invention offre une réponse optimale au problème de prise en charge d'architectures multiples en proposant une instance qui est adaptée au contexte d'exécution de l'application.
5.4 Exécutif décisionnel Selon une variante de réalisation, l'invention introduit la notion d'exécutif décisionnel. Il s'agit du gestionnaire des applications capables d'allouer globalement les ressources et de sélectionner les codes adaptés.
Un exécutif décisionnel a pour objectif de dissocier l'utilisation des arbres de décisions du code binaire de l'application. Ceci permet d'adapter le processus a posteriori après distribution des applications et d'adapter celle-ci à de nouveaux contextes d'exécution qui n'existait pas à la diffusion de l'application. L'exécutif décisionnel peut ainsi être distribué sous la forme de mises à jour logicielles qui sont réalisées de manière automatique.
On suppose une application comportant un certain nombre de codelets [Ci,...,Cn]. La détection des applications par l'exécutif peut par exemple être effectuée par un hash-code robuste sur le code binaire de l'application et/ou au moment de sa compilation l'application intègre une fonction capable d'indiquer son identité sans ambigϋité. Cette fonction pourra être activée par l'exécutif décisionnel. Le processus est globalement le suivant :
1. lancement de l'application ;
2. l'application charge et lance l'exécutif décisionnel ;
3. l'exécutif décisionnel identifie l'application ;
4. l'exécutif décisionnel identifie la configuration du nœud d'exécution ; 5. l'exécutif décisionnel détermine les codelets en présence dans l'application ;
6. l'exécutif décisionnel détermine les arbres de décisions embarqués ;
7. lors d'un appel de codelet, l'application transfert le contrôle dans l'exécutif décisionnel qui utilise les arbres de décisions embarqués pour choisir la variante de la codelet à utiliser ;
8. l'exécutif décisionnel retourne le contrôle à l'application.
La manière d'embarquer les arbres de décisions dans l'exécutif décisionnel est variée. Par exemple : dans un fichier de configuration chargé par l'exécutif ; - par accès à une base de données locale ou distante ; par intégration des arbres dans le code de l'exécutif ; par chargement d'une bibliothèque dynamique qui intègre les arbres. L'exécutif décisionnel est don particulièrement bien adapté à des applications qui peuvent nécessiter de nombreuses mises à jour logicielles, soit parce que l'application est par exemple en phase de test et qu'il est nécessaire d'améliorer ses performances en permanence et donc de réaliser des mise à jour de l'arbre de décision de manière régulière, soit encore parce que l'application est modulaire et qu'un utilisateur peut avoir l'envie ou le besoin de charger de nouveaux modules et dans ce cas d'utiliser un exécutif décisionnel différent en fonction des modules de l'application qui sont installés.

Claims

REVENDICATIONS
1. Procédé de réalisation d'un appel d'une instance d'une fonction présente au sein d'au moins un premier module logiciel et requise par un second module logiciel, dit module logiciel appelant, caractérisé en ce qu'il comprend : une étape d'obtention d'un contexte d'exécution courant, ledit contexte d'exécution courant dépend d'au moins une situation d'exécution dudit module logiciel appelant et comprend des données d'exécution ; - une étape de sélection de ladite instance de fonction, parmi au moins deux instances disponibles, en fonction desdites données d'exécution dudit contexte d'exécution courant.
2. Procédé de réalisation d'un appel selon la revendication 1, caractérisé en ce que ladite étape de sélection de ladite instance de fonction comprend : une étape de chargement, au sein d'un environnement d'exécution dudit module logiciel appelant, d'une structure de données préalablement construite associée à ladite fonction et à une pluralité de contexte d'exécution ; - une étape de recherche, au sien de ladite structure de données, d'une référence à ladite instance de fonction à sélectionner en fonction desdites données d'exécution dudit contexte d'exécution courant, délivrant un identifiant d'instance ; une étape d'identification, parmi lesdites au moins deux instances dudit premier module logiciel, de ladite instance de fonction à sélectionner à l'aide dudit identifiant d'instance.
3. Procédé selon la revendication 2, caractérisé en ce que ladite étape de sélection comprend en outre, lorsque ladite de recherche est infructueuse, une étape de sélection d'une instance d'appel par défaut.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit contexte d'exécution courant comprend en outre des données relatives à : une architecture matérielle d'une plateforme matérielle sur laquelle ledit module logiciel appelant s'exécute ; une charge de travail courante de ladite plateforme matérielle sur laquelle ledit module logiciel appelant s'exécute.
5. Procédé selon la revendication 4, caractérisé en ce que ledit contexte d'exécution courant est matérialisé sous la forme de données d'exécution dépendantes dudit module logiciel appelant et de ladite plateforme matérielle sur laquelle ledit module logiciel appelant s'exécute.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite d'au moins une situation d'exécution dudit module logiciel appelant comprend une taille de problème (n), ladite taille de problème (n) étant un paramètre de ladite instance de fonction sélectionnée.
7. Procédé selon l'une quelconque des revendications 5 et 6, caractérisé en ce que ladite structure de données se présente sous la forme d'un arbre de décision, dans lequel chaque nœud dudit arbre de décision correspond à une décision à prendre en fonction d'au moins une desdites données d'exécution dudit contexte d'exécution courant.
8. Procédé selon la revendication 7, caractérisé en ce qu'au moins certaines feuilles dudit arbre de décision comprennent au moins un identifiant d'instance de fonction à appeler.
9. Procédé selon la revendication 8, caractérisé en ce que lorsqu'une feuille dudit arbre de décision ne comprend pas d'identifiant d'instance de fonction à appeler, ledit procédé comprend une étape de sélection d'une instance de fonction utilisée par défaut.
10. Procédé selon la revendication 8, caractérisé en ce que lorsqu'une feuille dudit arbre de décision ne comprend pas d'identifiant d'instance de fonction à appeler, ledit procédé comprend une étape de compilation dynamique d'une instance de fonction à utiliser en fonction d'au moins certaines données dudit contexte d'exécution courant.
11. Procédé de construction d'une structure de données de sélection d'une instance de fonction à appeler lorsqu'un premier module logiciel, dit module logiciel appelant, requiert l'exécution d'une fonction auprès d'un second module logiciel, ledit procédé de construction comprend, pour une fonction donnée : - une étape de compilation d'une pluralité d'instances de fonction, chaque instance étant configurée pour présenter une performance probable en fonction d'au moins un contexte d'exécution déterminé ; une étape d'analyse de la performance réelle desdites instances de ladite pluralité d'instance de fonctions délivrant des indices de performances ; - une étape de construction de ladite structure de données associant un identifiant d'instance de fonction à un ensemble de données d'un contexte d'exécution de sorte que ladite structure de décision permettent de décider de l'instance de fonction à appeler en fonction desdits indices de performances délivrés.
12. Dispositif de réalisation d'un appel d'une instance d'une fonction présente au sein d'au moins un premier module logiciel et requise par un second module logiciel, dit module logiciel appelant, caractérisé en ce qu'il comprend : - des moyens d'obtention d'un contexte d'exécution courant, ledit contexte d'exécution courant dépend d'au moins une situation d'exécution dudit module logiciel appelant et comprend des données d'exécution ; des moyens de sélection de ladite instance de fonction, parmi au moins deux instances disponibles, en fonction desdites données d'exécution dudit contexte d'exécution courant.
13. Programme d'ordinateur caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre du procédé de réalisation d'un appel selon la revendication 1, lorsque ce programme est exécuté par un processeur.
14. Programme d'ordinateur caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre du procédé de construction selon la revendication 11, lorsque ce programme est exécuté par un processeur.
PCT/EP2009/063761 2008-10-30 2009-10-21 Procédé de réalisation d'un appel d'une instance d'une fonction, dispositif, et programme d'ordinateur correspondant. WO2010049317A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP09736975A EP2342636A1 (fr) 2008-10-30 2009-10-21 Procédé de réalisation d'un appel d'une instance d'une fonction, dispositif, et programme d'ordinateur correspondant
US13/126,938 US20110271290A1 (en) 2008-10-30 2009-10-21 Method for calling an instance of a function, and corresponding device and computer software

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0857416 2008-10-30
FR0857416A FR2938091B1 (fr) 2008-10-30 2008-10-30 Procede de realisation d'un appel d'une instance d'une fonction, dispositif, programme d'ordinateur correspondant

Publications (1)

Publication Number Publication Date
WO2010049317A1 true WO2010049317A1 (fr) 2010-05-06

Family

ID=40605287

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/063761 WO2010049317A1 (fr) 2008-10-30 2009-10-21 Procédé de réalisation d'un appel d'une instance d'une fonction, dispositif, et programme d'ordinateur correspondant.

Country Status (4)

Country Link
US (1) US20110271290A1 (fr)
EP (1) EP2342636A1 (fr)
FR (1) FR2938091B1 (fr)
WO (1) WO2010049317A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105677341A (zh) * 2016-01-04 2016-06-15 成都卫士通信息产业股份有限公司 一种解决软件分支语句过多的方法

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8448130B1 (en) * 2007-08-20 2013-05-21 The Mathworks, Inc. Auto-generated code validation
US20130326489A1 (en) * 2012-05-30 2013-12-05 Vector Fabrics B.V. Method and system for translating non-native instructions
US8918771B2 (en) * 2012-09-25 2014-12-23 Facebook, Inc. Decision tree ensemble compilation
US9176669B2 (en) * 2013-03-15 2015-11-03 Silicon Graphics International Corp. Address resource mapping in a shared memory computer system
US10915305B2 (en) * 2019-03-28 2021-02-09 International Business Machines Corporation Reducing compilation time for computer software

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5802367A (en) * 1995-07-07 1998-09-01 Microsoft Corporation Method and system for transparently executing code using a surrogate process
WO2001039046A1 (fr) * 1999-11-24 2001-05-31 Oz.Com SYSTEME D'INTERFAçAGE DE PROGRAMMES COMPLEMENTAIRES ET D'UN NAVIGATEUR WEB
WO2002071211A2 (fr) * 2000-11-20 2002-09-12 Zucotto Wireless, Inc. Machine de traitement des donnees a modes d'operation multiples
FR2884994A1 (fr) * 2005-04-22 2006-10-27 Gemplus Sa Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce
US20070168962A1 (en) * 2005-11-15 2007-07-19 Oracle International Corporation Configurable software application system

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020100034A1 (en) * 2001-01-22 2002-07-25 Croix John F. Application personality
US7743367B1 (en) * 2003-12-30 2010-06-22 Sap Ag Registration method for supporting bytecode modification
SG152022A1 (en) * 2004-01-15 2009-05-29 Agency Science Tech & Res Method and system for dynamic invocation of services in a service-oriented architecture environment
US7415702B1 (en) * 2005-01-20 2008-08-19 Unisys Corporation Method for zero overhead switching of alternate algorithms in a computer program

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5802367A (en) * 1995-07-07 1998-09-01 Microsoft Corporation Method and system for transparently executing code using a surrogate process
WO2001039046A1 (fr) * 1999-11-24 2001-05-31 Oz.Com SYSTEME D'INTERFAçAGE DE PROGRAMMES COMPLEMENTAIRES ET D'UN NAVIGATEUR WEB
WO2002071211A2 (fr) * 2000-11-20 2002-09-12 Zucotto Wireless, Inc. Machine de traitement des donnees a modes d'operation multiples
FR2884994A1 (fr) * 2005-04-22 2006-10-27 Gemplus Sa Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce
US20070168962A1 (en) * 2005-11-15 2007-07-19 Oracle International Corporation Configurable software application system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DUESTERWALD E: "Design and Engineering of a Dynamic Binary Optimizer", PROCEEDINGS OF THE IEEE, IEEE. NEW YORK, US, vol. 93, no. 2, 1 February 2005 (2005-02-01), pages 436 - 448, XP011125806, ISSN: 0018-9219 *
SHUDO K ET AL: "Asynchronous migration of execution context in Java Virtual Machines", FUTURE GENERATIONS COMPUTER SYSTEMS, ELSEVIER SCIENCE PUBLISHERS. AMSTERDAM, NL, vol. 18, no. 2, 1 October 2001 (2001-10-01), pages 225 - 233, XP004307732, ISSN: 0167-739X *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105677341A (zh) * 2016-01-04 2016-06-15 成都卫士通信息产业股份有限公司 一种解决软件分支语句过多的方法

Also Published As

Publication number Publication date
FR2938091B1 (fr) 2010-12-31
FR2938091A1 (fr) 2010-05-07
EP2342636A1 (fr) 2011-07-13
US20110271290A1 (en) 2011-11-03

Similar Documents

Publication Publication Date Title
EP1805611B1 (fr) Procede d&#39;ordonnancement de traitement de tâches et dispositif pour mettre en oeuvre le procede
WO2010049317A1 (fr) Procédé de réalisation d&#39;un appel d&#39;une instance d&#39;une fonction, dispositif, et programme d&#39;ordinateur correspondant.
WO2001014958A2 (fr) Protocole de gestion, procede de verification et de transformation d&#39;un fragment de programme telecharge et systemes correspondants
WO2016091826A1 (fr) Procede d&#39;ajustement de la precision d&#39;un programme d&#39;ordinateur manipulant au moins un nombre a virgule.
EP2649523B1 (fr) Méthode de compilation d&#39;un code intermédiaire d&#39;une application
FR3000578A1 (fr) Systeme et procede de calcul partage utilisant une fourniture automatisee de ressources informatiques heterogenes
WO2005073851A2 (fr) Systeme de generation automatique de codes optimises
BE1008621A3 (fr) Procedure et procede de communication entre machines et procede generalise de preparation de programmes afferents.
WO2012000949A1 (fr) Procédé de compilation sélective, dispositif et produit programme d&#39;ordinateur correspondant
EP1450253A2 (fr) Procédé de développement de projets informatiques
EP1960934B1 (fr) Procede pour securiser l&#39;execution d&#39;un code logiciel en langage intermediaire dans un appareil portatif
FR2967275A1 (fr) Procede, programme d&#39;ordinateur et dispositif de securisation de code intermediaire de programmation pour son execution par une machine virtuelle
US20180039488A1 (en) System module deployment optimization
EP3311265A1 (fr) Plateforme informatique et procédé associé pour rechercher, exécuter et évaluer des algorithmes computationnels
EP2417523A1 (fr) Procede et dispositif permettant l&#39;execution de composants transactionnels heterogenes
CA3188740C (fr) Systeme et procede d&#39;optimisation d&#39;un outil de simulation
EP2499570B1 (fr) Procede et dispositif d&#39;optimisation d&#39;execution d&#39;applications logicielles dans une architecture multiprocesseur comprenant plusieurs controleurs d&#39;entree/sortie et unites de calcul secondaires
EP2807557A1 (fr) Procédé de compilation, programme d&#39;ordinateur et système informatique
WO2009112566A1 (fr) Architecture de traitement informatique accelere
FR2957434A1 (fr) Dispositif de test d&#39;une architecture de calcul multitaches et procede de test correspondant
FR3087916A1 (fr) Procede de traitement d&#39;un code source, dispositif, systeme et programme correspondant
EP2959382B1 (fr) Systeme de compilation dynamique d&#39;au moins un flot d&#39;instructions
WO2017103116A1 (fr) Procede et calculateur d&#39;analyse predictive
Abel et al. First version of workflow tools published that allows to perform quarterly benchmarks of ML solutions
Binyamin A comparative study of applicationprogramming interface performancein. NET Framework and. NET Core

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09736975

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2009736975

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13126938

Country of ref document: US