Calculation task allocation method and device, equipment, storage medium and product

Abstract

The invention discloses a calculation task allocation method and device, equipment, a storage medium and a product, and relates to the technical field of artificial intelligence, and the method comprises the steps: obtaining a to-be-executed calculation task, and extracting the features of the to-be-executed task to obtain a feature label; decomposing the to-be-executed calculation task based on the feature labels to obtain sub-tasks; constructing a directed acyclic graph based on the dependency matrix of each sub-task, and performing topological sorting on each sub-task to obtain a priority and an execution sequence; according to the method, a to-be-executed calculation task is decomposed into a plurality of sub-tasks through feature labeling, a directed acyclic graph is constructed according to the dependency relationship among the sub-tasks, and the sub-tasks are distributed according to the reference execution time, the priority and the execution sequence. The priority and the execution sequence of each sub-task are determined by utilizing topological sorting, and the sub-tasks are allocated to each GPU for execution in combination with the reference execution time of each sub-task on different GPUs, so that the calculation efficiency of the calculation task is effectively improved.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence technology, and in particular to computing task allocation methods, devices, equipment, storage media and products. Background Art

[0002] With the development of technologies such as artificial intelligence, big data analysis, and cloud computing, the demand for high-performance computing resources continues to grow. In response to changes in the international market and the need for independent and controllable domestic computing power, the research and development and application of domestic GPUs have become a key direction.

[0003] The development of domestic GPU computing power scheduling technology requires in-depth research in areas such as algorithm innovation, software and hardware collaboration, and ecosystem construction to promote the widespread application of domestic GPU computing power. Existing heterogeneous computing power adaptation methods typically use static resource allocation strategies to manage domestic GPU computing power through static allocation of domestic GPU resources or simple load balancing. For example, the open source resource management and job scheduling system (Simple Linux Utility for Resource Management, referred to as Slurm) is used to manage and schedule computing resources. Its static resource allocation strategy is difficult to adapt to the dynamic nature of heterogeneous computing resources and the needs of different computing tasks. It cannot dynamically adjust according to actual task requirements and resource status, resulting in low resource utilization.

[0004] At the same time, existing technologies often overlook the performance characteristics of domestically produced GPUs, failing to fully leverage their performance advantages. These methods also fail to effectively cope with complex changes in computing requirements, especially in heterogeneous computing environments, where scheduling efficiency and resource utilization need to be improved. Summary of the Invention

[0005] The main purpose of this application is to provide a computing task allocation method, device, equipment, storage medium and product, aiming to solve the technical problem that the current domestic GPU computing power allocation cannot effectively cope with complex changes in computing needs.

[0006] To achieve the above objectives, the present application proposes a computing task allocation method, which includes:

[0007] Obtaining a computing task to be executed, performing feature extraction on the task to be executed, and obtaining feature annotations;

[0008] Decomposing the computing task to be executed based on the feature annotation to obtain subtasks;

[0009] Constructing a directed acyclic graph based on the dependency matrix between the subtasks, and topologically sorting the subtasks in the directed acyclic graph to obtain the priority and execution order of the subtasks;

[0010] The reference execution time of the subtasks on each GPU is calculated, and the subtasks are allocated according to the reference execution time, the priority, and the execution order.

[0011] The step of obtaining a computing task to be executed, extracting features of the task to be executed, and obtaining feature annotations includes:

[0012] Obtaining a computing task to be executed, and extracting computing features from the computing task to obtain computing features, wherein the computing features include computing intensity, memory requirements, and data transmission characteristics;

[0013] Obtaining a reference adaptive GPU model and an adaptation priority according to the computing intensity, the memory requirement, and the data transmission characteristics;

[0014] Generate feature annotations according to the reference adapted GPU model and the adaptation priority;

[0015] The step of decomposing the computing task to be executed based on the feature annotation to obtain subtasks includes:

[0016] Preliminarily decomposing the computing task to be executed to obtain initial subtasks;

[0017] Obtaining feature annotations for each initial subtask based on the feature annotations and the calculation ratios of the initial subtasks;

[0018] Each subtask is obtained according to the feature annotations of each initial subtask and the corresponding initial subtask.

[0019] The step of constructing a directed acyclic graph based on the dependency matrix between the subtasks and topologically sorting the subtasks in the directed acyclic graph to obtain the priority and execution order of the subtasks includes:

[0020] Constructing a dependency matrix according to the dependency relationships between the subtasks, and constructing a directed acyclic graph according to the dependency matrix;

[0021] Topologically sorting each subtask based on the directed acyclic graph to obtain an execution order of each subtask;

[0022] A critical path is obtained based on the execution order of the subtasks, and a priority of the subtasks is obtained based on the critical path and the execution order.

[0023] The topological sorting of the subtasks to obtain the execution order of the subtasks includes:

[0024] Identify the number of dependent subtasks of the subtask, and use the number of dependent subtasks as the in-degree value of the subtask;

[0025] Using the subtasks with a preset in-degree value in the directed acyclic graph as marked subtasks, and sequentially filling the marked subtasks into the subtask execution order table;

[0026] The marked subtask is removed from the directed acyclic graph to obtain an updated directed acyclic graph, and the subtasks with in-degree values ​​of a preset value in the directed acyclic graph are returned as marked subtasks, and the marked subtasks are sequentially filled into a subtask execution order table until each subtask is sequentially filled into the subtask execution order table;

[0027] The order of each subtask in the subtask execution order table is used as the execution order of each subtask.

[0028] Calculating the reference execution time of the subtask on each GPU includes:

[0029] Obtaining computing time based on the computing intensity of the subtask and the computing capability of each GPU;

[0030] Determine the transmission time based on the data size of the subtask and the actual bandwidth of each GPU;

[0031] A reference execution time of the subtask on each GPU is obtained according to the calculation time and the transmission time.

[0032] After calculating the reference execution time of the subtasks on each GPU and allocating the subtasks according to the reference execution time, the priority, and the execution order, the method further includes:

[0033] Get the real-time status of each GPU;

[0034] Identifying an abnormality cause of the GPU based on the real-time status abnormality, the abnormality cause including resource overload, power consumption or temperature abnormality, and task execution efficiency abnormality;

[0035] When the cause of the abnormality is resource overload, performing subtask load balancing adjustment on the GPU;

[0036] When the abnormality is caused by abnormal power consumption or temperature, performing subtask migration adjustment on the GPU;

[0037] When the abnormal reason is low task execution efficiency, subtask efficiency is adjusted on the GPU.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes a computing task allocation device, which includes:

[0039] An acquisition and annotation module is used to acquire computing tasks to be executed, perform feature extraction on the tasks to be executed, and obtain feature annotations;

[0040] A task decomposition module is used to decompose the computing task to be executed based on the feature annotation to obtain various subtasks;

[0041] A task allocation module is used to construct a directed acyclic graph based on the dependency matrix between the subtasks, and to topologically sort the subtasks in the directed acyclic graph to obtain the priority and execution order of the subtasks;

[0042] The task allocation module is further configured to calculate the reference execution time of the subtasks on each GPU, and allocate the subtasks according to the reference execution time, the priority, and the execution order.

[0043] In addition, to achieve the above-mentioned purpose, the present application also proposes a computing task allocation device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the computing task allocation method described above.

[0044] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and stores a computer program on the storage medium. When the computer program is executed by the processor, the steps of the computing task allocation method described above are implemented.

[0045] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the steps of the computing task allocation method described above.

[0046] One or more technical solutions proposed in this application have at least the following technical effects: decomposing the computing task to be executed into multiple subtasks by labeling its features, constructing a directed acyclic graph based on the dependency relationship between the subtasks, and determining the priority and execution order of each subtask by using topological sorting; calculating the reference execution time of each subtask on different GPUs, and comprehensively considering the reference execution time, priority and execution order to allocate the subtasks to each GPU for execution, thereby effectively optimizing the decomposition and scheduling process of the computing task, improving resource utilization and execution efficiency, and ensuring the efficient and orderly completion of large-scale computing tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0048] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0049] Figure 1 A flowchart of the first embodiment of the method for allocating computing tasks in this application is provided;

[0050] Figure 2 Flowchart of task container deployment provided in Example 1 of the computing task allocation method of this application;

[0051] Figure 3 The overall flow chart of the computing task allocation method provided in Example 1 of the computing task allocation method of this application;

[0052] Figure 4 A flowchart of the second embodiment of the method for allocating computing tasks in this application is provided;

[0053] Figure 5 A schematic diagram of the specific steps of representing a computing task as a directed acyclic graph provided in Example 2 of the computing task allocation method of this application;

