A dataflow runtime system for many-core heterogeneous platforms

Abstract

The application discloses a data flow runtime system for a many-core heterogeneous platform, and relates to the field of data flow programming, which comprises a plurality of runtime subsystems; each runtime subsystem comprises a management unit and a calculation unit group; the management unit is used for receiving tasks and the dependency relationship between the tasks, generating a ready task queue, and sending the tasks meeting the dependency in the ready task queue to the calculation unit group according to a calculation unit state array; the calculation unit group comprises a plurality of calculation threads, and the plurality of calculation threads of the same calculation unit group are mapped to a calculation core array of the many-core heterogeneous platform; the calculation unit group is used for executing the tasks issued by the management unit, and releasing the subsequent dependency of the tasks after the execution is completed. The application designs an efficient data flow runtime system for the many-core architecture, and reduces the complexity of data flow programming and cross-platform transplantation under the many-core heterogeneous platform.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data flow programming, and particularly relates to a data flow runtime system for many-core heterogeneous platforms. BACKGROUND

[0002] The data flow model was proposed by Dennis team of MIT in the late 1960s. The core idea is to abstract the entire computing task as a data flow graph. The processing process and flow direction of data flow are divided into a series of fine-grained computing units, and can be described by a directed acyclic graph, as shown in the following formula (1). In the data flow graph, nodes represent computing units, and edges represent the data dependency relationship between nodes. When all the pre-depending dependencies of a computing unit are satisfied, the execution can be started. Figure 1 The data flow model can mine the potential parallelism in the task and can express the program more naturally in a data-centric manner.

[0003] The Codelet program execution model is a fine-grained, task-driven parallel program execution model based on the data flow model, which supports using the data flow model for computing on the control flow machine. The most basic concept is called Codelet, which is composed of a code segment and is the smallest unit that can be scheduled. Codelet contains a dependency count inside, which describes the dependent tasks that need to be completed before the task execution. Codelet tasks and dependencies can form a data flow graph, called Codelet Graph (CDG). In order to better achieve data locality, the model divides the CDG into several sub-CDGs and introduces Thread Procedure (TP) to save the data required by Codelet.

[0004] Current work has designed a programming framework and runtime system based on the Codelet program execution model. The advantage of the data flow programming model is to describe more computing code of decomposable tasks and mine the parallelism therein. However, the existing data flow runtime system is designed for general platforms. Compared with general platforms, many-core platforms have the following characteristics: many-core platforms often contain a large number of cores, and there is heterogeneity between cores, and the concurrency is higher; many-core platforms often have a dedicated parallel programming model, and the memory architecture is more complex; many-core systems often use a heterogeneous computing mode, and computing units can share data through on-chip communication. At the same time, the existing data flow runtime system is designed for shared memory. If you want to enable node communication function, you must follow the process of communication-synchronization-computation, and cannot realize the mutual masking of communication and computation. At the same time, manually implementing the masking of computation and communication will further increase the difficulty and reduce the readability on the basis of the difficulty of data flow programming. Therefore, the existing data flow runtime system cannot be directly transplanted to many-core platforms.

[0005] In summary, there are two main problems in the current data flow framework: (1) only for general platform implementation, and there is no related design and support for many-core heterogeneous platform; (2) only suitable for single-node shared memory model, and there is no corresponding design and optimization for distributed memory communication between multiple nodes. SUMMARY

[0006] The purpose of the present application is to provide a data flow runtime system for many-core heterogeneous platform, which can realize efficient data flow running under many-core heterogeneous platform and reduce the complexity of data flow programming and cross-platform transplantation under many-core heterogeneous platform.

[0007] To achieve the above purpose, the present application provides the following solutions:

[0008] The present application provides a data flow runtime system for many-core heterogeneous platform, comprising a plurality of runtime subsystems; each runtime subsystem comprises a management unit and a calculation unit group;

[0009] The management unit is used for receiving tasks and the dependency relationship between tasks, generating a ready task queue, storing a calculation unit state array, and sending tasks in the ready task queue that meet the dependency to the calculation unit group of the same runtime subsystem according to the calculation unit state array; the calculation unit state array comprises the execution state of each calculation thread;

