Method and system for parallel processing of a software program consisting of a plurality of software blocks identified by function identifiers
The method and system use function identifiers to facilitate flexible and efficient parallel processing of software programs, eliminating the need for predefined entry points and specific environments, enabling execution across diverse machines.
Patent Information
- Authority / Receiving Office
- FR · FR
- Patent Type
- Applications
- Current Assignee / Owner
- MELODIUM
- Filing Date
- 2024-11-22
- Publication Date
- 2026-05-29
AI Technical Summary
Existing methods for massively parallel processing of software programs require predefined entry points and specific software environments, leading to inefficient distribution and execution across different machines, and are limited by operating systems and hardware architectures.
A method and system that uses function identifiers as start markers for software blocks, allowing execution engines to exchange necessary elements directly, eliminating the need for predefined entry points and specific software environments, and enabling flexible distribution across machines with diverse architectures.
Enables flexible and efficient parallel processing of software programs without requiring predefined entry points or specific software environments, reducing distribution load and allowing execution on machines with varying architectures.
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
Title of the invention: Method and system for parallel processing of a software program consisting of a plurality of software blocks identified by function identifiers. Technical field
[0001] The field of the invention is that of methods for massively parallel processing of software programs. The term "massively" should not, however, be interpreted as excluding small-scale software processing. State of the art
[0002] According to current methods, the distributed execution and software orchestration of a program consisting of a plurality of software blocks are executed by at least one computer orchestrator and a plurality of execution engines, using the following components concurrently: - an orchestration framework software; - virtual machines or software containers; - images of systems or containers; - software environments enabling the execution of the software; - the software itself, whose execution and orchestration are targeted.
[0003] The orchestration framework software is installed on a computer which then acts as the computer orchestrator. The virtual machines or software containers are in practice made up of execution engines orchestrated by the computer orchestrator.
[0004] In this context, any software intended for distributed execution must be designed specifically for distribution. In this sense, its design includes the definition of one or more entry points corresponding to software blocks of the software to be executed, which the orchestration framework software can specifically call. That being said, the operations or calculations performed during the execution of the software remain confined to the execution engine previously listed and identified so that software blocks of the software to be executed are instantiated by the orchestration framework software, which is therefore parameterized with a list of execution engines that it can call.
[0005] In other words, the computer orchestrator only orchestrates execution engines that are designed to work together, that is, those that are configured and prepared in a specific environment. In particular, each execution engine is configured with an entry point from a software block of the software, this The execution engine is therefore intended to execute only the software block or software blocks for which it is configured.
[0006] Typically, software requires a suitable execution environment to function. This environment usually consists of the software code, the corresponding interpreter, a configuration, and some resource elements. This environment is specific to each underlying operating system and hardware architecture.
[0007] Furthermore, in order to be executed in a suitable software environment (the execution engine being either a virtual machine or a software container), the environment and the software must have been previously prepared within system images intended for these virtual machines or container images.
[0008] A change of execution occurs when the software is run on a more powerful machine or distributed across multiple machines and executed in parallel. In this case, the orchestration framework software must call new execution engines (whether a virtual machine or a software container), and software blocks of the software can be executed on them based on the designated system images or container images.
[0009] With existing parallel processing methods, the different software execution entities are independent and isolated by default. Each time an execution engine starts, the execution process restarts from scratch. Software development technologies and languages therefore require a particular design effort to enable different execution entities to communicate with each other. Technical problem
[0010] The invention aims in particular to overcome these drawbacks of the prior art.
[0011] More specifically, the invention aims to provide a method for massively parallel processing of a software program which eliminates the need to predefine entry points of distributable software blocks and, concomitantly, to configure machines to assign them to the execution of certain software blocks of the software to be executed.
[0012] The invention also aims to provide such a method which avoids having to prepare, on the different dedicated execution engines, an adequate software environment, that is to say compatible with the design of the software to be executed.
[0013] In this sense, the invention also aims to provide such a method which avoids having to prepare system images or containers suitable for the execution of the software.
[0014] Yet another objective of the invention is to provide such a method which does not limit the execution of the distributed software by an operating system or a specific hardware architecture of the execution engines. Summary of the invention
[0015] These objectives, as well as others that will appear subsequently, are achieved thanks to the invention which relates to a method of massively parallel processing of a software program, consisting of a plurality of software blocks, by execution engines orchestrated by at least one computer orchestrator, characterized in that it comprises: - a software program configuration consisting of incorporating start markers for software blocks, each marker taking the form of a function identifier assigned to said software block, - the launch on a first machine, implementing a first processor and a first memory, of a first execution engine by the computer orchestrator, to have it execute at least two software blocks, the launch including the transmission of the function identifier of the software blocks and input parameters, - the execution, by said first execution engine, of a first of said software blocks, - the instantiation of at least a second execution engine by a computer orchestrator at the request of the first execution engine, to have it execute at least a second of the software blocks, the instantiation including the transmission of the function identifier of the second of the software blocks and input parameters, - the execution, by the second execution engine, of the second of said software blocks, - the reception, by the first execution engine, of execution status signals produced by the second execution engine, the execution status signals being transmitted with the function identifier of the second software block executed by the second execution engine.
[0016] With the parallel processing method of a software program according to the invention, the need to create system images or specific container images is eliminated. Indeed, the execution engines are capable of directly exchanging the implementation relevant to their respective tasks, as well as transmitting the input and output data necessary for the proper execution of these tasks until their completion.
[0017] The software program parameterization allows for the determination of function identifiers assigned to the software blocks. These function identifiers advantageously replace the entry points conventionally used in the prior art, which require, as a prerequisite for parallel program processing, the assignment, and therefore the identification, of execution engines for each entry point. In contrast, with a method according to the invention, using function identifiers, one obtains finer granularity and a potentially arbitrary distribution according to needs and constraints, without redefining the software design or impacting its implementation.
[0018] As a result, the orchestration of the software is made more flexible and the distribution load is reduced, the orchestration framework software no longer having to manage the instantiation of the target software, the execution engines being able to do it directly, the transmission of the elements necessary for the execution of the tasks being carried out by these engines as well, without resorting to images prepared in advance and requiring specific launches of machines or containers.
[0019] According to a particularly advantageous solution, the transmission of software blocks to execution engines is carried out in an intermediate form obtained by executing the following steps: - inventory of necessary elements (i.e. the elements on which a software block depends directly or indirectly in its implementation), for each software block, by an executing engine issuing from the function identifier of the software block; - transcription of necessary inventoried elements into a representation of serializable objects, including their descriptions and their logical implementations (by "logical descriptions" we mean the list of identifiers, parameters, characteristics of inputs and outputs, and associated logical properties); - serialization of serializable objects and transmission of these to at least one second execution engine; - reconstruction of the "necessary elements" based on the representations made by the objects (i.e. the reception and deserialization of the objects by a receiving engine, and reconstruction of the elements based on the representation contained by the objects), including a logical implementation of these; - interpretation of the logical implementation and execution on the receiving engine of the necessary elements from the function identifier of the transmitted software block.
[0020] Thanks to this feature, it is no longer necessary to consider the operating systems and hardware architectures on which the targeted software runs, the execution engine acting as the sole execution medium for the software.
[0021] In other words, the software blocks of the software program to be executed can be distributed and executed on execution engines implemented on machines that may have different physical architectures, differing in particular by a processor architecture or instruction set architecture.
[0022] According to an advantageous solution, the launch on the first machine of the first execution engine by the computer orchestrator, to make it execute at least two software blocks, is included in an instantiation.
[0023] In this way, the first machine is not necessarily equipped with the software block(s) that its execution engine must execute after being launched by the computer orchestrator. On the contrary, the execution engine of any computer machine connected to the computer orchestrator can be launched by the latter.
[0024] According to an advantageous feature, the launch or instantiation of the second execution engine by the first execution engine is executed if the processor of the first machine reaches a predetermined load level, and preferably if the processor of the first machine reaches a load level of 85%.
[0025] According to another advantageous, complementary or alternative feature of the processor load level of the first machine, the launch or instantiation of the second execution engine by the first execution engine is executed if the memory of the first machine reaches a predetermined occupancy level, and preferably if the memory of the first machine reaches an occupancy level of 85%.
[0026] According to yet another possibility, the launch or instantiation of the second execution engine by the first execution engine is executed if the processor of the first machine reaches a load level of 70% and the memory of the first machine reaches an occupancy level of 70%.
[0027] As an alternative to the launch or instantiation of the second execution engine by the first execution engine according to the load level of the processor of the first machine or the level of occupancy of its memory, it is possible that the request for instantiation of the second execution engine by the first execution engine to the computer orchestrator is triggered in a programmed manner by a part of the software block executed within this first execution engine.
[0028] According to a preferred solution, the method includes refreshing the input parameters transmitted during the instantiation of the first motor and / or the input parameters transmitted during the instantiation of the second motor or the successive execution engines if other execution engines are launched within the framework of the method according to the invention.
[0029] In this way, the input parameters can be updated as the tasks are executed by the upstream execution engine(s).
[0030] According to an advantageous solution, the method according to the invention comprises the reception, by the computer orchestrator, of a completion signal produced by the first execution engine, the emission of the completion signal being accompanied by the unloading of the first software block from the first execution engine.
[0031] Also advantageously, the method includes the reception, by the first engine, of a completion signal produced by the second execution engine, the emission of the completion signal being accompanied by the unloading of the second software block from the second execution engine.
[0032] This feature can be reproduced as many times as there are execution engines launched within the framework of the method according to the invention.
[0033] It is understood that such a feature makes it possible to avoid the congestion of the memory of the execution engine used during the parallel distribution of software blocks.
[0034] The invention also relates to a system for managing massively parallel processing of a software program consisting of a plurality of software blocks, implementing execution engines orchestrated by at least one computer orchestrator implementing a processor and an orchestrator memory, characterized in that: - The software program includes software block start markers, each marker taking the form of a function identifier assigned to said software block, - The computer orchestrator is configured to launch a first execution engine, to have it execute at least two software blocks, the instantiation including the transmission of the function identifier of the software blocks and input parameters, - said first execution engine launched executes the first of said software blocks, - The computer orchestrator is configured to instantiate a second execution engine at the request of the first execution engine, to have it execute at least one second of the software blocks, the launch including the transmission of the function identifier of the second of the software blocks and input parameters, - The second instantiated execution engine executes the second of said software blocks, and exchanges input data with the first execution engine. and outputs, and sends execution status signals to the first execution engine transmitted with the function identifier of the second software block executed by the second execution engine. Brief description of the drawings
[0035] Other features and advantages of the invention will become more apparent upon reading the following description of various preferred embodiments of the invention, given by way of simple illustrative and non-limiting examples, and the accompanying drawings, among which: - [Fig.1] [Fig.1] schematically illustrates a method and system for orchestrating execution engines, according to the principle of the invention; - [Fig. 2] [Fig. 2] schematically illustrates the exchanges between two engines execution to distribute the workload and data transmission within the framework of a method according to the invention; - [Fig.3] [Fig.3] schematically illustrates a treatment tree component of a software program; - [Fig.4] [Fig.4] schematically illustrates input and output links existing between the treatments illustrated in [Fig.3]; - [Fig. 5] [Fig. 5] schematically illustrates a method and system of parallel processing of a software program, according to the principle of the invention. Detailed description
[0036] With reference to [Fig.1], a massively parallel processing method for a software program classically implements execution engines M orchestrated by at least one computer orchestrator O, the software program being made up of a plurality of software blocks.
[0037] According to the principle of the invention, the software program is parameterized to incorporate start markers for software blocks, each of these markers taking the form of a function identifier assigned to said software block. Furthermore, the software program design also provides for the incorporation into the software block of the definition of any number of input parameters and execution status signals associated with each software block.
[0038] The design of the software program also provides for the incorporation into the software block of the definition of any number of inputs and outputs.
[0039] As illustrated in [Fig. 1], the method according to the invention involves launching a first execution engine M1 by the computer orchestrator O, in order to have it execute at least two software blocks (in practice, a plurality of software blocks). The launch by the computer orchestrator is included in an instantiation and includes the transmission, to the first execution engine M1, of the identifier of function of each of the software blocks and the input parameters associated with each of the software blocks.
[0040] The first execution engine M1 executes at least one of the received software blocks and transmits to the computer orchestrator O a request to instantiate at least one second execution engine M2, in order to have it execute at least one second of the software blocks. The instantiation of the second execution engine M2 includes the transmission of the function identifier of the second software block (or nth software blocks) and its (their) input parameters.
[0041] The second execution engine M2 executes the second software block, and exchanges input and output data, and transmits to the first execution engine M1 execution status signals and the function identifier of the second software block that it executed.
[0042] As shown in [Fig. 3], the software program L can comprise a plurality of software blocks B that can be distributed across a plurality of execution engines M, each software block being designed to execute a process (Process A, Process B, Process C, etc.). Thus, as illustrated in [Fig. 1], the first execution engine M1 can send the computer orchestrator O a request to instantiate the second execution engine M2, but also, for one or more other software blocks, a request to instantiate a third execution engine M3.
[0043] The computer orchestrator can, for its part, not only launch the first execution engine M1 but also another execution engine MN which itself can send to the computer orchestrator O a request to instantiate the execution engines MN+1 and MN+4, the execution engine MN+1 being able in turn to request the instantiation of execution engines MN+2 and MN+3.
[0044] In other words, the method according to the invention can implement a plurality of execution engines capable of executing one or more software blocks of the software program, each execution engine having the capacity to exchange any number of data streams consisting of input parameters and execution status signals, by the inputs and outputs associated with the software blocks executed by each execution engine.
[0045] It is hereafter considered that each execution engine executes one or more software blocks which are hereafter referred to as "processing".
[0046] For each processing, the transcription of the software block(s) is carried out in an intermediate form representing all the elements necessary for its logical implementation, independently of any characteristic specific to the machine including the execution engine, as well as independently of the operating system environment.
[0047] To achieve this, the transcription of the software block(s) is carried out as follows: - inventory, by an executing engine issuing from the function identifier of the software block, of the necessary elements on which a software block depends directly or indirectly in its implementation, this for each software block; - transcription of necessary inventoried elements into a representation of serializable objects, including their descriptions (identifiers, parameters, characteristics of inputs and outputs, associated logical properties) and their logical implementations; - reconstruction of the "necessary elements" on the basis of the representations made by the objects, i.e. the reception and deserialization of the objects by a receiving engine, and reconstruction of the elements on the basis of the representation contained by the objects), including a logical implementation of these; - interpretation of the logical implementation and execution on the receiving engine of the necessary elements from the function identifier of the transmitted software block.
[0048] Each of the necessary elements is represented in a logical object, comprising the description and implementation of the element. These logical objects are designed to be serializable, and their representation after serialization is sent.
[0049] Considering the example of [Fig.1], this can be translated at the level of the execution engines M1, M2 and M3 in the following way.
[0050] Considering a software program as illustrated in [Fig.4], having processes based on other processes, such as Processing A using Processing B and Processing E. The inputs Aa and Ab of Processing A being respectively connected to the inputs Ba and Bb of Processing B. The outputs Bc, Bd, and Be of Processing B being connected to the inputs Ea, Eb, Ec of Processing E, themselves notably connected to the inputs Fa and Fb of Processing F, whose outputs Fc and Fd are connected within Processing E.
[0051] As illustrated in [Fig. 5], motor M1 executes Process A and has transmitted Process B to motor M2, which M2 executes. Similarly, motor M1 has transmitted Process F to motor M3, which M3 executes. The data received at inputs Aa and Ab of Process A by motor M1 are sent by motor M1 to motor M2 to be received at inputs Ba and Bb of Process B. Likewise, the data sent at outputs Bc, Bd, and Be of Process B to motor M2 are sent by motor M2 to be received by motor M1 at inputs Ea, Eb, and Ec of Process E. By the same process, the data received on The inputs Ea and Eb of Processing E by motor M1 are sent to motor M3 to be received on the inputs Fa and Fb of Processing F. The data sent by the outputs Fc and Fd of Processing F on motor M3 are sent by motor M3 to motor M1 to be received by Processing G and the output Ed.
[0052] Fig. 2 schematically illustrates the exchanges between two execution engines, for example the execution engines M1 and M2.
[0053] Initially, the execution engine M1 transcribes the software block(s) to be executed by the block M2 into an intermediate form as described previously (step E0).
[0054] This intermediate representation is then transmitted to the M2 engine (step E1). The execution engine M2 confirms the reception and loading of the intermediate representation of the software block(s) and emits a signal to this effect to the execution engine M1 (step E2).
[0055] Instantiation is performed with the transmission of input parameters (step E3) and the execution engine M2 sends to the execution engine M1 an instantiation confirmation signal with receipt of the input parameters.
[0056] The execution of the software block(s) by the execution engine M2 can lead to a bidirectional data exchange (step E5), including the sending of data on the inputs, by the execution engine Ml to the execution engine M2 (step E6), the latter in turn sending output data to the execution engine Ml (step E7).
[0057] The termination of the execution of the software block(s) by the execution engine M2 can be triggered at the initiative of the execution engine M1 (step E8), this being realized by the closure of the transmission of input data (step E9).
[0058] Alternatively, the termination of the execution of the software block(s) by the execution engine M2 can be triggered on its own initiative (step E10), the executed software block(s) being programmed with a completion instruction (step Eli).
[0059] In either case, this is followed by a step of completion of output data transmission (step E12) and the closure of the output data transmission (step El3).
[0060] This is followed by an E14 step of emitting a completion signal of the software block executed by the execution engine M2, which is accompanied by an unloading of the intermediate representation from the execution engine M2 (step E15).
[0061] The execution engine Ml can, for its part, continue to execute the software block(s) for which it was launched (step El6).
[0062] The execution of the software block(s) by the Ml execution engine continues until the Ml execution engine emits a completion signal at destination of the computer orchestrator, the sending of this completion signal being accompanied by the unloading of the first software block by the first Ml engine.
[0063] It is noted that the launch or instantiation of the second execution engine M2 by the first execution engine M1 is executed if the processor of the first machine including the first execution engine M1 reaches a predetermined load level, which can be predetermined at 85%. This launch or instantiation of the second execution engine M2 by the first execution engine M1 can also be executed if the memory of the first machine reaches a predetermined occupancy level, which can be set at 85%. The launch or instantiation of the second execution engine can also be executed if two conditions are met simultaneously, namely if the processor of the first machine reaches a load level of 70% and the memory of the first machine reaches an occupancy level of 70%.
[0064] The request for instantiation of the second execution engine M2 by the first execution engine M1 from the computer orchestrator O can also be triggered programmatically by a part of the software block executed by the first execution engine ML
[0065] The parallel processing method of a software program just described is executed by a processing management system implementing the execution engines M orchestrated by the computer orchestrator, with software which includes software block start markers taking the form of function identifiers assigned to the software blocks.
[0066] In such a system, the computer orchestrator is configured to launch the first execution engine Ml to execute at least two software blocks, this launch being accompanied by the transmission of the function identifier(s) of the software blocks, as well as input parameters.
[0067] The first execution engine Ml executes the software blocks and is configured to request the computer orchestrator to instantiate a second execution engine, to have it execute at least one second of the software blocks, this instantiation including the transmission of the function identifier of the second of the software blocks as well as input parameters.
[0068] The second instantiated M2 execution engine executes the second software block and returns execution status signals to the first M2 execution engine accompanied by the function identifier of the second executed software block.
[0069] As previously stated, such a system is not limited as to the number of execution engines used, launched or instantiated each according to the method described above between the first execution engine M1 and the second execution engine M2.
Claims
1.
2. Demands A massively parallel processing method for a software program, consisting of a plurality of software blocks, by execution engines orchestrated by at least one computer orchestrator, characterized in that it comprises: - a software program configuration consisting of incorporating start markers for software blocks, each marker taking the form of a function identifier assigned to said software block, - the launch on a first machine, implementing a first processor and a first memory, of a first execution engine by the computer orchestrator, to have it execute at least two software blocks, the launch including the transmission of the function identifier of the software blocks and input parameters, - the execution, by said first execution engine, of a first of said software blocks, - the instantiation of at least a second execution engine by a computer orchestrator at the request of the first execution engine, to have it execute at least a second of the software blocks, the instantiation including the transmission of the function identifier of the second of the software blocks and input parameters, - the execution, by the second execution engine, of the second of said software blocks, - the reception, by the first execution engine, of execution status signals produced by the second execution engine, the execution status signals being transmitted with the function identifier of the second software block executed by the second execution engine. A massively parallel software program processing method according to claim 1, characterized in that the transmission of software blocks to execution engines is carried out in an intermediate form obtained by executing the following steps: - inventory, by an emitting execution engine from the function identifier of the software block, of the necessary elements on which a software block depends directly or indirectly in its implementation, this for each software block; - transcription of the inventoried necessary elements into a representation of serializable objects, including their descriptions (identifiers, parameters, characteristics of inputs and outputs, associated logical properties) and their logical implementations; - reconstruction of the "necessary elements" on the basis of the representations made by the objects, i.e. the reception and deserialization of the objects by a receiving engine, and reconstruction of the elements on the basis of the representation contained by the objects), including a logical implementation of these;- interpretation of the logical implementation and execution on the receiving engine of the necessary elements from the function identifier of the transmitted software block.;
3. A massively parallel software program processing method according to any one of claims 1 and 2, characterized in that the launching on the first machine, of the first execution engine by the computer orchestrator, to make it execute at least two software blocks, is included in an instantiation.
4. A massively parallel method of processing a software program according to any one of the preceding claims, characterized in that the launching or instantiation of the second execution engine by the first execution engine is executed if the processor of the first machine reaches a predetermined load level.
5. A massively parallel software program processing method according to claim 4, characterized in that the launch or instantiation of the second execution engine by the first execution engine is executed if the processor of the first machine reaches a load level of 85%.
6. A massively parallel processing method for a software program according to any one of the preceding claims, characterized in that the launch or instantiation of the second execution engine by the first execution engine is executed if the memory of the first machine reaches a predetermined occupancy level.
7. A massively parallel method for processing a software program according to claim 6, characterized in that the launch or instantiation of the second execution engine by the first execution engine is executed if the memory of the first machine reaches an occupancy level of 85%.
8. A massively parallel method for processing a software program according to any one of claims 1 to 4, characterized in that the launch or instantiation of the second execution engine by the first execution engine is executed if the processor of the first machine reaches a load level of 70% and the memory of the first machine reaches an occupancy level of 70%.
9. A massively parallel method for processing a software program according to any one of the preceding claims, characterized in that the request for instantiation of the second execution engine by the first execution engine from the orchestrator is triggered programmatically by a part of the software block executed within that first execution engine.
10. A massively parallel software program processing method according to any one of the preceding claims, characterized in that it includes at least one refresh of the input parameters passed during the instantiation of the second execution engine.
11. A massively parallel software program processing method according to any one of the preceding claims, characterized in that it comprises the computer orchestrator receiving a completion signal produced by the first execution engine, the emission of the completion signal being accompanied by the unloading of the first software block from the first execution engine.
12. A massively parallel method for processing a software program according to any one of the preceding claims, characterized in that it comprises the reception, by the first execution engine, of a completion signal produced by the
13. second execution engine, the emission of the completion signal being accompanied by the unloading of the second software block of the second execution engine. A system for managing massively parallel processing of a software program consisting of a plurality of software blocks, implementing execution engines orchestrated by at least one computer orchestrator implementing a processor and orchestrator memory, characterized in that: - The software program includes software block start markers, each marker taking the form of a function identifier assigned to said software block, - The computer orchestrator is configured to launch a first execution engine, to have it execute at least two software blocks; the launch includes the transmission of the function identifier of the software blocks and input parameters. - said first execution engine launched executes the first of said software blocks, - The computer orchestrator is configured to instantiate a second execution engine at the request of the first execution engine, to have it execute at least one second of the software blocks; the instantiation includes the transmission of the function identifier of the second of the software blocks and input parameters. - the second instantiated execution engine executes the second of said software blocks, exchanges input and output data with the first execution engine and sends execution status signals to the first execution engine transmitted with the function identifier of the second software block executed by the second execution engine.