[0054] Figure 6 This is a schematic diagram of the module structure of the computing task allocation device according to an embodiment of the present application;

[0055] Figure 7 Schematic diagram of the device structure of the hardware operating environment involved in the computing task allocation method in the embodiment of the present application.

[0056] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0057] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0058] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0059] The main solution of the embodiment of the present application is: obtain the computing task to be executed, extract the features of the task to be executed, and obtain feature annotations; decompose the computing task to be executed based on the feature annotations to obtain various subtasks; construct a directed acyclic graph based on the dependency matrix between each subtask, and topologically sort the subtasks in the directed acyclic graph to obtain the priority and execution order of each subtask; calculate the reference execution time of the subtask on each GPU, and allocate each subtask according to the reference execution time, priority and execution order.

[0060] As existing technologies advance with the development of artificial intelligence, big data analysis, cloud computing, and other technologies, the demand for high-performance computing resources continues to grow. In response to changes in the international market and the need for independent and controllable domestic computing power, the research and development and application of domestic GPUs have become a key direction.

[0061] The development of domestic GPU computing power scheduling technology requires in-depth research in areas such as algorithm innovation, software and hardware collaboration, and ecosystem construction to promote the widespread application of domestic GPU computing power. Existing heterogeneous computing power adaptation methods typically use static resource allocation strategies to manage domestic GPU computing power through static allocation of domestic GPU resources or simple load balancing. For example, Slurm and OpenPBS are used to manage and schedule computing resources. These static resource allocation strategies are difficult to adapt to the dynamic nature of heterogeneous computing resources and the needs of different computing tasks. They cannot dynamically adjust according to actual task requirements and resource status, resulting in low resource utilization.

[0062] The present application provides a solution, a computing task allocation method, device, equipment, storage medium and product, which relate to the field of artificial intelligence technology, including: obtaining a computing task to be executed, extracting features of the task to be executed to obtain feature annotations; decomposing the computing task to be executed to obtain subtasks based on the feature annotations; constructing a directed acyclic graph based on the dependency matrix of each subtask, and topologically sorting each subtask to obtain priority and execution order; calculating the reference execution time of the subtask on each GPU, and allocating each subtask according to the reference execution time, priority and execution order. The method decomposes the computing task to be executed into multiple subtasks through feature annotations, constructs a directed acyclic graph according to the dependency relationship between the subtasks, uses topological sorting to determine the priority and execution order of each subtask, and allocates the subtasks to each GPU for execution in combination with the reference execution time of each subtask on different GPUs, thereby effectively improving the computing efficiency of the computing task.

[0063] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of implementing the above functions, a computing task distribution device, etc. The following uses the computing task distribution device as an example to illustrate this embodiment and the following embodiments.

[0064] Based on this, the present application embodiment provides a method for allocating computing tasks, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the computing task allocation method of this application.

[0065] In this embodiment, the computing task allocation method includes steps S10 to S40:

[0066] Step S10: Obtain a computing task to be executed, perform feature extraction on the task to be executed, and obtain feature annotations.

[0067] It should be understood that the computing task to be executed may be a computing task submitted by a user with computing needs through an interface or user interface.

[0068] It should be noted that the features of the task to be executed are extracted, and the computing intensity, memory requirement and data transmission characteristics are obtained based on the features, and then a feature annotation is combined based on the computing intensity, memory requirement and data transmission characteristics.

[0069] It should be emphasized that the annotations clearly indicate the adaptability and priority of the task to specific domestic GPU models.

[0070] In a feasible implementation, step S10 may include steps A11 to A13:

[0071] Step A11: Obtain a computing task to be executed, extract features of the computing task to obtain computing features, wherein the computing features include computing intensity, memory requirements, and data transmission characteristics.

[0072] It should be noted that users submit computing tasks as computing tasks to be executed through the interface or user interface, and indicate the computing requirements of the task, including the number of CPU cores, the number and type of domestic GPUs (domestic GPU models), priority, latency sensitivity, memory requirements, the computing power share of each subtask and related configurations (such as recommending that a domestic GPU provide computing power).

[0073] Latency sensitivity is a task's sensitivity to execution delays, expressed in time units (such as seconds or milliseconds). Latency sensitivity is reflected in the execution requirements of the task. If a task has high latency sensitivity, computing resources should be prioritized to reduce waiting time.

[0074] Further explanation: From a business perspective, subtasks are defined as modules that can independently execute independently decomposed tasks. For example, tasks can be deployed through independent services, with service communication and business logic implemented through interfaces. The results of each subtask's execution process are processed by the overall task monitoring and control module. For example, assuming an image processing task, it can be decomposed into three subtasks based on 100% of the total computing power: "image loading" accounts for 10%, "image preprocessing" accounts for 25%, and "feature extraction" accounts for 65%. The principle of subtask decomposition is determined by business characteristics, and the proportions are determined based on business experience.

[0075] It should be noted that the differences in computing performance of different types of domestic GPUs need to be considered when extracting computing features.

[0076] It's worth noting that computing intensity = number of CPU cores + number of domestic GPUs × equivalent number of CPU cores of domestic GPUs (the equivalent number of CPU cores of domestic GPUs varies depending on the specific domestic GPU model, such as 64 or 128). "Equivalent number of CPU cores of domestic GPUs" is a unified metric for measuring the computing power of CPUs and domestic GPUs. Because different models of domestic GPUs have significant differences in processing performance, the actual computing power of each domestic GPU is taken into account when calculating "equivalent number of CPU cores of domestic GPUs." This value is determined through benchmark testing or reference to hardware performance documentation.

[0077] In specific implementations, a task requires the use of 4 CPU cores and 2 domestically produced GPUs with weaker performance (each domestically produced GPU has an equivalent number of 64 CPU cores). The computational intensity is then calculated as 4 + 2 × 64 = 4 + 128 = 132, which means the computational intensity of the task is equivalent to 132 CPU cores.

[0078] Memory requirement: directly uses the memory requirement value submitted by the user.

[0079] Among them, data transmission characteristics can include data transmission bandwidth requirements, data size, and scaling factors. The data transmission bandwidth requirement formula is: Data transmission bandwidth requirement = data size ÷ delay sensitivity × scaling factor. Among them, data size refers to the amount of data that needs to be processed or transmitted per unit time during the calculation process of the task. Among them, the scaling factor is a parameter used to adjust the data transmission bandwidth requirement. Domestic GPUs need to obtain the scaling factor through evaluation sampling before use. This value is empirical data, and it is recommended to flexibly adjust it according to business characteristics during the specific implementation process.

[0080] For example, suppose a task processes 500MB of data per unit time, has a latency sensitivity of 2 seconds, and a scaling factor of 1.5. Then, the required data transmission bandwidth = 500MB ÷ 2 seconds × 1.5 = 375MB / second. This means that to meet the requirements of this task, the system must provide at least 375MB / second of bandwidth.

[0081] Step A12: Obtain a reference adaptive GPU model and an adaptation priority based on the computing intensity, the memory requirement, and the data transmission characteristics.

[0082] It should be noted that the process of determining the reference adaptive GPU model and adaptation priority based on computing intensity, memory requirements, and data transmission characteristics is mainly to ensure that each subtask can be assigned to the most appropriate hardware resources for execution, thereby optimizing overall performance.

[0083] It should be understood that computational intensity refers to the number and complexity of the computational operations involved in a task. For computationally intensive tasks, it is more appropriate to choose a GPU with more CUDA cores or higher computational power (FLOPS) to ensure that complex computational tasks can be processed quickly.

[0084] It should be understood that memory requirements take into account the amount of memory required to run the task, including video memory (GPU memory). For tasks that require processing large datasets or using large models, GPUs with larger video memory capacities should be selected to avoid task failures or performance bottlenecks due to insufficient memory.

[0085] It should be understood that data transfer characteristics can refer to the frequency and volume of data input and output during an analysis task, particularly data exchange with host memory. If the task frequently exchanges data, a GPU with a higher-speed PCIe interface or NVLink technology should be selected to accelerate data transfer and reduce latency.

[0086] It's important to emphasize that the most suitable GPU model can be matched to each subtask based on three considerations: computational intensity, memory requirements, and data transfer characteristics. Adaptation priorities can be set accordingly. For example, for a task requiring both high computational power and extensive memory support, a high-end NVIDIA A100 or V100 series GPU might be prioritized. For tasks with lower computational intensity but high data transfer rate requirements, a GPU equipped with the latest generation of high-speed PCIe interfaces might be preferred. This not only improves the execution efficiency of individual tasks but also optimizes resource allocation across the entire system.

