Multi-core heterogeneous processor-oriented computing pool event-driven scheduling method and device

Abstract

The embodiment of the invention discloses a multi-core heterogeneous processor-oriented computing pool event-driven scheduling method and device. One specific embodiment of the method comprises the following steps: performing task node decoupling on an original task flow chart to obtain a virtual operator subset and a subtask information set; determining a candidate processor corresponding to each virtual operator according to mapping configuration representing an execution relationship between the operator and an execution processor; determining operator execution sequence information corresponding to each virtual operator according to a task node dependency relationship corresponding to the sub-task information set; for each virtual operator in the virtual operator set, executing a heterogeneous resource allocation step to serve as a virtual operator execution carrier; and through an event-driven mechanism and the operator execution sequence information, scheduling a virtual operator execution carrier to perform sequential execution of each sub-task to obtain a task execution result. According to the embodiment, the parallel efficiency when the multi-core heterogeneous processor processes the graph calculation task is improved, and the scheduling delay is reduced.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to a computing pool event-driven scheduling method and apparatus for multi-core heterogeneous processors. Background Technology

[0002] Currently, artificial intelligence and autonomous driving scenarios require the simultaneous handling of matrix operations and logical decision-making tasks. This makes it impossible for a single processor to balance efficiency and flexibility, leading to the development of multi-core heterogeneous processors. For graph computation tasks, the common approach is to use a master-slave architecture to manage task scheduling and queues, with the coordinating processor handling the tasks.

[0003] However, when using the above method to perform graph computation tasks, the following technical problems often arise:

[0004] When handling complex graph computation tasks, streams or work items are typically used as units, making it impossible to dynamically adapt to heterogeneous hardware based on operator characteristics. This leads to uneven utilization of hardware resources and wasted computing power. Cross-processor data transfer requires multiple copies, and bandwidth limitations increase transmission overhead. The lack of hardware-level memory protection mechanisms can result in out-of-bounds data corruption, illegal operations triggering bus errors, leading to system crashes and hardware failures.

[0005] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0007] Some embodiments of this disclosure propose a computing pool event-driven scheduling method and apparatus for multi-core heterogeneous processors to solve one or more of the technical problems mentioned in the background section above.

[0008] In a first aspect, some embodiments of this disclosure provide an event-driven scheduling method for computing pools of multi-core heterogeneous processors, comprising: decoupling task nodes of an original task flowchart to obtain a set of virtual operators and a set of subtask information with standardized interfaces; determining candidate processors corresponding to each virtual operator in the set of virtual operators based on a mapping configuration representing the execution relationship between the operators and the execution processors; determining the operator execution order information corresponding to each virtual operator in the set of virtual operators based on the task node dependency relationship corresponding to the set of subtask information; for each virtual operator in the set of virtual operators, performing a heterogeneous resource allocation step: determining candidate processors corresponding to the virtual operators; in response to the virtual operators satisfying preset activation conditions, selecting idle processing units from the candidate processors according to preset heterogeneous resource allocation rules to serve as virtual operator execution carriers; and scheduling the virtual operator execution carriers corresponding to each candidate processor in each candidate processor to perform sequential execution of each subtask through an event-driven mechanism and the operator execution order information, thereby obtaining the task execution result corresponding to the input data.

[0009] Secondly, some embodiments of this disclosure provide a computing pool event-driven scheduling device for multi-core heterogeneous processors, comprising: a task graph decoupling unit configured to decouple task nodes of an original task flowchart to obtain a set of virtual operators and a set of subtask information with standardized interfaces; a mapping configuration unit configured to determine a candidate processor corresponding to each virtual operator in the virtual operator set based on a mapping configuration representing the execution relationship between the operator and the executing processor; and an execution determination unit configured to determine the operator execution corresponding to each virtual operator in the virtual operator set based on the task node dependency relationship corresponding to the subtask information set. The system includes: a sequence information; a resource allocation unit configured to perform heterogeneous resource allocation steps for each virtual operator in the virtual operator set: determining the candidate processor corresponding to the virtual operator; in response to the virtual operator meeting a preset activation condition, selecting an idle processing unit from the candidate processors according to a preset heterogeneous resource allocation rule to serve as the virtual operator execution carrier; and an event-driven unit configured to schedule the virtual operator execution carrier corresponding to each candidate processor in each candidate processor through an event-driven mechanism and the operator execution sequence information to perform sequential execution of each subtask and obtain the task execution result corresponding to the input data.

[0010] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, such that when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any implementation of the first aspect.

[0011] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0012] The above embodiments of this disclosure have the following beneficial effects: The event-driven scheduling method for computing pools of multi-core heterogeneous processors, as described in some embodiments of this disclosure, improves the parallel efficiency and reduces scheduling latency when processing graph computation tasks on multi-core heterogeneous processors. Specifically, the low efficiency and long scheduling time of related processing tasks are due to the fact that traditional master-slave frameworks use streams or work items as scheduling units, and the coarse-grained mechanism is difficult to dynamically adapt to the differentiated characteristics of heterogeneous hardware. Based on this, the event-driven scheduling method for computing pools of multi-core heterogeneous processors, as described in some embodiments of this disclosure, firstly decouples the task nodes of the original task flowchart to obtain a set of virtual operators and a set of subtask information with standardized interfaces. This decouples the strong coupling between operators and the computation graph, achieving hardware-independent operator encapsulation as the basis for scheduling. Secondly, based on the mapping configuration representing the execution relationship between operators and executing processors, the candidate processor corresponding to each virtual operator in the virtual operator set is determined. This establishes the matching capability between operators and hardware, solving the resource rigidity problem of fixed processor types in traditional solutions. Next, based on the task node dependencies corresponding to the aforementioned subtask information set, the operator execution order information corresponding to each virtual operator in the aforementioned virtual operator set is determined. This reconstructs a task chain logically equivalent to the original computation graph, ensuring the correctness of the decoupled logical flow and eliminating the risk of data flow misordering. Then, for each virtual operator in the aforementioned virtual operator set, a heterogeneous resource allocation step is performed: Candidate processors corresponding to the aforementioned virtual operator are determined. This filters processors that can execute the current operator, avoiding invalid scheduling attempts. In response to the aforementioned virtual operator meeting preset activation conditions, idle processing units are selected from the aforementioned candidate processors according to preset heterogeneous resource allocation rules to serve as virtual operator execution carriers. Thus, resource allocation for event scheduling is only performed when the operator can satisfy the current state, reducing scheduling latency. Finally, through the event-driven mechanism and the aforementioned operator execution order information, the virtual operator execution carriers corresponding to each candidate processor are scheduled to execute each subtask sequentially, obtaining the task execution results corresponding to the input data. This creates an event-driven execution pipeline, automatically triggering downstream tasks through operator input and output events without central processing unit intervention, thus improving resource utilization. In summary, this approach employs an event-driven scheduling method for multi-core heterogeneous processors, replacing master-slave scheduling with operator-level event-driven scheduling. Event scheduling triggers operators to automatically execute downstream tasks, reducing scheduling latency. Attached Figure Description

[0013] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0014] Figure 1 This is a flowchart of some embodiments of the computing pool event-driven scheduling method for multi-core heterogeneous processors according to the present disclosure;

[0015] Figure 2 This is a structural schematic diagram of some embodiments of a computing pool event-driven scheduling apparatus for multi-core heterogeneous processors according to the present disclosure;

