Data stream runtime system oriented to many-core heterogeneous platform

Abstract

The invention discloses a data stream runtime system oriented to a many-core heterogeneous platform, and relates to the field of data stream programming, the system 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 the tasks and the dependency relationship between the tasks, generating a ready task queue, and sending the tasks meeting dependency in the ready task queue to the computing unit group according to the computing unit state array; each 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; and the calculation unit group is used for executing the task issued by the management unit and releasing the subsequent dependency of the task after the execution is completed. According to the invention, an efficient data stream runtime system is designed for a many-core architecture, and the complexity of data stream programming and cross-platform transplantation under a many-core heterogeneous platform is reduced.

Description

Technical Field

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

[0002] The data flow model was proposed by Dennis' team at MIT in the late 1960s. Its core idea is to abstract the entire computing task into a data flow graph. The processing and direction of the data flow are divided into a series of fine-grained computing units, which can be described by a directed acyclic graph, such as Figure 1 As shown in the figure. In the data flow graph, nodes represent computing units, and edges represent data dependencies between nodes. When all the pre-dependencies of a computing unit are satisfied, execution can begin. The data flow model can mine the potential parallelism in tasks and can express programs more naturally with data as the center.

[0003] The codelet program execution model is a fine-grained, task-driven parallel program execution model based on the data flow model, which supports the use of data flow models for calculations on control flow machines. Its most basic concept is called Codelet, which consists of a code snippet and is the smallest unit that can be scheduled. Codelet contains a dependency count to describe the dependent tasks that need to be completed before the task is executed. Codelet tasks and dependencies can form a data flow graph called a codelet graph (CDG). In order to better achieve data locality, the model divides the CDG into several sub-CDGs and introduces a thread procedure (TP) to save the data required by the codelet.

[0004] In current work, there are programming frameworks and runtime systems designed based on the codelet program execution model. The advantage of the data flow programming model is that it can describe more computational codes that can be decomposed into tasks and exploit 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 the cores, and the concurrency is higher; many-core platforms often have dedicated parallel programming models, and the memory architecture is also more complex; many-core systems often adopt heterogeneous computing modes, 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 the communication function between nodes, you must use the communication-synchronization-computation process, and it is impossible to achieve mutual concealment of communication and computation. At the same time, manually realizing the concealment of computation and communication will further increase the difficulty and reduce readability on the basis of the difficulty of data flow programming. Therefore, the existing data flow runtime system cannot be directly ported to the many-core platform.

[0005] In summary, the current data flow framework has two major problems: (1) it is only implemented for general platforms, but has no relevant design and support for many-core heterogeneous platforms; (2) it is only applicable to single-node shared memory models, and has no corresponding design and optimization for distributed memory communication between multiple nodes. Summary of the invention

[0006] The purpose of this application is to provide a data flow runtime system for many-core heterogeneous platforms, which can achieve efficient data flow operation on many-core heterogeneous platforms and reduce the complexity of data flow programming and cross-platform porting on many-core heterogeneous platforms.

[0007] To achieve the above objectives, this application provides the following solutions:

[0008] The present application provides a data flow runtime system for a many-core heterogeneous platform, including multiple runtime subsystems; each runtime subsystem includes a management unit and a computing unit group;

[0009] The management unit is used to receive tasks and dependencies between tasks, generate a ready task queue, store a computing unit state array, and send the tasks that meet 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 includes the execution state of each computing thread;

[0010] The computing unit group includes several computing threads, and several computing threads of the same computing unit group are mapped to a computing core array of a many-core heterogeneous platform; the computing unit group is used to execute the tasks issued by the management unit and release the subsequent dependencies of the tasks after the execution is completed.

[0011] Optionally, the management unit includes a memory and a scheduler; the memory is used to store a ready task queue and a computing unit status array; the scheduler is used to send the tasks that meet the dependencies in the ready task queue to the computing unit group of the same runtime subsystem according to the computing unit status array.