[0087] Step A13: Generate feature annotations based on the reference adapted GPU model and the adaptation priority.

[0088] It should be noted that the calculated computational intensity, memory requirements, and data transfer characteristics are combined into a feature annotation, which clearly defines the adaptability and priority of the task to a specific domestic GPU model.

[0089] In this implementation, by extracting features from the acquired computing tasks to be executed and analyzing their computing intensity, memory requirements, and data transmission characteristics, the reference adapted GPU model and its adaptation priority are determined to ensure that each task can be allocated the most appropriate hardware resources. At the same time, feature annotations are generated based on computing intensity, memory requirements, and data transmission characteristics to provide precise guidance for subsequent task scheduling and resource allocation, effectively improving the computing task execution efficiency and resource utilization, and realizing optimized configuration and management in a high-performance computing environment.

[0090] The above is only a feasible implementation of step S10 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S10.

[0091] Step S20: Decomposing the computing task to be executed based on the feature annotation to obtain subtasks.

[0092] It can be understood that task decomposition is to split a complex computing task into multiple subtasks, each of which represents an independent computing step.

[0093] It's important to note that after subtasks are split, the overall task's characteristic value is typically the sum of all subtask characteristic values. Each subtask's characteristic values, such as computational intensity, memory requirements, and bandwidth requirements, are calculated based on the specific subtask proportions.

[0094] It should be noted that, given the scheduling characteristics of domestic GPUs, we can decompose tasks into multiple subtasks and merge them using fusion technology. First, by breaking down the computational task into multiple subtasks, we leverage the powerful parallel computing capabilities of domestic GPUs to increase task execution speed. Second, we employ different fusion strategies, such as pipeline fusion and loop fusion, tailored to the characteristics of different subtasks to optimize execution order and reduce data transfer overhead. Furthermore, during task fusion, we fully consider the memory access patterns of domestic GPUs to reduce memory access conflicts and further improve computational efficiency.

[0095] In a feasible implementation, step S20 may include steps A21 to A23:

[0096] Step A21 : Preliminarily decompose the computing task to be executed to obtain initial subtasks.

[0097] It should be noted that when the computational task to be executed is decomposed to obtain initial subtasks, the computational intensity, memory requirements, and data transmission characteristics of each initial subtask have not yet been calculated.

[0098] Step A22: obtaining feature annotations of each initial subtask based on the feature annotations and the calculated proportions of the initial subtasks.

[0099] It should be noted that the computational proportion of the initial subtask may be pre-set according to the subtask type, and the feature annotation of the initial subtask includes the computational intensity, memory requirement, and data transmission characteristics of the initial subtask.

[0100] It should be emphasized that the values ​​calculated according to the proportion after the subtasks are decomposed are rounded up according to the principle of redundancy to ensure the validity of the calculation.

[0101] In a specific implementation, the overall task is broken down into four subtasks according to the example: Subtask 1 (image loading): Computational intensity 132 * 10% = 14 cores; memory requirement = user-submitted memory value * 10%; bandwidth requirement 375 * 10% = 38 MB / s. Subtask 2 (image preprocessing): Computational intensity 132 * 25% = 33 cores; memory requirement = user-submitted memory value * 25%; bandwidth requirement 375 * 25% = 94 MB / s. Subtask 3 (feature extraction): Computational intensity 132 * 65% = 86 cores; memory requirement = user-submitted memory value * 65%; bandwidth requirement 375 * 65% = 244 MB / s. The computational intensity, memory requirement, and bandwidth requirement (here, memory requirement can be used as the data transmission feature of the subtask) of each subtask are combined to form the feature annotation for that subtask.

[0102] Step A23 : obtaining each subtask according to the feature annotations of each initial subtask and the corresponding initial subtask.

[0103] It should be noted that the feature annotation of each initial subtask is bound to the initial subtask in a one-to-one correspondence, and the initial subtask with the feature annotation is used as a subtask.

[0104] In this embodiment, the computing tasks to be executed are preliminarily decomposed to generate initial subtasks, and corresponding feature labels are assigned to each initial subtask based on the previously generated feature labels and the computing proportion of each initial subtask. Feature labeling of each initial subtask ensures that each subtask can accurately reflect its requirements in computing intensity, memory requirements and data transmission characteristics, thereby achieving more refined task division and resource allocation, and improving overall computing efficiency and resource utilization effectiveness.

[0105] The above is merely a feasible implementation of step S20 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S20.

[0106] Step S30: constructing a directed acyclic graph based on the dependency matrix between the subtasks, and topologically sorting the subtasks in the directed acyclic graph to obtain the priority and execution order of the subtasks.

[0107] It should be noted that, in response to the scheduling characteristics of domestic GPUs, we propose a dynamic adjustment strategy for task execution. First, based on the task execution progress and GPU resource usage, we adjust the task execution order in real time, prioritizing high-priority tasks. Second, to address the memory access characteristics of domestic GPUs, we dynamically adjust the task data layout to reduce memory access conflicts and improve memory access efficiency. Furthermore, based on the hardware characteristics of domestic GPUs, we implement collaborative scheduling between tasks, allowing multiple tasks to run simultaneously and fully utilize GPU resources.

[0108] It's important to note that the dependency matrix is ​​a two-dimensional matrix used to represent the dependencies between subtasks. The rows and columns of the matrix correspond to different subtasks, and the values ​​of the matrix elements (usually 0 or 1) indicate whether there is a dependency between two subtasks. For example, if Task A depends on Task B, the corresponding value in the matrix is ​​1; otherwise, it is 0.

[0109] It should be noted that a directed acyclic graph (DAG) is a graph structure used to intuitively represent the dependencies between tasks. Nodes represent subtasks, and directed edges represent the dependencies between tasks (e.g., an edge from Task A to Task B indicates that Task A must be completed before Task B). A DAG is characterized by the absence of loops, meaning there are no circular dependencies. This ensures that tasks can be executed sequentially in a certain order without deadlock.

[0110] It should be noted that topological sorting linearly orders all nodes in a DAG, ensuring that for any directed edge (from node A to node B), node A always comes before node B in the sorted result. This topological sorting determines the priority and execution order of all subtasks. This order strictly adheres to inter-task dependencies, preventing execution failures due to incorrect ordering and ensuring the correctness and efficiency of task scheduling.

[0111] It should be understood that when computing feature annotations for multiple subtasks, all computational subtasks are represented as a directed acyclic graph (DAG). When analyzing the dependencies between subtasks and determining the execution order and priority of each subtask, the entire task is represented as a DAG.

[0112] Step S40: Calculating the reference execution time of the subtasks on each GPU, and allocating the subtasks according to the reference execution time, the priority, and the execution order.

[0113] It should be noted that, in light of the scheduling characteristics of domestic GPUs, we need to optimize the DAG scheduling algorithm. First, considering the scheduling strategy of domestic GPUs, we adopt a priority-based scheduling strategy, allowing high-priority tasks to obtain more GPU resources. Second, we introduce a dynamic resource allocation mechanism to dynamically adjust GPU resource allocation based on the execution progress of tasks, thereby improving resource utilization. Furthermore, in combination with the hardware characteristics of domestic GPUs, we optimize the parallel processing aspects of the algorithm, such as using GPU-specific memory access modes to reduce memory access conflicts and improve computational efficiency.

[0114] It is understandable that the reference execution time can be understood as the time required for the GPU to complete processing the subtask, which is calculated based on the computing power of the GPU and the annotated features of the subtask.

[0115] In a feasible implementation, step S40 may include steps A41 to A44:

[0116] Step A41: Obtain computing time based on the computing intensity of the subtask and the computing capability of each GPU.

[0117] It's important to note that the platform uses performance data from various domestic GPUs to accurately calculate the estimated completion time for each subtask on different GPUs. This performance data is dependent on parameters such as the GPU model, inference framework, image version, memory usage, and concurrent requests, all of which are crucial for predicting task completion time.

[0118] It should be noted that the computing time is the time it takes for a subtask to execute calculations on a domestic GPU. It can be estimated by dividing the computing intensity of the subtask by the computing power of the domestic GPU. Computing time = computing intensity / computing power of the domestic GPU.

[0119] Step A42: obtaining the transmission time according to the data size of the subtask and the actual bandwidth of each GPU.

[0120] It should be understood that the data transfer time is the time required to transfer data between different memories, hardware or networks during the execution of the subtask, and can be calculated by dividing the data size by the available bandwidth.