[0010] The calculation unit group comprises a plurality of calculation threads, and the plurality of calculation threads of the same calculation unit group are mapped to a calculation core array of the many-core heterogeneous platform; the calculation unit group is used for executing the tasks issued by the management unit and releasing the subsequent dependency of the tasks after execution is completed.

[0011] Optionally, the management unit comprises a memory and a scheduler; the memory is used for storing the ready task queue and the calculation unit state array; and the scheduler is used for sending tasks in the ready task queue that meet the dependency to the calculation unit group of the same runtime subsystem according to the calculation unit state array.

[0012] Optionally, the scheduler is further used for detecting the number of tasks in the ready task queue, and when the number of tasks is less than a set threshold, adopting a task stealing strategy to steal tasks from the ready task queue of other management units to balance the number of tasks in the management unit.

[0013] Optionally, the scheduler is further used for actively entering a sleep state when the ready task queue is empty and no tasks can be stolen from the ready task queue of other management units, and waking up and continuing to schedule when new tasks are added to the ready task queue.

[0014] Optionally, the execution state of the computing thread comprises an idle state, a running state and an end state.

[0015] The process that the scheduler sends the task meeting the dependency in the ready task queue to the computing thread group of the same runtime subsystem according to the computing unit state array comprises:

[0016] The scheduler polls the computing unit state array, takes the computing thread in the idle state as a target computing thread, sends the task meeting the dependency in the ready task queue to the target computing thread, and modifies the execution state of the target computing thread in the computing unit state array to the running state.

[0017] When the target computing thread finishes executing the task, the scheduler modifies the execution state of the target computing thread in the computing unit state array to the end state.

[0018] Optionally, the task in the ready task queue comprises a communication task and a normal task; the communication task is used to realize data transmission between runtime subsystems.

[0019] Optionally, each runtime subsystem further comprises an agent unit; the agent unit stores a communication task queue.

[0020] The management unit is further used to judge whether the task meeting the dependency is a communication task, if yes, inserts the communication task into the communication task queue of the agent unit of the same runtime subsystem, and schedules the next task meeting the dependency; if no, sends the task meeting the dependency to the computing thread group of the same runtime subsystem.

[0021] The agent unit is used to poll the communication state bit of the communication task in the communication task queue, and when the communication state bit is transmission complete, releases the subsequent dependency of the communication task.

[0022] Optionally, the management unit is further used to judge whether the task meeting the dependency is a communication task; if the task meeting the dependency is a communication task, judges whether data transmission is complete according to the communication state of the communication task, if yes, releases the subsequent dependency of the communication task, if no, inserts the communication task into the tail of the ready task queue, and schedules the next task meeting the dependency; if the task meeting the dependency is a normal task, sends the task meeting the dependency to the computing thread group of the same runtime subsystem.

[0023] Optionally, each task is mapped to multiple computing threads; each computing thread is used to execute an instance of the task.

[0024] Optionally, each computing unit group corresponds to a delayed release queue, the delayed release queue is used for storing all dependencies released by the computing unit group in the process of executing tasks; the management unit is further used for traversing the delayed release queue corresponding to the computing unit group after the computing unit group of the same runtime subsystem executes the tasks to update the dependency count.

[0025] According to the specific embodiments provided in the application, the following technical effects are disclosed:

[0026] The application provides a data flow runtime system for a many-core heterogeneous platform, designs an efficient data flow runtime system for a many-core architecture, effectively solves the data flow system transplantation problem caused by the many cores and heterogeneity of the many-core platform, and the data flow runtime system comprises a plurality of runtime subsystems, each runtime subsystem comprises a management unit and a computing unit group, a user only needs to implement a computing task logic and build a data flow graph, the management unit sends tasks meeting dependencies to the computing unit group for execution according to the tasks and the dependency relationship between the tasks, the data flow runtime system can be quickly adapted on a plurality of hardware platforms, the universality of the data flow runtime system is improved, the complexity of data flow programming and cross-platform transplantation under the many-core heterogeneous platform is reduced, and the efficiency of data flow running under the many-core heterogeneous platform is improved. BRIEF DESCRIPTION OF DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the drawings needed in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0028] Figure 1 is a schematic diagram of a data flow graph;

[0029] Figure 2 is a structural schematic diagram of a data flow runtime system for a many-core heterogeneous platform provided by an embodiment of the application;