[0012] Optionally, the scheduler is further 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 used to steal tasks from the ready task queues of other management units to balance the number of tasks in the management units.

[0013] Optionally, the scheduler is further configured to actively enter a sleep state when the ready task queue is empty and cannot steal tasks from the ready task queues of other management units, and wake up and continue scheduling when a new task is added to the ready task queue.

[0014] Optionally, the execution state of the computing thread includes an idle state, a running state and a terminated state;

[0015] The process of the scheduler sending the tasks satisfying the dependencies in the ready task queue to the computing unit group of the same runtime subsystem according to the computing unit state array specifically includes:

[0016] The scheduler polls the computing unit state array, takes the computing thread in the idle state as the target computing thread, sends the tasks that meet 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 task of the target computing thread is executed, the scheduler modifies the execution state of the target computing thread in the computing unit state array to a finished state.

[0018] Optionally, the tasks in the ready task queue include communication tasks and common tasks; the communication tasks are used to implement data transmission between runtime subsystems.

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

[0020] The management unit is also used to determine whether the task that meets the dependency is a communication task. If so, insert the communication task into the communication task queue of the proxy unit of the same runtime subsystem and schedule the next task that meets the dependency; if not, send the task that meets the dependency to the computing unit group of the same runtime subsystem;

[0021] The proxy unit is used to poll the communication status bit of the communication task in the communication task queue, and when the communication status bit indicates that the transmission is completed, release the subsequent dependency of the communication task.

[0022] Optionally, the management unit is also used to determine whether the task that meets the dependency is a communication task; if the task that meets the dependency is a communication task, then determine whether the data transmission is completed based on the communication status of the communication task; if completed, release the subsequent dependency of the communication task; if not completed, insert the communication task at the tail of the ready task queue and schedule the next task that meets the dependency; if the task that meets the dependency is an ordinary task, then send the task that meets the dependency to the computing unit group of the same runtime subsystem.

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

[0024] Optionally, each computing unit group corresponds to a delayed release queue, which is used to store all dependencies released by the computing unit group during the execution of the task; the management unit is also used to traverse the delayed release queue corresponding to the computing unit group after the computing unit group of the same runtime subsystem completes the execution of the task, and update the dependency count.

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

[0026] The present application provides a data flow runtime system for many-core heterogeneous platforms, designs an efficient data flow runtime system for many-core architectures, and effectively solves the data flow system transplantation problem caused by the multi-core and heterogeneous nature of the many-core platform. The data flow runtime system includes multiple runtime subsystems, each of which includes a management unit and a computing unit group. Users only need to implement the computing task logic and build a data flow graph. The management unit sends the tasks that meet the dependencies to the computing unit group for execution based on the tasks and the dependencies between the tasks. It can be quickly adapted to a variety of hardware platforms, thereby improving the versatility of the data flow runtime system, reducing the complexity of data flow programming and cross-platform transplantation under many-core heterogeneous platforms, and improving the efficiency of data flow operation under many-core heterogeneous platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

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

[0029] Figure 2 A schematic diagram of the structure of a data flow runtime system for a many-core heterogeneous platform provided in one embodiment of the present application;

[0030] Figure 3 A schematic diagram of a proxy thread assisted scheduling strategy provided in an embodiment of the present application;

[0031] Figure 4 A schematic diagram of adaptive scheduling of communication tasks provided in one embodiment of the present application;

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

[0033] Figure 6 A schematic diagram of a multi-instance task provided in an embodiment of the present application;

[0034] Figure 7 A schematic diagram of a delayed release strategy provided in one embodiment of the present application;

[0035] Figure 8 An implementation flow chart provided for an embodiment of the present application;

[0036] Fig. 9 This is a schematic diagram of the traditional traversal method;

