Heterogeneous computing power scheduling method and system

Abstract

The application is suitable for the technical field of computers, and provides a heterogeneous computing power scheduling method and system, wherein the heterogeneous computing power scheduling method comprises the following steps: analyzing a computing graph of a to-be-scheduled task; acquiring a communication data volume corresponding to each data dependency edge as a communication cost weight; acquiring a computing density weight corresponding to each subtask node; constructing an execution domain affinity matrix according to the communication cost weight and the computing density weight; dividing the computing graph into a plurality of execution domain sets based on a preset cost model, so that a global cost function is minimized; and binding and scheduling each execution domain to match a corresponding heterogeneous computing resource according to the execution domain sets obtained through the division. The application optimizes the overall matching relationship based on the task dependency strength and the resource difference characteristics, realizes the structural adaptation and collaborative allocation of the subtasks and the heterogeneous resources, and reduces the performance loss caused by cross-domain communication and resource mismatch from the source.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a heterogeneous computing power scheduling method. Background Technology

[0002] With the rapid development of fields such as artificial intelligence, scientific computing, and big data processing, the demand for computing power has exploded. Single-architecture computing processors can no longer meet the dual requirements of high performance and low power consumption. Against this backdrop, efficiently scheduling and managing diverse computing resources to maximize task execution efficiency has become a key challenge. Traditional scheduling methods often focus only on load balancing of computing resources or single-dimensional performance metrics, neglecting communication overhead between heterogeneous resources, data dependencies, and the structural characteristics within tasks. This leads to significant shortcomings when handling complex tasks containing multiple subtasks and their data dependencies.

[0003] Specifically, existing scheduling methods typically allocate resources to computing tasks as a whole or only based on load balancing. They lack the ability to model the internal computing graph structure of tasks and fail to establish a unified mapping between the data dependencies between subtasks and the physical resource topology. When subtasks with strong data dependencies are assigned to different physical nodes or different types of computing units, a large amount of cross-domain data transmission will be generated, resulting in a significant increase in communication overhead. Therefore, how to achieve collaborative scheduling between task structure and resource structure in a heterogeneous computing environment to improve overall computing efficiency is the technical problem that this invention aims to solve. Summary of the Invention

[0004] The purpose of this invention is to provide a heterogeneous computing power scheduling method to solve the above-mentioned problems.

[0005] This invention provides a heterogeneous computing power scheduling method, which is applied to a pooled cluster containing at least two heterogeneous computing resources, including CPU, GPU, NPU, and FPGA. The method includes: S1. Parse the computation graph of the task to be scheduled, wherein the computation graph consists of a set of subtask nodes and a set of data dependency edges; S2. Obtain the amount of communication data corresponding to each data dependency edge, and use it as the communication cost weight; S3. Obtain the computation density weight corresponding to each subtask node. The computation density weight is obtained by dividing the total computation amount of the subtask by the total amount of data to be accessed. S4. Based on the communication cost weight and the computation density weight, construct an execution domain affinity matrix. Any element in the execution domain affinity matrix is ​​used to characterize the comprehensive benefit brought about by the joint execution of any two subtasks in the same supernode. S5. Based on a preset cost model, the computation graph is divided into several execution domain sets to minimize the global cost function. The global cost function is calculated as follows: the sum of the computation time of all subtasks is multiplied by a first weight coefficient, plus the sum of the cross-domain communication time between subtasks belonging to different execution domains is multiplied by a second weight coefficient, plus the number of execution domains minus 1 is multiplied by a preset synchronization overhead baseline value and then multiplied by a third weight coefficient. Among these, the communication time between subtasks belonging to the same execution domain is considered zero, and the communication time between subtasks belonging to different execution domains is calculated based on the communication data volume of the corresponding subtask pair and the topology attenuation factor. S6. Based on the set of execution domains obtained from the partitioning, match the corresponding heterogeneous computing resources for each execution domain and bind and schedule them.

[0006] As a further aspect of the present invention, in step S4, any element in the execution domain affinity matrix... It is calculated in the following way: Get the amount of communication data between the first subtask and the second subtask. As the first factor; Obtain the computation density weights of the first subtask Computation density weights of the second subtask The sum of these factors serves as the second factor. Divide the first factor by the second factor to obtain the intermediate ratio. ; Obtain the topology decay factor between the first and second subtasks. ; The intermediate ratio Multiply by the aforementioned topological attenuation factor The element values ​​corresponding to the first subtask and the second subtask in the execution domain affinity matrix are obtained. .

[0007] As a further aspect of the present invention, the topological attenuation factor The value is pre-set based on the physical proximity of the first and second subtasks. The specific value rules are as follows: when the two subtasks are located on the same physical node, the value is 1; when they are located on different nodes but connected through a high-speed interconnect bus, the value is 0.6; and when they are located on different nodes and connected only through a general network, the value is 0.1.

[0008] As a further aspect of the present invention, in step S5, the cross-domain communication time between subtasks belonging to different execution domains is... Calculated in the following way: Get subtasks sub-tasks Communication data volume between ; Get subtasks sub-tasks Available bandwidth between computing units ; Get subtasks sub-tasks Topological attenuation factor between ; The amount of communication data Divide by the available bandwidth Then multiply by the aforementioned topological attenuation factor The cross-domain communication time was obtained. .

[0009] As a further aspect of the present invention, in step S5, the computation time of the subtask is... Calculated in the following way: Get subtasks Total computational load The unit is the number of floating-point operations; Get as a subtask Peak computing performance of allocated computing units The unit is floating-point operations per second; The total computational load Divide by the calculated peak performance The computation time of the subtask is obtained. .

[0010] As a further aspect of the present invention, in step S5, the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient are dynamically adjusted according to the cluster hardware environment, specifically including: When the proportion of high-speed interconnect buses in the cluster is detected to be higher than a preset threshold, the second weighting coefficient is reduced. When the average delay of cross-node synchronization operation is detected to be higher than a preset threshold, the third weighting coefficient is increased.

[0011] As a further aspect of the present invention, in step S6, after matching corresponding heterogeneous computing resources to each execution domain according to the partitioned execution domain set and binding and scheduling them, the method further includes: During the task execution phase, historical time-series data of link bandwidth are collected in real time, and the predicted value of available bandwidth for the next time window is calculated through a sliding window prediction model. Based on the predicted available bandwidth, the optimal communication block size is calculated. The optimal communication block size is the maximum value that satisfies the following constraint: the communication time obtained by dividing the block size by the predicted available bandwidth is not greater than the smaller of the computation time required for the next computation stage and the synchronization waiting time allowed by the task. The data to be transmitted is divided according to the optimal communication block size, and the divided data blocks are sequentially inserted into the idle time slots of the computing pipeline for transmission, so that the data transmission process and the numerical calculation process overlap in parallel on the timeline.