[0030] Figure 3 is a schematic diagram of a proxy thread auxiliary scheduling strategy provided by an embodiment of the application;

[0031] Figure 4 is a schematic diagram of communication task adaptive scheduling provided by an embodiment of the application;

[0032] Figure 5 is an execution schematic diagram of node communication and computing automatic masking provided by an embodiment of the application;

[0033] Figure 6 is a schematic diagram of a multi-instance task provided by an embodiment of the application;

[0034] Figure 7 A schematic diagram of a delay release strategy provided for an embodiment of the present application;

[0035] Figure 8 A flowchart of an implementation provided for an embodiment of the present application;

[0036] Figure 9 A schematic diagram of a traditional traversal mode;

[0037] Figure 10 A schematic diagram of a traversal mode from a core cluster priority. DETAILED DESCRIPTION

[0038] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0039] The present application faces the data stream parallel optimization practice scene of software on a many-core heterogeneous platform, and provides a high-performance and easy-to-program data stream runtime system for the many-core heterogeneous platform, to realize the programming framework design and runtime system scheduling design on the many-core heterogeneous platform.

[0040] The above purposes, features and advantages of the present application can be more apparent and easy to understand. The present application will be described in further detail below with reference to the drawings and specific embodiments.

[0041] In an exemplary embodiment, a data stream runtime system for a many-core heterogeneous platform is provided, including a plurality of runtime subsystems. As shown in Figure 2 each runtime subsystem includes a management unit and a calculation unit group. In the present application, each runtime subsystem includes one or more management units and one or more calculation unit groups. The number of management units of each runtime subsystem is the same as the number of calculation unit groups, and one management unit corresponds to one calculation unit group.

[0042] The calculation unit group includes a plurality of calculation threads, and the plurality of calculation threads of the same calculation unit group are mapped to a calculation core array of the many-core heterogeneous platform. The calculation unit group is used to execute the task issued by the management unit, and release the subsequent dependencies of the task after execution is completed.

[0043] The many-core heterogeneous platform includes a plurality of shared memory nodes, each of which includes a management core and a computing core array, and the computing core array includes a plurality of computing threads. Each runtime subsystem is mapped to a shared memory node, and a management unit of the runtime subsystem corresponds to the management core of the shared memory node, and a computing unit group of the runtime subsystem corresponds to the computing core array of the shared memory node.

[0044] The management unit is a management thread. The management unit mainly completes task scheduling, task resource allocation and recovery, inter-node communication and the like. The computing unit group mainly completes task computation and implements dependency relationship maintenance of a downstream task after computation. A user abstracts an application into a plurality of tasks (such as vector computation) and dependency relationships among the tasks through an interface provided by a runtime framework, and sends the tasks to the management unit. The management unit adopts a scheduling strategy and a load balancing method to send tasks meeting a dependency to a corresponding computing unit group to start computation.

[0045] The dependency of a task refers to that a dependency count of a next task needs to be reduced by one after a certain task is executed, for example, if a multiplication and addition operation needs to be completed, two tasks A and B are generated, task A is responsible for completing multiplication, and task B is responsible for completing addition. Task B must wait for the multiplication operation of task A to be completed before it can start execution, thus producing a dependency between tasks: A->B. Therefore, after task A is executed on the computing unit group, the A->B dependency needs to be released, and task B can execute the addition operation.

[0046] The management unit is configured to receive tasks and dependency relationships among the tasks, generate a ready task queue, store a computing unit state array, and send tasks meeting a dependency in the ready task queue to a computing unit group of a same runtime subsystem according to the computing unit state array. That is, the management unit sends tasks meeting a dependency in its ready task queue to its corresponding computing unit group.

[0047] Since the management unit and the computing unit are often heterogeneous on the many-core platform, the management unit is designed to schedule ready tasks to the computing unit group, such as the process ① in the following. Figure 2

[0048] The tasks in the ready task queue include communication tasks and ordinary tasks. The communication tasks are used to realize data transmission between runtime subsystems. The transmitted data is specified by a user, for example, for a stencil computation mode, a boundary region calculated by each runtime subsystem needs to be provided with related data by a neighbor subsystem. The ready task queue is used to store executable tasks. Each task in the ready task queue retains a flag bit, which is used to identify whether the task is an ordinary task or a communication task.

