JP2013020580A - Parallelization method, system and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technique to divide the regions of a block diagram including a block other than coded object by changing the disposition of the block other than coded object to optimize the operation speed after coding.SOLUTION: A block diagram is converted and abstracted into a task graph of DAG. A series-parallel tree (SPT) is obtained by analyzing the structure of the task graph. The SPT includes: an S-node from which a serial execution node branches; and a P-node from which parallel execution node branches. The SPT is converted into another SPT until no P-node exists prior to the block other than coded object. A corresponding block diagram is divided, and a code is generated for each region; and compiled and allotted to a different processor or core to execute a block following the P-node of the obtained SPT in parallel. The task graph of the DAG is deformed so that scattered blocks other than coded object are preferably merged.

Description

  The present invention relates to a technique for speeding up program execution by parallelization in a simulation system.

  In recent years, so-called multiprocessor systems having a plurality of processors have been used in fields such as scientific calculation and simulation. On the other hand, simulation software that has recently been actively developed includes simulation software for methcattronic plants such as robots, automobiles, and airplanes. Thanks to the development of electronic parts and software technology, robots, automobiles, airplanes, etc., perform most of the control electronically using wire connections, wireless LANs, etc. that are stretched like nerves.

  They are essentially mechatronic devices, but they also contain a lot of control software. Therefore, in developing products, it has become necessary to spend a long time, enormous costs, and a large number of personnel for developing and testing control programs.

  As a technique conventionally performed for such a test, there is HILS (Hardware In the Loop Simulation). In particular, the environment for testing the electronic control unit (ECU) of the entire automobile is called full vehicle HILS. In the full vehicle HILS, a real ECU is connected to a dedicated hardware device that emulates an engine, a transmission mechanism, and the like in a laboratory, and a test is performed according to a predetermined scenario. The output from the ECU is input to a monitoring computer and further displayed on a display, and a tester checks whether there is an abnormal operation while looking at the display.

  However, HILS requires a dedicated hardware device and has to be physically wired between it and a real ECU, so preparation is difficult. In addition, the test after replacing with another ECU also takes time since it must be physically reconnected. Furthermore, since the test is performed using a real ECU, real time is required for the test. Therefore, testing many scenarios takes a huge amount of time. In addition, a hardware device for HILS emulation is generally very expensive.

  Therefore, in recent years, a method has been proposed in which the entire simulation is configured by software without using an expensive emulation hardware device. In the method, a continuous simulation is used for a plant part such as an engine and a transmission, and a state chart or actual software code is used for a controller part. Depending on the simulation method of the controller part, the former is called MIL (Model-in-the-Loop) simulation and the latter is called SIL (Software-in-the-Loop) simulation. According to MIL and SIL, a test can be executed without the presence of ECU hardware.

  As a system that supports the construction of such MIL / SIL, for example, there is MATLAB® / Simulink®, which is a simulation modeling system available from MathWorks. Using MATLAB (R) / Simulink (R), a simulation program can be created by placing functional blocks on the screen using a graphical interface and specifying the processing flow. Here, there are various types of functional blocks such as basic operations such as sum and product, integration and conditional branching, and further a block for calling software code, and each has an input and / or an output. A simulation including a software block as an expression of a controller is SIL.

  In this way, once the functional block is configured and arranged on MATLAB (R) / Simulink (R) to create a block diagram, the simulation is executed using the Real-Time Workshop (R) function. Furthermore, the speed can be increased. That is, blocks other than the software code are converted into a source code in a known computer language such as C language having an equivalent function, thereby replacing a sequential interpretation process with a process optimized for the host. In the case of Real-Time WOrkshop®, the code conversion unit is the entire model or a sub-block unit as indicated by reference numerals 102 and 104 in FIG. Here, the sub-block represents a special boundary for expressing a hierarchical structure introduced for the readability of the model. For example, the sub-block 108 has an internal structure as indicated by reference numeral 108a.

  However, control systems such as automobiles and airplanes are complex, and usually include several thousand to several hundred thousand functional blocks. Therefore, in order to design a simulation model and obtain a desired model, it is necessary to repeat design, compilation, and execution many times.

  In FIG. 1, for example, an operator edits and compiles the sub-block 110 among the sub-blocks 102 to 110 to obtain executable binary code. Then, the executable binary code is executed on the computer system to confirm the operation, and if the desired operation cannot be obtained, the sub-block 110 is edited again, compiled and executed repeatedly.

  As the number of functional blocks increases, the resulting source code increases, but this also increases the compilation time when fully compiling the entire source code.

  In general, when editing a large-scale model, a sub-block to be edited is often limited to a part, for example, a sub-block 110 in FIG. In particular, in the case of a complex model, the other sub-blocks except for the part for which the designer is responsible are often fixed and treated like a black box without being changed. Therefore, both the execution speed and the editing work can be achieved by leaving the sub-blocks to be edited and performing code conversion on the other blocks in advance. Also, in a multi-processor or multi-core environment, the execution time can be shortened by allocating and separately executing the separately compiled code to different processors or cores. Particularly for the latter, there is a technique described in the following patent publication as a related technique.

  Japanese Patent Application Laid-Open No. 7-114486 relates to a method for parallelizing a sequential loop including an output statement for debugging, detects an I / O statement in the sequential loop, and the I / O statement becomes a conditional clause by a loop invariant expression. It is disclosed that the inclusion is detected, the dependency including the I / O statement is analyzed, a synchronous statement for keeping the execution order is inserted, and the loop is converted into a parallel processing loop.

  Japanese Patent Laid-Open No. 2011-96107 discloses a block used for each functional block in a program represented by a block diagram or the like based on a connection relationship between a functional block having an internal state and a functional block having no internal state. It is disclosed that the number of sets / definition block sets is obtained, and a plurality of strands are assigned based on the number, thereby dividing the block diagram into strands to parallelize the processes.

  FIG. 2 shows an example of simple division aligned to sub-blocks. That is, in FIG. 2, it is divided into regions 202, 204, 206, and the like. However, in the case of simulation based on time steps, such as MATLAB (R) / Simulink (R), code conversion is not always possible in units of sub-blocks. For example, in order to schedule the execution order of blocks, it is necessary to analyze up to the middle of the sub-block (lower hierarchy). In effect, the sub-block must be divided back and forth. Also, for example, blocks that display results, such as the MATLAB (R) / Simulink (R) Scope block, cannot be transcoded, and therefore include a functional block that cannot be coded. Cannot be coded in its units. FIG. 3 shows an example of division attempted in consideration of the above constraints. That is, as shown in FIG. 3, the division excludes the non-coding blocks 314 and 316 and applies code conversion by division and reconfiguration so that the execution start codes 310 and 312 according to the schedule come to the top. This is desirable for speeding up the simulation.

  However, such a division and reconstruction method is not self-evident, and in particular, a division procedure for parallelization becomes a combination problem, and it is generally very difficult to calculate an optimum combination in a short time. Therefore, it is strongly required to find a suboptimal solution within a limited time.