[0012] The present invention also provides a heterogeneous computing power scheduling system, which is used to implement the heterogeneous computing power scheduling method described above. The system includes: The parsing module is used to parse the computation graph of the task to be scheduled, which consists of a set of subtask nodes and a set of data dependency edges; The communication data analysis module is used to obtain the amount of communication data corresponding to each data dependency edge, which is used as the communication cost weight. The density weight determination module is used to obtain the computational density weight corresponding to each subtask node. The computational density weight is obtained by dividing the total computational amount of the subtask by the total amount of data to be accessed. The affinity analysis module is used to construct an execution domain affinity matrix based on the communication cost weight and the computation density weight. Any element in the execution domain affinity matrix is ​​used to characterize the comprehensive benefit brought about by the joint execution of any two subtasks in the same supernode. The minimization processing module is used to divide the computation graph into several execution domain sets based on a preset cost model, so as to minimize the global cost function. The global cost function is calculated as follows: the sum of the computation time of all subtasks is multiplied by a first weight coefficient, plus the sum of the cross-domain communication time between subtasks belonging to different execution domains is multiplied by a second weight coefficient, plus the number of execution domains minus 1 is multiplied by a preset synchronization overhead baseline value, and then multiplied by a third weight coefficient. Among them, the communication time between subtasks belonging to the same execution domain is considered to be zero, and the communication time between subtasks belonging to different execution domains is calculated based on the communication data volume of the corresponding subtask pair and the topology attenuation factor. The scheduling and execution module is used to match and bind heterogeneous computing resources to each execution domain according to the set of execution domains obtained from the division. As a further aspect of the present invention, in the affinity analysis module, any element in the execution domain affinity matrix... It is calculated in the following way: Get the amount of communication data between the first subtask and the second subtask. As the first factor; Obtain the computation density weights of the first subtask Computation density weights of the second subtask The sum of these factors serves as the second factor. Divide the first factor by the second factor to obtain the intermediate ratio. ; Obtain the topology decay factor between the first and second subtasks. ; The intermediate ratio Multiply by the aforementioned topological attenuation factor The element values ​​corresponding to the first subtask and the second subtask in the execution domain affinity matrix are obtained. .

[0013] As a further aspect of the present invention, the topological attenuation factor The value is pre-set based on the physical proximity of the first and second subtasks. The specific value rules are as follows: when the two subtasks are located on the same physical node, the value is 1; when they are located on different nodes but connected through a high-speed interconnect bus, the value is 0.6; and when they are located on different nodes and connected only through a general network, the value is 0.1.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention performs structured analysis of the task computation graph and establishes a unified computation-communication integrated cost model. This enables the scheduling process to be optimized based on the overall matching relationship between task dependency strength and resource differences, rather than solely on load or a single performance indicator. This achieves structural adaptation and collaborative allocation of subtasks and heterogeneous resources, reducing performance losses caused by cross-domain communication and resource mismatch from the source. When dealing with complex tasks, the execution process is more coherent and efficient, the overall execution time is effectively compressed, and the system resource utilization is significantly improved. This fundamentally improves the scheduling efficiency and execution performance of complex tasks in heterogeneous computing environments. Attached Figure Description

[0015] Figure 1 The flowchart shows the heterogeneous computing power scheduling method. Figure 2 This is a block diagram of the heterogeneous computing power scheduling system. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0017] The specific implementation of the present invention will be described in detail below with reference to specific embodiments.

[0018] Figure 1 A flowchart of a heterogeneous computing power scheduling method is shown, providing an embodiment of the present invention. This method is applied to a pooled cluster containing at least two types of heterogeneous computing resources, including CPU, GPU, NPU, and FPGA (a pooled cluster refers to a collection of computing resources that centrally manages and uniformly schedules multiple heterogeneous computing resources. In this cluster, computing resources are abstracted as resource pools that can be allocated on demand to support computing tasks of different types and scales). The method includes: S1. Parse the computation graph of the task to be scheduled, wherein the computation graph consists of a set of subtask nodes and a set of data dependency edges; S2. Obtain the amount of communication data corresponding to each data dependency edge, and use it as the communication cost weight; S3. Obtain the computation density weight corresponding to each subtask node. The computation density weight is obtained by dividing the total computation amount of the subtask by the total amount of data to be accessed. S4. Based on the communication cost weight and the computation density weight, construct an execution domain affinity matrix. Any element in the execution domain affinity matrix is ​​used to characterize the comprehensive benefit brought about by the joint execution of any two subtasks in the same supernode. S5. Based on a preset cost model, the computation graph is divided into several execution domain sets to minimize the global cost function. The global cost function is calculated as follows: the sum of the computation time of all subtasks is multiplied by a first weight coefficient, plus the sum of the cross-domain communication time between subtasks belonging to different execution domains is multiplied by a second weight coefficient, plus the number of execution domains minus 1 is multiplied by a preset synchronization overhead baseline value and then multiplied by a third weight coefficient. Among these, the communication time between subtasks belonging to the same execution domain is considered zero, and the communication time between subtasks belonging to different execution domains is calculated based on the communication data volume of the corresponding subtask pair and the topology attenuation factor. S6. Based on the set of execution domains obtained from the partitioning, match the corresponding heterogeneous computing resources for each execution domain and bind and schedule them.

[0019] First, in step S1, the computation graph of the task to be scheduled is parsed. This computation graph consists of a set of subtask nodes and a set of data dependency edges. For example, a scientific computing task can be decomposed into multiple independent computation modules (subtask nodes), such as matrix multiplication, Fourier transform, or data filtering, which are connected by data flows (data dependency edges). The parsing process can use static analysis tools to scan the task code, identify function calls and data structure accesses, and thus automatically construct the computation graph. Alternatively, the task developer can manually define the structure of the computation graph and submit it through a specific description language or API interface. Through in-depth parsing of the task's internal structure, the scheduling system can obtain fine-grained information about the task, laying the foundation for subsequent fine-grained scheduling.

[0020] Further, in step S2, the communication data volume corresponding to each data dependency edge is obtained and used as the communication cost weight. For example, if two subtasks need to transfer an intermediate result of size 1GB, then the communication data volume corresponding to that data dependency edge is 1GB. This communication data volume can be directly extracted from the definition of the computation graph, for example, by analyzing the size of the data structure or the capacity of the message queue. In some cases, the actual communication data volume can also be estimated by pre-running or simulating the tasks. This communication cost weight is a key indicator for evaluating the data transmission overhead between subtasks.

[0021] Subsequently, in step S3, the computation density weight corresponding to each subtask node is obtained. This computation density weight is obtained by dividing the total computation of the subtask by the total amount of data that needs to be accessed. For example, a subtask that performs a large number of floating-point operations but only accesses a small amount of input data will have a high computation density weight, indicating that it is a computationally intensive task. Conversely, a subtask that needs to read a large amount of data but has relatively simple computational operations will have a low computation density weight, indicating that it is a data-intensive task. The total computation can be estimated through static code analysis or dynamic performance profiling, while the total amount of data that needs to be accessed can be obtained by analyzing the input and output data scale of the subtask. This computation density weight helps to identify the computational characteristics of the subtask so that it can be matched with the most suitable heterogeneous computing resources.

[0022] Building upon this, in step S4, an execution domain affinity matrix is ​​constructed based on communication cost weights and computation density weights. Each element in this matrix represents the overall benefit of jointly executing any two subtasks within the same supernode (a logical execution unit composed of multiple heterogeneous computing units connected by a high-speed interconnect bus). For example, if two subtasks have significant data dependencies and similar computation density weights, assigning them to the same supernode may reduce communication overhead and improve collaboration efficiency, resulting in a higher benefit value in the affinity matrix. The execution domain affinity matrix is ​​a two-dimensional matrix where each element represents the overall benefit that may result from jointly executing any two subtasks within the same supernode. This matrix comprehensively considers the communication cost and computation density between subtasks to evaluate the potential efficiency improvement from subtask aggregation. The matrix can be constructed using various heuristics, such as simply performing a weighted sum or product of the communication cost weights and computation density weights to quantify the "affinity" between subtasks.