[0049] ​The computing unit state array includes execution states of each computing thread. The execution state of the computing thread includes an idle state, a running state and an end state.

[0050] In the present application, the management unit includes a memory and a scheduler. The memory is used to store a ready task queue and a computing unit state array. The scheduler is used to send tasks in the ready task queue that meet the dependencies to a computing unit group of the same runtime subsystem according to the computing unit state array. The role of the scheduler is to schedule the ready tasks to the computing threads when the resources of the computing threads are idle.

[0051] Specifically, the scheduler polls the computing unit state array, takes the computing thread in the idle state as a target computing thread, sends the tasks in the ready task queue that meet the dependencies to the target computing thread, and modifies the execution state of the target computing thread in the computing unit state array to the running state. When the target computing thread finishes the task execution, the scheduler modifies the execution state of the target computing thread in the computing unit state array to the end state.

[0052] In actual runtime, the scheduler first detects whether there is a task in the ready task queue. When there is a task to be scheduled, the scheduler polls the computing unit state array to find a computing thread in the idle state, allocates the task to the computing thread, and modifies the state of the computing thread to the running state. When the computing thread finishes the calculation, i.e., the scheduler finds a computing thread in the end state, the scheduler modifies the corresponding computing unit state array and recovers the resources and reallocates.

[0053] Further, the scheduler is also used to detect the number of tasks in the ready task queue, and when the number of tasks is less than a set threshold, a task stealing strategy is adopted to steal tasks from the ready task queue of other management units (other management units of the same runtime subsystem) to balance the number of tasks in the management units. That is, the scheduler adds the tasks in the ready task queue of other management units of the same runtime subsystem to its own ready task queue, such as the process ② in Figure 2 .

[0054] Further, the scheduler is also used to actively enter the sleep state when the ready task queue is empty and no tasks can be stolen from the ready task queue of other management units, and is woken up and continues to schedule when new tasks are added to the ready task queue. Specifically, when the ready task queue is empty and all computing threads finish the calculation and no tasks can be stolen from other management units, the scheduler actively enters the sleep state, such as the process ③ in Figure 2 , and is woken up and continues to schedule when new tasks are added to the ready task queue. Further, useless polling is reduced, and more resources are given to other tasks.

[0055] The management unit adopts the scheduling and management strategy as above, can correctly and efficiently schedule the tasks to be executed to the computing unit groups, the task stealing strategy realizes the load balancing in the runtime subsystem, and ensures the maximum utilization of the computing resources; and the sleep mechanism also realizes the sleep of the management unit in the idle time, gives more computing resources to the computing tasks, so as to realize the rapid advancement of the computing tasks.

[0056] In order to further improve the performance of the data flow runtime system, the application also optimizes the communication task scheduling between the runtime subsystems, and the runtime subsystems perform data transmission through the message passing interface (MPI) communication mode.

[0057] The application designs an automatic masking strategy taking the communication task as the core. Each communication task contains a communication state bit, which is used to indicate whether the asynchronous communication between the runtime subsystems is completed. Each communication task corresponds to an asynchronous communication of MPI, and when the asynchronous communication is completed, the MPI callback function modifies the communication state bit of the communication task, indicating that the asynchronous communication is completed. Each communication task also contains an execution function, which is used to execute the subsequent process after the transmission is completed. The execution logic of the communication task is the same as that of the ordinary task, and the communication task is created only after the front-end dependency is released.

[0058] The application adopts the following two methods to add communication task scheduling support to the data flow runtime system:

[0059] (1) Adopting an agent thread auxiliary scheduling strategy.

[0060] As shown in Figure 3 , each runtime subsystem also includes an agent unit. The agent unit stores a communication task queue. The agent unit includes an agent thread and an auxiliary scheduler.

[0061] The management unit is also used to judge whether the task meeting the dependency is a communication task, if yes, the communication task is inserted into the communication task queue of the agent unit of the same runtime subsystem, and the next task meeting the dependency is scheduled; if not, the task meeting the dependency is sent to the computing unit group of the same runtime subsystem.