JP-A-7-114486 JP 2011-96107 A

An object of the present invention is to divide a block diagram representing the flow of basic processing so as to optimize its execution speed.
Another object of the present invention is to provide a technique for arranging non-coding blocks on the boundary of division so as not to impair the execution speed.

  The present invention has been made to solve the above problems, and a system according to the present invention first converts a block diagram into a DAG (directed acyclic graph) task graph.

  Next, the system according to the present invention converts the task graph into a serial-parallel graph (SPG) according to a known algorithm, and then performs a structural (syntax) analysis to obtain a unique serial- Obtain a parallel-parse tree (SPT). The SPT includes an S node from which a serial execution node branches and a P node from which a parallel execution node branches. The terminal node represents a node of the task graph.

  Next, the system according to the present invention transforms the SPT into another SPT until there is no P node above the non-coding target block.

  Once the optimal SPT is thus obtained, the system according to the invention generates and compiles the code to execute in parallel the blocks under the P node of the resulting SPT, assigns it to different processors or cores, and Let it run.

  Note that there are generally a plurality of SPTs that do not contradict the context of the node execution order for a DAG task graph. Therefore, according to a preferred aspect of the present invention, the DAG task graph is transformed so that scattered non-coding target blocks are merged as much as possible before the conversion into the SPT. As a result, the number of divisions of the resulting task graph can be reduced. In general, if the size of each division is about the same, the overall critical path becomes smaller and the effect of speeding up in parallel processing increases. Even in the case of sequential processing, if the number of divisions is small, the overhead of calls is reduced, which greatly contributes to speeding up execution.

  According to the present invention, in a program code represented by a block diagram, a technique for reducing the number of code divisions and giving a balanced division of parallel execution costs in consideration of the presence of non-coding blocks is provided. Is done.