[0016] Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0017] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0018] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0019] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0020] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0021] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0022] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] refer to Figure 1The diagram illustrates a flow 100 of some embodiments of a compute pool event-driven scheduling method for multi-core heterogeneous processors according to the present disclosure. This compute pool event-driven scheduling method for multi-core heterogeneous processors includes the following steps:

[0024] Step 101: Decouple the task nodes of the original task flowchart to obtain a set of virtual operators and a set of subtask information with standardized interfaces.

[0025] In some embodiments, the execution entity (e.g., an electronic device) of the above-described event-driven scheduling method for multi-core heterogeneous processors can be a heterogeneous computing pool (HCP) scheduling unit. This heterogeneous computing pool scheduling unit can be a dedicated hardware scheduling unit within a heterogeneous processing unit (XPU) independent of the central processing unit (CPU). The original task flowchart can be a directed acyclic graph (DAG) describing the overall logic of the processing task, where nodes represent processing operations and edges represent dependencies. The virtual subset can be a set of standardized computing units generated after decoupling the computational logic of the original nodes. The subtask information set can be a metadata set describing the dependencies between task nodes and the logical order between task chains. The task node decoupling can involve removing direct pointer dependencies between nodes, replacing them with standardized interface interactions, and splitting the coupled nodes in the original task flowchart into independent schedulable computing units.

[0026] As an example, firstly, a static structure analysis is performed on the original task flowchart to generate a dependency matrix between nodes. Secondly, based on the topology sorting algorithm and the node dependency matrix, the original nodes are decoupled into independent schedulable operators, serving as virtual operators. Finally, direct pointer dependencies between nodes are removed and replaced with asynchronous communication interfaces using message queues. The data flow dependencies between nodes are converted into structured metadata, serving as subtask information.

[0027] Step 102: Based on the mapping configuration of the execution relationship between the representation operator and the execution processor, determine the candidate processor corresponding to each virtual operator in the virtual operator set.

[0028] In some embodiments, the execution entity can determine the candidate processor corresponding to each virtual operator in the virtual operator set based on the mapping configuration of the execution relationship between the characterizing operator and the execution processor. The execution processor can be a physical computing unit (e.g., CPU, GPU, and NPU) with specific computing capabilities in a heterogeneous computing pool. The mapping configuration can be a mapping relationship between operator type and processor supported capabilities. The candidate processor can be a physical processor for scheduling and allocating execution virtual operators by the execution entity after dynamic screening.

[0029] As an example, firstly, the mapping configuration file can be converted into a mapping table and a processor weight table. Secondly, by identifying the type and characteristic information of virtual operators, they are marked in the mapping table, and the executable processor priorities are marked according to the processor weight table as candidate processors.

[0030] In some optional implementations of certain embodiments, the execution entity can determine the candidate processor corresponding to each virtual operator in the virtual operator set based on the mapping configuration of the execution relationship between the characterizing operator and the execution processor. This can include the following steps:

[0031] The first step is to transform the above mapping configuration to obtain a mapping table and a processor weight table. The mapping table can be a file recording the mapping relationship between operator types and processors. The processor weight table can be used to describe the baseline performance weights of the processors when processing the corresponding operators. The transformation can be based on specific extractions from the mapping configuration. For example, the mapping configuration could be {Conv2D: processors: [NPU, GPU], NPU_weight: 0.9, GPU_weight: 0.7}. The mapping table could be {"Conv2D": ["NPU", "GPU"]}. The processor weight table could be {"NPU": 0.9, "GPU": 0.7}.

[0032] The second step involves performing the following processor selection step for each virtual operator in the aforementioned set of virtual operators:

[0033] The first sub-step involves determining the operator type and input data characteristics of the aforementioned virtual operator. The operator type can be a classification identifier describing how the operator determines the hardware processor selection. The input data characteristics can be structured attributes (e.g., data dimensions) of the virtual operator's input data. In practice, feature extraction can be performed on the virtual operator's data characteristics, and the extracted results can be represented in a structured manner.

[0034] The second sub-step, in response to the unique correspondence between the aforementioned operator type and the aforementioned mapping table, identifies the processors in the mapping table that have a mapping relationship with the aforementioned virtual operator as candidate processors. Here, the unique correspondence may mean that the operator type in the mapping table is associated with only a single processor. The candidate processor may be a physical processor (e.g., an NPU) that can currently execute the virtual operator. In practice, the number of corresponding processors in the mapping table is determined by matching the mapping relationships in the mapping table based on the operator type. In response to the number of processors being one, that processor is selected as a candidate processor.

[0035] The third sub-step, in response to the fact that the above operator type has multiple corresponding results in the above mapping table, executes the following processor first determination step:

[0036] Sub-step one involves identifying multiple processors corresponding to the aforementioned operator types to obtain a candidate processor sequence. This candidate processor sequence can be a sequence composed of multiple processors corresponding to the operator type.

[0037] Sub-step two involves retrieving the weight coefficients of all candidate processors in the aforementioned candidate processor sequence from the processor weight table, thus obtaining a set of candidate processor weight coefficients. This set of candidate processor weight coefficients can be a collection of weight coefficients corresponding to processors in the weight table. In practice, processors can be selected from the candidate processor sequence, and their corresponding weight coefficients can be found in the processor weight table to obtain the set of weight coefficients.

[0038] Sub-step three involves determining the load factor based on the aforementioned input data characteristics and load parameters, where the load parameters are obtained in real-time. These load parameters can be the real-time operating status of the processor (e.g., GPU utilization) obtained through the system interface. The load factor can be a dynamically adjusted coefficient based on the input characteristics and load parameters. For example, first, the computational load of the virtual operator and the computing power of the hardware processor are obtained from the input data characteristics. Second, the ratio of the computational load of the virtual operator to the computing power of the hardware processor is determined as the base load. Finally, the base load is summed with the real-time obtained processor load to obtain the total load. The difference between the total load and the real number is then determined as the load factor. The computational load in the input data characteristics can be 1 TFLOPs of computing resources. The load parameter can be the GPU utilization (40%). The GPU computing power can be 2 TFLOPs. The base load can be 0.5. Therefore, the load factor can be 1 - (0.5 + 0.4) = 0.1.

[0039] Sub-step four involves determining the comprehensive score of the candidate processors based on the aforementioned candidate processor weight coefficient set and load factor, thus obtaining the candidate processors. The comprehensive score can represent the compatibility score between the hardware processor and the virtual operator. For example, it can be the product of the candidate processor's weight coefficient and the load factor. The candidate processor with the highest comprehensive score in the candidate processor sequence is selected as the candidate processor.

[0040] The fourth sub-step, in response to the fact that no corresponding result is found for the above operator type in the above mapping table, executes the following processor second determination step:

[0041] Sub-step one involves extracting features from the virtual operator to obtain a virtual operator feature vector. This virtual operator feature vector is an array of structured numerical values ​​(e.g., operator type encoding, computational cost, and memory usage) describing the operator's characteristics. For example, the numerical values ​​corresponding to the virtual operator's features can be determined as the values ​​in the feature vector. For instance, the virtual operator's features could be {operator type: convolution (0), input data: 224×224×3, output data: 1000, computational cost: 1 GFLOPs, memory: 50 MB}. Then the virtual operator feature vector could be [0, 150528, 1000, 1e9, 50].