[0121] It should be noted that the transmission time can be calculated by dividing the data size by the actual bandwidth. The actual bandwidth is limited by the memory bandwidth or other I / O capabilities of the domestic GPU. Therefore, it needs to be estimated based on specific hardware parameters. The parameters can be provided by the domestic GPU hardware manufacturer to be used and obtained by actual measurement before use.

[0122] Step A43: Obtain a reference execution time of the subtask on each GPU according to the calculation time and the transmission time.

[0123] It should be noted that by adding the calculation time and data transmission time, we can get the estimated completion time of the subtask on the domestic GPU.

[0124] Step A44: Allocate the subtasks according to the reference execution time, the priority, and the execution order.

[0125] It should be noted that the estimated completion time for each subtask on all available domestic GPUs is calculated, and the task priorities are initially assigned based on the execution order and critical path of the subtasks. Starting from the starting node, the DAG is traversed along the task priority path, and the tasks on the critical path are identified. During the task execution process, the task priority and critical path are dynamically adjusted according to the actual situation, and subtasks are assigned based on the adjusted priority and critical path.

[0126] It should be emphasized that the following problems may exist during the execution of subtasks: Real-time usage of resources: For example, the load on a domestic GPU is too high, and the task may need to be reallocated to a domestic GPU with a lower load. Task execution progress: Some tasks may be executed faster or slower than expected due to certain reasons (such as inaccurate estimates of computational complexity). Data transmission bottleneck: During the data transmission process, bottlenecks or delays may occur, and the priority of the task needs to be adjusted to reduce waiting time. Hardware failure or performance fluctuation: For example, a domestic GPU may fail or its performance may degrade, and the task needs to be reallocated. Dynamic resource allocation: There may be other tasks or processes in the system that occupy computing resources, resulting in the need to adjust the execution priority of the task.

[0127] In this implementation, the reference execution time is calculated based on the computational intensity of the subtask, the data size, the computing power of each GPU, and the actual bandwidth of each GPU. Combined with the priority and execution order of the subtask, the subtask is reasonably allocated to the most suitable GPU for execution, ensuring that subtasks with high priority and on the critical path can obtain sufficient computing resources in a timely manner. By optimizing resource allocation, the overall task processing efficiency and system throughput are significantly improved, the effective utilization of computing resources and the optimization of task scheduling are achieved, the execution performance of each subtask on different GPUs is accurately evaluated, and the task allocation process is optimized.

[0128] The above is merely a feasible implementation of step S40 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S40.

[0129] It should be noted that, after calculating the reference execution time of the subtasks on each GPU and allocating the subtasks according to the reference execution time, the priority and the execution order, the method further includes: obtaining the real-time status of each GPU; identifying the abnormal cause of the GPU based on the real-time status abnormality, the abnormal cause including resource overload, power consumption or temperature abnormality and task execution efficiency abnormality; when the abnormal cause is resource overload, performing subtask load balancing adjustment on the GPU; when the abnormal cause is power consumption or temperature abnormality, performing subtask migration adjustment on the GPU; when the abnormal cause is low task execution efficiency abnormality, performing subtask efficiency adjustment on the GPU.

[0130] It should be noted that resource overload can be when the utilization rate of a domestic GPU is in a high load state for a long time or the resources are idle for a long time, which requires triggering a dynamic scheduling strategy to reallocate tasks to achieve load balancing. Power consumption or temperature anomalies can be when the power consumption or temperature of a domestic GPU is detected to be continuously exceeding the standard, which requires adjusting task allocation to reduce the load on the domestic GPU and avoid hardware damage. Inefficient task execution can be when the execution time or data transmission rate of a task is significantly lower than expected, which may require reallocation of the task to a domestic GPU with better performance.

[0131] It's worth emphasizing that the specific steps of the dynamic scheduling strategy include: 1. Evaluate current resource status: Based on the analysis results, determine which domestic GPUs are overloaded, overheated, or have idle resources. Identify nodes with low task execution efficiency and assess whether the reasons may be excessive GPU load, data transmission bottlenecks, etc. 2. Optimize task allocation: Load balancing: Reassign some tasks from overloaded domestic GPUs to idle domestic GPUs to balance resource utilization. Power management: Migrate tasks from domestic GPUs with high power consumption or high temperature to domestic GPUs with lower power consumption or lower temperature to ensure safe hardware operation. Performance optimization: If a task is inefficient on the current domestic GPU, consider migrating it to a domestic GPU with greater computing power, or consolidating multiple lightweight tasks onto a single domestic GPU. 3. Real-time adjustment and feedback: Monitor the execution status of the adjusted tasks in real time. If new bottlenecks or issues are discovered, the central management system can trigger the scheduling strategy again for further optimization. Feedback on the adjusted resource utilization and task execution status is provided to the central management system to ensure closed-loop management and continuous optimization.

[0132] In the implementation, resource overload and load balancing were addressed. The central management system received monitoring data from edge nodes and discovered that the utilization rate of domestic GPU 1 remained above 95% for a long period of time, while the utilization rate of domestic GPU 2 was only 30%. Domestic GPU 1 was overloaded, potentially affecting its execution efficiency, while domestic GPU 2 had ample idle resources. CloudCore migrated some low-priority tasks from domestic GPU 1 to domestic GPU 2 to achieve load balancing and improve overall task execution efficiency.

[0133] In the specific implementation, power consumption and temperature management, the central management system detects that the temperature of the domestic GPU3 has been above 85°C for a long time, and the power consumption is close to the maximum limit. The domestic GPU3 may be overloaded or the ambient temperature is too high, and there is a risk of overheating. Its load needs to be reduced to avoid hardware damage. Some tasks on the domestic GPU3 are migrated to the domestic GPU4 with a lower temperature, or the task priority of the domestic GPU3 is adjusted to reduce the execution of its high-computing-intensity tasks and lower the temperature.

[0134] During implementation, we optimized task execution efficiency. Task A on a domestically produced GPU5 took significantly longer than expected, impacting the execution of other dependent tasks in the DAG. The performance of the domestically produced GPU5 was insufficient to support efficient execution of Task A, or data transmission bottlenecks were present. Task A was migrated to a domestically produced GPU6 with greater computing power, or data transmission paths and bandwidth were optimized to improve task execution efficiency.

[0135] It should be understood that through CloudCore's real-time monitoring and dynamic scheduling, the system can continuously adjust resource configuration and task allocation strategies to cope with various situations that arise in actual operation, thereby optimizing overall task execution efficiency and ensuring system stability.

[0136] It should be further explained that when task migration is executed, the task migration algorithm is used to dynamically migrate tasks with insufficient or overloaded resources to other idle or better-performing domestic GPUs for execution, and a synchronization mechanism is used to ensure seamless migration of tasks between different nodes.

[0137] It is worth noting that a resource monitoring module is deployed on edge computing nodes. Prometheus and Grafana are integrated as performance monitoring tools to monitor key performance indicators such as utilization, power consumption, and temperature of domestic GPUs and edge nodes in real time. A Node Exporter container is deployed to collect node-level system information. The collected performance data is stored in a central database, and Prometheus is configured to regularly capture performance indicators of domestic GPUs and edge nodes and send the data to the database.

[0138] It should be noted that a resource monitoring module is deployed on edge computing nodes, integrating Prometheus and Grafana to monitor key performance indicators such as utilization, power consumption, and temperature of domestically produced GPUs in real time, with particular attention paid to the usage of different types of domestically produced GPUs. Monitoring data is regularly collected by the Agent program and sent to CloudCore for analysis and processing. CloudCore receives and analyzes monitoring data from edge nodes, assessing the current system status and task execution. Based on this analysis, it provides a basis for dynamic scheduling decisions to adjust task allocation and resource allocation strategies.

[0139] CloudCore receives and analyzes monitoring data from edge nodes, primarily for data storage and preprocessing. It also performs utilization analysis, power consumption and temperature analysis, task execution analysis, and trend analysis. Subtask execution analysis assesses whether the actual operating efficiency of subtasks meets expectations based on their execution time and data transmission rate. Trend analysis uses historical data analysis to predict future resource demand and load conditions, providing a reference for scheduling strategies.

[0140] Among them, CloudCore has been customized to optimize task allocation by real-time monitoring of the resource usage of domestic GPUs. Its dynamic scheduling strategy is mainly based on three trigger conditions: resource overload, abnormal power consumption or temperature, and low task execution efficiency. When the utilization rate of domestic GPUs is too high or too low for a long time, CloudCore will reallocate tasks to achieve load balancing. If power consumption or temperature exceeds the standard, the system will adjust task allocation to protect the hardware. In addition, if the task execution efficiency is lower than expected, CloudCore will consider migrating the task to a GPU with better performance. These features together improve the utilization efficiency of GPU resources and the stability of the system.