[0037] Fig.10 Schematic diagram of the core cluster-first traversal method. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0039] This application is aimed at the practical scenario of data flow parallel optimization of software on many-core heterogeneous platforms, and provides a high-performance, easy-to-program data flow runtime system for many-core heterogeneous platforms, realizing the programming framework design and runtime system scheduling design on the many-core heterogeneous platforms.

[0040] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

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

[0042] The computing unit group includes several computing threads, and the 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 used to execute the task issued by the management unit and release the subsequent dependency of the task after the execution is completed.

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

[0044] The management unit is the management thread. The management unit mainly completes the functions of task scheduling, task resource allocation and recycling, and inter-node communication. The computing unit group mainly completes task calculations and maintains the dependencies of downstream tasks after the calculations are completed. Users abstract the application into several tasks (such as vector calculations, etc.) and the dependencies between tasks through the interface provided by the runtime framework, and send them to the management unit. The management unit adopts scheduling strategies and load balancing methods to send the tasks that meet the dependencies to the corresponding computing unit group to start calculations.

[0045] Task dependency refers to the need to reduce the dependency count of the next task by one after a 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 the multiplication operation, and Task B is responsible for completing the addition operation. Task B must wait for the multiplication operation of Task A to be completed before it can start executing, thus generating 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 before Task B can perform the addition operation.

[0046] The management unit is used to receive tasks and dependencies between tasks, generate a ready task queue, store a computing unit state array, and send the tasks that meet the dependencies in the ready task queue to the computing unit group of the same runtime subsystem according to the computing unit state array. That is, the management unit sends the tasks that meet the dependencies 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 in this application is responsible for scheduling the ready tasks to the computing unit group, such as Figure 2 ① process in.

[0048] Among them, the tasks in the ready task queue include communication tasks and ordinary tasks. The communication task is used to realize data transmission between runtime subsystems. The transmitted data is specified by the user. For example, for the stencil calculation mode, the boundary area that each runtime subsystem is responsible for calculating requires the neighbor subsystem to provide relevant data. The role of the ready task queue is to store executable tasks. Each task in the ready task queue reserves a flag bit to identify whether this task is an ordinary task or a communication task.

[0049] The computing unit state array includes the execution state of each computing thread. The execution state of the computing thread includes an idle state, a running state and a terminated 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 status array. The scheduler is used to send the tasks that meet the dependencies in the ready task queue to the computing unit group of the same runtime subsystem according to the computing unit status array. The function of the scheduler is to schedule the ready tasks to the computing thread when the resources of the computing thread are idle.

[0051] Specifically, the scheduler polls the computing unit state array, takes the computing thread in the idle state as the target computing thread, sends the tasks that meet 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 of the target computing thread is executed, the scheduler modifies the execution state of the target computing thread in the computing unit state array to the ending state.

[0052] In actual operation, the scheduler first checks whether there are tasks in the ready task queue. When there are tasks to be scheduled, the scheduler polls the computing unit state array to find a computing thread in the idle state, and assigns tasks to the computing thread, changing its state to the running state; when the computing thread is finished, that is, when the scheduler finds a computing thread in the end state, the scheduler will modify its corresponding computing unit state array and recycle and reallocate resources.

[0053] Furthermore, the scheduler is also used to detect the number of tasks in the ready task queue. When the number of tasks is less than a set threshold, the scheduler adopts a task stealing strategy to steal tasks from the ready task queues 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 tasks in the ready task queues of other management units of the same runtime subsystem to its own ready task queue, such as Figure 2 ② process in .

[0054] Furthermore, the scheduler is also used to actively enter a sleep state when the ready task queue is empty and cannot steal tasks from the ready task queues of other management units, and wake up and continue scheduling when a new task is added to the ready task queue. Specifically, when the ready task queue is empty, all computing threads have completed computing and cannot steal tasks from other management units, the scheduler will actively enter a sleep state, such as Figure 2 In the process ③, it will not wake up and continue scheduling until a new task is added to the ready task queue. This will reduce useless polling and give more resources to other tasks.