[0042] Sub-step two involves determining the similarity between the aforementioned virtual operator feature vector and the corresponding capability vector of the processor to obtain candidate processors. The capability vector is a feature vector that quantifies the multi-dimensional description of the processor's hardware characteristics. The similarity can be the cosine similarity value between the operator feature vector and the capability vector. For example, firstly, the capability vector can be obtained by acquiring the corresponding feature parameters in the processor through the corresponding features in the virtual operator feature vector. Secondly, the cosine similarity value between the capability vector and the virtual operator feature vector is determined. Finally, based on the corresponding cosine similarity value of the processors, those with high similarity values ​​and strong correlation are selected as candidate processors.

[0043] Step 103: Based on the task node dependency relationship corresponding to the subtask information set, determine the operator execution order information corresponding to each virtual operator in the virtual operator set.

[0044] In some embodiments, the aforementioned execution entity can determine the operator execution order information corresponding to each virtual operator in the virtual operator set based on the task node dependencies corresponding to the subtask information set. Here, the aforementioned task node dependencies can represent data flow constraints between operators and the order in which operators are executed in the task flow. The aforementioned operator execution order information can be information that determines the execution order between each operator based on the subtask information and data flow dependencies, ensuring the correct timing of the task chain.

[0045] As an example, firstly, a node dependency graph can be constructed using subtask information. Secondly, by analyzing the topological sorting of the node dependency graph and the virtual operators corresponding to each node, the execution order information of the virtual operators can be obtained.

[0046] In some optional implementations of certain embodiments, the execution entity can determine the operator execution order information corresponding to each virtual operator in the virtual operator set based on the task node dependency relationship corresponding to the subtask information set, which may include the following steps:

[0047] The first step is to construct a task dependency graph based on the aforementioned subtask information set. This task dependency graph can be a directed acyclic graph where nodes are virtual operators and edges represent data flow directions, indicating local logic within the task process.

[0048] As an example, extract the virtual operators and the data flow between them from the subtask information set. Construct a dependency dictionary based on the data flow. Then, construct a directed acyclic graph based on the dependency dictionary.

[0049] The second step is to perform a topological sort on the task dependency graph to obtain a topological sort sequence. This topological sort can ensure that each node precedes its successor and linearly sorts the nodes of the directed acyclic graph. The topological sort sequence can also be a linear execution sequence of virtual operators under data flow constraints.