[0141] It should be noted that the computing task allocation in this application is achieved through task containerization, DAG task graph construction, CPOP algorithm scheduling, dynamic resource monitoring and feedback, task migration and load balancing, as well as comprehensive scheduling and resource optimization, to achieve coordinated adaptation of domestic GPU computing power under heterogeneous computing platforms, thereby improving task execution efficiency and system performance.

[0142] Among them, container technology is used to package the computing tasks to be executed and their dependent environments into container images that can run seamlessly on any computing node, and container orchestration tools are used to deploy each task container image to the edge computing node.

[0143] In practice, computing task allocation first requires deploying an edge computing framework on edge nodes. The specific steps include: ① Select KubeEdge as the edge computing framework. ② Install a Kubernetes cluster and the kubectl command-line tool. ③ Download and execute the KubeEdge installation script, confirming that the KubeEdge control plane is started. ④ Configure CloudCore, set edge node management parameters in the CloudCore configuration file, and start CloudCore. ⑤ Install and configure EdgeCore on each edge node, confirming that EdgeCore is started.

[0144] Secondly, it is necessary to encapsulate and virtualize domestic GPU resources. The specific steps include: Basic image construction: For different models of domestic GPUs, the technical solution builds special basic container images. These images are pre-installed with the corresponding GPU drivers and necessary runtime libraries to ensure that applications can run smoothly on domestic GPUs. At the same time, by using container technology, this solution solves the incompatibility issues between different operating systems and enhances the versatility and compatibility of the system. The flowchart of task container deployment can be referred to. Figure 2 , Figure 2 The deployment process of the edge node is to first deploy the edge computing framework, install and configure EdgeCore on each edge node, and install Docker on each edge node at the same time, then encapsulate and virtualize the GPU resources, and then build the Docker image (create a Dockerfile to encapsulate GPU resources, build the Docker image and run the Docker container), further install the Kuber netes device plug-in on the master node and issue tasks, and then run the main container on the CloudCore master node and the edge container on each edge node. Each subtask corresponds to a container, and the computing tasks are represented as a directed acyclic graph, and the execution order and priority of each task are determined.

[0145] Adaptation Scripts: The technical solution introduces a set of domestic GPU adaptation scripts that automatically convert application source code to accommodate different domestic GPUs. The script package includes a Dockerfile build script, making image creation and distribution more convenient and efficient.

[0146] The constructed domestic GPU container image library and domestic GPU adaptation script are the core resources for domestic GPU adaptation. The scheduler can extract the appropriate container image according to the model of the domestic GPU and deploy it to the designated computing node to ensure that it can run normally on the target hardware. Using these container image libraries and scripts, the computing tasks to be executed and their dependent environments can be packaged into container images that can run seamlessly on any computing node, and each task container image can be deployed to the edge computing node using the container orchestration tool. The specific steps include: ① Install Docker on each edge node. ② Build an image through Dockerfile to encapsulate domestic GPU resources. The image includes: GPU driver and subtask operating environment. The image is differentiated according to the domestic GPU manufacturer and model. The number of domestic GPUs used in the scheduling process is determined by the subtask characteristics and is configured by parameters when the subtask is started. The subtask is determined by the main task deployed on the edge node.

[0147] It's worth emphasizing that the construction of a domestic GPU container image library enables customized base container images for different domestic GPU models. The system tags images based on domestic GPU models, inference frameworks, and measured performance, enabling efficient task scheduling based on a "task-computing power" model. Compared to traditional manual scheduling or simple rule-based scheduling, this method offers higher scheduling efficiency and more precise allocation strategies, achieving optimal resource utilization and efficiency for domestic GPU scheduling. During the image library construction process, corresponding domestic GPU adaptation scripts were developed. These scripts automatically perform the necessary conversions on application source code to adapt to different domestic GPU models. The introduction of adaptation scripts greatly simplifies the application adaptation process, lowers the technical barriers, and accelerates application deployment and operation. They address the traditional method of manually configuring and installing GPU drivers, which is complex and error-prone. They also address compatibility issues between different GPU models and operating systems, improve the usability of cross-platform deployments, and automate the build process, reducing manual intervention and increasing build efficiency.

[0148] Thirdly, the device plug-in enables it to identify and schedule domestic GPUs, and controls the scheduling of specific domestic GPU resources through labels and selectors. When requesting domestic GPU resources, the container can match and schedule according to the label. The specific plug-in can be an improved or customized version of the Huawei Ascend 310, 910B or Cambrian MLU370 device plug-in, which is suitable for domestic GPUs. When deploying containers, specify the required domestic GPU resources. It supports tasks for single-card and multi-card domestic GPUs; when tasks are issued, it supports heterogeneous scheduling strategies, that is, dynamically adjusts the scheduling of tasks according to the computing power and load conditions of different domestic GPUs. For example, idle high-performance domestic GPU resources can be allocated first to urgent tasks, while ordinary tasks use lower-performance domestic GPUs.

[0149] It's important to emphasize that building a basic image for domestic GPU resource encapsulation and virtualization and introducing adaptation scripts can achieve the following: 1. Expanding the compatibility of domestic GPUs: A modular design separates the GPU driver from the rest of the system, facilitating subsequent expansion and maintenance. Leveraging a plug-in mechanism, adapter plug-ins for different GPU models are developed, facilitating integration through standardized interfaces. 2. Real-time hardware environment monitoring: A hardware monitoring module is built to collect real-time system hardware status, such as GPU model, temperature, and power consumption. Based on this collected data, the system configuration is dynamically adjusted to optimize hardware resource allocation. 3. Accelerating image library retrieval: A caching mechanism is introduced to cache frequently used images, reducing repeated search time. Index optimization is implemented to improve search efficiency and shorten deployment time. 4. Strengthening coordination between the scheduler and hardware: Optimizing the scheduling algorithm prioritizes tasks requiring high GPU performance. Implementing load balancing ensures optimal resource allocation and improves overall resource utilization. 5. Improving compatibility with domestic operating systems: Based on the characteristics of domestic operating systems, system kernel parameters are adjusted to ensure compatibility. Developing drivers specifically for domestic operating systems improves system stability. 6. Regularly update adaptation scripts: Establish an adaptation script update mechanism to track hardware upgrades and optimizations in real time. Optimize existing adaptation scripts to improve script execution efficiency.

[0150] It's worth noting that after deploying edge nodes, further registration and management are required. The specific steps include: ① Generate a token on the CloudCore master node. ② Run the registration command on each edge node to confirm that the edge node has been registered. ③ Configure EdgeCore by editing the EdgeCore configuration file on each edge node and starting EdgeCore. ④ Use kubectl to manage resources on the edge node.

[0151] In the specific implementation, the overall process of the computing task allocation method is as follows: Figure 3 , Figure 3In step S1, task containerization deployment includes using container technology to package the computing task to be executed and its dependent environment into a container image that can run seamlessly on any computing node, and using the container orchestration tool to deploy each task container image to the edge computing node; step S2 represents the computing task as a directed acyclic graph, where nodes represent computing subtasks and edges represent dependencies between subtasks; the dependencies between subtasks are analyzed to determine the execution order and priority of each subtask; step S3 determines the priority of the subtask, which can be determined based on the DAG task graph constructed based on the subtask priority, wherein the subtasks on the critical path are determined, that is, the most critical part of the subtask execution sequence; step S4 identifies the critical path tasks in the DAG graph, which can be identified by using CPOP to identify the critical path tasks in the DAG graph, and calculates the execution order and priority of each subtask in the DAG graph. Based on the estimated completion time on the GPU, the optimal GPU is selected for scheduling each subtask according to the calculated results. Step S5 deploys a resource monitoring module, which can integrate Prometheus and Grafana to monitor key performance indicators such as GPU utilization, power consumption, and temperature in real time. Monitoring data is regularly collected by the Agent program and sent to the central management system for analysis and processing. Monitoring data from edge nodes is received and analyzed to evaluate the current system status and task execution status. Based on the analysis results, a basis for dynamic scheduling decisions is provided to adjust task allocation and resource allocation strategies. Step S6 triggers task migration, which can detect whether there is insufficient or overloaded resources on the edge node based on real-time monitoring data and load balancing algorithms. If it is detected that the resource utilization of a node is too high or the execution time of a task is too long, the task migration operation is triggered. Scheduling is performed based on a comprehensive indicator of task priority, resource utilization, energy consumption, and task response time.