It is a figure for demonstrating compilation and execution of a task graph. It is a figure which shows the simple division | segmentation aligned to the subblock. It is a figure which shows the largest division | segmentation according to the non-coding object block and the execution schedule. It is a block diagram of the hardware for implementing this invention. It is a functional block diagram for implementing this invention. It is a figure which shows the general | schematic flowchart of the whole process of this invention. It is a figure which shows the flowchart of a task graph deformation | transformation process. It is a figure which shows the example of the list scheduling in a task graph deformation | transformation process. It is a figure which shows the flowchart of the process which converts a task graph into SPT. It is a figure which shows the example of the process which converts a task graph into SPT. It is a figure which shows the example of the process which converts a task graph into SPT. It is a figure which shows the flowchart of a SPT deformation | transformation process. It is a figure which shows the example of a SPT deformation | transformation process. It is a figure which shows the example of a SPT deformation | transformation process. It is a figure for demonstrating the main processes in a SPT deformation | transformation process. It is a figure for demonstrating the main processes in a SPT deformation | transformation process. It is a figure which shows the flowchart of the process for producing | generating the code allocated to an individual processor or a core.

  The configuration and processing of an embodiment of the present invention will be described below with reference to the drawings. In the following description, the same elements are referred to by the same reference numerals throughout the drawings unless otherwise specified. It should be understood that the configuration and processing described here are described as an example, and the technical scope of the present invention is not intended to be limited to this example.

  First, with reference to FIG. 4, the hardware of a computer used to implement the present invention will be described. 4, a plurality of CPU1 404a, CPU2 404b, CPU3 404c,... CPUn 404n are connected to the host bus 402. Further connected to the host bus 402 is a main memory 406 for arithmetic processing of the CPU1 404a, CPU2 404b, CPU3 404c,..., CPUn 404n.

  On the other hand, a keyboard 410, a mouse 412, a display 414, and a hard disk drive 416 are connected to the I / O bus 408. The I / O bus 408 is connected to the host bus 402 via the I / O bridge 418. The keyboard 410 and the mouse 412 are used by an operator to operate by typing a command or clicking a menu. The display 414 is used to display a menu for operating the program according to the present invention using a GUI as necessary.

  IBM (R) System X is the preferred computer system hardware used for this purpose. At that time, CPU1 404a, CPU2 404b, CPU3 404c,..., CPUn 404n are, for example, Intel (R) Xeon (R), and the operating system is Windows (trademark) Server 2003. The operating system is stored on the hard disk drive 416 and is read from the hard disk drive 416 into the main memory 406 when the computer system is started.

  In order to implement the present invention, it is necessary to use a multiprocessor system. Here, the multiprocessor system is generally intended to be a system using a processor having a plurality of cores of processor functions that can independently perform arithmetic processing. Therefore, a multicore single processor system or a single core multiprocessor system is used. And any multi-core multi-processor system.

  The hardware of the computer system that can be used for carrying out the present invention is not limited to IBM (R) System X, and any hardware that can run the simulation program of the present invention can be used. A computer system can be used. As the operating system, any operating system such as Windows (R) XP, Windows (R) 7, Linux (R), Mac OS (R), or the like can be used. Further, in order to operate the simulation program at a high speed, a computer system such as IBM (R) System P whose operating system is AIX (trademark) based on POWER (trademark) 6 may be used.

  The hard disk drive 416 further includes MATLAB® / Simulink®, C compiler or C ++ compiler, task graph generation, task graph modification direct-parallel tree (SPT) conversion, SPT modification, etc. Are stored in the main memory 406 and executed in response to an operator's keyboard or mouse operation. Modules for task graph generation, task graph transformation direct-parallel tree (SPT) transformation, SPT transformation, etc. can be created in any existing programming language such as Java (R), C, C ++, C #.