[0050] As an example, determine the in-degree of each node in the graph and sort it using a topological sorting algorithm (e.g., Kahn's algorithm) to output a topological sequence.

[0051] The third step involves applying priority weights to the aforementioned topological sorting sequence based on critical path analysis, resulting in the task execution sequence. The critical path analysis can be performed by traversing the topologically sorted nodes in the task dependency graph to determine the total time consumption of the critical path. The priority weighting can be a method used to increase the scheduling priority of operators within the critical path. The task execution sequence can be a queue representing the order in which tasks are executed within the task flow.

[0052] As an example, the process traverses from the starting point to the ending point, determining the critical path based on the time taken. Then, iterates through the topological sequence, identifying entries that appear on the critical path. If any entries in the topological sequence appear on the critical path, the corresponding virtual operators in the topological sequence are weighted to obtain a sequence with priority labels.

[0053] Fourth, based on the above task execution sequence, perform operator mapping on the above virtual operator set to generate operator execution order information. This operator execution order information can be the order in which the virtual operators are executed.

[0054] As an example, one could assign sequential numbers to the virtual operators in the task execution sequence and match them with the operators in the virtual operator set. This would result in a structured operator sequence configuration.

[0055] Step 104: For each virtual operator in the virtual operator set, perform the heterogeneous resource allocation step:

[0056] Step 1041: Determine the candidate processors corresponding to the virtual operators.

[0057] In some embodiments, the execution entity described above can determine the candidate processor corresponding to the virtual operator. For example, the candidate processor can be determined based on the operator type of the virtual operator.

[0058] In addressing the aforementioned technical problems using technical solutions, the following issues often arise: the inability to allocate hardware processors based on task differences and the real-time status of processors in the system. Conventional solutions typically incorporate processor status into task allocation. However, the inventors recognized that conventional methods neglect the compatibility requirements between task characteristics and processor capabilities. Processors with high computing power may be occupied by simple tasks (resource waste), while suitable processors remain idle. Therefore, we decided to adopt the following solution.

[0059] In some optional implementations of certain embodiments, the execution entity may determine the candidate processor corresponding to the virtual operator, which may include the following steps:

[0060] The first step is to extract features from the aforementioned virtual operators to obtain a basic feature set, which serves as the static feature matrix. This feature extraction can involve extracting features with inherent attributes from the virtual operators. The basic feature set can be a collection of static features extracted from the virtual operators, including operator type, input and output data features, and computational complexity. The static feature matrix can be a matrix representation of the basic features, where rows correspond to virtual operators and columns correspond to basic features.

[0061] The second step involves performing performance tests on the aforementioned virtual operators to obtain a performance feature set, which serves as the dynamic feature matrix. This performance testing can simulate the actual operation of the virtual operators in a virtual environment to measure performance metrics (e.g., runtime and power consumption). The performance feature set can be performance metrics obtained from testing the virtual operators on different hardware processors. The dynamic feature matrix can represent the performance features in matrix form, where the rows of the matrix correspond to virtual operators, and the columns correspond to performance features.

[0062] As an example, firstly, test data that matches the execution of virtual operators can be randomly generated. Finally, the test data can be used on multiple processors in the virtual environment to perform tests and obtain performance test results.

[0063] The third step involves performing a normalization operation on the aforementioned static and dynamic feature matrices to obtain a standardized feature vector. This normalization operation can scale features from different ranges to a uniform range (e.g., the "0-1" range). The standardized feature vector can be formed by concatenating the normalized features into a vector using virtual operators.

[0064] The fourth step is to obtain the current system environment state and thus the environment feature vector. The system environment state can be the performance state of the processor in the system (e.g., current load, available memory, and temperature). The environment feature vector can be a vector representation of the system environment state.

[0065] Fifth, based on the aforementioned environmental feature vectors, perform environmental feature enhancement on the standardized feature vectors to obtain enhanced feature vectors. This environmental feature enhancement can be achieved by fusing the environmental feature vectors with the standardized feature vectors of the virtual operator (e.g., vector concatenation). The enhanced feature vector can be a fused feature vector that includes both the operator's own features and environmental information.

[0066] The sixth step is to extract task quantity metrics from the enhanced feature vectors described above, thus obtaining quantified metrics. These task quantity metrics can be key quantified parameters describing the task scale of the virtual operator. The quantified metrics can be the extracted core task scale parameter data.

[0067] Step 7: Based on the aforementioned quantitative indicators and system benchmark values, determine the task level corresponding to the virtual operator. The system benchmark value is a threshold for quantifying the typical task size that a single processor can handle. This typical task size threshold can be the upper limit of resources available for tasks that a processor can efficiently process. The task level can be an intensity level representing the resource consumption of the virtual operator's task size.

[0068] As an example, firstly, a baseline value table for the hardware processor can be loaded. Secondly, the scale coefficient of the processing task of the virtual operator is determined based on quantization metrics. Finally, based on the scale coefficient and the corresponding baseline value table, the task level is found and classified.

[0069] Step 8: Construct a processor status table based on the real-time status of the processors in the cluster. The real-time status can be the current operating metrics of the processors (e.g., load and temperature). The processor status table can be a structured representation of the processor resource status information in the cluster, stored in tabular form.

[0070] Step 9: In response to the above task level being lower than the preset level, execute the following task resource processor determination step one:

[0071] The first sub-step involves determining the task processor corresponding to the virtual operator based on the aforementioned processor status table. The task processor can be a single hardware processor capable of meeting the task requirements of the virtual operator. The preset level can be a task level threshold used to differentiate the task processing intensity of the virtual operator.

[0072] As an example, you can query the processors that meet the basic resource requirements for virtual operators to execute tasks based on the processor status table.

[0073] The second sub-step is to determine the task processor as a candidate processor in response to the task processor meeting the above quantitative indicators.

[0074] As an example, check if the computational load of the task processor can meet the execution quantification criteria. If it does, then the current task processor is designated as the execution processor for this virtual operator.

[0075] Step 10: In response to the above task level being equal to the preset level, execute the following task resource processor determination step two:

[0076] The first sub-step involves determining the task processor set corresponding to the virtual operator based on the aforementioned processor state table. This task processor set can be a collection of multiple hardware processors capable of meeting the task requirements of the virtual operator.

[0077] As an example, you can query the processor status table to find all the hardware processors that meet the basic resource requirements for the virtual operator to execute the task.

[0078] The second sub-step involves determining the similarity between the enhanced feature vector and the capability vectors of each task processor in the task processor set, thus obtaining a similarity information set. This similarity can be the cosine similarity between the enhanced feature vector of the virtual operator and the capability vectors of each hardware processor. The similarity information set can be a collection storing the similarity information between each candidate processor and the virtual operator.

[0079] As an example, first, the capability vector of the hardware processor (e.g., computing power, memory, and bandwidth) is obtained. Finally, the cosine similarity between the capability vector and the enhanced feature vector is determined.

[0080] The third sub-step involves filtering similar information from the aforementioned similar information set that meets a preset value to obtain the task processors corresponding to the similar information, which serve as the task resource processor set. This task resource processor set is a set of hardware processors that meet the similarity criteria and require further filtering to be executed as virtual operators.

[0081] The fourth sub-step involves obtaining the resource utilization rate of the task resource processors in the aforementioned task resource processor set. This resource utilization rate can be the current resource usage rate of the hardware processor. In practice, the processor's status (e.g., resource utilization rate) can be directly obtained from the processor status table.

[0082] The fifth sub-step involves determining the comprehensive score of each task resource processor based on the resource utilization rate and the similarity information corresponding to the task resource processor set, thus obtaining a comprehensive score set for task resource processors. This comprehensive score can be a weighted score combining similarity information and resource utilization rate. The comprehensive score set for task resource processors can be the set of comprehensive scores for each candidate processor.

[0083] As an example, first, the scoring criteria can be determined (e.g., overall score = similar information × 70% + resource availability × 3%). Finally, the overall score is determined based on the scoring criteria.

[0084] The sixth sub-step involves sorting the aforementioned set of comprehensive scores for task resource processors in descending order to obtain a sequence of comprehensive scores for task resource processors. This sequence can be a sequence of candidate processors sorted in descending order of their comprehensive scores.

[0085] The seventh sub-step is to determine the task resource processor corresponding to the first comprehensive score of the task resource processor in the above task resource processor comprehensive score sequence as the candidate processor.

[0086] Step 11: In response to the above task level being greater than the specified level, execute the following task resource processor determination step three:

[0087] The first sub-step involves determining the number of task segments based on the enhanced feature vector and the processor state table. This number can be the number of subtasks into which the task executed by the virtual operator is divided.

[0088] As an example, first, the maximum concurrency is determined based on the task size in the enhanced feature vector and the number of available processors in the processor state table. Second, the average computing power of the available processors is determined. Finally, the task is split based on the average computing power and the maximum concurrency to obtain the number of task splits.

[0089] The second sub-step involves dividing the tasks corresponding to the virtual operators according to the aforementioned task division number, thereby obtaining a set of subtasks. This set of subtasks can be the collection of subtasks obtained by dividing the tasks corresponding to the virtual operators.

[0090] As an example, partitioning can be based on the task type of the virtual operator. For instance, if the task type of the virtual operator is model parallelism, then a graph partitioning algorithm can be used to uniformly partition the task.

[0091] The third sub-step involves extracting features from each subtask group in the aforementioned subtask group set to obtain subtask group features, which serve as the subtask group feature matrix. These subtask group features can be feature information describing the computational characteristics of each subtask. The subtask group feature matrix can be a matrix composed of subtask features and their corresponding feature details.

[0092] The fourth sub-step involves allocating subtask resource processors to each subtask group within the aforementioned subtask group set, based on the subtask group feature matrix and the processor status table, thus obtaining a subtask resource processor set. Here, each subtask resource processor can be a hardware processor used to process a subtask. The subtask resource processor set can be a collection of hardware processors used to process subtasks.

[0093] As an example, firstly, the features representing computational load in the subtask group feature matrix can be sorted in descending order. Secondly, they can be sorted in ascending order according to the current processor utilization. Finally, the processors are traversed to match the computational load, determining which processors have sufficient utilization to meet the computational load of the subtask and thus are designated as the subtask resource processors.

[0094] The fifth sub-step involves encapsulating the aforementioned set of subtask resource processors into task resource processors, which will then serve as candidate processors. This task resource processor encapsulation can be a process of combining the hardware processors corresponding to multiple subtasks into a single logical processing group.

[0095] As an example, first, a logical processing group can be created. Second, the assigned physical processors are added to the logical processing group. Finally, based on the data flow of the task, the internal communication topology is configured and encapsulated for each assigned physical processor.

[0096] The above-described steps, as an inventive point of this disclosure, solve the technical problem mentioned in the background: "When processing complex graph computation tasks, the process typically uses streams or work items as units, making it impossible to dynamically adapt to heterogeneous hardware based on operator characteristics. This leads to uneven utilization of hardware resources and wasted computing power." In practice, task allocation is adjusted solely by incorporating real-time processor status information (e.g., current load, available memory, and temperature), but it cannot accurately and adaptively match hardware processors based on task differences (e.g., inherent computational characteristics of operators, data requirements, and execution dependencies) and inherent differences in processor capabilities within the system (e.g., the parallel computing power of GPUs and the dedicated acceleration units of NPUs). This disclosure designs a feature fusion-based differentiated scheduling scheme based on a task hierarchy mechanism. By fusing the static features of virtual operators (e.g., operator type, computational load, and input / output data characteristics) with environmental features (e.g., runtime performance of operators on different hardware and the real-time status of hardware processors), an enhanced feature vector capable of jointly representing the nature of the task and environmental constraints is constructed. The operator tasks are classified into levels based on the task size of the operator and the task threshold of a single processor. By combining enhanced feature vectors with task level for dynamic analysis, the matching hardware processor is determined. Therefore, precise adaptive scheduling of task requirements and hardware resources in heterogeneous computing environments is achieved, ensuring that operator tasks are always scheduled to the most suitable processor for execution.

[0097] In addressing the aforementioned technical problems using technical solutions, the following issues often arise: relying solely on the computational characteristics of the task itself without considering the relationships between tasks leads to discontinuous task execution and task blocking. Subsequent processors idle while the preceding task is incomplete. Assigning tasks to hardware processors without direct paths increases additional copying overhead. Conventional solutions to these problems typically involve increasing the computing power of individual processors to process tasks faster. However, the inventors recognized that improving processor hardware cannot fundamentally resolve the contradiction of task topology fragmentation. Therefore, we decided to adopt the following solution.

[0098] Optionally, in some optional implementations of some embodiments, the execution entity may determine the candidate processor corresponding to the virtual operator, which may include the following steps:

[0099] The first step is to determine the topological relationships of the virtual operators in the original task flowchart, thus obtaining a task subgraph. These topological relationships can be the sequential dependencies of the virtual operators in the task processing flow. The task subgraph can be a local subgraph centered on a virtual operator, containing its direct predecessors, direct successors, and directly related nodes (e.g., nodes sharing input).

[0100] As an example, firstly, the direct predecessor and direct successor nodes of the virtual operator can be obtained from the original task flowchart. Secondly, the directly associated nodes that share the input with the virtual operator (the same as the predecessor node of the virtual operator) can be obtained. Then, the aforementioned predecessor, direct successor, and directly associated nodes are deduplicated, and the edges between the nodes are retained to form the task subgraph.

[0101] The second step is to determine the task execution resource requirements of the aforementioned virtual operator and task subgraph, thereby obtaining the computing power resource requirements, task type, and task execution type. The computing power resource requirements can be the basic computing power resources needed for the execution of the virtual operator. The task type can be the type of task performed by the virtual operator (e.g., matrix computation). The task execution type can be the data flow order type when executing the virtual operator (e.g., chained order).

[0102] As an example, the dependencies between virtual operators and neighboring nodes in the task subgraph can be determined as the type of task execution. The number of operations of virtual operators can be counted to determine the computational load and obtain the computing resource requirements.

[0103] The third step is to construct a processor status table based on the real-time status of the processors in the cluster. This real-time status can be the processor's current operating metrics (e.g., load and temperature). The processor status table can be a structured representation of the processor resource status information in the cluster, stored in tabular form.

[0104] The fourth step is to determine the first processor based on the task type and processor status table described above. The first processor may be a hardware processor selected from those that meet the requirements for executing virtual operators.

[0105] As an example, the type of hardware processor can be filtered based on the type of task (e.g., matrix operations could be performed using a GPU).

[0106] Fifth step: In response to the fact that the computing power resources corresponding to the first processor are not less than the computing power resource requirements, the first processor is determined as a candidate processor.

[0107] Step 6: In response to the fact that the computing power resources corresponding to the first processor are less than the computing power resource requirements, and the task execution type is a chained execution task, perform the following step:

[0108] The first sub-step involves decomposing the task subgraph based on the computing resources corresponding to the first processor to obtain a sequential subtask queue. This sequential subtask queue can be a queue composed of subtasks arranged in a sequential order after decomposition. The chained execution task can be a task mode corresponding to the virtual operator, where subtasks are executed sequentially, with the output of one subtask serving as the input of the next.

[0109] As an example, firstly, the task subgraph is broken down into multiple sequentially executed subtasks based on the computing power of the hardware processor, while maintaining dependencies. For instance, the task is divided into multiple parts according to the critical path, ensuring that the computing power requirement of each part does not exceed the computing power of the hardware processor. Finally, the multiple sequentially executed subtasks are combined into a sequential subtask queue, ensuring the sequential execution dependencies of the tasks in the queue are maintained.

[0110] The second sub-step involves constructing an inter-step cache area based on the content resource requirements of each sequential subtask in the aforementioned sequential subtask queue. This cache serves as the interval for resource exchange during the execution of sequential subtasks. The aforementioned content resource requirements can be non-computing resources (e.g., memory, storage, and bandwidth) required for subtask execution. The inter-step cache area can be a dedicated storage area for temporarily storing intermediate results of chained tasks.

[0111] As an example, for two adjacent subtasks in a sequential subtask queue, the output of the previous subtask serves as the input of the next, requiring the intermediate result to be stored. Therefore, an inter-step buffer is constructed for each pair of adjacent subtasks, and the location of the inter-step buffer can be in the local memory of the hardware processor. This buffer serves as the interval for resource exchange during the execution of sequential subtasks.

[0112] The third sub-step is to determine the first processor mentioned above as a candidate processor.

[0113] Step 7: In response to the fact that the computing power resources corresponding to the first processor are less than the computing power resource requirements, and the task execution type is parallel execution, perform step 2 of the following operations:

[0114] The first sub-step involves decomposing the task subgraph based on the computing resources corresponding to the first processor, resulting in a first task and a second task. The first task may be a core task retained by the main processor. The second task may be a task offloaded to other processors for parallel execution. This parallel execution task can be a task type where multiple independent subtasks can be executed simultaneously.

[0115] As an example, firstly, the parallel portion of the task subgraph is analyzed. Secondly, the computational cost of the parallel portion is analyzed, and it is split into the first and second tasks based on computing resources.

[0116] The second sub-step involves determining the aforementioned first processor as a candidate processor for the aforementioned first task, thereby obtaining a first candidate processor. The aforementioned first candidate processor may be a hardware processor used to process the main tasks in the virtual operator.

[0117] The third sub-step involves determining a second processor based on the content resource requirements corresponding to the second task and the processor status table, serving as a second candidate processor. This second processor can be a hardware processor selected from those that meet the requirements for executing the offloading task.

[0118] As an example, the processor state table can be filtered according to the computational requirements, content resource (e.g., memory and storage) requirements, and task type (determined by the type of virtual operator) of the second task to select a processor that meets the execution requirements of the second task.

[0119] The fourth sub-step involves determining the first candidate processor and the second candidate processor as candidate processors.

[0120] As an example, first, a logical processing group can be created. Second, the physical processors corresponding to the first and second candidate processors are added to the logical processing group. Finally, the physical processors in the logical processing group are connected according to the order of the task subgraph to ensure that they can be executed in sequence.

[0121] The above-described steps, as an inventive point of this disclosure, solve the technical problem mentioned in the background: "When processing complex graph computation tasks, the flow or work item is usually used as a unit, which cannot dynamically adapt to heterogeneous hardware according to the characteristics of the operator. This leads to unbalanced utilization of hardware resources and wasted computing power." In practice, there are topological dependencies between operators, which can cause execution breaks. The lack of modeling of inter-task relationships (e.g., data dependencies, parallel branches) leads to discontinuous task execution and a surge in data transfer latency during processor scheduling, which in turn causes cascading blocking. This disclosure designs a hardware processor resource scheduling scheme that dynamically allocates resources based on task dependencies. First, by parsing the original task flowchart, a task subgraph centered on the target virtual operator is constructed. The subgraph includes direct predecessor nodes, successor nodes, and associated nodes sharing input, representing the sequential dependencies and parallel relationships between operators. Second, the resource requirements of the task subgraph are extracted: computing power resources (e.g., computational load), task type (e.g., matrix computation), and execution type (chained sequential or parallel). At the same time, a cluster processor status table is dynamically constructed to track the available resources (e.g., load and temperature) of each hardware processor in real time. The processor initially selected based on task type is designated as the first processor (e.g., GPU-adapted matrix calculation). If the computing power meets the requirements, it is directly allocated for execution. If the computing power is insufficient and the task is a chained execution type, the task subgraph is decomposed into a sequential subtask queue according to the processor's computing power limit, and an inter-step cache in local memory is created between adjacent subtasks to achieve zero-copy transfer of intermediate results. Finally, this processor is used to handle the entire chain of tasks. If the computing power is insufficient and the task is parallel, the task subgraph is decomposed into core tasks (reserved for the first processor) and divisible tasks. The second processor is selected based on the computing power and memory requirements of the divisible tasks, and the first and second processors are encapsulated into logical processing groups according to data flow. Parallel collaborative execution is ensured through internal topology connections. Therefore, through topology-driven dynamic decomposition and adaptive collaborative mechanisms, the problems of execution blocking and resource allocation errors caused by ignoring task dependencies in traditional scheduling are completely solved.

[0122] Step 1042: In response to the virtual operator meeting the preset activation conditions, an idle processing unit is selected from the candidate processors according to the preset heterogeneous resource allocation rules to serve as the execution carrier of the virtual operator.

[0123] In some embodiments, the execution entity may, in response to the virtual operator satisfying a preset activation condition, select an idle processing unit from candidate processors according to a preset heterogeneous resource allocation rule to serve as the execution carrier for the virtual operator. The preset activation condition may be data dependency satisfaction, resource dependency release, and execution prerequisite readiness. Specifically, data dependency satisfaction may mean that the input data of the virtual operator is complete. Resource dependency release may mean that the resources (e.g., locks and memory) on which the virtual operator depends have been acquired. Execution prerequisite readiness may mean that the preconditions for virtual operator execution (e.g., the predecessor operator has completed execution) are met. The idle processing unit may be a currently unused and allocable computing resource unit of the hardware processor (e.g., a GPU stream processor). The virtual operator execution carrier may be a physical computing resource used to execute the virtual operator.

[0124] As an example, firstly, the virtual operator undergoes state detection to determine if it meets preset activation conditions. Finally, when the virtual operator meets the activation conditions, a unit in the hardware processor is selected and bound to the virtual operator according to preset heterogeneous resource allocation rules. For example, preset heterogeneous resource allocation rules may include the following rules: high matching degree between operator type and processor architecture; light load on the hardware processor; selection of a hardware processor close to the location of operator data; and selection of a hardware processor with high energy efficiency.

[0125] In some optional implementations of certain embodiments, the execution entity may select an idle processing unit from the candidate processors according to a preset heterogeneous resource allocation rule to serve as a virtual operator execution carrier, which may include the following steps:

[0126] The first step, based on the aforementioned preset heterogeneous resource allocation rules, is to perform resource access verification through the memory virtualization layer:

[0127] The first sub-step involves determining the virtual operator address and virtual operator permissions corresponding to the aforementioned virtual operator. The virtual operator address can be the location identifier of the virtual operator operand in the virtual address space. The virtual operator permissions can be the virtual operator's access permissions to hardware resources (e.g., read permissions, write permissions, and execute permissions). The aforementioned memory virtualization layer can be a virtualization view that manages access control and security isolation between hardware processor memories.

[0128] As an example, virtual addresses and corresponding permissions can be extracted from virtual operator feature information.

[0129] The second sub-step verifies the mapping status between the virtual operator address and the physical address, and verifies the permission content corresponding to the virtual operator's permissions. The mapping status can be used to check if the virtual address is valid. The mapping status determination can determine whether the virtual address is mapped to a physical address. Verifying the virtual operator's permissions can check whether the virtual operator's permissions are within the granted permission scope.

[0130] As an example, the physical address mapping corresponding to a virtual address can be queried through the memory virtualization layer (e.g., MMU). It can be checked whether the permissions requested by a virtual operator (e.g., write permissions) are within the permissions recorded in the page table entry.

[0131] The second step, in response to the successful resource permission access verification mentioned above, is to execute the address space verification step:

[0132] The first sub-step involves determining the physical page corresponding to the aforementioned virtual operator. This physical page can be the smallest operational unit of the memory management unit. In practice, the physical page can be the page containing the physical address obtained through virtual address mapping.

[0133] As an example, the base address of the physical page can be obtained from the page table entry to get the physical page corresponding to the virtual operator.

[0134] The second sub-step involves determining whether there are other tasks on the physical page and whether the cross-processor shared flag for the physical page is valid. These other tasks can be identifiers of processes or threads currently accessing the physical page. The cross-processor shared flag can be protocol status bits (e.g., modified, exclusive, shared, and invalid) that control cache coherency across multiple hardware processors.

[0135] As an example, the locking status of a physical page can be checked to determine if it is being used by another task. For instance, when detecting the cross-processor shared flag of a physical page, if a virtual operator requests exclusive access (not used in a shared state) and the page's shared flag is set, it must wait.

[0136] Third, in response to the successful address space verification, the following resource binding steps are performed:

[0137] The first sub-step involves creating a shared memory channel. This shared memory channel can be a zero-copy communication pipe based on RDMA technology and may include the following features: kernel bypass, memory registration, and queue pair (QP) mechanism.

[0138] As an example, one could allocate a block of memory in a shared memory region as a shared channel.

[0139] The second sub-step involves identifying the idle processing units among the aforementioned candidate processors.

[0140] As an example, an idle processing unit could be selected by traversing the computing resource units in the processor.

[0141] The third sub-step involves binding the virtual operator to the idle processing unit via the shared memory channel to obtain a task execution unit, which serves as the execution carrier for the virtual operator. The binding of the idle processing unit can create a hardware-recognizable execution context, which may include the following characteristics: instruction pointer, data address, and register state. The task execution unit can be the executable entity of the virtual operator after binding to the idle processing unit.

[0142] As an example, first, the code and data of the virtual operator are moved to a shared memory channel. Second, the context of the idle processing unit is configured to access the shared channel. Finally, the processing unit is marked as non-idle and becomes an executable entity.

[0143] Step 105: Through the event-driven mechanism and operator execution order information, schedule the virtual operator execution carrier corresponding to each candidate processor in each candidate processor to execute each subtask sequentially, and obtain the task execution result corresponding to the input data.

[0144] In some embodiments, the aforementioned execution entity can schedule the virtual operator execution carrier corresponding to each candidate processor in each candidate processor to perform the sequential execution of each subtask through an event-driven mechanism and operator execution order information, thereby obtaining the task execution result corresponding to the input data. The event-driven mechanism can be a task triggering and execution management framework based on asynchronous events, and may include the following modules: event generation, event distribution, and event processing. The input data can be the raw input data required for task processing, and the task execution result can be the final output of the entire task processing flow.

[0145] As an example, firstly, an event-driven engine can be created to receive and dispatch events. These events can include: operator execution completion events and data readiness events. Secondly, a callback function is registered for each virtual operator's execution completion event. This callback function is responsible for triggering the execution of subsequent virtual operators. Then, operator execution order information is loaded, and the task queue is initialized. Virtual operators without dependencies (e.g., those with an in-degree of 0) are placed in the task queue as starting operators. Afterward, the system waits for events to occur. When an event occurs, the callback function registered for that event is invoked. Finally, operators are retrieved from the executable queue, and their execution carriers are scheduled for execution on candidate processors. The input data required for execution is obtained from shared memory or event delivery. After all virtual operators have executed, the final virtual operator output is used as the task execution result.

[0146] In some optional implementations of certain embodiments, the aforementioned execution entity can schedule the virtual operator execution carrier corresponding to each candidate processor in each candidate processor to perform sequential execution of each subtask through an event-driven mechanism and the aforementioned operator execution order information, which may include the following steps:

[0147] The first step is to construct an event mapping table based on the operator execution order information mentioned above. This event mapping table can be a table mapping the correspondence between event signals (e.g., event ID and event type) and the operators to be executed.

[0148] As an example, firstly, the execution order and dependencies of each virtual operator are extracted from the operator execution order information. Finally, a unique event signal is assigned to each operator, and an event mapping table is constructed based on the dependencies.

[0149] The second step involves binding the virtual operator execution carriers to the corresponding event signals in the event mapping table to obtain chained tasks. These event signals can be event identifiers that trigger operations in an event-driven mechanism. The chained tasks can be a sequence of tasks triggered by event signals, arranged in a specified execution order. The topology of this task sequence satisfies the data flow dependency constraints between operators.

[0150] As an example, firstly, the event mapping table is traversed to obtain the corresponding virtual operator execution carrier for each event signal. Finally, the event signals and virtual operator execution carriers are bound together to form a chained task. The binding described above simply stores the relationship between events and carriers within the structure of the chained task.

[0151] Third, in response to task event activation, perform the following operations on the above chain of tasks:

[0152] The first sub-step involves determining the virtual operator execution carrier corresponding to the aforementioned task event within the chained tasks, thus obtaining the task execution carrier. This task execution carrier can be the virtual operator execution carrier corresponding to the current task event. Furthermore, the activation of the aforementioned task event can be triggered by an event-driven mechanism (such as data readiness or completion of a preceding task), thereby initiating the corresponding operation within the chained tasks.

[0153] As an example, the corresponding task execution carrier can be obtained from the chained tasks based on the characteristics of the event (e.g., event ID).

[0154] The second sub-step involves generating the execution instructions corresponding to the aforementioned task events. These execution instructions can be the actual commands that cause the task execution carrier to run on the processor (e.g., operator code and passed parameters).

[0155] As an example, this could be creating executable instructions (e.g., functions and command strings) for an execution carrier.

[0156] The fourth step is to add the aforementioned execution instructions to the aforementioned task execution carrier to process task events. The processing of these task events can involve performing event-related operations (e.g., running operators and processing data).

[0157] As an example, first, the generated execution instructions are associated with the task execution vehicle. Finally, the task execution vehicle is used to handle events.

[0158] The above embodiments of this disclosure have the following beneficial effects: The event-driven scheduling method for computing pools of multi-core heterogeneous processors, as described in some embodiments of this disclosure, improves the parallel efficiency and reduces scheduling latency when processing graph computation tasks on multi-core heterogeneous processors. Specifically, the low efficiency and long scheduling time of related processing tasks are due to the fact that traditional master-slave frameworks use streams or work items as scheduling units, and their coarse-grained mechanism is difficult to dynamically adapt to the differentiated characteristics of heterogeneous hardware. Based on this, the event-driven scheduling method for computing pools of multi-core heterogeneous processors, as described in some embodiments of this disclosure, firstly decouples the task nodes of the original task flowchart to obtain a set of virtual operators and a set of subtask information with standardized interfaces. This decouples the strong coupling between operators and the computation graph, achieving hardware-independent operator encapsulation as the basis for scheduling. Secondly, based on the mapping configuration representing the execution relationship between operators and executing processors, the candidate processor corresponding to each virtual operator in the virtual operator set is determined. This establishes the matching capability between operators and hardware, solving the resource rigidity problem of fixed processor types in traditional solutions. Next, based on the task node dependencies corresponding to the aforementioned subtask information set, the operator execution order information corresponding to each virtual operator in the aforementioned virtual operator set is determined. This reconstructs a task chain logically equivalent to the original computation graph, ensuring the correctness of the decoupled logical flow and eliminating the risk of data flow misordering. Then, for each virtual operator in the aforementioned virtual operator set, a heterogeneous resource allocation step is performed: Candidate processors corresponding to the aforementioned virtual operator are determined. This filters processors that can execute the current operator, avoiding invalid scheduling attempts. In response to the aforementioned virtual operator meeting preset activation conditions, idle processing units are selected from the aforementioned candidate processors according to preset heterogeneous resource allocation rules to serve as virtual operator execution carriers. Thus, resource allocation for event scheduling is only performed when the operator can satisfy the current state, reducing scheduling latency. Finally, through the event-driven mechanism and the aforementioned operator execution order information, the virtual operator execution carriers corresponding to each candidate processor are scheduled to execute each subtask sequentially, obtaining the task execution results corresponding to the input data. This creates an event-driven execution pipeline, automatically triggering downstream tasks through operator input and output events without central processing unit intervention, thus improving resource utilization. In summary, this approach employs an event-driven scheduling method for multi-core heterogeneous processors, replacing master-slave scheduling with operator-level event-driven scheduling. Event scheduling triggers operators to automatically execute downstream tasks, reducing scheduling latency.

[0159] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a computing pool event-driven scheduling device for multi-core heterogeneous processors. These device embodiments are similar to... Figure 1Corresponding to the method embodiments shown, this compute pool event-driven scheduling device for multi-core heterogeneous processors can be specifically applied to various electronic devices.

[0160] like Figure 2 As shown, a computing pool event-driven scheduling device 200 for multi-core heterogeneous processors includes: a task graph decoupling unit 201, a mapping configuration unit 202, an execution determination unit 203, a resource allocation unit 204, and an event-driven unit 205. The task graph decoupling unit 201 is configured to decouple task nodes in the original task flowchart to obtain a set of virtual operators and a set of subtask information with standardized interfaces. The mapping configuration unit 202 is configured to determine the candidate processor corresponding to each virtual operator in the virtual operator set based on the mapping configuration representing the execution relationship between the operator and the executing processor. The execution determination unit 203 is configured to determine the operator execution order information corresponding to each virtual operator in the virtual operator set based on the task node dependencies corresponding to the subtask information set. Resource allocation unit 204 is configured to: for each virtual operator in the above virtual operator set, perform a heterogeneous resource allocation step: determine the candidate processor corresponding to the above virtual operator; in response to the above virtual operator satisfying the preset activation condition, select an idle processing unit from the above candidate processors according to the preset heterogeneous resource allocation rule to serve as the virtual operator execution carrier. Event-driven unit 205 is configured to: through the event-driven mechanism and the above operator execution order information, schedule the virtual operator execution carrier corresponding to each candidate processor in each candidate processor to perform the sequential execution of each subtask, and obtain the task execution result corresponding to the input data.

[0161] It is understandable that the units described in the computing pool event-driven scheduling device 200 for multi-core heterogeneous processors are related to the reference... Figure 1 The steps in the described method correspond accordingly. Therefore, the operations, features, and beneficial effects described above for the method also apply to the computing pool event-driven scheduling device 200 for multi-core heterogeneous processors and the units contained therein, and will not be repeated here.

[0162] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device (e.g., an electronic device) 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0163] like Figure 3As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0164] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0165] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0166] It should be noted that, in some embodiments of this disclosure, the computer-readable medium described above may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0167] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0168] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs. When the aforementioned one or more programs are executed by the electronic device, the electronic device causes the following: it decouples the task nodes of the original task flowchart to obtain a set of virtual operators and a set of subtask information with standardized interfaces; it determines candidate processors corresponding to each virtual operator in the aforementioned virtual operator set based on the mapping configuration representing the execution relationship between the operators and the execution processors; it determines the operator execution order information corresponding to each virtual operator in the aforementioned virtual operator set based on the task node dependencies corresponding to the aforementioned subtask information set; for each virtual operator in the aforementioned virtual operator set, it performs a heterogeneous resource allocation step: it determines candidate processors corresponding to the aforementioned virtual operators; in response to the aforementioned virtual operators satisfying preset activation conditions, it selects idle processing units from the aforementioned candidate processors as virtual operator execution carriers according to preset heterogeneous resource allocation rules; and through an event-driven mechanism and the aforementioned operator execution order information, it schedules the virtual operator execution carriers corresponding to each candidate processor in each candidate processor to perform sequential execution of each subtask, obtaining the task execution result corresponding to the input data.