[0023] Next, in step S5, based on a preset cost model, the computation graph is divided into several execution domain sets to minimize the global cost function. This global cost function is calculated as follows: the sum of the computation times of all subtasks multiplied by a first weighting coefficient, plus the sum of the cross-domain communication times between subtasks belonging to different execution domains multiplied by a second weighting coefficient, plus the number of execution domains minus 1 multiplied by a preset synchronization overhead baseline value, and then multiplied by a third weighting coefficient. The communication time between subtasks belonging to the same execution domain is considered zero, while the communication time between subtasks belonging to different execution domains is calculated based on the communication data volume of the corresponding subtask pair and the topology attenuation factor. For example, graph cutting algorithms or clustering algorithms can be used to perform the partitioning, aiming to maximize internal communication volume and minimize external communication volume within the partitioned execution domains, and to balance the computational load of each execution domain. The computation time of a subtask can be roughly estimated based on its estimated computational volume and the theoretical peak performance of the target computing unit. The cross-domain communication time can be simply estimated by dividing the communication data volume by an average bandwidth value. The weighting coefficients can be calibrated based on empirical values ​​or historical data. By minimizing this global cost function, comprehensive optimization of computation, communication, and synchronization overhead can be achieved.

[0024] Finally, in step S6, based on the divided set of execution domains, each execution domain is matched with corresponding heterogeneous computing resources for binding and scheduling. For example, an execution domain mainly containing matrix multiplication subtasks can be matched to GPU resources with high-performance floating-point operations; while an execution domain mainly containing logical judgments and control flow may be matched to CPU resources. The matching process can be based on resource availability, load conditions, and the computational characteristics required by the execution domain. For example, a greedy algorithm can be used to prioritize allocating resources to execution domains with the most urgent computational needs or the highest resource matching degree. Another approach is to use a predefined resource pool strategy to fix specific types of execution domains to specific types of heterogeneous resources. This binding scheduling ensures that each execution domain can execute efficiently on the heterogeneous computing resources most suitable for its characteristics.

[0025] In a preferred embodiment of the present invention, in step S4, any element in the execution domain affinity matrix... It is calculated in the following way: Get the amount of communication data between the first subtask and the second subtask. As the first factor; Obtain the computation density weights of the first subtask Computation density weights of the second subtask The sum of these factors serves as the second factor. Divide the first factor by the second factor to obtain the intermediate ratio. ; Obtain the topology decay factor between the first and second subtasks. ; The intermediate ratio Multiply by the aforementioned topological attenuation factor The element values ​​corresponding to the first subtask and the second subtask in the execution domain affinity matrix are obtained. .

[0026] In this embodiment, the amount of communication data between the first subtask and the second subtask is obtained. As the first factor, it aims to quantify the overhead of data transmission between two subtasks. This amount of communication data can be determined, for example, by statically analyzing the data dependency edges in the computation graph, i.e., identifying the total amount of data when the output data of one subtask is used as the input data of another; or, it can be estimated by simulating the operation before task execution or based on historical data statistics.

[0027] Obtain the computation density weights of the first subtask Computation density weights of the second subtask The sum, as the second factor, reflects the computational intensity of the subtask and is used to balance computational resource requirements and communication overhead. This computational density weight can be calculated, for example, based on the type of subtask (such as matrix multiplication, convolution operations, data transformation, etc.) and the scale of the data it processes, using a preset empirical formula or machine learning model; or, it can be obtained by performing performance profiling on the subtask, measuring its total computational load (e.g., number of floating-point operations) and the total amount of data accessed, and then calculating the ratio between the two.

[0028] Divide the first factor by the second factor to obtain the intermediate ratio. This step aims to dynamically adjust the weights of communication overhead and computational intensity, thereby avoiding bias in affinity assessment caused by a single factor. Specifically, this ratio is obtained by performing a numerical division operation with the amount of communication data (the first factor) as the numerator and the sum of the density weights (the second factor) as the denominator.

[0029] Obtain the topology decay factor between the first and second subtasks. The purpose is to consider the impact of physical location on communication latency in order to accurately capture the constraints of network topology on communication efficiency. This topology attenuation factor can be set, for example, according to a preset rule table or configuration, based on the physical proximity of two subtasks (e.g., whether they are located on the same physical node, whether they are connected via a high-speed interconnect bus, or whether they are only connected via a general network); or, it can be used to assess the data transmission latency and available bandwidth between different physical locations through real-time probing or historical data analysis, and dynamically calculate or adjust the topology attenuation factor accordingly.

[0030] The intermediate ratio Multiply by the aforementioned topological attenuation factor The element values ​​corresponding to the first subtask and the second subtask in the execution domain affinity matrix are obtained. This step aims to comprehensively consider all relevant factors to generate an accurate affinity value, effectively guiding the partitioning of the execution domain. Specifically, this element value is obtained by numerically multiplying the intermediate ratio with the topological attenuation factor.

[0031] This application's solution, through the aforementioned calculation method, provides a mechanism for quantifying the comprehensive benefits of jointly executing any two subtasks within the same supernode. This mechanism first utilizes a first factor... This directly reflects the overhead of data transfer between subtasks. A large amount of communication data means that if these two subtasks are assigned to different execution domains, significant communication costs will occur. Therefore, this factor emphasizes the necessity of placing them together to reduce cross-domain communication. Secondly, through the second factor... This reflects the overall computational intensity of the two subtasks, which helps balance computational resource requirements and communication overhead. When both subtasks have high computational density, they may require more computational resources, in which case the affinity may be relatively low to avoid resource contention. The intermediate ratio is obtained by dividing the first factor by the second factor. This scheme dynamically adjusts the weights of communication overhead and computational intensity in affinity evaluation, enabling the affinity value to more comprehensively reflect the collaborative potential between subtasks and avoiding evaluation biases that may result from a single factor. Based on this, a topology attenuation factor is introduced. Furthermore, the actual impact of the physical proximity of subtasks on communication efficiency was considered. For example, when two subtasks are located on the same physical node, the communication latency is extremely low, and the topology attenuation factor may take a high value; while when they are connected through a general network, the communication latency is high, and the topology attenuation factor takes a low value. Finally, the intermediate ratio was... With topological attenuation factor Multiplication yields the element values ​​in the execution domain affinity matrix. This element value integrates multiple dimensions such as communication overhead, computational intensity, and physical topology, enabling a more accurate representation of the combined benefits of jointly executing two subtasks within the same supernode. Through this multi-dimensional and refined quantification method, this approach overcomes the limitations of traditional methods that lack specific computational methods in affinity assessment, providing a more reliable and accurate basis for subsequent execution domain partitioning (S5). This minimizes the global cost function and ultimately improves the overall efficiency and optimization effect of heterogeneous computing power scheduling.

[0032] As a preferred embodiment of the present invention, the topological attenuation factor The value is pre-set based on the physical proximity of the first and second subtasks. The specific value rules are as follows: when the two subtasks are located on the same physical node, the value is 1; when they are located on different nodes but connected through a high-speed interconnect bus, the value is 0.6; and when they are located on different nodes and connected only through a general network, the value is 0.1.