[0062] The agent unit is used to poll the communication state bit of the communication task in the communication task queue, and when the communication state bit is transmission completed, the subsequent dependency of the communication task is released.

[0063] The agent thread completes the task state detection, and when the management unit detects and discovers the executable communication task, the communication is started, and the communication task is inserted into the communication task queue of the agent thread, as shown in Figure 3In the middle ② process, the auxiliary scheduler in the agent unit is responsible for constantly polling the communication state bit of the task in the communication task queue, and when the communication state bit shows that the transmission is completed, the subsequent logic (such as MPI resource release) of the communication task is executed, and the subsequent dependency is released. Figure 3 In the middle ① process, when the communication state bit shows that the transmission is completed, the subsequent logic (such as MPI resource release) of the communication task is executed, and the subsequent dependency is released.

[0064] This method is suitable for scenarios where communication is frequent and small object communication is more common. The overhead of small object communication is large because the data volume is too small and the transmission frequency is high, so adding an agent thread can use various optimization methods such as communication aggregation and underlying communication optimization, thereby greatly reducing the overhead.

[0065] (2) Communication task adaptive scheduling strategy.

[0066] As shown in Figure 4 , the management unit is also used to judge whether the task meeting the dependency is a communication task; if the task meeting the dependency is a communication task, it is judged according to the communication state bit of the communication task whether the data transmission is completed, if yes, the subsequent dependency of the communication task is released, if no, the communication task is inserted into the tail of the ready task queue, and the next task meeting the dependency is scheduled; if the task meeting the dependency is a normal task, the task meeting the dependency is sent to the computing unit group of the same runtime subsystem.

[0067] Under this strategy, the execution process of the communication task contains two stages: the transmission stage and the execution stage. When the communication task is created, the inter-process communication specified by the user will be automatically started and enter the transmission stage. When the management unit detects the communication task, the process in Figure 4 ①, first, the communication state bit is detected to determine whether the communication task has been completed, if yes, the subsequent logic (such as MPI resource release) is scheduled for execution, and the downstream dependency is released; if no, the communication task is re-queued and the next task is executed, as in Figure 4 ② process.

[0068] This method is suitable for scenarios where the communication data volume is large. For MPI communication with a large communication volume, using multiple threads to simultaneously perform data transmission and detection can more quickly advance the application execution process, thereby achieving better performance.

[0069] The application further designs a communication method selection strategy. The overhead of the communication task adaptive scheduling strategy is slightly higher than that of the agent thread auxiliary scheduling strategy because each management unit performs MPI communication, so the agent thread auxiliary scheduling strategy is adopted by default. When the scheduler detects a communication task with a large communication volume, the communication task adaptive scheduling strategy is automatically switched to meet the transmission resource overhead required by the large communication volume.

[0070] The application optimizes the communication between runtime subsystems. When data transmission is completed, the data flow runtime system can automatically schedule tasks that depend on the data to the computing unit group for calculation without waiting for other data transmission to complete, thereby completing automatic communication and calculation masking transparent to users. The process is as shown in Figure 5 When the data transmission synchronization is broken, the program can proceed with execution faster, thereby achieving higher performance.

[0071] In order to improve the data transmission speed between computing threads, the application also provides a multi-instance task based on on-chip high-speed communication and designs a runtime scheduling strategy. As shown in Figure 6 The application allows users to create multi-instance tasks, each of which is mapped to multiple computing threads of the computing core array of the many-core heterogeneous platform. Each computing thread is used to execute an instance of the task, as shown in Figure 6 Each instance has a unique logical number, which is specified when the task is created, and users distinguish different instances through the logical number. When on-chip communication is performed, the data flow runtime system stores the logical number of each instance and the physical information that each instance runs on which computing thread. Therefore, according to the logical number specified by the user, the data flow runtime system can automatically map the destination to the physical logical number and start high-speed transmission between computing threads.

[0072] In the data flow idea, the maintenance of the dependency relationship between tasks is an important factor to ensure the correct and efficient operation of the application. However, the many-core heterogeneous platform often has different instruction sets, different support granularities of atomic operations, etc., which leads to the fact that even under shared memory, atomic operations cannot be used on the same memory address. Therefore, after the computing thread is executed, how to realize the correct update of the dependency is a difficult problem on the many-core heterogeneous platform.