[0169] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0170] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0171] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a task graph decoupling unit, a mapping configuration unit, an execution determination unit, a resource allocation unit, and an event-driven unit. The names of these units do not necessarily limit the specific unit itself; for example, the task graph decoupling unit may also be described as "a unit that decouples task nodes from the original task flowchart to obtain a set of virtual operators and a set of subtask information with standardized interfaces."

[0172] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0173] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A computation pool event-driven scheduling method for multi-core heterogeneous processors, comprising: The task nodes of the original task flowchart are decoupled to obtain a set of virtual operators and a set of subtask information with standardized interfaces; Based on the mapping configuration of the execution relationship between the characterization operator and the execution processor, the candidate processor corresponding to each virtual operator in the virtual operator set is determined; Based on the task node dependencies corresponding to the subtask information set, determine the operator execution order information corresponding to each virtual operator in the virtual operator set; For each virtual operator in the virtual operator set, perform the heterogeneous resource allocation step: Determine the candidate processor corresponding to the virtual operator; In response to the virtual operator meeting the preset activation conditions, an idle processing unit is selected from the candidate processors according to the preset heterogeneous resource allocation rules to serve as the execution carrier of the virtual operator; By using an event-driven mechanism and the operator execution order information, the virtual operator execution carrier corresponding to each candidate processor in each candidate processor is scheduled to execute each subtask sequentially, so as to obtain the task execution result corresponding to the input data.