Note that the simulation modeling tools that can be used are not limited to MATLAB (R) / Simulink (R), but any simulation model represented by a task graph based on time steps, such as open source Scilab / Scicos. Modeling tools can be used.

  Alternatively, in some cases, it is possible to write the source code of a simulation system directly in C, C ++, etc. without using a simulation modeling tool. In this case as well, individual functions depend on each other. The present invention can be applied if it can be described as individual functional blocks.

  FIG. 5 is a functional block diagram according to the embodiment of the present invention. Each block basically corresponds to a module stored in the hard disk drive 416.

  In FIG. 5, the simulation modeling tool 502 is preferably MATLAB® / Simulink®, and in addition, any simulation model that can include non-coded blocks such as Scilab / Scicos. Modeling tools can be used.

  The model data 504 is created using a simulation modeling tool 502, preferably described in a block diagram, and stored in the hard disk drive 416. In the blocks included in the block diagram, the non-coding target blocks are marked in advance.

  The main routine 506 is a program for calling and executing various modules of the processing according to the present invention, and preferably a GUI for performing processing by operating the keyboard 410 or the mouse 412 on the display 414. Give the interface.

  The DAG conversion module 508 has a function of reading the model data 504 and converting it into a DAG task graph. Preferably, the converted task graph data is expanded while securing a necessary area on the main memory 406. As a data structure for representing a graph on a computer memory, a matrix representation or a list representation is known. In this embodiment, any known data structure can be used.

  The task graph transformation module 510 has a function of merging non-coding target blocks included in the task graph obtained by conversion by the DAG conversion module 508 to the extent possible. The task graph resulting from the transformation is preferably expanded while securing a necessary area on the main memory 406. This process will be described in detail later with reference to the flowchart of FIG.

  The SPT conversion module 512 has a function of converting the task graph obtained by transformation by the task graph transformation module 510 into a direct-parallel tree (SPT). The SPT includes an S node from which a serial execution node branches and a P node from which a parallel execution node branches. The task graph obtained as a result of the conversion is preferably expanded while securing a necessary area on the main memory 406. This process will be described in detail later with reference to the flowchart of FIG.

  The SPT transformation module 514 has a function of transforming the SPT graph obtained by the SPT transformation module 512 into another direct-parallel tree (SPT). The transformation is performed until there is no P node above the non-coding target block. The task graph resulting from the transformation is preferably expanded while securing a necessary area on the main memory 406. This process will be described later in detail with reference to the flowchart of FIG.

  The CPU allocation module 516 extracts codes for allocation to individual processors or cores based on the SPT obtained as a result of the deformation of the SPT deformation module 514. The extracted code is preferably written to the hard disk drive 416. This code is preferably C or C ++ source code corresponding to the functional block. The processing of the CPU allocation module 516 will be described in more detail later with reference to the flowchart of FIG.

  The compiler 518 compiles the code written by the CPU allocation module 516 to generate executable code. The execution environment 520 is assigned to individual processors or cores and executed in parallel. The execution environment 520 preferably assigns executable code with reference to auxiliary information generated by the CPU assignment module 516.

  When using MATLAB (R) / Simulink (R) as part of the execution environment 520, it distinguishes uncompiled (sub) blocks from compiled subblocks, and the former is executed as an interpreter. The latter runs as binary code on the host.

  FIG. 6 is a schematic flowchart showing the overall flow of the processing of the present invention. The subsequent detailed description will be described along this flow.

  In step 602, the DAG conversion module 508 converts the model data into a DAG task graph.

  In step 604, the task graph is transformed by the task graph transformation module 510 so as to merge the blocks to be encoded as far as possible.

  In step 606, the task graph is converted into SPT by the SPT conversion module 512.

  In step 608, the SPT transformation module 514 converts the SPT into another SPT so that no P node exists above the non-coding target block.

  In step 610, based on the SPT generated by the SPT deformation module 514, a code for allocation to each CPU is generated by the CPU allocation module 516.

  In step 612, the generated code is compiled by the compiler 518, and in step 614, the compiled code is executed.