[0033] In this embodiment, the topological attenuation factor This is a multiplicative factor used to quantify the communication efficiency or overhead between two subtasks. It reflects the impact of the relative positions of the subtasks on physical computing resources on data transmission performance. Pre-setting means that before the scheduling process begins, this factor is assigned a value based on the cluster's physical topology and the potential deployment locations of the subtasks. This ensures that when evaluating the affinity or communication time between subtasks, the differences in communication performance caused by the physical topology are fully considered, thus making the scheduling scheme closer to reality. This pre-setting can be configured manually by the system administrator based on the cluster's physical cabling diagram and network device types, setting corresponding attenuation factors for subtasks with different proximity levels; alternatively, it can be automated by tools that automatically detect the physical connection types between computing nodes during cluster initialization or topology changes and generate topology attenuation factors according to preset mapping rules.

[0034] The specific value rules are designed to accurately reflect the communication overhead under different levels of physical proximity. When two subtasks are located on the same physical node, such as between a CPU and a GPU within the same server, or between different computing cores within the same GPU, the communication efficiency is highest due to the shortest data transmission path, lowest latency, and greatest communication efficiency. Therefore, the topology attenuation factor is used. Setting it to 1 indicates that communication experiences almost no additional attenuation. This ensures that the advantages of intra-node communication are fully reflected when calculating execution domain affinity, encouraging strongly related subtasks to be scheduled to the same node whenever possible. In implementation, the system can maintain a mapping between physical node IDs and subtask IDs. When two subtasks have the same physical node ID, they are determined to be located on the same physical node and assigned a topology attenuation factor of 1.

[0035] When two subtasks reside on different physical nodes, but these nodes are connected via a high-speed interconnect bus, although there is cross-node communication overhead, the high-speed interconnect provides bandwidth far exceeding that of a general-purpose network and lower latency. In this case, the topology attenuation factor... A topology attenuation factor of 0.6 quantifies this moderate level of communication attenuation. This allows the scheduler to identify and leverage the advantages of high-speed interconnects, prioritizing nodes connected via high-speed interconnects during cross-node scheduling to reduce the impact of communication on overall performance. The system can identify node pairs in the cluster that support high-speed interconnects, for example, by detecting network interface types or querying network topology configuration. When a subtask is assigned to different nodes connected via such high-speed interconnects, its topology attenuation factor is set to 0.6.

[0036] Furthermore, when two subtasks reside on different physical nodes and are connected only via a common network (such as standard Ethernet), the communication overhead increases significantly due to the typically high latency and relatively low bandwidth of the common network. In this case, the topology attenuation factor... A topology attenuation factor of 0.1 reflects significant communication attenuation. This prompts the scheduler to avoid assigning strongly related subtasks to different nodes connected only by a common network when partitioning execution domains and matching resources, thus effectively avoiding performance bottlenecks caused by high communication overhead. For all cases not belonging to the "same physical node" and "high-speed interconnect bus connection," i.e., connected by the default common network connection, the topology attenuation factor is set to 0.1.

[0037] The solution in this application, through the aforementioned explicit value rules, enables the topological attenuation factor to... Able to be accurately integrated into the execution domain affinity matrix In the calculation. At that time, the amount of communication data between the first subtask and the second subtask Divide by the sum of their calculated density weights To obtain the median ratio Then Multiply by this topology attenuation factor, which is set based on physical proximity. This calculation method makes It not only considers data volume and computational density, but more importantly, it accurately reflects the actual impact of physical topology on communication efficiency. Therefore, when partitioning the computation graph based on the execution domain affinity matrix, it can more accurately evaluate the comprehensive benefits of joint execution of subtasks, thereby generating a more optimized set of execution domains and ultimately achieving more efficient heterogeneous computing power scheduling.

[0038] In a preferred embodiment of the present invention, in step S5, the cross-domain communication time between subtasks belonging to different execution domains is... Calculated in the following way: Get subtasks sub-tasks Communication data volume between ; Get subtasks sub-tasks Available bandwidth between computing units ; Get subtasks sub-tasks Topological attenuation factor between ; The amount of communication data Divide by the available bandwidth Then multiply by the aforementioned topological attenuation factor The cross-domain communication time was obtained. .

[0039] In this embodiment, the subtask is obtained. sub-tasks Communication data volume between This refers to determining the subtasks in the computation graph. sub-tasks The total amount of data required for data-dependent transmission between subtasks. This data volume is the basis for quantifying communication overhead and directly affects transmission time. It can be obtained in ways including, but not limited to: estimating or calculating the data transmission volume between subtasks by statically analyzing the data flow and data type in the computation graph; dynamically monitoring and recording the actual amount of data transmitted by performing simulation or sampling runs before task execution; or, explicitly specifying the data dependencies and their data volumes between subtasks in the task description file when the task is submitted by the user or developer.

[0040] Get subtasks sub-tasks Available bandwidth between computing units This refers to a subtask at a specific moment. Kazuko's Mission The available network bandwidth between allocated computing units is the actual bandwidth available for data transmission. This available bandwidth is a key factor determining the data transmission rate and reflects the real-time status of network resources. It can be obtained through methods including, but not limited to: collecting bandwidth data of links between different computing units in the cluster in real time using network monitoring tools and calculating it by averaging or weighted averaging; or predicting the available bandwidth for a future time window based on historical data and predictive models; or estimating the available bandwidth by periodically sending probe packets between computing units to measure the actual transmission rate.

[0041] Get subtasks sub-tasks Topological attenuation factor between This is a coefficient between 0 and 1 used to quantify the impact of physical topology on communication time between subtasks, reflecting the differences in communication efficiency under different connection methods. This factor incorporates the non-ideals of physical topology (such as latency and congestion) into the communication time calculation, making the estimation more realistic. Its acquisition methods can include, but are not limited to, based on subtasks. sub-tasks The proximity of the allocated computing units in the physical architecture is pre-set. For example, when two subtasks are located on the same physical node, the value can be close to 1, indicating high communication efficiency; when they are located on different nodes but connected through a high-speed interconnect bus, the value can be moderate, indicating some communication overhead; when they are located on different nodes and connected only through a general network, the value can be small, indicating large communication overhead; or, based on the type of different interconnect links in the cluster and their theoretical bandwidth and actual latency characteristics, different attenuation factors are preset for each link type; or, during the cluster deployment phase, benchmark tests are conducted on different topology paths to measure their average communication latency and throughput, and then the corresponding attenuation factors are calculated based on these test results.

[0042] The amount of communication data Divide by the available bandwidth Then multiply by the aforementioned topological attenuation factor The cross-domain communication time was obtained. This is a calculation formula used to comprehensively consider the impact of data volume, network bandwidth, and physical topology to derive the estimated time for data transmission between subtasks. This calculation is the core step in integrating the three independent factors mentioned above into a single communication time metric, providing accurate input to the global cost function. This calculation can be performed directly in the mathematical model within the scheduler as part of the global cost function; or it can be calculated through a dedicated communication time estimation module and the results provided to the scheduler; alternatively, in a distributed system, each computing unit can calculate the communication time between itself and its neighboring computing units and aggregate this information to the central scheduler.

[0043] In a preferred embodiment of the present invention, in step S5, the computation time of the sub-task is... Calculated in the following way: Get subtasks Total computational load The unit is the number of floating-point operations; Get as a subtask Peak computing performance of allocated computing units The unit is floating-point operations per second; The total computational load Divide by the calculated peak performance The computation time of the subtask is obtained. .