2. The method according to claim 1, wherein, The step of determining the candidate processor corresponding to each virtual operator in the virtual operator set based on the mapping configuration of the execution relationship between the characterization operator and the execution processor includes: The mapping configuration is transformed to obtain a mapping table and a processor weight table; For each virtual operator in the set of virtual operators, the following processor selection step is performed: Determine the operator type and input data characteristics of the virtual operator; In response to the fact that the operator type has a unique corresponding result in the mapping table, the processors that have a mapping relationship with the virtual operator in the mapping table are determined as candidate processors; In response to the fact that the operator type has multiple corresponding results in the mapping table, the following processor first determination step is performed: Identify multiple processors corresponding to the operator type to obtain a candidate processor sequence; The weight coefficients of all candidate processors in the candidate processor sequence are retrieved from the processor weight table to obtain the candidate processor weight coefficient set. The load factor is determined based on the input data characteristics and load parameters, wherein the load parameters are obtained in real time; Based on the candidate processor weight coefficient set and the load factor, the comprehensive score of the candidate processor is determined to obtain the candidate processor; In response to the fact that the operator type has no corresponding result in the mapping table, the following processor second determination step is performed: Feature extraction is performed on the virtual operator to obtain the virtual operator feature vector; The similarity between the virtual operator feature vector and the corresponding capability vector of the processor is determined to obtain candidate processors, wherein the capability vector is a feature vector that quantifies the multi-dimensional description of the processor's hardware characteristics.