[0073] In the existing design of the data flow framework, the runtime system uses a signal mechanism to complete dependency maintenance. Specifically, when the computing unit group needs to perform atomic operations on the dependency, it will explicitly send a signal to the management unit and pass in the address of the task to be released; when the management unit receives the signal, it enters the interrupt processing function and completes the atomic update instead of the computing unit group. However, the management unit will inevitably be in a non-reentrant function, which will cause undefined behavior.

[0074] Therefore, the application designs a dependency delayed release strategy. The strategy delays the update time of the dependency count and completes the update by the management unit instead of the computing unit group. The process is as shown in Figure 7

[0075] ​This application additionally creates a delayed release queue for each computing unit group; that is, each computing unit group corresponds to one delayed release queue. This delayed release queue is used to store all dependencies released by the computing unit group during task execution. When a computing unit group releases dependencies on certain tasks, such as... Figure 7 In step ①, the pointer corresponding to the task will be inserted into the delayed release queue, such as... Figure 7 The management unit performs process ②, rather than actually atomically updating dependencies. It is also used to update dependency counts by traversing the delayed release queues corresponding to the computing unit groups after the computing unit groups within the same runtime subsystem have completed their tasks. Specifically, when the computing unit group finishes computation and the management unit reclaims resources, the corresponding scheduler will traverse the task release queues of the computing unit group and update the dependency counts, such as... Figure 7 The process is described in step ③. If all dependencies of a task are satisfied after release, the scheduler will insert the task into the ready task queue.

[0076] Because many-core platforms suffer from the amorphous relationship between computing unit groups and management units, a dependency delay release strategy solves the problem of correctly releasing dependencies between computing unit groups with minimal impact on performance. This dependency delay release strategy can be used to correctly maintain dependencies for different many-core platform backends.

[0077] To better understand the solution in this application, the following will be combined with... Figure 8 This document provides a detailed introduction to the specific application process of the dataflow programming framework and runtime system for many-core heterogeneous platforms.

[0078] Step 1: Building the front-end user task.

[0079] When using the framework on a heterogeneous platform with many cores, users need to build the front-end tasks. For applications that need to be streamed, users use the unified programming interface provided in this application to abstract the application into several context structures, computational subtasks, communication tasks, etc., and specify the data dependencies between tasks. After completing the task construction, users send the data to the data streaming runtime system through a specific interface.

[0080] Step 2: System abstraction and scheduling during data flow runtime.

[0081] The data flow runtime system first abstracts the user-provided task into a fine-grained data flow graph and waits for the management unit to execute the scheduling task according to the task. Each runtime subsystem runs multiple management units, and each management unit is responsible for the state detection and task allocation of a computing unit group. The management unit maintains a ready task queue to save the ready tasks and sends the tasks to the computing thread to start the calculation when the computing resources are available. At the same time, in order to balance the load in the runtime subsystem, each management unit actively steals tasks from the ready task queue of other management units and schedules the execution when there is no task in the ready task queue.

[0082] Each management unit is also responsible for dynamically detecting and maintaining the MPI communication state to complete the communication between the runtime subsystems. For communication tasks, the management unit will detect whether the asynchronous transmission is completed when identifying, and select to execute the task or insert the task into the queue again according to the result.

[0083] Step three: the hardware resource mapping of the data flow runtime system.

[0084] The hardware cores of the many-core heterogeneous platform are divided into two parts: management cores and computing core arrays in the present application. In a shared memory node, the management cores and the computing core arrays in the same non-uniform memory access (NUMA) region are divided into a group, and each group runs one management thread and one computing thread in the management core, and one computing thread in the computing core. The management threads between the groups in the shared memory node can complete the management cooperation such as task stealing and load balancing through the shared memory. The shared memory nodes are connected by an interconnection network to support the MPI tasks and the task migration between nodes in the upper layer.

[0085] In a specific example, the data flow runtime system provided by the present application is mapped to a new generation of ShenWei many-core heterogeneous platform.

[0086] The new generation of ShenWei many-core heterogeneous platform integrates a multi-core processor and a dedicated accelerator, aiming to improve the computing power and energy efficiency, and is widely used in scientific computing and engineering simulation fields. The platform adopts a master-slave core architecture, that is, there are six master cores and 384 slave core arrays on a chip, and the master-slave cores are heterogeneous and share memory in a shared memory manner.