[0044] In this embodiment, the subtask is obtained. Total computational load The unit is floating-point operations, which refers to the quantization of subtasks. The total number of floating-point operations required during execution. This represents the subtask. The inherent computational requirements are independent of the hardware on which they will be executed. This total computational load... It can be obtained in a variety of ways. For example, for subtasks with known algorithmic structures (such as matrix multiplication or convolutional neural network layers), the calculation can be made accurately by statically analyzing their input size and algorithmic complexity. Alternatively, for more complex and dynamically changing subtasks, the number of floating-point operations can be measured by running them on a reference hardware platform and using performance analysis tools (such as hardware performance counters) for dynamic profiling.

[0045] Get as a subtask Peak computing performance of allocated computing units , measured in floating-point operations per second (Floating-Point Operations Per Second), refers to the maximum number of floating-point operations per second that a specific heterogeneous computing resource (such as a CPU core, GPU stream processor, NPU engine, or FPGA logic unit) can perform under ideal conditions. This parameter directly reflects the computing power of the allocated hardware and is a key indicator for evaluating its processing speed. Peak computing performance This information can be obtained from the technical specifications provided by the hardware manufacturer, or it can be measured by running standard benchmark programs (such as LINPACK) on the actual computing units. In addition, to address potential dynamic performance changes in computing units within the cluster (such as due to load, temperature, etc.), the current effective peak computing performance of the computing units can be obtained by monitoring their performance counters in real time.

[0046] The total computational load Divide by the calculated peak performance The computation time of the subtask is obtained. This is based on the computational requirements of the subtask and the computing power of the allocated hardware, directly estimating the execution time required. It is a direct arithmetic operation, and its result... This represents the subtask under ideal conditions. The theoretical shortest time required to complete a calculation on a specified computing unit.

[0047] The solution in this application obtains subtasks. Total computational load Quantify subtasks The computational requirements laid the foundation for time-consuming calculations. Meanwhile, acquisition was designated as a subtask. Peak computing performance of allocated computing units It considers the performance characteristics of actually allocated resources, rather than general or average performance values, thus avoiding estimation bias caused by resource heterogeneity. The total computational load... Divide by the calculated peak performance It directly performs division operations based on actual parameters to generate an accurate time consumption value, ensuring that this value serves as a reliable input in the global cost function and supporting precise optimization of the scheduling scheme. This calculation method ensures the computation time... This approach accurately reflects the execution efficiency of subtasks on specific heterogeneous computing units, thus providing a more precise input for the global cost function. In the aforementioned heterogeneous computing scheduling method, the global cost function is calculated by multiplying the sum of the computation times of all subtasks by a first weighting coefficient, adding the sum of the cross-domain communication times between subtasks belonging to different execution domains by a second weighting coefficient, adding the number of execution domains minus 1, multiplying by a preset synchronization overhead baseline value, and then multiplying by a third weighting coefficient. This precise calculation of the computation time of each subtask ensures a more accurate representation of the computational efficiency of each task. This allows the global cost function to more accurately evaluate the merits of different scheduling schemes, thereby enabling a more effective minimization of the global cost function when dividing the execution domain set, and ultimately matching each execution domain with the most suitable heterogeneous computing resources for binding and scheduling.

[0048] In a preferred embodiment of the present invention, step S5, in which the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient are dynamically adjusted according to the cluster hardware environment, specifically includes: Specifically, the first, second, and third weighting coefficients mentioned above are used in the global cost function to balance computation time, cross-domain communication time, and synchronization overhead. Dynamic adjustment means that these coefficients are no longer fixed values, but are corrected according to real-time or periodic changes in the cluster environment to ensure that the cost function can more accurately reflect the actual overhead under the current cluster state, thereby guiding a better scheduling scheme. Specifically, a separate monitoring module can periodically collect cluster hardware environment data and calculate new weighting coefficients according to a preset strategy or machine learning model, and then update them in the scheduler. Alternatively, before each scheduling task, the scheduler can query the cluster environment parameters in real time and calculate the weighting coefficients applicable to the current environment in real time according to a set of dynamic adjustment rules (e.g., based on an expert system or fuzzy logic).

[0049] When the proportion of high-speed interconnect buses in the cluster exceeds a preset threshold, the second weighting coefficient is reduced. Specifically, the second weighting coefficient measures the importance of cross-domain communication time in the global cost function. When the proportion of high-speed interconnect buses (such as NVLink) in the cluster is high, it means that the overall communication capability of the cluster is strong, and the actual overhead of cross-domain communication is relatively low. Reducing the second weighting coefficient at this time can reduce the proportion of communication overhead in the global cost function, making the scheduler more inclined to allow more cross-domain communication when performing execution domain partitioning. This may result in more granular execution domain partitioning or more flexible utilization of computing resources without worrying too much about communication bottlenecks. The system can continuously monitor the type and bandwidth of all interconnect links in the cluster and count the proportion of high-speed interconnect buses (e.g., those with bandwidth exceeding a certain value, or belonging to specific technical standards such as InfiniBand EDR / HDR, PCIe Gen4 / Gen5 direct connection, etc.) to the total bandwidth or total number of all interconnect links. When this proportion exceeds a preset threshold, the second weighting coefficient is reduced. Alternatively, the overall communication performance of the cluster can be evaluated by periodically running network benchmark tests. If the test results show that the average communication latency or bandwidth of the cluster is significantly better than a certain benchmark value, it can be determined that the high-speed interconnect bus has a greater impact, and thus the second weighting coefficient should be reduced.

[0050] When the average latency of cross-node synchronization operations is detected to be higher than a preset threshold, the third weighting coefficient is increased. Specifically, the third weighting coefficient is used to measure the importance of cross-execution domain synchronization overhead in the global cost function. When the average latency of cross-node synchronization operations is high, it means that the synchronization cost between execution domains is high, and frequent synchronization operations will seriously slow down the overall execution efficiency of the task. Increasing the third weighting coefficient at this time can increase the proportion of synchronization overhead in the global cost function, prompting the scheduler to minimize the number of execution domains when dividing execution domains, or to divide subtasks that require frequent synchronization into the same execution domain as much as possible, so as to reduce the number of synchronizations and thus reduce the performance loss caused by synchronization. The scheduling system can have a built-in or integrated synchronization latency monitoring module, which measures and records the average synchronization latency by periodically executing small-scale cross-node synchronization test tasks in the cluster. When the average latency exceeds the preset threshold, the third weighting coefficient is increased. Alternatively, the average time of cross-node synchronization operations in actual tasks can be statistically analyzed by analyzing historical task execution logs. If the time is found to be consistently higher than a certain threshold, it is considered that the synchronization overhead in the current cluster environment is large, and the third weighting coefficient needs to be increased.

[0051] This application's solution addresses the scheduling inaccuracy caused by fixed weights under changing environments by dynamically adjusting the weight coefficients in the global cost function, thereby optimizing the global cost function. In the heterogeneous computing power scheduling method, the computation graph of the task to be scheduled is first analyzed to obtain communication cost weights and computation density weights, and an execution domain affinity matrix is ​​constructed. Subsequently, based on a preset cost model, the computation graph is divided into several execution domain sets, minimizing the global cost function. This global cost function comprehensively considers the computation time of all subtasks, the cross-domain communication time between subtasks belonging to different execution domains, and the synchronization overhead caused by the number of execution domains. To ensure the accuracy of this cost function in a dynamically changing cluster environment, this application introduces a dynamic adjustment mechanism for the weight coefficients. When the system detects that the proportion of high-speed interconnect buses in the cluster is higher than a preset threshold, it indicates that the cluster's communication capability is enhanced and the actual overhead of cross-domain communication is relatively reduced. At this time, the system will correspondingly reduce the second weight coefficient, reducing the proportion of communication overhead in the global cost function, thereby encouraging the scheduler to be more flexible in cross-domain communication when dividing execution domains to better utilize distributed computing resources. Conversely, when the average latency of cross-node synchronization operations exceeds a preset threshold, indicating that synchronization overhead has become a performance bottleneck, the system increases the third weight coefficient, increasing the proportion of synchronization overhead in the global cost function. This prompts the scheduler to minimize the number of execution domains or group strongly synchronized subtasks into the same execution domain when partitioning execution domains, thereby reducing the number of synchronizations and minimizing performance loss caused by synchronization. This dynamic adjustment mechanism allows the global cost function to adapt to changes in the cluster hardware environment in real time, ensuring the accuracy and effectiveness of execution domain partitioning. Consequently, when matching corresponding heterogeneous computing resources for binding and scheduling each execution domain, a better solution can be made.