[0152] It should be noted that by deeply analyzing the specific requirements of different computing tasks, including specific requirements for video memory and computing power, we accurately match the performance indicators of domestic GPUs in different training and inference frameworks in actual tests to achieve the best match between tasks and domestic GPUs. This model aims to provide users with accurate and efficient GPU adaptation strategies by optimizing task execution efficiency and achieving effective management of performance task matching.

[0153] This embodiment provides a computing task allocation method, which decomposes a computing task to be executed into multiple subtasks by labeling its features, constructs a directed acyclic graph based on the dependencies between the subtasks, and uses topological sorting to determine the priority and execution order of each subtask. By calculating the reference execution time of each subtask on different GPUs, the subtasks are allocated to each GPU for execution by comprehensively considering the reference execution time, priority, and execution order. This effectively optimizes the decomposition and scheduling process of the computing task, improves resource utilization and execution efficiency, and ensures the efficient and orderly completion of large-scale computing tasks.

[0154] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 4 , step S30 further includes steps S31 to S33:

[0155] Step S31: constructing a dependency matrix according to the dependency relationships between the subtasks, and constructing a directed acyclic graph according to the dependency matrix.

[0156] It should be noted that the nodes in the directed acyclic graph represent computing tasks, and the edges represent the dependencies between tasks; the dependencies between tasks are analyzed to determine the execution order and priority of each task. Each subtask is represented as a node, which can contain metadata about the subtask, such as task ID, task description, and resources required for the task (including specific domestic GPU types and quantities). Directed edges are added between subtasks to represent the dependencies between subtasks. If subtask A must be completed before subtask B, a directed edge is added between nodes A and B, pointing from A to B.

[0157] It should be noted that when analyzing the dependencies between subtasks, dependency analysis is performed using a dependency matrix to determine the dependencies between subtasks. The elements in the matrix represent the dependencies between subtasks. For example, a matrix element M[i][j] of 1 indicates that subtask i depends on subtask j.

[0158] The dependency matrix is ​​constructed. When the matrix element M[i][j] is 1, it indicates that subtask i depends on subtask j. The steps to implement the dependency matrix include: listing the subtasks, identifying all subtasks, and assigning each subtask a unique number. Determining the dependencies, analyzing the dependencies between subtasks, and determining which subtasks depend on the completion of other subtasks. Constructing the matrix: Create a matrix where the rows and columns represent the task numbers. If subtask i depends on subtask j, fill the i-th row and j-th column of the matrix with 1; otherwise, fill them with 0.

[0159] In the specific implementation, there are three subtasks. Subtask 1 depends on subtask 2, and subtask 2 depends on subtask 3. The specific dependency matrix can be referred to in Table 1 below:

[0160] Table 1

[0161] Subtask 1 Subtask 2 Subtask 3 Subtask 1 0 1 0 Subtask 2 0 0 1 Subtask 3 0 0 0

[0162] Among them, the computing task is represented as a directed acyclic graph (DAG). Before analyzing the dependencies between subtasks, the task submission and feature annotation are performed first. The specific steps of representing the computing task as a directed acyclic graph can be referred to Figure 5 , Figure 5 First, user task submission is performed (users submit computing tasks through an interface or user interface, indicating the task computing requirements), then task feature extraction is performed (analyzing the computing characteristics, computing intensity, memory requirements, and data transmission bandwidth requirements of the task), then feature annotation generation is performed (the calculated computing intensity, content requirements, and data transmission characteristics are combined to generate feature annotations), then task decomposition is performed (the computing task is decomposed into multiple subtasks, the subtask feature values ​​are calculated, each subtask is represented as a node, directed edges are added between tasks to represent the dependencies between tasks, priorities are confirmed, and a dependency matrix is ​​constructed), the execution order and priority are determined (topological sorting is used to sort the DAG, the execution order of subtasks is determined, linear sorting is performed according to topological sorting, and the priority of each subtask is determined), and finally the critical path tasks of the DAG graph are identified (CPOP is used to identify the critical path subtasks in the DAG graph, and the estimated completion time of each subtask on different GPUs is calculated, and the optimal GPU is selected for task scheduling based on the calculation results)

[0163] Step S32: topologically sorting each subtask based on the directed acyclic graph to obtain an execution order of each subtask.

[0164] It should be noted that when determining the execution order and priority of each subtask, a topological sort is used to sort the DAG and determine the execution order of the subtasks. Linear sorting based on topological sorting ensures that each subtask can only be executed after all its predecessor subtasks have completed. When calculating the priority, the topological sort result and the critical path of the subtask are used to determine the priority of each subtask.

[0165] It should be emphasized that topological sorting is a method of sorting the nodes in a directed acyclic graph (DAG) so that for each directed edge (u, v) in the graph, node u comes before node v in the sorting. The result of topological sorting can be used to formulate the execution plan of subtasks to ensure that subtasks are executed in the correct order.

[0166] In a feasible implementation, step S32 may include steps A321 to A324:

[0167] Step A321 : Identify the number of dependent subtasks of the subtask, and use the number of dependent subtasks as the in-degree value of the subtask.

[0168] It should be noted that the number of dependent subtasks can be understood as the number of other subtasks that depend on this subtask. For example, if the subtasks that depend on subtask A are subtask K, subtask J, and subtask M, then the number of dependent subtasks is 3, and 3 is used as the in-degree value of this subtask.

[0169] Step A322: The subtasks with the preset in-degree value in the directed acyclic graph are marked as subtasks, and the marked subtasks are sequentially filled into the subtask execution sequence table.

[0170] It is understandable that the preset value may be a previously set value. In this embodiment, the preset value is 0 for illustration.

[0171] It should be noted that a subtask with an in-degree of 0 can be understood as a subtask that has no dependencies on any other subtasks and is usually the earliest subtask that can be started.

[0172] It should be noted that the subtask execution sequence table can be a blank table created in advance, and the execution order of each subtask can be determined based on the time when the subtasks are filled into the subtask execution sequence table.

[0173] Step A323, the marked subtask is removed from the directed acyclic graph to obtain an updated directed acyclic graph, and the subtask with the preset in-degree value in the directed acyclic graph is returned as the marked subtask, and the marked subtask is filled into the subtask execution sequence table in sequence, until each subtask is filled into the subtask execution sequence table in sequence.

[0174] It should be understood that the subtasks are represented as a directed acyclic graph, and the subtask nodes with zero in-degree are removed to obtain an updated directed acyclic graph. The number of subtask nodes in the updated directed acyclic graph becomes smaller, and the in-degree of each subtask node in the directed acyclic graph is recalculated, and the subtasks with zero in-degree are filled into the subtask execution order table in sequence again.

[0175] It should be noted that the process of removing subtask nodes with zero in-degree and then updating the directed acyclic graph and recalculating the in-degree of each subtask node is repeated until all nodes are sorted. If there are still unsorted nodes in the graph, it indicates a circular dependency and topological sorting cannot be performed.

[0176] Step A324: The order of each subtask in the subtask execution order table is used as the execution order of each subtask.

[0177] It is understandable that the position of the subtasks in the sequence table determines the order in which they are executed.

[0178] In this embodiment, the dependency analysis and execution order optimization of the subtasks in the directed acyclic graph are performed through a topological sorting algorithm. The dependency of the subtasks can be dynamically tracked, and subtasks with no dependencies or whose dependencies have been fully completed can be continuously screened and removed. The execution order table is gradually constructed, and finally a conflict-free linearized execution sequence is generated.

[0179] The above is only a feasible implementation of step S32 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S32.

[0180] Step S33: obtaining a critical path based on the execution order of each subtask, and obtaining a priority of each subtask based on the critical path and the execution order.

[0181] It should be noted that the subtask priority is determined based on the constructed DAG task graph. Among them, the tasks on the critical path are identified, that is, the most critical part of the task execution sequence. The CPOP (Critical Path on a Processor) algorithm is used to identify the critical path tasks in the DAG graph.

[0182] Furthermore, continuously monitor the execution of tasks and the usage of system resources, such as GPU utilization, computing load, data transmission speed, etc. Adjust the priority of tasks based on the monitoring data. For example, if a task is found to have a data transmission speed much lower than expected during execution, the priority of the task can be increased so that data transmission and calculation can be completed as quickly as possible. The critical path is the most important path that affects the overall task completion time. If the execution time of a task changes, the critical path may need to be recalculated to ensure optimized scheduling. Based on the actual operation of the task, migrate the task from a domestic GPU with a higher load to a domestic GPU with a lower load, or assign the task to a new domestic GPU resource for load balancing. Update the scheduling strategy and reallocate resources based on the adjusted task priority and critical path.