Hereinafter, each step will be described in detail. Before that, terms relating to nodes on the DAG and the SPT are defined.
x node: non-coding target node non-x node: order of term nodes related to nodes on coding target node SPT: determined in the order followed by depth-first search of tree (Tree) left priority . For two nodes in the SPT, the order in which they are traced is earlier than the other, and the later is the later.
Root node: Follows the general definition.
Leaf node: A node that has no children. Corresponds to a node on the DAG. (Same as general definition)
Internal node: a node that is not a leaf node (same as the general definition)
Parent node: Child node that conforms to general definition: Brother node that conforms to general definition: Node whose parent node is the same, node before target node Brother node: Target node of the same parent node Node sibling nodes after the node: Brother nodes and brother nodes
Grandfather node: Parent node of parent node Great grandfather node: Parent node of grandfather node
S node: An internal node representing the serial execution of child nodes
P node: An internal node representing the parallel execution of child nodes

  In addition, a supplement regarding the configuration of the SPT will be described. On the SPT, S nodes or P nodes do not have a parent-child relationship. If the same type of internal node has a parent-child relationship, the child node is disconnected, and the child node of the child node is moved to the parent node while maintaining the order (at this time, the nodes below the moved node are also brought along) Process automatically). The above processing does not change the meaning of serial / parallel execution expressed by a tree.

  Based on the above definitions and supplements, the steps in FIG. 6 will be described in order. First, in step 602 of converting model data into a DAG task graph, the DAG conversion module 508 reads the model data 504 and converts it into a DAG task graph. At this time, the block at the head of the schedule as shown in FIG. 3 is interpreted and converted to a DAG structure having no self-loop. Preferably, the converted task graph data is expanded while securing a necessary area on the main memory 406. In the model data 504 described as a block diagram, the DAG conversion module 508 uses a function block having no input or a function block that comes first in the execution schedule as a whole source and a connection between nodes as a directed edge. Constructs a DAG (acyclic directed graph). The entire sink is a function block without output or a function block scheduled last in execution.

  Step 604 of transforming the task graph so that the task graph transformation module 510 merges non-coding target blocks as much as possible performs list scheduling with the following properties on the task graph, and schedule Perform the process of merging adjacent non-coding target nodes (X) into one.

  At this time, if the node scheduled immediately before is x, x is scheduled as much as possible, and if the node scheduled immediately before is not x, a non-x node is scheduled as much as possible.

  The purpose here is to make x a single block as much as possible within a range that does not contradict the context of task nodes. Thus, x is distributed and arranged on the SPT extracted in the next step to increase the number of final code divisions, or the parallel that can be originally used by extracting parallelism with x that cannot be finally used (exploit). Avoid situations where sex is not extracted as much as possible.

  FIG. 7 is a flowchart of the process of the task / graph transformation module 510 corresponding to step 604 of FIG. In this process, a DAG having x nodes and non-x nodes is input and a serial schedule S is output. The serial schedule S is treated as a single merged node in the task graph.

  In step 702 of FIG. 7, the task / graph transformation module 510 prepares S as an empty list and C as all nodes (unscheduled node set) of the DAG.

  In step 704, the task graph transformation module 510 prepares Ro as a set of non-x nodes in C that do not have a parent in C, and Rx as a set of x nodes in C that do not have a parent in C. To do.

  In step 706, the task graph transformation module 510 determines whether Ro = φ φRx = φ, that is, whether Ro is an empty set and Rx is an empty set.

  If not, the task graph transformation module 510 determines in step 708 whether the node just added to S is an x node, and if so, in step 710 determines whether Rx = φ.

  If it is determined in step 710 that Rx = φ is not true, task graph transformation module 510 extracts one node from Rx, deletes it from Rx, and adds the node to the end of S in step 712. Furthermore, the node is deleted from C. Then, the process returns to step 704.

  Returning to step 710, if it is determined that Rx = φ, the task graph transformation module 510 proceeds to step 714 and determines whether Ro = φ.

  If it is determined in step 714 that Ro = φ is not true, task graph transformation module 510 retrieves one node from Ro, deletes it from Ro, and adds the node to the end of S in step 716. Furthermore, the node is deleted from C. Then, the process returns to step 704.

  Returning to step 708, if the node added to S just before is not an x node, proceed to step 714, where the task graph transformation module 510 determines if Ro = φ, and if so, proceed to step 710. The processing in step 710 is as described above. The processing in the case where it is determined in step 714 that Rx = φ is also as described above.

  Thus, upon returning to step 706 via step 704, if it is determined that Ro is an empty set and Rx is an empty set, task graph transformation module 510 determines in step 718 the adjacent x nodes in S. Is set as one set, and the process of merging x nodes included in each set into one node on the DAG is completed.

  FIG. 8 is a diagram schematically showing the state of the processing of FIG. That is, when a task graph as shown in FIG. 8A is given, list scheduling shown in FIG. 8B is performed in the processing of steps 702 to 716 shown in the flowchart of FIG. Therefore, in the process of step 718, the adjacent x nodes are made into one set, and the x nodes included in each set are merged into one node on the DAG, whereby the changed task shown in FIG.・ A graph is obtained.

  FIG. 9 is a diagram illustrating a flowchart of processing of the SPT conversion module 512. This process corresponds to step 606 in FIG. In this process, DAG is input and SPT is output.

In step 902, the SPT conversion module 512 converts the DAG into a serial-parallel graph and puts it as SPG. For example, A. Gonzalez Escribano, V. Cardenoso and AJC van Gemund, “Conversion from NSP to SP graphs”, Tech. Rep. TR-DINFO-01-97, Universidad de Techniques described in Valladolid, Valladolid (Spain), 1997, etc. can be used. In step 902, the structure of the SPG is analyzed to obtain an SPT (series-parallel parsed tree).
Here, leaf nodes on the SPT correspond to SPG nodes. Also, non-terminal (non-leaf) nodes do not exist on the SPG, but indirectly represent the connection order between the nodes.

  Next, in step 904, the SPT conversion module 512 determines whether the number of nodes on the SPG is 1 or less, and if not, proceeds to step 906.

  In step 906, the SPT conversion module 512 performs the following processing. That is, a path of nodes connected in series on the SPG is found. Here, the path of a node connected in series is a node with one parent and one child from a node having multiple parents or no parent to a node having multiple children or no children. Points to a path composed of nodes.