[0052] In a preferred embodiment of the present invention, after step S6, which involves matching corresponding heterogeneous computing resources to each execution domain according to the partitioned execution domain set and binding and scheduling them, the method further includes: During the task execution phase, historical time-series data of link bandwidth is collected in real time, and the predicted available bandwidth for the next time window is calculated using a sliding window prediction model. Specifically, during task execution, the system needs to collect historical time-series data of link bandwidth in real time. This can be achieved by deploying a traffic monitoring agent at the network interface layer, which periodically records network performance indicators such as packet sending / receiving rates, latency, and packet loss rates. Alternatively, network performance counters provided by the operating system can be used to obtain real-time bandwidth usage. Furthermore, the available bandwidth of the link can be estimated by sending probe packets and measuring the round-trip time.

[0053] After acquiring historical time-series data, a sliding window prediction model is used to calculate the predicted available bandwidth for the next time window. This prediction model can employ statistical methods, such as autoregressive moving average models, exponential smoothing, or Kalman filtering, to predict future bandwidth values ​​by analyzing trends and periodicity in historical data. Alternatively, it can use machine learning-based prediction models, such as recurrent neural networks, long short-term memory networks, or temporal convolutional networks, to learn complex patterns of bandwidth changes and make predictions by training on historical time-series data.

[0054] Based on the predicted available bandwidth, the optimal communication block size is calculated. This optimal block size is the maximum value satisfying the following constraint: the communication time obtained by dividing the block size by the predicted available bandwidth is not greater than the smaller of the computation time required for the next computation stage and the allowed synchronization waiting time limit of the task. Specifically, the optimal communication block size is the maximum value satisfying a specific constraint: the communication time obtained by dividing the block size by the predicted available bandwidth is not greater than the smaller of the computation time required for the next computation stage and the allowed synchronization waiting time limit of the task. During the calculation, optimization algorithms such as iterative search or binary search can be used to find the value that maximizes the block size while satisfying the constraints. Alternatively, a lookup table or empirical formula can be pre-established to directly estimate the optimal block size based on the predicted available bandwidth, the computation time of the next computation stage, and the allowed synchronization waiting time limit of the task.

[0055] The data to be transmitted is divided according to the optimal communication block size, and the divided data blocks are sequentially inserted into the idle time slots of the computation pipeline for transmission, so that the data transmission process and the numerical computation process overlap in parallel on the timeline. Specifically, dividing the data to be transmitted according to the calculated optimal communication block size can be achieved through a data buffer management mechanism, which slices the original data stream according to the calculated optimal block size and generates a corresponding transmission request for each data block. Alternatively, a block segmenter module can be set at the data sending end, which dynamically divides the data stream into data blocks of a specified size based on the received optimal communication block size parameter.

[0056] Finally, the split data blocks are sequentially inserted into idle time slots in the computation pipeline for transmission, allowing the data transmission process and the numerical computation process to overlap in parallel on the timeline. This can be achieved by a scheduler monitoring the execution status of the computation units; when an idle time slot is detected in the computation pipeline, the data transmission module is immediately triggered to send a data block. Alternatively, a double-buffered or multi-buffered mechanism can be used, where the next data block is pre-transmitted to another buffer while the computation unit is processing the current data block, thus achieving seamless integration of computation and communication. Furthermore, a hardware DMA (Direct Memory Access) controller can be used to independently handle data block transmission when the CPU, GPU, or other computational cores are busy with computation, further improving parallelism.

[0057] This application's solution addresses the issue of low communication and computational parallel efficiency caused by dynamic changes in link bandwidth after heterogeneous computing resource binding scheduling by introducing a dynamic communication optimization mechanism during the task execution phase. Specifically, in the heterogeneous computing power scheduling method, an execution domain affinity matrix is ​​first constructed based on the computation graph, communication cost weights, and computation density weights. Then, based on the cost model, the computation graph is divided into several execution domains, and heterogeneous computing resources are matched and bound for scheduling in each execution domain. Furthermore, during the task execution phase, this application collects historical time-series data of link bandwidth in real time and uses a sliding window prediction model to predict the available bandwidth for the next time window. Based on this prediction, the system can dynamically calculate the optimal communication block size. This block size ensures that the data transmission time does not exceed the computation time of the next computation stage or the allowed synchronization waiting time limit of the task, thus preventing communication from becoming a bottleneck in the computation pipeline. Subsequently, the data to be transmitted is split according to this optimal block size, and these data blocks are cleverly inserted into the idle time slots of the computation pipeline for transmission. This mechanism enables efficient parallel overlap of data transmission and numerical computation on the timeline, greatly reducing the synchronization waiting time caused by bandwidth fluctuations, making full use of the bound heterogeneous computing resources, and thus significantly improving the overall task execution efficiency.

[0058] Figure 2 A block diagram of the heterogeneous computing power scheduling system is shown. As a preferred embodiment of the technical solution of the present invention, a heterogeneous computing power scheduling system is also provided, the system 10 comprising: Parsing module 11 is used to parse the computation graph of the task to be scheduled, wherein the computation graph consists of a set of subtask nodes and a set of data dependency edges; The communication data analysis module 12 is used to obtain the amount of communication data corresponding to each data dependency edge, which is used as the communication cost weight. The density weight determination module is used to obtain the computational density weight corresponding to each subtask node. The computational density weight is obtained by dividing the total computational amount of the subtask by the total amount of data to be accessed. Affinity analysis module 13 is used to construct an execution domain affinity matrix based on the communication cost weight and the computation density weight. Any element in the execution domain affinity matrix is ​​used to characterize the comprehensive benefit brought about by the joint execution of any two subtasks in the same supernode. The minimization processing module 14 is used to divide the computation graph into several execution domain sets based on a preset cost model, so as to minimize the global cost function. The global cost function is calculated as follows: the sum of the computation time of all subtasks is multiplied by a first weight coefficient, plus the sum of the cross-domain communication time between subtasks belonging to different execution domains is multiplied by a second weight coefficient, plus the number of execution domains minus 1 is multiplied by a preset synchronization overhead benchmark value and then multiplied by a third weight coefficient. Among them, the communication time between subtasks belonging to the same execution domain is considered to be zero, and the communication time between subtasks belonging to different execution domains is calculated based on the communication data volume of the corresponding subtask pair and the topology attenuation factor. The scheduling and execution module 15 is used to match the corresponding heterogeneous computing resources for each execution domain according to the set of execution domains obtained by division, and to bind and schedule them.

