EP3931696A1 - Procédé et système d'utilisation de ressources de calcul d'un système de calcul multiprocesseurs - Google Patents

Procédé et système d'utilisation de ressources de calcul d'un système de calcul multiprocesseurs

Info

Publication number
EP3931696A1
EP3931696A1 EP20707268.7A EP20707268A EP3931696A1 EP 3931696 A1 EP3931696 A1 EP 3931696A1 EP 20707268 A EP20707268 A EP 20707268A EP 3931696 A1 EP3931696 A1 EP 3931696A1
Authority
EP
European Patent Office
Prior art keywords
software
execution
priority
tasks
software tasks
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.)
Pending
Application number
EP20707268.7A
Other languages
German (de)
English (en)
Inventor
Nicolas GOREAUD
Romain REBOULLEAU
Remi BATAIL
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.)
Areva NP SAS
Original Assignee
Framatome SA
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 Framatome SA filed Critical Framatome SA
Publication of EP3931696A1 publication Critical patent/EP3931696A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/46—Multiprogramming arrangements
    • G06F9/461—Saving or restoring of program or task context
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/48—Indexing scheme relating to G06F9/48
    • G06F2209/483—Multiproc
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/503—Resource availability

Definitions

  • TITLE Method and system for using computing resources of a multiprocessor computing system
  • the present invention relates to a method and a system for using computing resources of a computing system comprising a plurality of interconnected microprocessors and adapted to operate in parallel, to perform software tasks.
  • the invention lies in the field of optimizing computing resources in microprocessor "clusters", and finds particular application in the use of such computing resources to solve complex physical problems, for example to simulate physical phenomena, by using iterative calculations implementing the resolution of mathematical equations modeling physical phenomena.
  • the invention is applicable in the field of computer simulation, in particular in the context of simulation methods which consume a lot of resources, or in the computational resolution of problems in fluid dynamics.
  • the invention proposes a method of using the computing resources of a computing system comprising a plurality of interconnected microprocessors and adapted to operate in parallel, to perform software tasks. This process uses:
  • an experiment plan comprising a plurality of software tasks to be performed in order to solve a predetermined physical problem, defined by at least one input parameter and at least one output parameter, the experiment plan being calculated as a function of a predetermined initial computational budget, said software tasks of the experimental plan having a first level of priority,
  • the method makes it possible to achieve an optimized occupation of the available computation resources.
  • the method of using computing resources according to the invention may exhibit one or more of the characteristics below, taken independently or in any acceptable combination:
  • Obtaining freed computation resources comprises an analysis of available computational resources, and in the event of no available computational resource, an analysis of the first priority level software tasks currently being executed, an execution stop of at least part of said first level software tasks and a backup of an associated execution context.
  • obtaining freed up compute resources includes a license availability check available to perform a second priority software task.
  • the method further comprises, in the event of the absence of at least one software task of second priority level awaiting execution, a resumption of execution of software tasks of first priority level placed in execution stop.
  • the distribution of at least part of the first priority level software tasks over the available computing resources comprises an analysis of available computing resources, comprising an analysis of available computation queues, and a distribution of the first priority level software tasks on selected calculation queues.
  • the process of calculating an experiment design involves a supervised learning algorithm of a statistical meta-model.
  • the statistical meta-model is a regression model by Gaussian process, and the process of calculating an experimental design involves an entropy maximization of a kernel of covariance of said Gaussian process.
  • the calculation of an experimental design comprises a determination of an experimental space from the input parameters of the problem to be solved, a mesh of said experimental space in calculation points, and a determination of a set of calculation points according to an associated computational budget.
  • the calculation of an experiment plan is iterated based on the execution results obtained from an execution of a previous experiment plan, and in which at each iteration, a current computational budget is calculated.
  • the current computational budget is equal, at each iteration, to half of a remaining computational budget calculated based on the initial computational budget and a computational budget consumed during previous iterations.
  • the iteration of calculating an experiment design to solve a predetermined physical problem is stopped when a stop criterion is verified, in particular when the remaining computational budget is consumed.
  • the invention relates to the use of the resources of a computing system comprising a plurality of interconnected microprocessors and adapted to operate in parallel, to perform software tasks.
  • This system includes:
  • a module for calculating an experiment plan comprising a plurality of software tasks to be carried out to solve a physical problem defined by at least one input parameter and at least one output parameter, the experiment plan being calculated by as a function of a predetermined initial computational budget, said software tasks to be performed having a first level of priority,
  • a module for planning the execution of software tasks by the computing system configured for:
  • Figure 1 schematically illustrates a system for using the computing resources of a microprocessor farm according to one embodiment
  • FIG. 2 is a block diagram of the processes implemented in one embodiment of a method for using the computing resources according to one embodiment
  • Figure 3 is a block diagram of the steps for generating experimental designs according to one embodiment.
  • the invention will be described below in its application to the simulation and calculations associated with solving physical problems, performed as sequences of software tasks, but is not limited to this field of application.
  • the computing resource utilization system 1 of Figure 1 comprises a farm (or "cluster") of interconnected microprocessors forming a computing system 2.
  • microprocessors are divided into interconnected computation nodes and grouped together in different computation queues, each having an associated computational capacity.
  • the cluster 2 consists of a plurality of interconnected programmable electronic devices, for example computers, each programmable electronic device comprising an electronic memory unit and a central computing unit, or CPU, comprising one or more electronic microprocessors, adapted to communicate via a communication bus.
  • each programmable electronic device is produced in the form of programmable logic components, such as an FPGA (standing for Field-Programmable Gâte Arra ⁇ ), or else in the form of dedicated integrated circuits, of the ASIC type (for Application-Specific Integrated Circuit).
  • Programmable electronic devices are suitable for executing software tasks, from computer code instructions in executable format, in any appropriate format.
  • a software task is understood here to mean the execution of a computer program on a set of input data.
  • System 1 also includes a module 4 for planning the execution of software tasks.
  • the module 4 is produced in the form of an executable computer program, stored in a memory unit 6 of a programmable electronic device 8 forming part of the cluster 2, and executable by a processor of the programmable electronic device 8.
  • the memory unit 6 also stores a module 10 for formatting the results of execution of software tasks.
  • the module 4 for scheduling the execution of the software tasks of the system 1 is configured to manage the execution of the software tasks 20 of the first level of priority, also called non-priority tasks, and of the software tasks 22 of the second level of priority, also. called priority tasks.
  • priority software tasks come from user commands.
  • the non-priority software tasks are associated with physical problems to be studied Ri. .Rg, and are intended to be executed when space is available on the cluster.
  • Each physical problem to be studied P L is defined by a set of data, which are for example stored in a file 24 stored on a physical medium readable by computer, and supplied at the input of the system 1.
  • a physical problem is defined by:
  • a parameter noted ParameterJ is between the minimum limits Val_min_i and maximum Val_max_i;
  • the resolution of the physical problem consists in studying the values of a parameter or of several parameters of output, considered to be parameters of interest, as a function of the values of the input parameters.
  • Non-exhaustive examples of such physical phenomena are, for example: calculation of the time required to completely melt a metal paving stone subjected to a heat source on a wall, as a function of the heating power, of the outside temperature, of the heat capacity of the material and dimensions of the paving stone; based on an angle and size of a deflector, calculate an associated pressure loss; as a function of the input parameters: speed of entry into the computation domain, dynamic viscosity, geometric dimension of the computation domain, calculate a pressure variation at the limits of the computation domain, gluing length.
  • the computational budget is, in one embodiment, a maximum number of software tasks to be executed for the resolution of the physical problem.
  • the computational budget also includes the minimum number of microprocessors to be taken into account for the computation.
  • the calculation code is scientific calculation software, looking for a solution to equations representing physical phenomena iteratively.
  • such software is subject to a runtime license, and the number of parallel runs is limited to the number of runtime licenses available.
  • Each PL physical problem defined by a set of data as described above, is processed by a module 30 for calculating the design of the experiment.
  • the module 30 is produced in the form of a computer program that can be executed by one of the programmable electronic devices of the cluster 2.
  • Module 30 implements an experiment design process for each physical problem to be addressed.
  • An experiment plan is defined by a set of simulations to be carried out, each simulation implementing a plurality of software tasks to be executed, with a set of parameters chosen as input, each simulation making it possible to obtain a value for each output parameter chosen forming an execution result 32.
  • the execution result is provided, for example in raw form, for example a binary file, to an operator, via a suitable interface of the system, for example as a computer file.
  • the execution result 32 in raw form is transmitted to the module 10 for formatting the execution results of software tasks, which generates formatted execution results 34.
  • These formatted results contain the input parameters and the parameters. output of the problem, which are extracted, if any, from the raw execution results, which include a lot of data.
  • the experiment design calculation module 30 is adapted to iteratively calculate successive experiment designs for the resolution of a given physical problem, taking into consideration, for the calculation of a current experiment design, formatted results 34 resulting from the execution of the software tasks implemented for the preceding steps of the experimental design.
  • FIG. 2 is a block diagram of the processes implemented by the module 4 for planning the execution of software tasks.
  • Module 4 implements a step 40 for obtaining the state of the hardware resources, in particular the availability of computing resources in the interconnected microprocessors of cluster 2.
  • step 40 the number of microprocessors available among the plurality of interconnected microprocessors is obtained in step 40. This step is repeated at regular time intervals, for example every minute.
  • the module 4 also implements a step 42 of receiving requests for execution of first priority software tasks (non-priority software tasks) submitted by the module 30 for calculating the design of the experiment, and a step 44 for checking the presence second priority software task execution requests (priority software tasks). For example, non-priority software tasks are submitted in a first computation queue, and priority software tasks are submitted in a second computation queue.
  • Steps 42 and 44 are for example carried out substantially in parallel, and repeated at regular time intervals.
  • module 4 retrieves (step 46) information relating to the current availability of computing resources.
  • the availability of computing resources here includes the availability of computing microprocessors and also the availability of software licenses, for example by a license token mechanism, to perform priority software tasks.
  • step 54 the execution of the priority task or tasks is started (step 54).
  • step 46 is followed by a step 48 of freeing computational resources to perform the priority software tasks.
  • Step 48 comprises a sub-step 50 for analyzing the non-priority software tasks being executed, and for selecting non-priority software tasks to stop, as a function of the computing resources and the licenses consumed.
  • the software tasks of a plan of experiment implemented for the resolution of a given physical problem are selected.
  • any license token released by stopping execution of one of the non-priority tasks is made available.
  • the module 4 for planning the execution of the software tasks detects the presence of priority software tasks awaiting execution, it obtains the computational resources freed to allow the execution of these software tasks in step d execution 54.
  • the priority software task or tasks are distributed over the calculation queues comprising available calculation resources.
  • module 4 checks (step 56) for the presence of computing resources, including license resources, available.
  • non-priority software tasks that were stopped previously are resumed (step 58), if applicable.
  • the non-priority software tasks awaiting execution, forming part of experiment plans submitted by the experiment plan calculation module 30, are loaded and executed on the available computing resources (step 60).
  • a calculation queue is selected for the execution of a non-priority software task, according to the state of the resources of the cluster, for example according to the number of available microprocessors. and the number of calculations to be performed for the execution of the software task (s).
  • Non-priority software tasks in a given experiment plan are executed until a stop criterion is validated.
  • the validation of the stop criterion corresponds to the achievement of the predetermined computational budget in terms of the number of computations or to the achievement of a target learning performance value of the problem.
  • the non-priority software tasks are determined by the module 30 for calculating experimental designs, an operation of which is described below with reference to FIG. 3.
  • the occupation of the computing resources is optimized, while at the same time. maintaining the prioritization of certain priority software tasks, in particular software tasks whose processing is required by a user.
  • FIG. 3 is a block diagram of the processes implemented by the experiment design calculation module 30.
  • a first step 70 the data defining the physical problem to be solved are obtained.
  • this data is provided by an operator.
  • this is the only intervention of a human operator, the generation of the successive experimental plans being performed automatically by the module 30.
  • a PL physical problem is defined by:
  • a parameter noted ParameterJ is between the minimum limits Val_min_i and maximum Val_max_i;
  • the computational budget is a maximum number of software tasks to be performed to solve the PL problem.
  • An experimental space is defined by the number N L of input parameters, which is a positive integer, depending on the problem PL to be solved.
  • the experimental space is a hyper-pad of dimension N L , possibly reduced by the user according to the unnecessary combinations of parameters.
  • a mesh of this experimental space in calculation points is then defined.
  • the mesh is isotropic.
  • the mesh is defined so that the total number of calculation points is less than a predetermined limit value, for example equal to 10 5 .
  • step 72 additional information is provided during a step 72, for example information making it possible to refine the mesh of the experimental space.
  • the initial experimental design to solve the physical problem PL is calculated, based on the remaining computational budget.
  • the remaining computational budget is the value corresponding to the initial computational budget minus the computational budget already consumed. On initialization, the remaining computational budget is equal to the initial computational budget.
  • a computational budget for the experimental design is current is computed.
  • the remaining computational budget is then also equal to B L / 2.
  • an initial experiment plan is designed in step 76, consisting in choosing a number of calculation points NP L, o on which the calculation code is to be executed, forming a set of software tasks to be executed, according to of the available computational budget ML , O.
  • the design of the experiment plan is based on an optimization procedure described in detail below with reference to steps 84 and 86, focused on an optimality criterion of the experiment plan, for example a maximum entropy criterion (in the sense of Shannon's information theory). Of course, this is an example of an optimality criterion, other criteria could be used.
  • the experimental design is initialized by random drawing in the experiment space and then enhanced by the optimization procedure.
  • the experimental design is built point by point with the objective of optimizing the same criteria as the optimization procedure for each addition.
  • the experiment plan thus generated is transmitted to module 4 for planning the execution of software tasks, and executed by cluster 2.
  • Formatted execution results 34 are received in step 78 following execution of the experimental design.
  • execution results are processed by the module 30 to update knowledge of the PL problem to be treated, in order to allow optimization of the generation of experiment plans.
  • the influence of the input parameters on the values of the output parameters, known from the run results, is analyzed, so as to refine the selection of calculation points to generate the experimental design.
  • the module 30 constructs a mathematical meta-model and implements a supervised statistical learning algorithm as a function of the execution results.
  • the statistical meta-model is a Gaussian process regression model.
  • Gaussian process regression models are well known in the field of statistical data processing. They assimilate the covariance of the Gaussian random variable representative of the modeled process to an analytical function, also called kernel, parameterized by scalar values called hyperparameters.
  • the module 30 optimizes the hyperparameters of the covariance kernel, for example by the maximum likelihood method.
  • the regression by Gaussian process, provided with an a priori kernel of covariance kg is linked to the optimality criterion of the experimental design.
  • the optimality criterion consists in maximizing the determinant of the matrix K such that:
  • Ki j kg (x ir Xj ) where i, X j are calculation points of the experimental design.
  • the validation of the stop criterion is verified during a step 80.
  • the stop criterion is validated when the initial computational budget has been consumed, or, in other words, when the remaining computational budget is at 0. In this case, step 80 is followed by stopping the calculations (step 82).
  • reaching a performance target is also a stop criterion.
  • reaching a performance target is also a stop criterion.
  • the performance criterion is the average value of the coefficient of determination of the linear regression between the exact result of the simulation on the one hand, and the result predicted by the meta-model on the other hand, the latter being trained on a selection of other cases, for example by the "10-fold cross-validation" method.
  • the target value of the performance criterion is then set when the user submits the problem, and can typically be of the order of 0.95.
  • the computational budget for the current iteration i c is calculated, and in one embodiment, it is equal to half of the remaining computational budget.
  • computation points are selected (step 84), and a current experimental design is calculated (step 86).
  • an exchange procedure optimization algorithm configured to increase the entropy of Shannon information is implemented.
  • Exchange candidate calculation points are selected as follows.
  • a number PL, ÎC of “endangered” calculation points is determined, for example a percentage of the N L , i calculation points of the current experimental plan. For example, this percentage is between 10% and 30%.
  • the normalized covariance matrix K is calculated, and the inverse matrix K -1 called the precision matrix is calculated.
  • PL, ÎC calculation points are selected. These points of calculation are the points having the least mutual information with the other points of calculation of the experimental plan previously executed.
  • the experiment design calculation module 30 implements supervised statistical methods for an automated resolution of the problems to be solved, while controlling the calculation budget and without human intervention.
  • the process implemented by the calculation module makes it possible to perform calculations with control over material resources and execution time thanks to the implementation of the calculation budget.
  • the module 4 for planning the execution of the software tasks implements an optimization of the use of resources, while managing the priorities of the software tasks to be executed.
  • the system 1 for the use of computational resources including these two collaborating modules allows optimized and controlled management of costs, including material cost, license cost and cost in human intervention, computation times and resource optimization being optimized.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Multi Processors (AREA)

Abstract

Procédé et système d'utilisation de ressources de calcul d'un système de calcul multiprocesseurs L'invention concerne un procédé et système d'utilisation de ressources de calcul d'un système de calcul comportant une pluralité de microprocesseurs interconnectés et adaptés à fonctionner en parallèle, pour effectuer des tâches logicielles. Le système (1) comporte : - un module de calcul (30) d'un plan d'expérience comportant une pluralité de tâches logicielles à effectuer pour résoudre un problème physique défini par au moins un paramètre d'entrée et au moins un paramètre de sortie, le plan d'expérience étant calculé en fonction d'un budget calculatoire initial prédéterminé, lesdites tâches logicielles à effectuer ayant un premier niveau de priorité, - un module de planification (4) de l'exécution des tâches logicielles par le système de calcul, configuré pour : - vérifier la présence d'au moins une tâche logicielle de deuxième niveau de priorité supérieur au premier niveau de priorité en attente d'exécution, - en cas de présence d'au moins une telle tâche logicielle, obtenir des ressources de calcul libérées pour exécuter ladite au moins une tâche logicielle de deuxième niveau de priorité; - en cas d'absence d'au moins une telle tâche logicielle, répartir au moins une partie des tâches logicielles de premier niveau de priorité sur les ressources de calcul disponibles.

Description

DESCRIPTION
TITRE : Procédé et système d’utilisation de ressources de calcul d’un système de calcul multiprocesseurs
La présente invention concerne un procédé et un système d’utilisation de ressources de calcul d’un système de calcul comportant une pluralité de microprocesseurs interconnectés et adaptés à fonctionner en parallèle, pour effectuer des tâches logicielles.
L’invention se situe dans le domaine de l’optimisation des ressources de calcul dans les fermes (« clusters » en anglais) de microprocesseurs, et trouve une application particulière dans l’exploitation de telles ressources de calcul pour résoudre des problèmes physiques complexes, par exemple pour simuler des phénomènes physiques, en utilisant des calculs itératifs mettant en oeuvre la résolution d’équations mathématiques modélisant des phénomènes physiques.
En particulier, l’invention s’applique dans le domaine de la simulation par ordinateur, notamment dans le cadre de procédés de simulation qui consomment beaucoup de ressources, ou de la résolution calculatoire de problèmes de la dynamique des fluides.
L’utilisation de fermes de microprocesseurs interconnectés pour effectuer des calculs de simulation de problèmes physiques complexes est connue, de telles fermes de microprocesseurs permettant d’obtenir une augmentation de la capacité de calcul. Pour exploiter mieux de telles fermes de microprocesseurs, il existe des logiciels de gestion des queues de calcul pour lisser la charge des microprocesseurs. Ces logiciels sont génériques, et ne prennent pas en compte d’éventuelles spécificités des tâches logicielles spécifiques à effectuer dans un domaine particulier ou de gestion optimale des priorités. On entend ici par gestion optimale des priorités, le fait que chaque tâche logicielle en tant que telle et dans son contexte ait un coût économique le plus bas possible pour l’utilisateur. Dans l’état de l’art les fermes de calcul sont dimensionnées pour absorber les pics de charge, Il en résulte en pratique, une puissance calculatoire de la ferme de microprocesseurs représentant 120 à 150 % de la puissance calculatoire nécessaire hors pics. Par ailleurs, la gestion des pics de charge nécessite d’avoir à disposition des licences logicielles supplémentaires sous-exploitée qui ne sont utilisées que lors des pics de charge,
Il existe donc un besoin d’optimiser l’utilisation des ressources d’un système de calcul comportant une ferme de microprocesseurs interconnectés. A cet effet, l’invention propose un procédé d’utilisation de ressources de calcul d’un système de calcul comportant une pluralité de microprocesseurs interconnectés et adaptés à fonctionner en parallèle, pour effectuer des tâches logicielles. Ce procédé met en oeuvre :
- un processus de calcul d’un plan d’expérience comportant une pluralité de tâches logicielles à effectuer pour résoudre un problème physique prédéterminé, défini par au moins un paramètre d’entrée et au moins un paramètre de sortie, le plan d’expérience étant calculé en fonction d’un budget calculatoire initial prédéterminé, lesdites tâches logicielles du plan d’expérience ayant un premier niveau de priorité,
- un processus de planification de l’exécution des tâches logicielles par le système de calcul, configuré pour :
- vérifier la présence d’au moins une tâche logicielle de deuxième niveau de priorité supérieur au premier niveau de priorité en attente d’exécution,
- en cas de présence d’au moins une tâche logicielle de deuxième niveau de priorité en attente d’exécution, obtention de ressources de calcul libérées pour exécuter ladite au moins une tâche logicielle de deuxième niveau de priorité ;
- en cas d’absence d’au moins une tâche logicielle de deuxième niveau de priorité en attente d’exécution, répartition d’au moins une partie des tâches logicielles de premier niveau de priorité sur les ressources de calcul disponibles.
Avantageusement, grâce à la gestion des premier et deuxième niveaux de priorité des tâches logicielles, le procédé permet de réaliser une occupation optimisée des ressources de calcul disponibles.
Le procédé d’utilisation de ressources de calcul selon l’invention peut présenter une ou plusieurs des caractéristiques ci-dessous, prises indépendamment ou selon toutes les combinaisons acceptables :
L’obtention de ressources de calcul libérées comporte une analyse de ressources calculatoires disponibles, et en cas d’absence de ressource calculatoire disponible, une analyse des tâches logicielles de premier niveau de priorité en cours d’exécution, un arrêt d’exécution d’au moins une partie desdites tâches logicielles de premier niveau et une sauvegarde d’un contexte d’exécution associé.
L’obtention de ressources de calcul libérées comporte en outre une vérification de disponibilité de licence disponible pour effectuer une tâche logicielle de deuxième priorité.
Le procédé comporte en outre, en cas d’absence d’au moins une tâche logicielle de deuxième niveau de priorité en attente d’exécution, une reprise d’exécution de tâches logicielles de premier niveau de priorité mises en arrêt d’exécution. La répartition d’au moins une partie des tâches logicielles de premier niveau de priorité sur les ressources de calcul disponibles comporte une analyse de ressources calculatoires disponibles, comportant une analyse de queues de calcul disponibles, et une répartition des tâches logicielles de premier niveau de priorité sur des queues de calcul sélectionnées.
Le processus de calcul d’un plan d’expérience met en oeuvre un algorithme d’apprentissage supervisé d’un méta-modèle statistique.
Le méta-modèle statistique est un modèle de régression par processus gaussien, et le processus de calcul d’un plan d’expérience met en oeuvre une maximisation d’entropie d’un noyau de covariance dudit processus gaussien.
Le calcul d’un plan d’expérience comporte une détermination d’un espace expérimental à partir des paramètres d’entrée du problème à résoudre, un maillage dudit espace expérimental en points de calcul, et une détermination d’un ensemble de points de calcul en fonction d’un budget calculatoire associé.
Le calcul d’un plan d’expérience est itéré en fonction de résultats d’exécution obtenus suite à une exécution d’un plan d’expérience précédent, et dans lequel à chaque itération, un budget calculatoire courant est calculé.
Le budget calculatoire courant est égal, à chaque itération, à la moitié d’un budget calculatoire restant calculé en fonction du budget calculatoire initial et d’un budget calculatoire consommé lors d’itérations précédentes.
L’itération de calcul d’un plan d’expérience pour résoudre un problème physique prédéterminé est arrêtée lorsqu’un critère d’arrêt est vérifié, en particulier lorsque le budget calculatoire restant est consommé.
Selon un autre aspect l’invention concerne d’utilisation des ressources d’un système de calcul comportant une pluralité de microprocesseurs interconnectés et adaptés à fonctionner en parallèle, pour effectuer des tâches logicielles. Ce système comporte :
- un module de calcul d’un plan d’expérience comportant une pluralité de tâches logicielles à effectuer pour résoudre un problème physique défini par au moins un paramètre d’entrée et au moins un paramètre de sortie, le plan d’expérience étant calculé en fonction d’un budget calculatoire initial prédéterminé, lesdites tâches logicielles à effectuer ayant un premier niveau de priorité,
- un module de planification de l’exécution des tâches logicielles par le système de calcul, configuré pour :
- vérifier la présence d’au moins une tâche logicielle de deuxième niveau de priorité supérieur au premier niveau de priorité en attente d’exécution, - en cas de présence d’au moins une tâche logicielle de deuxième niveau de priorité en attente d’exécution, obtenir des ressources de calcul libérées pour exécuter ladite au moins une tâche logicielle de deuxième niveau de priorité ;
- en cas d’absence d’au moins une tâche logicielle de deuxième niveau de priorité en attente d’exécution, répartir au moins une partie des tâches logicielles de premier niveau de priorité sur les ressources de calcul disponibles.
D’autres caractéristiques et avantages de l’invention ressortiront de la description qui en est donnée ci-dessous, à titre indicatif et nullement limitatif, en référence aux figures annexées, parmi lesquelles :
[Fig 1] la figure 1 illustre schématiquement un système d’utilisation des ressources de calcul d’une ferme de microprocesseurs selon un mode de réalisation ;
[Fig 2] la figure 2 est un synoptique des processus mis en oeuvre dans un mode de réalisation d’un procédé d’utilisation des ressources de calcul selon un mode de réalisation ;
[Fig 3] la figure 3 est un synoptique des étapes de la génération de plans d’expérience selon un mode de réalisation.
L’invention sera décrite ci-après dans son application à la simulation et aux calculs associés à la résolution de problèmes physiques, exécutés sous forme de séquences de tâches logicielles, mais n’est pas limitée à ce domaine d’application.
Le système d’utilisation des ressources de calcul 1 de la figure 1 comprend une ferme (ou « cluster ») de microprocesseurs interconnectés formant un système de calcul 2.
Les microprocesseurs sont répartis en noeuds de calcul interconnectés et regroupés en différentes queues de calcul, ayant chacune une capacité calculatoire associée.
Par exemple, dans un mode de réalisation pratique, le cluster 2 est constitué d’une pluralité de dispositifs électroniques programmables interconnectés, par exemple des ordinateurs, chaque dispositif électronique programmable comprenant une unité électronique de mémoire et une unité centrale de calcul, ou CPU, comportant un ou plusieurs microprocesseurs électroniques, adaptées à communiquer via un bus de communication. En variante, chaque dispositif électronique programmable est réalisé sous forme de composants logiques programmables, tel qu’un FPGA (de l’anglais Field- Programmable Gâte Arraÿ), ou encore sous forme de circuits intégrés dédiés, de type ASIC (de l’anglais Application-Specific Integrated Circuit). Les dispositifs électroniques programmables sont adaptés à exécuter des tâches logicielles, à partir d’instructions de code informatique en format exécutable, selon tout format approprié.
On entend ici par tâche logicielle l’exécution d’un programme informatique sur un ensemble de données d’entrée.
Le système 1 comporte également un module 4 de planification de l’exécution des tâches logicielles.
Dans un mode de réalisation, le module 4 est réalisé sous forme de programme informatique exécutable, mémorisé dans une unité mémoire 6 d’un dispositif électronique programmable 8 faisant partie du cluster 2, et exécutable par un processeur du dispositif électronique programmable 8.
L’unité mémoire 6 mémorise également un module 10 de formatage des résultats d’exécution de tâches logicielles.
Le module 4 de planification de l’exécution des tâches logicielles du système 1 est configuré pour gérer l’exécution des tâches logicielles 20 de premier niveau de priorité, également appelées tâches non prioritaires, et des tâches logicielles 22 de deuxième niveau de priorité, également appelées tâches prioritaires.
Par exemple, les tâches logicielles prioritaires proviennent de commandes utilisateur.
Les tâches logicielles non prioritaires sont associées à des problèmes physiques à étudier Ri . .Rg, et sont destinées à être exécutées quand de la place est disponible sur le cluster.
Chaque problème physique à étudier PL est défini par un ensemble de données, qui sont par exemple mémorisées dans un fichier 24 mémorisé sur un support physique lisible par ordinateur, et fourni en entrée du système 1.
Dans un mode de réalisation, un problème physique est défini par :
-un code de calcul et un jeu de données associé ;
-un ensemble de paramètres d’entrée, chaque paramètre d’entrée ayant une plage de valeurs associée. Par exemple, un paramètre noté ParamètreJ est compris entre les bornes minimale Val_min_i et maximale Val_max_i ;
-au moins un paramètre de sortie ;
-un budget calculatoire associé.
-un nombre de microprocesseurs minimal à utiliser.
Dans le cas d’une simulation d’un phénomène physique, la résolution du problème physique consiste à étudier les valeurs d’un paramètre ou de plusieurs paramètres de sortie, considérés comme étant des paramètres d’intérêt, en fonction des valeurs des paramètres d’entrée.
Des exemples non exhaustifs de tels phénomènes physiques sont par exemple : calcul du délai pour faire totalement fondre un pavé métallique soumis à une source de chaleur sur une paroi, en fonction de la puissance de chauffe, de la température extérieure, de la capacité calorifique du matériau et des dimensions du pavé ; en fonction d’un angle et d’une taille d’un déflecteur, calculer une perte de pression associée ; en fonction des paramètres d’entrée : vitesse d”entrée dans le domaine de calcul, viscosité dynamique, dimension géométrique du domaine de calcul, calculer une variation de pression aux bornes du domaine de calcul, longueur de recollement.
Le budget calculatoire est, dans un mode de réalisation, un nombre maximal de tâches logicielles à exécuter pour la résolution du problème physique.
En variante ou en complément, le budget calculatoire comprend également le nombre minimal de microprocesseurs à prendre en compte pour le calcul.
Par exemple, le code de calcul est un logiciel de calcul scientifique, recherchant une solution à des équations représentant des phénomènes physiques de façon itérative. Dans un mode de réalisation, un tel logiciel est soumis à une licence d’exécution, et le nombre d’exécutions parallèles est limité au nombre de licences d’exécution disponibles.
Chaque problème physique PL, défini par un ensemble de données comme décrit ci- dessus, est traité par un module 30 de calcul de plan d’expérience.
Dans un mode de réalisation, le module 30 est réalisé sous forme de programme informatique exécutable par un des dispositifs électroniques programmables du cluster 2.
Le module 30 met en oeuvre un processus de conception de plan d’expérience pour chaque problème physique à traiter.
Un plan d’expérience est défini par un ensemble de simulations à réaliser, chaque simulation mettant en oeuvre une pluralité de tâches logicielles à exécuter, avec un jeu de paramètres choisi en entrée, chaque simulation permettant d’obtenir une valeur pour chaque paramètre de sortie choisi formant un résultat d’exécution 32.
Le résultat d’exécution est fourni, par exemple sous forme brute, par exemple un fichier binaire, à un opérateur, via une interface adaptée du système, par exemple sous forme de fichier informatique.
De plus, le résultat d’exécution 32 sous forme brute est transmis au module 10 de formatage des résultats d’exécution de tâches logicielles, qui génère des résultats d’exécution formatés 34. Ces résultats formatés contiennent les paramètres d’entrée et les paramètres de sortie du problème, qui sont extraits, le cas échéant, des résultats d’exécution sous forme brute, qui comprennent de nombreuses données. Avantageusement, le module 30 de calcul de plan d’expérience est adapté à calculer itérativement des plans d’expérience successifs pour la résolution d’un problème physique donné, en prenant en considération, pour le calcul d’un plan d’expérience courant, des résultats formatés 34 issus de l’exécution des tâches logicielles mises en oeuvre pour les étapes précédentes du plan d’expérience.
En particulier, il est prévu de générer des plans d’expérience successifs ayant des durées d’exécution décroissantes ou des nombres de jeux de paramètres décroissants.
La figure 2 est un synoptique des processus mis en oeuvre par le module 4 de planification de l’exécution des tâches logicielles.
Le module 4 met en oeuvre une étape d’obtention 40 de l’état des ressources matérielles, en particulier de la disponibilité de ressources calculatoires dans les microprocesseurs interconnectés du cluster 2.
Par exemple, le nombre de microprocesseurs disponible parmi la pluralité de microprocesseurs interconnectés est obtenu à l’étape 40. Cette étape est répétée à intervalles temporels réguliers, par exemple toutes les minutes.
Le module 4 met également en oeuvre une étape 42 de réception des requêtes d’exécution de tâches logicielles de première priorité (tâches logicielles non prioritaires) soumises par le module 30 de calcul de plan d’expérience, et une étape 44 de vérification de présence de requêtes d’exécution de tâches logicielles de deuxième priorité (tâches logicielles prioritaires). Par exemple, les tâches logicielles non prioritaires sont soumises dans une première queue de calcul, et les tâches logicielles prioritaires sont soumises dans une deuxième queue de calcul.
Les étapes 42 et 44 sont par exemple effectuées sensiblement en parallèle, et répétées à intervalles temporels réguliers.
En cas de présence de tâches logicielles prioritaires en attente d’exécution, le module 4 récupère (étape 46) une information relative à la disponibilité courante des ressources calculatoires. La disponibilité des ressources calculatoires comprend ici la disponibilité de microprocesseurs de calcul et également la disponibilité de licence logicielle, par exemple par un mécanisme de jetons de licence, pour effectuer les tâches logicielles prioritaires.
En cas de disponibilité, l’exécution de la ou des tâches prioritaires est lancé (étape 54).
En cas de non disponibilité des ressources calculatoires, l’étape 46 est suivie d’une étape 48 de libération de ressources calculatoires pour effectuer les tâches logicielles prioritaires. L’étape 48 comporte une sous-étape 50 d’analyse des tâches logicielles non- prioritaires en cours d’exécution, et de sélection de tâches logicielles non prioritaires à arrêter, en fonction des ressources calculatoires et des licences consommées.
Par exemple, les tâches logicielles d’un plan d’expérience mis en oeuvre pour la résolution d’un problème physique donné sont sélectionnées.
Ensuite, lors d’une sous-étape 52, les tâches logicielles non prioritaires sélectionnées sont arrêtées et leur contexte d’exécution est mémorisé, de manière à donner la possibilité d’une reprise d’exécution de ces tâches ultérieurement (étape 58 ci- après). De plus, tout jeton de licence libéré par l’arrêt d’exécution d’une des tâches non prioritaires est remis à disposition.
Ainsi, avantageusement, lorsque le module 4 de planification de l’exécution des tâches logicielles détecte la présence de tâches logicielles prioritaires en attente d’exécution, il obtient des ressources calculatoires libérées pour permettre l’exécution de ces tâches logicielles à l’étape d’exécution 54. La ou les tâches logicielles prioritaires sont réparties sur les queues de calcul comprenant des ressources calculatoires disponibles.
Lorsqu’aucune tâche logicielle prioritaires en attente d’exécution n’a été détectée à l’étape 44, le module 4 vérifie (étape 56) la présence de ressources calculatoires, y compris de ressources de licence, disponibles.
En cas de disponibilité de ressources calculatoires, des tâches logicielles non prioritaires mises en arrêt précédemment sont reprises (étape 58), le cas échéant. Les tâches logicielles non prioritaires en attente d’exécution, faisant partie de plans d’expérience soumis par le module 30 de calcul de plan d’expérience, sont chargées et exécutées sur les ressources calculatoires disponibles (étape 60).
Dans un mode de réalisation, à l’étape 60, une queue de calcul est sélectionnée pour l’exécution d’une tâche logicielle non prioritaire, en fonction de l’état des ressources du cluster, par exemple en fonction du nombre de microprocesseurs disponibles et du nombre de calculs à effectuer pour l’exécution de la ou des tâches logicielles.
Les tâches logicielles non prioritaires d’un plan d’expérience donné sont exécutées jusqu’à ce qu’un critère d’arrêt soit validé. Dans un mode de réalisation, la validation du critère d’arrêt correspond à l’atteinte du budget calculatoire prédéterminé en termes de nombre de calculs ou à l’atteinte d’une valeur cible de performance d’apprentissage du problème.
Les tâches logicielles non prioritaires sont déterminées par le module 30 de calcul de plans d’expérience, dont un fonctionnement est décrit ci-après en référence à la figure 3. Avantageusement, l’occupation des ressources calculatoires est optimisée, tout en conservant la priorisation de certaines tâches logicielles prioritaires, en particulier les tâches logicielles dont le traitement est requis par un utilisateur.
La figure 3 est un synoptique des processus mis en oeuvre par le module 30 de calcul de plan d’expérience.
Lors d’une première étape 70, les données définissant le problème physique à résoudre sont obtenues. Par exemple, ces données sont fournies par un opérateur. Avantageusement, c’est la seule intervention d’un opérateur humain, la génération des plans d’expérience successifs étant effectuée automatiquement par le module 30.
Dans un mode de réalisation, un problème physique PL est défini par :
-un code de calcul et un jeu de données associé ;
-un ensemble de NL paramètres d’entrée, chaque paramètre d’entrée ayant une plage de valeurs associée. Par exemple, un paramètre noté ParamètreJ est compris entre les bornes minimale Val_min_i et maximale Val_max_i ;
-au moins un paramètre de sortie ;
-un budget calculatoire initial associé BL.
A l’étape d’initialisation 70, aucune connaissance supplémentaire sur les dépendances entre paramètres d’entrée et de sortie n’est requise.
Par exemple, pour un problème PL, le budget calculatoire est un nombre maximal de tâches logicielles à effectuer pour résoudre le problème PL.
Un espace expérimental est défini par le nombre NL de paramètres d’entrée, qui est un nombre entier positif, dépendant du problème PL à résoudre. L’espace expérimental est un hyper-pavé de dimension NL, éventuellement réduit par l’utilisateur en fonction des combinaisons inutiles de paramètres. Un maillage de cet espace expérimental en points de calcul est défini ensuite.
Par défaut, lors de l’étape d’initialisation, le maillage est isotrope.
Par exemple, le maillage est défini de manière à ce que le nombre total de points de calcul soit inférieur à une valeur limite prédéterminée, par exemple égale à 105.
Optionnellement, des informations complémentaires sont fournies lors d’une étape 72, par exemple des informations permettant d’affiner le maillage de l’espace expérimental.
Ensuite, le plan d’expérience initial pour résoudre le problème physique PL est calculé, en fonction du budget calculatoire restant.
On appelle budget calculatoire restant la valeur correspondant au budget calculatoire initial moins le budget calculatoire déjà consommé. A l’initialisation, le budget calculatoire restant est égal au budget calculatoire initial. A l’étape 74, un budget calculatoire pour le plan d’expérience est courant est calculé.
De préférence, pour le plan d’expérience initial, le budget calculatoire est choisi égal à une fraction du budget restant, par exemple la moitié : ML,o=BL/2. Le budget calculatoire restant est alors également égal à BL/2.
Ensuite, un plan d’expérience initial est conçu à l’étape 76, consistant à choisir un nombre de points de calcul NPL,o sur lesquels le code de calcul est à exécuter, formant un ensemble de tâches logicielles à exécuter, en fonction du budget calculatoire disponible ML,O. La conception du plan d’expérience repose sur une procédure d’optimisation décrite en détail ci-après en référence aux étapes 84 et 86, focalisée sur un critère d’optimalité du plan d’expérience, par exemple un critère de maximum d’entropie (au sens de la théorie de l’information de Shannon). Bien entendu, il s’agit d’un exemple de critère d’optimalité, d’autres critères pourraient être utilisés.
Dans un mode de réalisation, le plan d’expérience est initialisé par tirage aléatoire dans l’espace d’expérience puis amélioré par la procédure d’optimisation.
En variante, le plan d’expérience est construit point par point avec l’objectif d’optimiser le même critère que la procédure d’optimisation à chaque ajout.
Le plan d’expérience ainsi généré est transmis au module 4 de planification de l’exécution des tâches logicielles, et exécuté par le cluster 2.
Des résultats d’exécution formatés 34 sont reçus à l’étape 78 suite à l’exécution du plan d’expérience.
Ces résultats d’exécution sont traités par le module 30 pour mettre à jour une connaissance du problème PL à traiter, afin de permettre une optimisation de la génération de plans d’expérience. En particulier, l’influence des paramètres d’entrée sur les valeurs des paramètres sortie, connues à partir des résultats d’exécution, est analysée, de manière à affiner la sélection des points de calcul pour générer le plan d’expérience.
Dans un mode de réalisation, le module 30 construit un méta-modèle mathématique et met en oeuvre un algorithme d’apprentissage statistique supervisé en fonction des résultats d’exécution. Par exemple, le méta-modèle statistique est un modèle de régression par processus gaussien. Les modèles de régression par processus gaussien sont bien connus dans le domaine du traitement statistique des données. Ils assimilent la covariance de la variable aléatoire gaussienne représentative du processus modélisé à une fonction analytique, également appelée noyau, paramétrée par des valeurs scalaires nommées hyperparamètres. Le module 30 procède à l’optimisation des hyperparamètres du noyau de covariance, par exemple par la méthode du maximum de vraisemblance. Dans un mode de réalisation, la régression par processus gaussien, munie d’un noyau de covariance a priori kg, est reliée au critère d’optimalité du plan d’expérience. Par exemple, le critère d’optimalité consiste à maximiser le déterminant de la matrice K telle que :
Kij = kg(xir Xj ) où i , Xj sont des points de calcul du plan d’expérience.
Dans un mode de réalisation, pour un problème PL donné, des plans d’expérience successifs sont générés et exécutés, par itérations, jusqu’à ce qu’un critère d’arrêt soit validé.
La validation du critère d’arrêt est vérifiée lors d’une étape 80.
Dans un mode de réalisation, le critère d’arrêt est validé lorsque le budget calculatoire initial a été consommé, ou, en d’autres termes, lorsque le budget calculatoire restant est à 0. Dans ce cas, l’étape 80 est suivie par un arrêt des calculs (étape 82).
S’il reste un budget calculatoire à l’itération courante, un budget calculatoire courant est établi.
En variante, une atteinte d’une valeur cible de performance est également un critère d’arrêt. Ainsi, les calculs sont arrêtés si la valeur cible de performance est atteinte, même si le budget calculatoire n’a pas été entièrement consommé.
Dans un mode de réalisation, le critère de performance est la valeur moyenne du coefficient de détermination de la régression linéaire entre le résultat exact de la simulation d’une part, et le résultat prédit par le méta-modèle d’autre part, ce dernier étant entraîné sur une sélection d’autres cas, par exemple par la méthode de validation croisée « 10-fold cross-validation ». La valeur cible du critère de performance est alors fixée à la soumission du problème par l’utilisateur, et peut typiquement être de l’ordre de 0.95.
Si le critère d’arrêt n’est pas validé, le budget calculatoire pour l’itération courante ic, dit budget calculatoire courant, est calculé, et dans un mode de réalisation, il est égal à la moitié du budget calculatoire restant.
En fonction du budget calculatoire courant, des points de calcul sont sélectionnés (étape 84), et un plan d’expérience courant est calculé (étape 86).
Dans un mode de réalisation, un algorithme d’optimisation par procédure d’échange configuré pour augmenter l’entropie de l’information de Shannon est mis en oeuvre.
Des points de calcul candidats d’échange sont sélectionnés de la manière suivante. Un nombre PL,ÎC de points de calcul « en danger » est déterminé, par exemple un pourcentage des NL,i points de calcul du plan d’expérience courant. Par exemple ce pourcentage est compris entre 10% et 30%.
La matrice de covariance K normalisée est calculée, et la matrice inverse K-1 dite matrice de précision est calculée. Sur la base de ces matrices, PL,ÎC points de calcul sont sélectionnés. Ces points de calcul sont les points ayant le moins d’information mutuelle avec les autres points de calcul du plan d’expérience précédemment exécuté.
Ils sont remplacés par des nouveaux points de calcul recherchés dans l’espace expérimental, permettant d’augmenter l’information mutuelle, ce qui se traduit calculatoirement par une augmentation de la valeur du déterminant de la matrice de covariance K calculée avec les nouveaux points de calcul.
Avantageusement, cette optimisation de l’information mutuelle permet de comprendre le plus profondément possible le problème, à budget calculatoire fixé.
Un plan d’expérience courant, pour l’itération courante ic, est obtenu à l’étape 86. Les étapes 78 à 86 sont itérées jusqu’à la validation du critère d’arrêt.
Avantageusement, le module 30 de calcul de plans d’expérience met en oeuvre des méthodes statistiques supervisées pour une résolution automatisée des problèmes à résoudre, tout en contrôlant le budget calculatoire et en se passant d’intervention humaine.
Avantageusement, le processus mis en oeuvre par le module de calcul permet d’effectuer des calculs avec une maîtrise des ressources matérielles et du temps d’exécution grâce à la mise en oeuvre du budget calculatoire.
En particulier, le choix de budgets calculatoires décroissants en lien avec l’algorithme d’optimisation d’échange permet d’améliorer la performance des plans d’expérience tout en limitant les ressources de calcul utilisées.
Avantageusement, le module 4 de planification de l’exécution des tâches logicielles met en oeuvre une optimisation de l’exploitation des ressources, tout en gérant des priorités de tâches logicielles à exécuter.
Le système 1 d’utilisation des ressources calculatoires incluant ces deux modules qui collaborent permet une gestion optimisée et contrôlée des coûts, incluant le coût matériel, le coût de licence et le coût en intervention humaine, les temps de calcul et l’optimisation des ressources étant optimisés.

Claims

REVENDICATIONS
1. Procédé d’utilisation de ressources de calcul d’un système de calcul (2) comportant une pluralité de microprocesseurs interconnectés et adaptés à fonctionner en parallèle, pour effectuer des tâches logicielles, caractérisé en ce qu’il met en oeuvre :
- un processus de calcul (70-86) d’un plan d’expérience comportant une pluralité de tâches logicielles à effectuer pour résoudre un problème physique prédéterminé, défini par au moins un paramètre d’entrée et au moins un paramètre de sortie, le plan d’expérience étant calculé en fonction d’un budget calculatoire initial prédéterminé, lesdites tâches logicielles du plan d’expérience ayant un premier niveau de priorité,
- un processus de planification (40-60) de l’exécution des tâches logicielles par le système de calcul (2), configuré pour :
- vérifier (44) la présence d’au moins une tâche logicielle de deuxième niveau de priorité supérieur au premier niveau de priorité en attente d’exécution,
- en cas de présence d’au moins une tâche logicielle de deuxième niveau de priorité en attente d’exécution, obtention (46, 48) de ressources de calcul libérées pour exécuter (54) ladite au moins une tâche logicielle de deuxième niveau de priorité ;
- en cas d’absence d’au moins une tâche logicielle de deuxième niveau de priorité en attente d’exécution, répartition (58, 60) d’au moins une partie des tâches logicielles de premier niveau de priorité sur les ressources de calcul disponibles.
2. Procédé selon la revendication 1 , dans lequel l’obtention (48) de ressources de calcul libérées comporte une analyse (46) de ressources calculatoires disponibles, et en cas d’absence de ressource calculatoire disponible, une analyse (50) des tâches logicielles de premier niveau de priorité en cours d’exécution, un arrêt (52) d’exécution d’au moins une partie desdites tâches logicielles de premier niveau et une sauvegarde d’un contexte d’exécution associé.
3. Procédé selon 2, dans lequel l’obtention (48) de ressources de calcul libérées comporte en outre une vérification de disponibilité de licence disponible pour effectuer une tâche logicielle de deuxième priorité.
4. Procédé selon l’une quelconque des revendications 1 à 3, comportant en outre, en cas d’absence d’au moins une tâche logicielle de deuxième niveau de priorité en attente d’exécution, une reprise d’exécution (58) de tâches logicielles de premier niveau de priorité mises en arrêt d’exécution.
5. Procédé selon l’une quelconque des revendications 1 à 4, dans lequel la répartition d’au moins une partie des tâches logicielles de premier niveau de priorité sur les ressources de calcul disponibles comporte une analyse (56) de ressources calculatoires disponibles, comportant une analyse de queues de calcul disponibles, et une répartition (60) des tâches logicielles de premier niveau de priorité sur des queues de calcul sélectionnées.
6. Procédé selon l’une quelconque des revendications 1 à 5, dans lequel le processus de calcul d’un plan d’expérience met en oeuvre un algorithme d’apprentissage supervisé d’un méta-modèle statistique.
7. Procédé selon la revendication 6, dans lequel ledit méta-modèle statistique est un modèle de régression par processus gaussien, et le processus de calcul d’un plan d’expérience met en oeuvre une maximisation d’entropie d’un noyau de covariance dudit processus gaussien.
8. Procédé selon les revendications 1 à 7, dans lequel le calcul d’un plan d’expérience comporte une détermination (70-74) d’un espace expérimental à partir des paramètres d’entrée du problème à résoudre, un maillage dudit espace expérimental en points de calcul, et une détermination d’un ensemble de points de calcul en fonction d’un budget calculatoire associé.
9. Procédé selon la revendication 8, dans lequel le calcul d’un plan d’expérience est itéré en fonction de résultats d’exécution obtenus suite à une exécution d’un plan d’expérience précédent, et dans lequel à chaque itération, un budget calculatoire courant est calculé.
10. Procédé selon la revendication 9, dans lequel le budget calculatoire courant est égal, à chaque itération, à la moitié d’un budget calculatoire restant calculé en fonction du budget calculatoire initial et d’un budget calculatoire consommé lors d’itérations précédentes.
11. Procédé selon la revendication 10, dans lequel l’itération de calcul d’un plan d’expérience pour résoudre un problème physique prédéterminé est arrêtée (82) lorsqu’un critère d’arrêt est vérifié (80), en particulier lorsque le budget calculatoire restant est consommé.
12. Système d’utilisation de ressources de calcul d’un système de calcul comportant une pluralité de microprocesseurs interconnectés et adaptés à fonctionner en parallèle, pour effectuer des tâches logicielles, caractérisé en ce qu’il comporte :
- un module de calcul (30) d’un plan d’expérience comportant une pluralité de tâches logicielles à effectuer pour résoudre un problème physique défini par au moins un paramètre d’entrée et au moins un paramètre de sortie, le plan d’expérience étant calculé en fonction d’un budget calculatoire initial prédéterminé, lesdites tâches logicielles à effectuer ayant un premier niveau de priorité,
- un module de planification (4) de l’exécution des tâches logicielles par le système de calcul, configuré pour :
- vérifier la présence d’au moins une tâche logicielle de deuxième niveau de priorité supérieur au premier niveau de priorité en attente d’exécution,
- en cas de présence d’au moins une tâche logicielle de deuxième niveau de priorité en attente d’exécution, obtenir des ressources de calcul libérées pour exécuter ladite au moins une tâche logicielle de deuxième niveau de priorité ;
- en cas d’absence d’au moins une tâche logicielle de deuxième niveau de priorité en attente d’exécution, répartir au moins une partie des tâches logicielles de premier niveau de priorité sur les ressources de calcul disponibles.
EP20707268.7A 2019-03-01 2020-02-28 Procédé et système d'utilisation de ressources de calcul d'un système de calcul multiprocesseurs Pending EP3931696A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1902132A FR3093366B1 (fr) 2019-03-01 2019-03-01 Procédé et système d’utilisation de ressources de calcul d’un système de calcul multiprocesseurs
PCT/EP2020/055266 WO2020178168A1 (fr) 2019-03-01 2020-02-28 Procédé et système d'utilisation de ressources de calcul d'un système de calcul multiprocesseurs

Publications (1)

Publication Number Publication Date
EP3931696A1 true EP3931696A1 (fr) 2022-01-05

Family

ID=67660203

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20707268.7A Pending EP3931696A1 (fr) 2019-03-01 2020-02-28 Procédé et système d'utilisation de ressources de calcul d'un système de calcul multiprocesseurs

Country Status (5)

Country Link
US (1) US12039367B2 (fr)
EP (1) EP3931696A1 (fr)
CA (1) CA3131756A1 (fr)
FR (1) FR3093366B1 (fr)
WO (1) WO2020178168A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117151709A (zh) * 2023-05-15 2023-12-01 中国银联股份有限公司 用于确定应用程序的执行主体的类型的方法和装置
CN121050864B (zh) * 2025-11-03 2026-03-13 恒生电子股份有限公司 数据处理方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120060165A1 (en) * 2010-09-02 2012-03-08 International Business Machines Corporation Cloud pipeline

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9513962B2 (en) * 2013-12-03 2016-12-06 International Business Machines Corporation Migrating a running, preempted workload in a grid computing system
US10691488B2 (en) * 2017-12-01 2020-06-23 International Business Machines Corporation Allocating jobs to virtual machines in a computing environment
US11379263B2 (en) * 2018-08-13 2022-07-05 Ares Technologies, Inc. Systems, devices, and methods for selecting a distributed framework

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120060165A1 (en) * 2010-09-02 2012-03-08 International Business Machines Corporation Cloud pipeline

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of WO2020178168A1 *
TENG FEI ET AL: "Scheduling real-time workflow on MapReduce-based cloud", THIRD INTERNATIONAL CONFERENCE ON INNOVATIVE COMPUTING TECHNOLOGY (INTECH 2013), IEEE, 29 August 2013 (2013-08-29), pages 117 - 122, XP032519551, DOI: 10.1109/INTECH.2013.6653690 *

Also Published As

Publication number Publication date
WO2020178168A1 (fr) 2020-09-10
FR3093366B1 (fr) 2021-03-12
US12039367B2 (en) 2024-07-16
US20220147387A1 (en) 2022-05-12
CA3131756A1 (fr) 2020-09-10
FR3093366A1 (fr) 2020-09-04

Similar Documents

Publication Publication Date Title
US20250371349A1 (en) Methods and apparatus for hardware-aware machine learning model training
a Ilemobayo et al. Hyperparameter tuning in machine learning: A comprehensive review
US11966860B2 (en) Systems and methods implementing an intelligent machine learning tuning system providing multiple tuned hyperparameter solutions
US20200342419A1 (en) Intelligent management of one or more machines of a vehicle service center
WO2020190526A1 (fr) Apprentissage de précision mixte d'un réseau neuronal artificiel
EP3836030B1 (fr) Procédé et appareil à optimisation de modèle et système d'accélérateur
US20220335285A1 (en) Methods, apparatus, and articles of manufacture to improve performance of an artificial intelligence based model on datasets having different distributions
US12561407B2 (en) One-pass approach to automated timeseries forecasting
EP3931696A1 (fr) Procédé et système d'utilisation de ressources de calcul d'un système de calcul multiprocesseurs
KR102765759B1 (ko) 딥 뉴럴 네트워크를 양자화하는 방법 및 장치
EP3588301A1 (fr) Determination automatique et auto-optimisee des parametres d'execution d'une application logicielle sur une plateforme de traitement de l'information
US11823027B1 (en) System, network and method for selective activation of a computing network
Deutel et al. Combining multi-objective bayesian optimization with reinforcement learning for TinyML
EP4394658A1 (fr) Procédé amélioré d apprentissage sensible à la quantification pour un réseau de neurones
JP2023035911A (ja) 人工知能モデルを訓練する方法、コンピュータシステム、コンピュータプログラム（管理限界を使用して人工知能モデル訓練を早期停止すること）
EP3506201A1 (fr) Système et procédé adaptatifs de suivi automatique d au moins une cible dans au moins un flux vidéo
US12443855B2 (en) Optimizing cascade of classifiers schema using genetic search
EP3764286A1 (fr) Procédé et outil informatique de détermination de fonctions de transferts entre des paires de couches successives d'un réseau de neurones
CN116302545A (zh) 一种资源分配方法、装置、电子设备、及存储介质
CN112101704B (zh) 一种可再生能源资源间互补性评价方法及系统
Minhas et al. Increased leverage of transprecision computing for machine vision applications at the edge
FR3058810A1 (fr) Procede et dispositif d'actualisation d'un modele predictif d'une variable relative a un terminal mobile
US20240256901A1 (en) Information processing apparatus, information processing method and non-transitory computer-readable storage medium
KR102945228B1 (ko) 분산 처리를 이용한 경량화 인공지능 서비스 시스템 및 그 방법
FR3122759A1 (fr) Implementations et procedes de traitement de reseau neuronal dans un materiel semi-conducteur

Legal Events

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

Free format text: STATUS: UNKNOWN

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: 20210831

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230606

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: 20240226