[0183] In this implementation, assume the following subtasks in a DAG: Task A (Compute Intensity = 80, Data Size = 200MB, Latency Sensitivity = 1 second); Task B (Compute Intensity = 120, Data Size = 300MB, Latency Sensitivity = 1.5 seconds). When Task A was executed on domestic GPU 1, the data transfer speed was found to be far lower than expected. The monitoring system revealed that the excessive load on domestic GPU 1 caused Task A to complete 30% longer.

[0184] The adjustment strategy is to increase the priority of Task A to ensure its execution first. Recalculating the critical path in the DAG reveals that Task B is now the new critical path task. Task A is then migrated to GPU 2, a domestic GPU with a lower load and higher data transfer rates.

[0185] The scheduling strategy was further updated to reflect the newly added domestic GPU resource allocation for Task A and Task B. This adjustment ensured that the critical path in the DAG was optimized, thereby improving overall task execution efficiency.

[0186] It is worth noting that optimization is carried out at the driver level to improve the performance of domestic GPUs in specific application scenarios. The compatibility and performance of the computing library are improved through customized drivers or patches. For domestic GPUs, the operating parameters of the deep learning framework or computing library are optimized to ensure efficient operation. Cooperate with relevant manufacturers to improve the adaptability of the software ecosystem; tasks with more dependencies in the DAG graph are assigned to the same type of GPU to reduce the data transmission overhead across GPUs. For tasks that must communicate across GPUs, choose a connection path with higher bandwidth. Different domestic GPUs have different types of computing acceleration implementations. For example, Huawei Ascend uses its own Mindie framework to achieve computing acceleration. This solution makes up for the shortcomings of domestic GPUs in specific computing tasks by supporting different types of acceleration frameworks.

[0187] Furthermore, monitoring modules (such as Prometheus and Grafana) are used to track the performance indicators of domestic GPUs in real time, dynamically adjust task scheduling and resource allocation strategies according to actual conditions, and adjust task allocation in real time according to performance changes detected during task execution. The system will perform calculations based on the performance data of domestic GPUs to ensure that the performance after switching is not lower than the original performance, thereby ensuring the service quality of the system. A dynamic scheduling method for heterogeneous computing power of domestic GPUs based on containerization has been implemented, which can effectively solve the problems of insufficient static resource allocation and performance optimization, realize the coordinated adaptation of domestic GPU computing power under heterogeneous computing platforms, and maximize the utilization of computing power. This technical solution is suitable for various edge computing scenarios, especially application fields that require large-scale parallel computing and complex data processing, such as industrial Internet of Things, intelligent transportation, etc.

[0188] Furthermore, the load of domestic GPUs is monitored in real time, and a dynamic resource allocation strategy is implemented. The system uses a resource allocation algorithm designed specifically for domestic GPUs. The resource allocation algorithm targets GPUs and tasks, and first creates GPU resources, each with a unique ID, load, and performance. Tasks are sorted by task demand through a priority queue, and the algorithm traverses the tasks and assigns them to the most suitable GPU. The algorithm takes into account factors such as power consumption, priority, and load limits to ensure efficient resource utilization. Based on the matching degree between GPU performance and task requirements, high-load tasks are automatically directed to GPUs with stronger performance, while low-load tasks are preferentially assigned to GPUs with lower power consumption. This solution aims to optimize resource utilization efficiency and ensure the stability and efficiency of task execution.

[0189] This embodiment provides a method for allocating computing tasks, which uses a directed acyclic graph (DAG) model to represent subtasks and their dependencies, and determines the execution order and priority of subtasks through analysis. The method includes critical path identification and subtask priority allocation to ensure that critical tasks can be executed preferentially on high-performance domestic GPUs. The CPOP algorithm is applied to identify tasks on the critical path and calculate the estimated completion time of these tasks on different domestic GPUs. Based on the task execution efficiency, the optimal domestic GPU is selected to optimize resource utilization and reduce task execution time. Compared with traditional resource scheduling algorithms based on static configurations that cannot adapt to dynamically changing workloads, dynamic scheduling strategies are used to improve resource utilization and system scalability, solving the problems of low resource utilization and insufficient system scalability of heterogeneous domestic GPUs.

[0190] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the computing task allocation method of this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0191] This application also provides a computing task allocation device, please refer to Figure 6 , the computing task allocation device includes:

[0192] The labeling module 10 is used to obtain a computing task to be executed, extract features of the task to be executed, and obtain feature labels;

[0193] A task decomposition module 20 is configured to decompose the computing task to be executed based on the feature annotation to obtain subtasks;

[0194] The task allocation module 30 is used to construct a directed acyclic graph based on the dependency matrix between the subtasks, and to perform topological sorting on the subtasks in the directed acyclic graph to obtain the priority and execution order of the subtasks;

[0195] The task allocation module 30 is further configured to calculate the reference execution time of the subtasks on each GPU, and allocate the subtasks according to the reference execution time, the priority, and the execution order.

[0196] The computing task allocation device provided in this application, which utilizes the computing task allocation method described in the aforementioned embodiments, can address the current technical issue of domestically produced GPU computing power allocation being unable to effectively respond to complex changes in computing requirements. Compared to the prior art, the computing task allocation device provided in this application has the same beneficial effects as the computing task allocation method described in the aforementioned embodiments, and the other technical features of the computing task allocation device are the same as those disclosed in the aforementioned embodiments, and are not further elaborated here.

[0197] In one embodiment, the obtaining and marking module 10 is further used to obtain a computing task to be executed, and extract computing features from the computing task to obtain computing features, wherein the computing features include computing intensity, memory requirements, and data transmission characteristics;

[0198] Obtaining a reference adaptive GPU model and an adaptation priority according to the computing intensity, the memory requirement, and the data transmission characteristics;

[0199] Generate feature annotations according to the reference adapted GPU model and the adaptation priority;

[0200] In one embodiment, the task decomposition module 20 is further configured to perform a preliminary decomposition on the computing task to be executed to obtain initial subtasks;

[0201] Obtaining feature annotations for each initial subtask based on the feature annotations and the calculation ratios of the initial subtasks;

[0202] Each subtask is obtained according to the feature annotations of each initial subtask and the corresponding initial subtask.

[0203] In one embodiment, the task allocation module 30 is further configured to construct a dependency matrix based on the dependency relationships between the subtasks, and to construct a directed acyclic graph based on the dependency matrix;

[0204] Topologically sorting each subtask based on the directed acyclic graph to obtain an execution order of each subtask;

[0205] A critical path is obtained based on the execution order of the subtasks, and a priority of the subtasks is obtained based on the critical path and the execution order.

[0206] In one embodiment, the task allocation module 30 is further configured to identify the number of dependent subtasks of the subtask, and use the number of dependent subtasks as the in-degree value of the subtask;

[0207] Using the subtasks with a preset in-degree value in the directed acyclic graph as marked subtasks, and sequentially filling the marked subtasks into the subtask execution order table;

[0208] The marked subtask is removed from the directed acyclic graph to obtain an updated directed acyclic graph, and the subtasks with in-degree values ​​of a preset value in the directed acyclic graph are returned as marked subtasks, and the marked subtasks are sequentially filled into a subtask execution order table until each subtask is sequentially filled into the subtask execution order table;

[0209] The order of each subtask in the subtask execution order table is used as the execution order of each subtask.

[0210] In one embodiment, the task allocation module 30 is further configured to obtain a computing time based on the computing intensity of the subtask and the computing capability of each GPU;

[0211] Determine the transmission time based on the data size of the subtask and the actual bandwidth of each GPU;

[0212] A reference execution time of the subtask on each GPU is obtained according to the calculation time and the transmission time.

[0213] In one embodiment, the task allocation module 30 is further configured to obtain the real-time status of each GPU;

[0214] Identifying an abnormality cause of the GPU based on the real-time status abnormality, the abnormality cause including resource overload, power consumption or temperature abnormality, and task execution efficiency abnormality;

[0215] When the cause of the abnormality is resource overload, performing subtask load balancing adjustment on the GPU;

[0216] When the abnormality is caused by abnormal power consumption or temperature, performing subtask migration adjustment on the GPU;

[0217] When the abnormal reason is low task execution efficiency, subtask efficiency is adjusted on the GPU.

[0218] The present application provides a computing task allocation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the computing task allocation method in the above-mentioned embodiment one.