[0055] The management unit adopts the above scheduling and management strategies to correctly and efficiently schedule the tasks to be executed to the computing unit group. The task stealing strategy realizes the load balancing within the runtime subsystem to ensure the maximum utilization of computing resources. The sleep mechanism also enables the management unit to sleep during idle time, giving more computing resources to computing tasks to achieve rapid advancement of computing tasks.

[0056] In order to further improve the performance of the data flow runtime system, the present application also optimizes the communication task scheduling between runtime subsystems, and the runtime subsystems transmit data through the Message Passing Interface (MPI) communication method.

[0057] This application designs an automatic masking strategy with communication tasks as the core. Each communication task contains a communication status bit, which is used to indicate whether the asynchronous communication between subsystems at runtime is completed. Each communication task corresponds to an MPI asynchronous communication. When the asynchronous communication is completed, the MPI callback function modifies the communication status bit of this 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. The communication task can only be created after the previous dependencies are released.

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

[0059] (1) Use proxy thread assisted scheduling strategy.

[0060] like Figure 3 As shown, each runtime subsystem further 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 determine whether the task that meets the dependency is a communication task. If so, the communication task is inserted into the communication task queue of the agent unit of the same runtime subsystem, and the next task that meets the dependency is scheduled; if not, the task that meets the dependency is sent to the computing unit group of the same runtime subsystem.

[0062] The proxy unit is used to poll the communication status bit of the communication task in the communication task queue, and when the communication status bit indicates that the transmission is completed, release the subsequent dependency of the communication task.

[0063] The task status detection is completed through the proxy thread. When the management unit detects and finds the communication task that can be executed, it will start the communication and insert the communication task into the communication task queue of the proxy thread. Figure 3The auxiliary scheduler in the proxy unit is responsible for continuously polling the communication status bits of the tasks in the communication task queue, such as Figure 3 In process ①, when the communication status bit shows that the transmission is completed, the subsequent logic of the communication task (such as MPI resource release) will be executed and the subsequent dependencies will be released.

[0064] This method is suitable for scenarios with frequent communication and more small object communication. The overhead of small object communication is high because the amount of data is too small and the number of times it is sent is frequent. Therefore, adding a proxy thread can use a variety of optimization methods, such as communication aggregation and underlying communication optimization, which can greatly reduce the overhead.

[0065] (2) Adaptive scheduling strategy for communication tasks.

[0066] like Figure 4 As shown, the management unit is also used to determine whether the task that meets the dependency is a communication task; if the task that meets the dependency is a communication task, then determine whether the data transmission is completed based on the communication status bit of the communication task, if completed, release the subsequent dependency of the communication task, if not completed, insert the communication task at the tail of the ready task queue, and schedule the next task that meets the dependency; if the task that meets the dependency is a normal task, then send the task that meets the dependency to the computing unit group of the same runtime subsystem.

[0067] Under this strategy, the execution process of a communication task consists of two phases: the transmission phase and the execution phase. When a communication task is created, the inter-process communication specified by the user will be automatically started and enter the transmission phase. When the management unit detects a communication task, such as Figure 4 In the process of ①, firstly, the communication task is checked whether it has been completed according to the communication status bit. If the transmission is completed, the subsequent logic (such as MPI resource release, etc.) is scheduled to execute and the downstream dependencies are released. If the transmission is not completed, the communication task is re-queued and the next task is scheduled for execution. Figure 4 ② process in .

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

[0069] The present application further designs a communication method selection strategy. The communication task adaptive scheduling strategy has a slightly higher overhead than the proxy thread assisted scheduling strategy because each management unit performs MPI communication. Therefore, the proxy thread assisted scheduling strategy is adopted by default. When the scheduler detects a communication task with a large communication volume, it automatically switches to the communication task adaptive scheduling strategy to meet the transmission resource overhead required for the large communication volume.