[0087] The mapping of the data flow runtime system provided by the present application to ShenWei is as follows: each runtime subsystem uses six management threads, each of which runs on a master core and is responsible for managing 64 slave cores of the master core; each slave core runs a computing thread to execute the tasks scheduled by the management thread.

[0088] For the scheduling strategy, since there are multiple-instance tasks in the application, it is necessary to design a traversal method for the on-chip communication characteristics of the Godson many-core. In order to more efficiently utilize the high-speed remote memory access (RMA) transmission between the core clusters, the traversal method of the data flow runtime system is converted from the traditional traversal according to the slave core logic number to preferentially filling a slave core cluster, as shown in Figure 9 and Figure 10 The traversal method will preferentially traverse within the slave core cluster, and will first fill the same high-speed communication domain in the face of single-instance tasks, so that when a multiple-instance task is detected, there is a greater opportunity to directly transmit to the entire slave core cluster.

[0089] The application converts the slave core physical location index provided by the Godson library into the slave core cluster priority index through simple bit operations, and the conversion method is:

[0090] spcid = (tid & 0x31) | ((tid & 0x6) << 1) | ((tid & 0x8) >> 2) | (tid & ~0b111111) ;

[0091] tid = (spcid & 0x31) | ((spcid & 0xc) >> 1) | ((spcid & 0x2) << 2) | (spcid & ~0b111111) ;

[0092] Wherein, tid is the slave core location index, and spcid is the slave core cluster priority index.

[0093] Therefore, when a user uses the data flow runtime system provided by the application on a new generation Godson many-core heterogeneous platform, only the dependencies between tasks and tasks need to be written, which can be sent to the back end for efficient scheduling by the data flow runtime system provided by the application.

[0094] Compared with the prior art, the beneficial effects of the application at least include the following points:

[0095] (1) Support for many-core architecture: the application designs an efficient data flow runtime system for many-core architecture, effectively solving the data flow system porting problem caused by the core multiple and heterogeneity of many-core platform.

[0096] (2) Effective cross-platform adaptability: the front end of the application uses a unified programming interface, and the user does not need to consider the back-end parallel programming model of the many-core platform, only needs to implement the computing task logic and build a data flow graph. The data flow runtime system will automatically schedule the data flow graph, and adopt different scheduling strategies for different back-ends, so that it can quickly adapt to and improve the performance on multiple hardware platforms.

[0097] (3) Multi-level communication optimization: at the communication level between runtime subsystems, the application data flows the communication flow through the communication task, and automatically realizes the mutual masking of communication and calculation; at the on-chip network level within a single node, the application can effectively support the on-chip network communication (such as RMA) provided by the many-core architecture through multi-instance tasks, improve the sharing between tasks, increase data reuse, and further reduce memory access delay while ensuring programmability and readability.

[0098] Overall, the application provides a programming framework and corresponding data flow runtime system for many-core heterogeneous architecture in the aspect of data flow programming. Through a unified programming interface, efficient communication mechanism and functional support, the application realizes efficient adaptation of the data flow runtime system and the back-end architecture, and significantly reduces the programming difficulty of users.

[0099] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant regulations.

[0100] Any reference to memory, database or other medium used in each embodiment provided by the application can include at least one of non-volatile and volatile memory. The non-volatile memory can include read-only memory (Read-Only Memory, ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive memory (ReRAM), magnetoresistive random access memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric memory (Ferroelectric Random Access Memory, FRAM), phase change memory (Phase Change Memory, PCM), graphene memory, etc. The volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, etc. As an illustration but not limitation, the RAM can be in various forms, such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), etc.

[0101] The database involved in each of the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a blockchain, and the like, without being limited thereto. The processor involved in each of the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, and the like, without being limited thereto.

[0102] The technical features of the above embodiments can be combined in any manner. To make the description concise, all possible combinations of the technical features in the above embodiments are not described, but it should be considered that any combination of the technical features is within the scope of the present disclosure, as long as there is no contradiction.