[0219] Reference below Figure 7, which shows a schematic diagram of the structure of a computing task allocation device suitable for implementing the embodiments of the present application. The computing task allocation device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The computing task allocation device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0220] like Figure 7 As shown, the computing task distribution device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the computing task distribution device. Processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and communication device 1009. Communication device 1009 can allow the computing task distribution device to communicate with other devices wirelessly or wired to exchange data. Although the figure shows a computing task distribution device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0221] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0222] The computing task allocation device provided in this application, which utilizes the computing task allocation method described in the aforementioned embodiment, can address the current technical issue of domestically produced GPU computing power allocation being unable to effectively respond to complex changes in computing requirements. Compared to the prior art, the computing task allocation device provided in this application has the same beneficial effects as the computing task allocation method described in the aforementioned embodiment. Other technical features of this computing task allocation device are the same as those disclosed in the aforementioned embodiment and are not further elaborated here.

[0223] It should be understood that the various parts disclosed in this application can be implemented with hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in a suitable manner in any one or more embodiments or examples. The above is only a specific implementation method of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or replacements within the technical scope disclosed in this application, which should be included in the scope of protection of this application. Therefore, the scope of protection of the present application shall be based on the scope of protection of the claims.

[0224] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer program) stored thereon, and the computer-readable program instructions are used to execute the computing task allocation method in the above-mentioned embodiment.

[0225] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0226] The computer-readable storage medium may be included in the computing task allocation device, or may exist independently without being assembled into the computing task allocation device.

[0227] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the computing task allocation device, the computing task allocation device enables the following: to obtain the computing task to be executed, perform feature extraction on the task to be executed, and obtain feature annotation; to decompose the computing task to be executed based on the feature annotation to obtain each subtask; to construct a directed acyclic graph based on the dependency matrix between each subtask, and to topologically sort each subtask in the directed acyclic graph to obtain the priority and execution order of each subtask; to calculate the reference execution time of the subtask on each GPU, and to allocate each subtask according to the reference execution time, priority and execution order.

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

[0229] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0230] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0231] The computer-readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned computing task allocation method. This computer-readable storage medium can address the current technical issue of domestically produced GPU computing power allocation being unable to effectively respond to complex changes in computing requirements. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the computing task allocation method provided in the aforementioned embodiment, and are not further elaborated here.

[0232] The present application also provides a computer program product, comprising a computer program, which implements the steps of the above-mentioned computing task allocation method when executed by a processor.

[0233] The computer program product provided in this application can address the current technical problem of domestically produced GPU computing power allocation being unable to effectively cope with complex changes in computing requirements. Compared to the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the computing task allocation method provided in the above-mentioned embodiment, and will not be elaborated here.

[0234] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A computing task allocation method, characterized in that: The computing task allocation method includes: Obtaining a computing task to be executed, performing feature extraction on the task to be executed, and obtaining feature annotations; Decomposing the computing task to be executed based on the feature annotation to obtain subtasks; Constructing a directed acyclic graph based on the dependency matrix between the subtasks, and topologically sorting the subtasks in the directed acyclic graph to obtain the priority and execution order of the subtasks; The reference execution time of the subtasks on each GPU is calculated, and the subtasks are allocated according to the reference execution time, the priority, and the execution order.

2. The method according to claim 1, wherein The step of obtaining a computing task to be executed, extracting features of the task to be executed, and obtaining feature annotations includes: Obtaining a computing task to be executed, and extracting computing features from the computing task to obtain computing features, wherein the computing features include computing intensity, memory requirements, and data transmission characteristics; Obtaining a reference adaptive GPU model and an adaptation priority according to the computing intensity, the memory requirement, and the data transmission characteristics; Generate feature annotations according to the reference adapted GPU model and the adaptation priority.

3. The method according to claim 1, wherein Decomposing the computing task to be executed based on the feature annotation to obtain subtasks includes: Preliminarily decomposing the computing task to be executed to obtain initial subtasks; Obtaining feature annotations for each initial subtask based on the feature annotations and the calculation ratios of the initial subtasks; Each subtask is obtained according to the feature annotations of each initial subtask and the corresponding initial subtask.

4. The method according to claim 1, wherein The step of constructing a directed acyclic graph based on the dependency matrix between the subtasks, and topologically sorting the subtasks in the directed acyclic graph to obtain the priority and execution order of the subtasks includes: Constructing a dependency matrix according to the dependency relationships between the subtasks, and constructing a directed acyclic graph according to the dependency matrix; Topologically sorting each subtask based on the directed acyclic graph to obtain an execution order of each subtask; A critical path is obtained based on the execution order of the subtasks, and a priority of the subtasks is obtained based on the critical path and the execution order.

5. The method according to claim 4, wherein The topological sorting of the subtasks based on the directed acyclic graph to obtain the execution order of the subtasks includes: Identify the number of dependent subtasks of the subtask, and use the number of dependent subtasks as the in-degree value of the subtask; Using the subtasks with a preset in-degree value in the directed acyclic graph as marked subtasks, and sequentially filling the marked subtasks into the subtask execution order table; The marked subtask is removed from the directed acyclic graph to obtain an updated directed acyclic graph, and the subtasks with in-degree values ​​of a preset value in the directed acyclic graph are returned as marked subtasks, and the marked subtasks are sequentially filled into a subtask execution order table until each subtask is sequentially filled into the subtask execution order table; The order of each subtask in the subtask execution order table is used as the execution order of each subtask.

6. The method according to claim 1, wherein Calculating the reference execution time of the subtask on each GPU includes: Obtaining computing time based on the computing intensity of the subtask and the computing capability of each GPU; Determine the transmission time based on the data size of the subtask and the actual bandwidth of each GPU; A reference execution time of the subtask on each GPU is obtained according to the calculation time and the transmission time.

7. The method according to claim 1, wherein After calculating the reference execution time of the subtasks on each GPU and allocating the subtasks according to the reference execution time, the priority, and the execution order, the method further includes: Acquire the real-time status of each GPU, and identify the cause of the GPU abnormality based on the real-time status abnormality, wherein the cause of the abnormality includes resource overload, power consumption or temperature abnormality, and task execution efficiency abnormality; When the cause of the exception is resource overload, identifying a first reference GPU, where the utilization of the first reference GPU meets the utilization requirement, obtaining a first subtask to be adjusted from the GPU whose priority is lower than a preset priority, and migrating the first subtask to be adjusted to the first reference GPU to achieve subtask load balancing adjustment; When the abnormality is caused by abnormal power consumption or temperature, identifying a second reference GPU, the temperature of the second GPU meeting the temperature requirement, obtaining a second subtask to be adjusted in the GPU whose priority is lower than a preset priority, migrating the second subtask to be adjusted to the second reference GPU or adjusting the task priority of the GPU; When the cause of the exception is low task execution efficiency, a third reference GPU is identified, the computing power of the third reference GPU meets the computing power requirements, and the subtask being executed in the GPU is migrated to the third reference GPU or the data transmission path and bandwidth of the GPU are optimized.

8. The method according to claim 7, wherein The acquiring of the real-time status of each GPU and identifying the abnormal cause of the GPU based on the abnormal real-time status, wherein the abnormal cause includes resource overload, power consumption or temperature abnormality, and task execution efficiency abnormality, include: Obtain the real-time status of each GPU, including real-time utilization, real-time temperature, real-time power consumption, and current task execution time; If the real-time utilization is greater than a preset utilization threshold, the GPU is resource overloaded; If the real-time temperature is greater than a preset high temperature threshold and the real-time power consumption is greater than a power consumption threshold, then the GPU has power consumption or temperature anomalies; If the current task execution time is greater than a preset time threshold, the GPU has task execution efficiency abnormality.

9. A computing task allocation device, characterized in that: The computing task allocation device comprises: An acquisition and annotation module is used to acquire computing tasks to be executed, perform feature extraction on the tasks to be executed, and obtain feature annotations; A task decomposition module is used to decompose the computing task to be executed based on the feature annotation to obtain various subtasks; A task allocation module is used to construct a directed acyclic graph based on the dependency matrix between the subtasks, and to topologically sort the subtasks in the directed acyclic graph to obtain the priority and execution order of the subtasks; The task allocation module is further configured to calculate the reference execution time of the subtasks on each GPU, and allocate the subtasks according to the reference execution time, the priority, and the execution order.

10. A computing task allocation device, characterized in that: The computing task allocation device includes: a memory, a processor, and a computing task allocation program stored in the memory and executable on the processor, wherein the computing task allocation program is configured to implement the computing task allocation method according to any one of claims 1 to 6.

11. A storage medium, characterized in that: The storage medium stores a computing task allocation program, which, when executed by a processor, implements the computing task allocation method according to any one of claims 1 to 8.

12. A computer program product, characterized in that The computer program product comprises a computing task allocation program, which implements the steps of the computing task allocation method according to any one of claims 1 to 9 when executed by a processor.

Images