[0070] This application optimizes the communication between runtime subsystems. When data transmission is completed, there is no need to wait for other data transmissions to be completed. The data flow runtime system can automatically schedule tasks that depend on the data to the computing unit group for calculation, thereby completing user-transparent automatic communication and calculation masking. The process is as follows: Figure 5 When data transfer synchronization is broken, the program can advance execution faster, thus achieving higher performance.

[0071] In order to improve the data transmission speed between computing threads, this application also provides multi-instance tasks based on on-chip high-speed communication and designs a runtime scheduling strategy. Figure 6 As shown, the present 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, such as Figure 6 Each instance has a unique logical number, which is specified when creating a task. Users distinguish different instances by logical numbers. When performing on-chip communication, the data flow runtime system stores the logical number of each instance and the physical information of which computing threads each instance runs on. Therefore, based on the logical number specified by the user, the data flow runtime system can automatically map the destination to the physical logical number and enable high-speed transmission between computing threads.

[0072] In the data flow concept, the maintenance of dependencies between tasks is an important factor in ensuring the correct and efficient operation of applications. However, many-core heterogeneous platforms often have problems such as different instruction sets and different granularity of atomic operations, which makes it impossible to use atomic operations on the same memory address even in shared memory. Therefore, after the computing thread is executed, how to correctly update the dependency is a difficult problem to solve on many-core heterogeneous platforms.

[0073] In the existing data flow framework design, 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 on behalf of the computing unit group. However, the management unit will inevitably be in a non-reentrant function, which will lead to undefined behavior.

[0074] Therefore, the present application designs a dependency delay release strategy. This strategy postpones the update time of the dependency count, and the management unit replaces the computing unit group to complete the update. The process is as follows: Figure 7 shown.

[0075] The present application creates an additional delayed release queue for each computing unit group, that is, each computing unit group corresponds to a delayed release queue, and the delayed release queue is used to store all dependencies released by the computing unit group during the execution of tasks. When the computing unit group releases its dependencies on certain tasks, such as Figure 7 In the first process, the pointer corresponding to the task is inserted into the delayed release queue, such as Figure 7 ② process in the above, rather than actually atomically updating the dependency. The management unit is also used to traverse the delayed release queue corresponding to the computing unit group after the computing unit group of the same runtime subsystem completes the execution of the task, and update the dependency count. Specifically, when the computing unit group completes the calculation and the management unit reclaims the resources, the corresponding scheduler will traverse the task release queue of the computing unit group and complete the update of the dependency count, such as Figure 7 If all dependencies of a task are met after release, the scheduler is responsible for inserting the task into the ready task queue.

[0076] Since the computing unit group and management unit of the many-core platform are not identical, the delayed release strategy solves the problem of the correctness of the computing unit group release dependency with minimal impact on performance. For different many-core platform backends, the delayed release strategy can be used to correctly maintain dependencies.

[0077] In order to better understand the solution of this application, Figure 8 The specific application process of the data flow programming framework and runtime system for many-core heterogeneous platforms is introduced in detail.

[0078] Step 1: Front-end user task construction.

[0079] When using the framework on a multi-core heterogeneous platform, the user needs to complete the construction of the front-end task. For the application to be streamed, the user uses the unified programming interface provided by this application to abstract the application into several types such as context structures, computing subtasks, communication tasks, etc. and specify the data dependencies between tasks. After completing the task construction, the user sends the data to the data flow 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 task into a fine-grained data flow graph based on the task provided by the user, and waits for the management unit to execute the scheduled task. Each runtime subsystem runs multiple management units, each of which is responsible for the status detection and task allocation of a computing unit group. The management unit maintains a ready task queue to save the ready tasks and send 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 within the runtime subsystem, each management unit will actively steal tasks from the ready task queues of other management units and schedule them for execution when there are no tasks in the ready task queue.

[0082] Each management unit is also responsible for dynamic MPI communication status detection and maintenance to complete the communication between subsystems at runtime. For communication tasks, the management unit will detect whether the asynchronous transmission is completed when identifying it, and choose to execute the task or insert the task into the queue again based on the result.