Then, the SPT conversion module 512 performs the following processing for each path L.
All nodes belonging to L on the SPG are replaced with one node S (at this time, the connection relationship with nodes outside L is maintained).
At the same time, S is set as one node on the SPT, and a node on the SPT corresponding to the node in the L is added as a child node of the SPT on the SPT in the order in the order in the L. Here, the nodes configured on the SPG can always be associated with each other because the corresponding nodes are also constructed on the SPT.

  Next, in step 908, the SPT conversion module 512 finds a set of nodes in parallel relation on the SPG. Here, the set of nodes in a parallel relationship refers to a set of nodes whose parent and child nodes match (including a case where they do not exist).

Further, the SPT conversion module 512 performs the following processing for each set C.
All the nodes belonging to C on the SPG are replaced with one node P (at this time, the connection relationship with a node outside P is maintained).
At the same time, P is set as one node on the SPT, and a node on the SPT corresponding to the node in C is added as a child node of P on the SPT. Again, it should be noted that the nodes configured on the SPG are always associated with each other because the corresponding nodes are also built on the SPT.

  After step 908, the SPT conversion module 512 returns to step 904, and the SPT conversion module 512 determines whether or not the number of nodes on the SPG is 1 or less, and if so, ends the process.

  FIG. 10 is a diagram illustrating an example in which DAG is converted into SPT in accordance with the processing of the flowchart illustrated in FIG. 9. That is, the DAG in FIG. 10A is converted into the SPT in FIG. At that time, it can be seen that in the SPT, an S node that is an internal node representing serial execution of child nodes and a P node that is an internal node representing parallel execution of child nodes are generated.

  For reference, FIG. 11 is a diagram showing an example of converting a DAG that has not undergone the transformation of the task graph transformation module 510 into an SPT. In the SPT shown in FIG. 11B, it can be seen that the x nodes are scattered as leaf nodes as compared to the SPT in FIG. 10B.

  FIG. 12 is a diagram showing a flowchart of processing of the SPT deformation module 514. This process corresponds to step 608 in FIG. This process takes SPT as input and outputs SPT.

  In step 1202, if the root node of the SPT is a P node, the SPT transformation module 514 provides an S node as a new root node, and sets the P node that was the original root as a child node of the S node. Also, let X be the set of all x nodes on the SPT with P nodes in the upper level.

  In step 1204, the SPT deformation module 514 determines whether X is an empty set. If it is an empty set, the process ends.

  If X is not an empty set, the process proceeds to step 1206, where the SPT transformation module 514 extracts one element x from X (x is deleted from X).

  In step 1208, the SPT deformation module 514 determines whether the parent of x is S. Otherwise, the SPT transformation module 514 moves to step 1210 with x as the grandfather node and immediately before the parent node. At this time, when moving a node on the SPT, all the children below the child node are also moved.

  In step 1212, the SPT transformation module 514 determines whether there is a P node in the ancestor of x. If so, processing returns to step 1208; otherwise processing returns to step 1204.

  Returning to step 1208, if it is determined that the parent of x is S, the process proceeds to step 1214, where the SPT transformation module 514 has the sum of the weights of the brother nodes of x <the sum of the weights of the brother nodes of x. Determine if there is. Here, the weight of the node on the SPT is the sum of the weights of the leaf nodes below the node. The leaf node is a node on the original DAG, and the node on the DAG is associated with a specific process in the simulation model. The calculation time of the process is set as the weight of the node on the DAG.

  If it is determined that the sum of the weights of the brother nodes of x is less than the sum of the weights of the brother nodes of x, the SPT transformation module 514 determines in step 1216 that the brother nodes and x of x are kept in order and As a child of the grandfather node, the node moves immediately before the grandfather node of x and returns to step 1212. When determining that the sum of the weights of the brother nodes of x is not the sum of the weights of the brother nodes of x, the SPT transformation module 514 determines in step 1218 that the sibling nodes of x and x are maintained in order, and the great-grandfather of x As a child of the node, move immediately after the grandfather node of x, and return to step 1212.

  From step 1212, processing returns to step 1208 or step 1204, depending on the determination made there.

  FIG. 13 is a diagram illustrating an example of modifying the SPT in accordance with the processing of the flowchart illustrated in FIG. That is, in FIG. 13B, it can be seen that there is no P node above the non-coding target block x in the transformed SPT.

  For reference, FIG. 14 is a diagram showing an example in which the SPT (FIG. 14 (a)) converted from the DAG that has not undergone the transformation of the task / graph transformation module 510 is transformed in accordance with the process of the flowchart shown in FIG. is there. In FIG. 14 (b), the P node already exists in the upper part of the non-coding target block x in the modified SPT, but the non-coding target block x is distributed below the top S node. You can see that.

  15 and 16 show a state in the middle of deformation of the SPT. First, as shown in FIG. 15 (a), if the node x of the non-coding target block is directly under P, the transformation process is performed as shown in FIG. 15 (b) or FIG. 15 (c). x is moved as a child node of the grandfather node S before or behind the parent node P. That is, FIG. 15B corresponds to moving the node x behind the parent node P, and FIG. 15C corresponds to moving the node x before the parent node P. This does not violate dependencies.

  Then, the state shifts to a state as shown in FIG. This is a case where the node x is directly under S as shown in FIG. In this case, as shown in FIG. 16 (b) or FIG. 16 (c), the transformation process uses the node x and the preceding node or the succeeding node under the same parent S as children of the great grandfather node S. Is to move in front of or behind the grandfather node P. 16B corresponds to moving the subsequent node after the grandfather node P, and FIG. 16C corresponds to moving the preceding node before the grandfather node P. This does not violate dependencies. At this time, since the workload of the node moving from under P differs depending on the moving direction, the smaller one is selected and moved.

  FIG. 17 is a diagram illustrating a flowchart of processing in which the CPU allocation module 516 generates SPTs corresponding to codes that are individually allocated to a plurality of CPUs based on the modified SPT. This process corresponds to step 610 in FIG. This process takes SPT as input and outputs SPT. In the following, max is the number of available processors or cores.

  In step 1702, the CPU allocation module 516 prepares T as a set of P nodes among the child nodes of the root node of the SPT.