3. The method according to claim 1, wherein, The step of determining the operator execution order information corresponding to each virtual operator in the virtual operator set based on the task node dependency relationship corresponding to the subtask information set includes: Construct a task dependency graph based on the subtask information set; Perform a topological sort on the task dependency graph to obtain a topological sort sequence; Based on critical path analysis, the topological sorting sequence is weighted to obtain the task execution sequence; Based on the task execution sequence, operator mapping is performed on the virtual operator set to generate operator execution order information.

4. The method according to claim 1, wherein, The step of selecting an idle processing unit from the candidate processors according to a preset heterogeneous resource allocation rule to serve as a virtual operator execution carrier includes: According to the preset heterogeneous resource allocation rules, resource access verification steps are performed through the memory virtualization layer: Determine the virtual operator address and virtual operator permissions corresponding to the virtual operator; Verify the mapping status between the virtual operator address and the physical address, and verify the permission content corresponding to the virtual operator permission; In response to the successful resource permission access verification, the address space verification step is executed: Determine the physical page corresponding to the virtual operator; Determine if the physical page has other tasks and whether the cross-processor shared flag of the physical page is valid; In response to the successful address space verification, the following resource binding steps are performed: Create a shared memory channel; Identify the idle processing units among the candidate processors; The virtual operator is bound to the idle processing unit through the shared memory channel to obtain a task execution unit, which serves as the execution carrier for the virtual operator.