[0083] Step 3: Mapping of underlying hardware resources of the system during data flow runtime.

[0084] This application divides the hardware core of the many-core heterogeneous platform into two parts: the management core and the computing core array. On a shared memory node, the management core and computing core array of the same non-uniform memory access architecture (NUMA) area are divided into a group. In each group, the management core runs a management thread and a computing thread, and the computing core runs a computing thread. The management threads between groups in the shared memory node can complete management collaboration through shared memory, such as task stealing, load balancing, etc. The shared memory nodes are linked by an Internet network to support upper-level MPI tasks and task migration between nodes.

[0085] In a specific example, the data flow runtime system provided in this application is mapped to the new generation Shenwei multi-core heterogeneous platform.

[0086] The new generation of Sunway multi-core heterogeneous platform integrates multi-core processors and dedicated accelerators to improve computing power and energy efficiency, and is widely used in scientific computing and engineering simulation. The platform adopts a master-slave core architecture, that is, there are 6 master cores and 384 slave core arrays on a chip. The master and slave cores are heterogeneous and share memory in a shared memory manner.

[0087] The data flow runtime system provided in this application is mapped to Shenwei in the following way: each runtime subsystem uses six management threads, each management thread runs on a master core and is responsible for the 64 slave cores managed by the master core; each slave core runs a computing thread to execute tasks scheduled by the management thread.

[0088] Regarding the scheduling strategy, since this application has multiple instance tasks, it is necessary to design a traversal method based on the on-chip communication characteristics of the Shenwei multi-core. In order to more efficiently utilize the high-speed remote memory access (RMA) transmission between slave core clusters, the traversal method of the data flow runtime system is changed from the traditional traversal by slave core logical number to the traversal that first fills a slave core cluster, such as Fig. 9 and Fig.10 This traversal method will give priority to traversing within the slave core cluster, and first fill up the same high-speed communication domain when facing a single-instance task, so that when a multi-instance task is detected, there is a greater chance to directly transmit it to the entire slave core cluster.

[0089] This application converts the slave core physical location index provided by the Shenwei library into a slave core cluster priority index through simple bit operations. 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] Among them, tid is the slave core position index, and spcid is the slave core cluster priority index.

[0093] Therefore, when users use the data flow runtime system provided by this application on the new generation of Shenwei multi-core heterogeneous platform, they only need to write the dependencies between tasks and send them to the backend, which will be efficiently scheduled by the data flow runtime system provided by this application.

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

[0095] (1) Support for many-core architecture: This application designs an efficient data flow runtime system for the many-core architecture, which effectively solves the data flow system migration problem caused by the multi-core and heterogeneous nature of the many-core platform.

[0096] (2) Effective cross-platform adaptability: The front end of this application uses a unified programming interface. Users do not need to consider the back-end parallel programming model of the many-core platform. They only need 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 multiple hardware platforms and improve performance.

[0097] (3) Multi-level communication optimization: At the communication level between subsystems at runtime, this application uses communication tasks to stream the communication process data and automatically achieve mutual concealment of communication and computing. At the on-chip network level within a single node, this 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 latency while ensuring programmability and readability.

[0098] In general, this application provides a programming framework and a corresponding data flow runtime system for many-core heterogeneous architectures in terms of data flow programming. Through a unified programming interface, efficient communication mechanism and functional support, it achieves efficient adaptation of the data flow runtime system and the back-end architecture, significantly reducing the programming difficulty for users.

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

[0100] Any reference to memory, database or other media used in the embodiments provided in the present application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM may be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0101] The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. The non-relational database may include a distributed database based on blockchain, etc., but is not limited thereto. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but is not limited thereto.

[0102] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0103] This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core ideas of this application. At the same time, for those skilled in the art, according to the ideas of this application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting this application.

Claims