In step 1704, the CPU allocation module 516 determines whether T is an empty set, and if so, ends the process. Otherwise, go to Step 1706 to extract one P node q from T. q is deleted from T. Also, let Y be the set of q and all P nodes under q.
Also, e _max : = 0, U _max : = φ, p _max : = null.

In step 1708, the CPU allocation module 516 determines whether Y is an empty set, otherwise, in step 1710, retrieves one P node p from Y. And p is deleted from Y. Furthermore, an empty set (U ₁ ,... U _n ) corresponding to the number of available processors (n) is prepared, and each child node of p is set to U ₁ ,… U _n so that the weights of each set are as equal as possible. Allocate (use bin packing algorithm etc. for this)
Also, prepare the following variables.
m: = Calculates the sum of the weights of the nodes belonging to each allocated set, and the maximum value among them
sum of weights of all child nodes of e: = p-m
If e _max <e, e _max : = e, U _max = {U ₁ ,…, U _n } and p _max : = p. Thereafter, the processing returns to Step 1708.

Therefore, returning to step 1708, if it is determined that Y is an empty set, the CPU allocation module 516 determines in step 1712 that the leaf node is a lower leaf node of l: = q and not lower than p _max . , P _max is a list of leaf nodes before p _max .
In addition, r: = the lower of the leaf node of q, of the leaf node is not a subordinate of p _max, a list of the back of the leaf node than p _max.
In this way, the CPU allocation module 516 sets the order in the list immediately after q with the leaf node included in l as the child node of the root node and immediately before q with the leaf node included in r as the child node of the root node. Move while maintaining. Then replace q with p _max .
Further, the CPU allocation module 516 performs the following processing.
_Detach the p _max child node (there is no child node once).
For each set U _i that is not empty among the elements of U _max , a new S node is created as a child node of p _max .
The lower leaf nodes of all the nodes included in each U _i are child nodes of the corresponding S node while maintaining the order relation.

When the process of step 1712 is completed, the process returns to step 1704. If T is not an empty set, the process proceeds to step 1706. If it is determined that T is an empty set, the process ends. As a result of this processing, SPT is given to each of U _max = {U ₁ ,..., U _n }.

When this process ends, the output SPT has the following structure.
The root node is the S node. The child node of the root node is the leaf node (that is, the node on the original DAG) or P node. The number of child nodes of the P node is less than or equal to the number of processors n. The child nodes of the P node are all S nodes. Having only leaf nodes as child nodes Since the number of child nodes of all P nodes existing on the SPT is less than or equal to the number of processors, how are the leaf nodes (nodes on the original DAG) below each child node It is a structure that shows whether to allocate to
Among the child nodes of the root node, leaf nodes that are continuous non-x nodes and each P node are one coding unit.