[0059] In the affinity analysis module, any element in the execution domain affinity matrix... It is calculated in the following way: Get the amount of communication data between the first subtask and the second subtask. As the first factor; Obtain the computation density weights of the first subtask Computation density weights of the second subtask The sum of these factors serves as the second factor. Divide the first factor by the second factor to obtain the intermediate ratio. ; Obtain the topology decay factor between the first and second subtasks. ; The intermediate ratio Multiply by the aforementioned topological attenuation factor The element values ​​corresponding to the first subtask and the second subtask in the execution domain affinity matrix are obtained. .

[0060] Furthermore, the topological attenuation factor The value is pre-set based on the physical proximity of the first and second subtasks. The specific value rules are as follows: when the two subtasks are located on the same physical node, the value is 1; when they are located on different nodes but connected through a high-speed interconnect bus, the value is 0.6; and when they are located on different nodes and connected only through a general network, the value is 0.1.

[0061] Specifically, regarding each process mentioned above, there is another possible way to describe it, as follows: A computation graph parser is used to read user-submitted task programs, generate corresponding computation graphs, and extract the computation density weights of each sub-task node and the communication data volume of each data dependency edge from the computation graph. Specifically, the computation graph parser is a software module whose main function is to perform in-depth analysis of user-submitted task programs and abstract them into a structured computation graph representation. This computation graph consists of a series of sub-task nodes and dependency edges representing data flow. The computation graph parser can identify and extract the computational characteristics of each sub-task node, such as its required number of floating-point operations or memory access patterns, and then calculate the computation density weights. Simultaneously, it can also analyze the data transmission volume on data dependency edges and use it as the communication cost weight. The computation graph parser can be based on compiler front-end technology to parse task code written in high-level programming languages, construct an abstract syntax tree, and further convert it into a computation graph; alternatively, it can directly utilize the graph representation API provided by a specific computation framework to read the computation graph structure generated internally by the framework.

[0062] An execution domain partitioner, connected to the computation graph resolver, incorporates a cost model and solver. It divides the computation graph into several execution domains based on the computation density weights and communication data volume, minimizing the global cost function value of all execution domains. The global cost function is calculated as follows: the sum of the computation time of all subtasks multiplied by a first weight, plus the sum of the cross-domain communication time between subtasks belonging to different execution domains multiplied by a second weight, plus the number of execution domains minus 1, multiplied by a preset synchronization overhead benchmark value, and then multiplied by a third weight. Specifically, the execution domain partitioner is the core module of this system. Its function is to divide the entire computation graph into multiple logical execution domains based on the subtask computation density weights and communication data volume of data-dependent edges provided by the computation graph resolver, combined with the topology decay factor provided by the resource topology perceptron. The goal of the partitioning is to minimize a comprehensive global cost function that balances computation time, cross-domain communication time, and synchronization overhead. The execution domain partitioner can employ a graph cutting algorithm (e.g., a variant based on the Metis or Kernighan-Lin algorithm) combined with heuristic search or genetic algorithms to find the minimum solution of the global cost function under preset constraints; alternatively, it can utilize a deep reinforcement learning model to learn and generate the optimal execution domain partitioning strategy through training in different task and cluster environments.

[0063] The resource topology sensor is used to collect real-time data on the physical topology location, interconnect bandwidth, and real-time load status of heterogeneous computing units in the cluster, and to generate topology attenuation factors between different subtasks. Specifically, the resource topology sensor is a continuously running monitoring and information acquisition module responsible for acquiring real-time physical topology information, interconnect bandwidth, and current load status of heterogeneous computing units in the cluster. This information is crucial for accurately assessing communication overhead and performing resource matching. The resource topology sensor can obtain the physical topology structure through APIs provided by the operating system or hardware management interfaces; it can also periodically use network probing tools to measure the actual bandwidth and latency between nodes, and combine this with the SNMP protocol to obtain real-time load data of devices.

[0064] The heterogeneous scheduler, connected to both the execution domain partitioner and the resource topology sensor, is used to match the optimal computing power unit for each execution domain and issue scheduling instructions based on the execution domain partitioning results and the real-time status of each heterogeneous computing unit. Specifically, the heterogeneous scheduler is the central coordination module of the system. It receives the execution domain partitioning results generated by the execution domain partitioner and combines them with the real-time status information of heterogeneous computing units provided by the resource topology sensor. Its task is to match the most suitable heterogeneous computing resources for each execution domain and issue specific scheduling instructions to the underlying resource management system. The heterogeneous scheduler can perform resource matching based on multi-objective optimization algorithms, comprehensively considering multiple dimensions such as the resource requirements of the execution domain, the available resources of the heterogeneous computing units, the load situation, and topology affinity; alternatively, it can also adopt an auction mechanism or game theory model, allowing execution domains to "bid" for resources or resource units to "bid" for execution domains, achieving dynamic and efficient resource matching.

[0065] The overlapped execution engine, deployed on each computing node, dynamically adjusts the size of data communication blocks based on real-time monitored link bandwidth during task execution, enabling parallel overlap between communication and computation processes. Specifically, the overlapped execution engine is a runtime optimization component deployed on each computing node. Its core function is to monitor changes in link bandwidth in real time during task execution and dynamically adjust the size of data communication blocks accordingly to achieve parallel overlap between data transmission and numerical computation. The overlapped execution engine can integrate dynamic block partitioning logic into the data transmission library to adjust the message transmission size based on predicted available bandwidth; alternatively, it can utilize hardware features such as DMA controllers for data transmission when the computing core is busy, through user-level threads or asynchronous I / O mechanisms, thereby achieving parallelism between computation and communication.

[0066] The system works as follows: First, the computation graph parser analyzes the user-submitted task program, constructing a computation graph containing subtask nodes and data dependency edges, and extracting the computation density weight of each subtask and the communication data volume of each data dependency edge. This information forms the basis of the subsequent scheduling scheme, ensuring that the scheduling process can deeply understand the internal structure of the task. Simultaneously, the resource topology sensor continuously monitors the hardware environment of the entire heterogeneous cluster, including the physical location, interconnect bandwidth, and real-time load status of each heterogeneous computing unit, and generates topology decay factors between different subtasks accordingly, providing a dynamic and real-time environmental context for scheduling.

[0067] Next, the execution domain partitioner receives task structure information from the computation graph resolver and topology decay factors provided by the resource topology perceptron. Utilizing its built-in cost model and solver, it divides the computation graph into several execution domains, aiming to minimize a global cost function that comprehensively considers computation time, cross-domain communication time, and synchronization overhead. This partitioning process is the core of static scheduling optimization, aiming to form optimal subtask groups to reduce overall task execution time. Subsequently, after receiving the set of execution domains generated by the execution domain partitioner, the heterogeneous scheduler, combined with the real-time status of heterogeneous computing units (such as available resources and load) provided by the resource topology perceptron, matches the most suitable heterogeneous computing resources for each execution domain and issues scheduling instructions. This step ensures efficient matching of computational characteristics and resource characteristics and deploys the static optimization results onto actual hardware.

[0068] During task execution, the overlapping execution engine is deployed on each computing node. It monitors changes in link bandwidth in real time and adjusts the size of data communication blocks based on this dynamic information. By calculating the optimal communication block size and inserting data blocks into idle time slots of the computing pipeline, the overlapping execution engine achieves parallel overlap of data transmission and numerical computation. The entire system achieves static optimization scheduling of tasks through a computation graph resolver, execution domain partitioner, resource topology sensor, and heterogeneous scheduler. Building on this, the overlapping execution engine further provides runtime dynamic adaptability, effectively addressing the challenges posed by dynamic changes in link bandwidth and ensuring efficient parallelism of communication and computation.