1. A data flow runtime system for many-core heterogeneous platforms, characterized in that: The data flow runtime system for many-core heterogeneous platforms includes multiple runtime subsystems; each runtime subsystem includes a management unit and a computing unit group; The management unit is used to receive tasks and dependencies between tasks, generate a ready task queue, store a computing unit state array, and send the tasks that meet 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 includes the execution state of each computing thread; The computing unit group includes several computing threads, and several computing threads of the same computing unit group are mapped to a computing core array of a many-core heterogeneous platform; the computing unit group is used to execute the tasks issued by the management unit and release the subsequent dependencies of the tasks after the execution is completed.

2. The data flow runtime system for many-core heterogeneous platforms according to claim 1, characterized in that: The management unit includes a memory and a scheduler; The memory is used to store the ready task queue and the computing unit status array; The scheduler is used to send the tasks that meet the dependencies in the ready task queue to the computing unit group of the same runtime subsystem according to the computing unit status array.

3. The data flow runtime system for many-core heterogeneous platforms according to claim 2, characterized in that: The scheduler is also used to detect the number of tasks in the ready task queue. When the number of tasks is less than a set threshold, a task stealing strategy is used to steal tasks from the ready task queues of other management units to balance the number of tasks in the management units.

4. The data flow runtime system for many-core heterogeneous platforms according to claim 3, characterized in that: The scheduler is also used for actively entering a sleep state when the ready task queue is empty and cannot steal tasks from the ready task queues of other management units, and waking up and continuing scheduling when a new task is added to the ready task queue.

5. The data flow runtime system for many-core heterogeneous platforms according to claim 2, characterized in that: The execution state of the computing thread includes an idle state, a running state and a terminated state; The process of the scheduler sending the tasks satisfying the dependencies in the ready task queue to the computing unit group of the same runtime subsystem according to the computing unit state array specifically includes: The scheduler polls the computing unit state array, takes the computing thread in the idle state as the target computing thread, sends the tasks that meet 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 of the target computing thread is executed, the scheduler modifies the execution state of the target computing thread in the computing unit state array to a finished state.

6. The data flow runtime system for many-core heterogeneous platforms according to claim 1, characterized in that: The tasks in the ready task queue include communication tasks and common tasks; the communication tasks are used to realize data transmission between runtime subsystems.

7. The data flow runtime system for many-core heterogeneous platforms according to claim 6, characterized in that: Each runtime subsystem also includes an agent unit; the agent unit stores a communication task queue; The management unit is also used to determine whether the task that meets the dependency is a communication task. If so, insert the communication task into the communication task queue of the proxy unit of the same runtime subsystem and schedule the next task that meets the dependency; if not, send the task that meets the dependency to the computing unit group of the same runtime subsystem; The proxy unit is used to poll the communication status bit of the communication task in the communication task queue, and when the communication status bit indicates that the transmission is completed, release the subsequent dependency of the communication task.

8. The data flow runtime system for many-core heterogeneous platforms according to claim 6, characterized in that: The management unit is also used to determine whether the task that meets the dependency is a communication task; if the task that meets the dependency is a communication task, then determine whether the data transmission is completed based on the communication status of the communication task. If completed, release the subsequent dependency of the communication task; if not completed, insert the communication task at the tail of the ready task queue and schedule the next task that meets the dependency; if the task that meets the dependency is an ordinary task, send the task that meets the dependency to the computing unit group of the same runtime subsystem.

9. The data flow runtime system for many-core heterogeneous platforms according to claim 1, characterized in that: Each task is mapped to multiple compute threads; each compute thread is used to execute one instance of the task.

10. The data flow runtime system for many-core heterogeneous platforms according to claim 1, characterized in that: Each computing unit group corresponds to a delayed release queue, and the delayed release queue is used to store all dependencies released by the computing unit group during the execution of the task; The management unit is also used to traverse the delayed release queue corresponding to the computing unit group and update the dependency count after the computing unit group of the same runtime subsystem completes the execution of the task.

Images