Thus, in step 612 of FIG. 6, the SPT is expanded into code for each of U _max = {U ₁ ,..., U _n }, compiled into an executable file, and assigned to individual processors or cores in step 614. Executed. At this time, the elements of U ₁ ,…, U _n that contain uncoded code must not be compiled into an executable file but executed by the MATLAB (R) / Simulink (R) interpreter. become.

  In the embodiment described above, the task graph is modified so that the non-coding target code is merged before the task graph is converted into the SPT, but this is a desirable process but is not essential. It should be understood that the effect of improving the execution speed of the compilation result can be obtained even if the process of deforming the task graph is omitted.

  The present invention has been described based on the specific embodiments. However, the present invention is not limited to the specific embodiments, and various configurations and techniques such as various modifications and replacements obvious to those skilled in the art can be applied. Please understand that. For example, the present invention is not limited to a specific processor architecture or operating system.

  Further, although the above embodiment has been described by taking MATLAB (R) / Simulink (R) as an example, those skilled in the art will understand that the present invention is not limited to this and can be applied to any modeling tool. Will.

302 Block to be coded 406 Main memory 416 Hard disk drive 502 Simulation modeling tool 504 Model data 508 DAG conversion module 510 Task graph transformation module 512 SPT transformation module 514 SPT transformation module 516 CPU allocation module 518 Compiler 520 execution environment

Claims (13)

A method of parallelizing a code configured by connecting a plurality of blocks including a block to be coded and a block to be coded by computer processing,
Preparing the code as a DAG task graph;
Transforming the task graph into a direct-parallel tree including an S node from which a serial execution node branches and a P node from which a parallel execution node branches;
Transforming the direct-parallel tree into another direct-parallel tree until the P node no longer exists above the non-coding block,
Code parallelization method. Merging the non-coded blocks in the task graph before converting to the direct-parallel tree;
The code parallelization method according to claim 1.   The code parallelization method according to claim 2, wherein the merging of the non-coding target blocks is performed by list scheduling. A method for executing the code generated by the code parallelization method of claim 1 in a multiprocessor environment,
Encoding individual nodes below the P node;
Separately compiling the coded code into executable code;
Assigning and executing the executable code to an individual processor;
Code parallel execution method. A method for executing the code generated by the code parallelization method of claim 1 in a multiprocessor environment having an interpreter for executing the code of the non-coding target block,
Encoding individual nodes below the P node;
Individually compiling into executable code if the coded code does not include the non-coded block;
Assigning and executing the executable code to individual processors;
If the coded code includes the non-coded block, the coded code is executed by the interpreter.
Code parallel execution method. A program for parallelizing a code configured by connecting a plurality of blocks including a non-coding target block and a coding target block by computer processing,
In the computer,
Preparing the code as a DAG task graph;
Transforming the task graph into a direct-parallel tree including an S node from which a serial execution node branches and a P node from which a parallel execution node branches;
Performing the step of transforming the direct-parallel tree into another direct-parallel tree until the P node no longer exists above the non-coding target block;
program. Merging the non-coded blocks in the task graph before converting to the direct-parallel tree;
The program according to claim 6.   The program according to claim 7, wherein the merging of the non-coding blocks is performed by list scheduling. A system for parallelizing a code configured by connecting a plurality of blocks including a block to be coded and a block to be coded by computer processing,
Storage means;
A DAG task graph stored in the storage means;
Means for transforming said task graph into a direct-parallel tree comprising an S node from which a serial execution node branches and a P node from which a parallel execution node branches;
Means for transforming the direct-parallel tree into another direct-parallel tree until the P node no longer exists above the non-coding target block;
Code parallelization system. Means for merging the non-coded blocks in the task graph;
The code parallelization system according to claim 9.   The code parallelization system according to claim 10, wherein the merging of the non-coding blocks is performed by list scheduling. A multiprocessor environment,
Means for encoding individual nodes below the P node;
Means for individually compiling the coded code into executable code;
Means for assigning and executing the executable code to individual processors;
The code parallelization system according to claim 9. A multiprocessor environment having an interpreter for executing the code of the non-coding block;
Means for encoding individual nodes below the P node;
Means for separately compiling into executable code if the coded code does not include the non-coded block;
Means for assigning and executing the executable code to individual processors;
If the encoded code includes the non-coding target block, the encoded code further includes means for executing the encoded code by the interpreter.
The code parallelization system according to claim 9.

Images