[0069] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A heterogeneous computing power scheduling method, wherein the method is applied to a pooled cluster containing at least two heterogeneous computing resources, including CPU, GPU, NPU, and FPGA, characterized in that, The method includes: S1. Parse the computation graph of the task to be scheduled, wherein the computation graph consists of a set of subtask nodes and a set of data dependency edges; S2. Obtain the amount of communication data corresponding to each data dependency edge, and use it as the communication cost weight; S3. Obtain the computation density weight corresponding to each subtask node. The computation density weight is obtained by dividing the total computation amount of the subtask by the total amount of data to be accessed. S4. Based on the communication cost weight and the computation density weight, construct an execution domain affinity matrix. Any element in the execution domain affinity matrix is ​​used to characterize the comprehensive benefit brought about by the joint execution of any two subtasks in the same supernode. S5. Based on a preset cost model, the computation graph is divided into several execution domain sets to minimize the global cost function. The global cost function is calculated as follows: the sum of the computation time of all subtasks is multiplied by a first weight coefficient, plus the sum of the cross-domain communication time between subtasks belonging to different execution domains is multiplied by a second weight coefficient, plus the number of execution domains minus 1 is multiplied by a preset synchronization overhead baseline value and then multiplied by a third weight coefficient. Among these, the communication time between subtasks belonging to the same execution domain is considered zero, and the communication time between subtasks belonging to different execution domains is calculated based on the communication data volume of the corresponding subtask pair and the topology attenuation factor. S6. Based on the set of execution domains obtained from the partitioning, match the corresponding heterogeneous computing resources for each execution domain and bind and schedule them.

2. The heterogeneous computing power scheduling method according to claim 1, characterized in that, In step S4, any element in the execution domain affinity matrix It is calculated in the following way: Get the amount of communication data between the first subtask and the second subtask. As the first factor; Obtain the computation density weights of the first subtask Computation density weights of the second subtask The sum of these factors serves as the second factor. Divide the first factor by the second factor to obtain the intermediate ratio. ; Obtain the topology decay factor between the first and second subtasks. ; The intermediate ratio Multiply by the aforementioned topological attenuation factor The element values ​​corresponding to the first subtask and the second subtask in the execution domain affinity matrix are obtained. .

3. The heterogeneous computing power scheduling method according to claim 2, characterized in that, The topological attenuation factor The value is pre-set based on the physical proximity of the first and second subtasks. The specific value rules are as follows: when the two subtasks are located on the same physical node, the value is 1; when they are located on different nodes but connected through a high-speed interconnect bus, the value is 0.6; and when they are located on different nodes and connected only through a general network, the value is 0.

1.

4. The heterogeneous computing power scheduling method according to claim 1, characterized in that, In step S5, the cross-domain communication time between subtasks belonging to different execution domains is calculated. Calculated in the following way: Get subtasks sub-tasks Communication data volume between ; Get subtasks sub-tasks Available bandwidth between computing units ; Get subtasks sub-tasks Topological attenuation factor between ; The amount of communication data Divide by the available bandwidth Then multiply by the aforementioned topological attenuation factor The cross-domain communication time was obtained. .

5. The heterogeneous computing power scheduling method according to claim 1, characterized in that, In step S5, the computation time of the subtask is... Calculated in the following way: Get subtasks Total computational load The unit is the number of floating-point operations; Get as a subtask Peak computing performance of allocated computing units The unit is floating-point operations per second; The total computational load Divide by the calculated peak performance The computation time of the subtask is obtained. .

6. The heterogeneous computing power scheduling method according to claim 1, characterized in that, In step S5, the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient are dynamically adjusted according to the cluster hardware environment, specifically including: When the proportion of high-speed interconnect buses in the cluster is detected to be higher than a preset threshold, the second weighting coefficient is reduced. When the average delay of cross-node synchronization operation is detected to be higher than a preset threshold, the third weighting coefficient is increased.

7. The heterogeneous computing power scheduling method according to claim 1, characterized in that, In step S6, after matching corresponding heterogeneous computing resources to each execution domain according to the partitioned execution domain set and binding and scheduling them, the process further includes: During the task execution phase, historical time-series data of link bandwidth are collected in real time, and the predicted value of available bandwidth for the next time window is calculated through a sliding window prediction model. Based on the predicted available bandwidth, the optimal communication block size is calculated. The optimal communication block size is the maximum value that satisfies the following constraint: the communication time obtained by dividing the block size by the predicted available bandwidth is not greater than the smaller of the computation time required for the next computation stage and the synchronization waiting time allowed by the task. The data to be transmitted is divided according to the optimal communication block size, and the divided data blocks are sequentially inserted into the idle time slots of the computing pipeline for transmission, so that the data transmission process and the numerical calculation process overlap in parallel on the timeline.

8. A heterogeneous computing power scheduling system, said system being used to implement the heterogeneous computing power scheduling method as described in any one of claims 1 to 7, characterized in that, The system includes: The parsing module is used to parse the computation graph of the task to be scheduled, which consists of a set of subtask nodes and a set of data dependency edges; The communication data analysis module is used to obtain the amount of communication data corresponding to each data dependency edge, which is used as the communication cost weight. The density weight determination module is used to obtain the computational density weight corresponding to each subtask node. The computational density weight is obtained by dividing the total computational amount of the subtask by the total amount of data to be accessed. The affinity analysis module is used to construct an execution domain affinity matrix based on the communication cost weight and the computation density weight. Any element in the execution domain affinity matrix is ​​used to characterize the comprehensive benefit brought about by the joint execution of any two subtasks in the same supernode. The minimization processing module is used to divide the computation graph into several execution domain sets based on a preset cost model, so as to minimize the global cost function. The global cost function is calculated as follows: the sum of the computation time of all subtasks is multiplied by a first weight coefficient, plus the sum of the cross-domain communication time between subtasks belonging to different execution domains is multiplied by a second weight coefficient, plus the number of execution domains minus 1 is multiplied by a preset synchronization overhead baseline value, and then multiplied by a third weight coefficient. Among them, the communication time between subtasks belonging to the same execution domain is considered to be zero, and the communication time between subtasks belonging to different execution domains is calculated based on the communication data volume of the corresponding subtask pair and the topology attenuation factor. The scheduling and execution module is used to match and bind the corresponding heterogeneous computing resources to each execution domain according to the set of execution domains obtained by partitioning.

9. The heterogeneous computing power scheduling system according to claim 8, characterized in that, In the affinity analysis module, any element in the execution domain affinity matrix It is calculated in the following way: Get the amount of communication data between the first subtask and the second subtask. As the first factor; Obtain the computation density weights of the first subtask Computation density weights of the second subtask The sum of these factors serves as the second factor. Divide the first factor by the second factor to obtain the intermediate ratio. ; Obtain the topology decay factor between the first and second subtasks. ; The intermediate ratio Multiply by the aforementioned topological attenuation factor The element values ​​corresponding to the first subtask and the second subtask in the execution domain affinity matrix are obtained. .

10. The heterogeneous computing power scheduling system according to claim 8, characterized in that, The topological attenuation factor The value is pre-set based on the physical proximity of the first and second subtasks. The specific value rules are as follows: when the two subtasks are located on the same physical node, the value is 1; when they are located on different nodes but connected through a high-speed interconnect bus, the value is 0.6; and when they are located on different nodes and connected only through a general network, the value is 0.1.

Images