[0103] The principles and implementation manners of the present application are described by using specific examples herein, and the above embodiments are only used to help understand the method of the present application and its core idea. Meanwhile, for those skilled in the art, the specific implementation manners and application ranges can be changed according to the idea of the present application. In summary, the content of the present description should not be understood as a limitation of the present application.

Claims

1. A dataflow runtime system for a many-core heterogeneous platform, characterized in that, The data flow runtime system for the many-core heterogeneous platform comprises a plurality of runtime subsystems; each runtime subsystem comprises a management unit, a computing unit group and an agent unit; the agent unit stores a communication task queue; The management unit is configured to receive tasks and dependencies between the tasks, generate a ready task queue, store a computing unit state array, and send tasks meeting the dependencies in the ready task queue to the computing unit group of the same runtime subsystem according to the computing unit state array; the computing unit state array comprises the execution state of each computing thread; the computing unit group comprises a plurality of computing threads, and the plurality of computing threads of the same computing unit group are mapped to a computing core array of the many-core heterogeneous platform; the computing unit group is configured to execute the tasks assigned by the management unit and release the subsequent dependencies of the tasks after execution is completed; The tasks in the ready task queue comprise communication tasks and normal tasks; the communication tasks are configured to realize data transmission between the runtime subsystems; The management unit is further configured to determine whether the task meeting the dependencies is a communication task, and if so, insert the communication task into the communication task queue of the agent unit of the same runtime subsystem, and schedule the next task meeting the dependencies; if not, send the task meeting the dependencies to the computing unit group of the same runtime subsystem; The management unit is further configured to determine whether the task meeting the dependencies is a communication task; if the task meeting the dependencies is a communication task, determine whether data transmission is completed according to the communication state bit of the communication task, and if so, release the subsequent dependencies of the communication task, and if not, insert the communication task into the tail of the ready task queue, and schedule the next task meeting the dependencies; if the task meeting the dependencies is a normal task, send the task meeting the dependencies to the computing unit group of the same runtime subsystem; The agent unit is configured to poll the communication state bit of the communication task in the communication task queue, and release the subsequent dependencies of the communication task when the communication state bit is transmission completed.

2. The many-core heterogeneous platform oriented dataflow runtime system of claim 1, wherein, The management unit comprises a memory and a scheduler; The memory is configured to store the ready task queue and the computing unit state array; The scheduler is configured to send the tasks meeting the dependencies in the ready task queue to the computing unit group of the same runtime subsystem according to the computing unit state array.

3. The many-core heterogeneous platform oriented dataflow runtime system of claim 2, wherein, The scheduler is further configured to detect the number of tasks in the ready task queue, and when the number of tasks is less than a set threshold, adopt a task stealing strategy to steal tasks from the ready task queue of other management units, so as to balance the number of tasks in the management units.

4. The many-core heterogeneous platform oriented dataflow runtime system of claim 3, wherein, The scheduler is further configured to actively enter a sleep state when the ready task queue is empty and no tasks can be stolen from the ready task queue of other management units, and wake up and continue scheduling when new tasks are added to the ready task queue.

5. The many-core heterogeneous platform oriented dataflow runtime system of claim 2, wherein, The execution state of the computing thread comprises an idle state, a running state and an end state; The process that the scheduler sends the tasks meeting the dependency in the ready task queue to the same computing unit group of the runtime subsystem according to the computing unit state array specifically comprises: The scheduler polls the computing unit state array, takes the computing thread in the idle state as a target computing thread, sends the tasks meeting the dependency in the ready task queue to the target computing thread, and modifies the execution state of the target computing thread in the computing unit state array to the running state; When the task execution of the target computing thread is completed, the scheduler modifies the execution state of the target computing thread in the computing unit state array to the end state.

6. The many-core heterogeneous platform oriented dataflow runtime system of claim 1, wherein, Each task is mapped to a plurality of computing threads; and each computing thread is used for executing an instance of the task.

7. The many-core heterogeneous platform oriented dataflow runtime system of claim 1, wherein, Each computing unit group corresponds to a delayed release queue, and the delayed release queue is used for storing all dependencies released by the computing unit group in the process of executing the task. The management unit is also used for, after the computing unit group of the same runtime subsystem completes the task execution, traversing the delayed release queue corresponding to the computing unit group to update the dependency count.

Images