5. The method according to claim 1, wherein, The step of scheduling the virtual operator execution carrier corresponding to each candidate processor in each candidate processor to perform the sequential execution of each subtask through the event-driven mechanism and the operator execution order information includes: Based on the operator execution order information, construct an event mapping table; The virtual operator execution carrier is bound to the corresponding event signal in the event mapping table to obtain a chained task; In response to task event activation, perform the following operations on the chained tasks: Determine the virtual operator execution carrier corresponding to the task event in the chained task to obtain the task execution carrier; Generate the execution instructions corresponding to the task event; The execution instructions are added to the task execution carrier to process task events.

6. A computing pool event-driven scheduling device for multi-core heterogeneous processors, comprising: The task graph decoupling unit is configured to decouple the task nodes of the original task flowchart to obtain a set of virtual operators and a set of subtask information with standardized interfaces. The mapping configuration unit is configured to determine the candidate processor corresponding to each virtual operator in the virtual operator set based on the mapping configuration representing the execution relationship between the operator and the execution processor; The execution determination unit is configured to determine the operator execution order information corresponding to each virtual operator in the virtual operator set based on the task node dependency relationship corresponding to the subtask information set. The resource allocation unit is configured to perform a heterogeneous resource allocation step for each virtual operator in the set of virtual operators: Determine the candidate processor corresponding to the virtual operator; In response to the virtual operator meeting the preset activation conditions, an idle processing unit is selected from the candidate processors according to the preset heterogeneous resource allocation rules to serve as the execution carrier of the virtual operator; The event-driven unit is configured to schedule the virtual operator execution carrier corresponding to each candidate processor in each candidate processor to perform the sequential execution of each subtask through the event-driven mechanism and the operator execution order information, so as to obtain the task execution result corresponding to the input data.

7. An electronic device, comprising: One or more processors; Storage device, on which one or more programs are stored, When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-5.

8. A computer-readable medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1-5.

Images