Task processing device and computing device

Abstract

The invention discloses a task processing device and a computing device, and relates to the technical field of computers.According to the task processing device, a task management module is newly added behind each task execution unit, and a task analysis module sends a task mask to the task management module, so that the task management module can perform task processing according to the task masks. After each sub-task execution module executes the sub-tasks, execution results of the sub-tasks can be sent to the task management module for caching, then the task management module monitors whether all the sub-tasks of the to-be-calculated task are executed or not based on the task masks, and under the condition that all the sub-tasks of the to-be-calculated task are executed, the sub-tasks of the to-be-calculated task are executed. And outputting a task execution result. Therefore, the sub-tasks can be prevented from being retained in the sub-task execution units, so that the processing efficiency of the system is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to task processing devices and computing devices. Background Technology

[0002] With the increasing popularity of high-concurrency systems, the producer-consumer model, as a concurrent computing model, is widely used in fields such as chip design and real-time data processing. Because the functions of producers and consumers are independent of each other, decoupling between task generation and task execution can be achieved.

[0003] Currently, in some technologies, tasks issued by producers are typically divided into multiple subtasks, which are then executed in parallel by multiple task execution units of the consumer. For multiple task execution units performing the same task, the final task execution result can be obtained based on the output of each unit. However, due to the varying complexity of different subtasks, the completion time of different task execution units differs significantly, causing some subtasks to remain in the execution units for extended periods, thus affecting the overall processing efficiency of the system and requiring improvement. Summary of the Invention

[0004] This application provides a task processing device and a computing device to at least solve the problem of low system processing efficiency caused by subtasks lingering in the execution unit in related technologies.

[0005] This application provides a task processing apparatus, including a task receiving module, a task parsing module, a task execution module, and a task management module, wherein: The task receiving module is used to receive task information for tasks to be calculated; The task parsing module is used to divide the task to be calculated into multiple subtasks, construct a task mask based on the number of subtasks, and send the task mask to the task management module. The task mask includes multiple bits, and each bit corresponds to a subtask. The task execution module includes multiple sub-task execution modules. The sub-task execution modules are used to execute the sub-tasks issued by the task parsing module, and when the sub-tasks are completed, they notify the task management module to update the task mask so as to record the completed sub-tasks through the task mask. The task management module is used to output the task execution result based on the task mask, provided that all subtasks of the task to be calculated have been completed.

[0006] This application also provides a computing device for running the above-described task processing device.

[0007] In some embodiments of this application, a task management module is added after each task execution unit. The task parsing module sends the task mask to the task management module. After each subtask execution module completes its subtask, it can send the execution result to the task management module for caching. The task management module then monitors whether all subtasks of the task to be calculated have been completed based on the task mask. Only when all subtasks of the task to be calculated have been completed is the task execution result output. This avoids subtasks remaining in the subtask execution unit, thereby improving the system's processing efficiency. Attached Figure Description

[0008] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a schematic diagram of the structure of the task processing device provided in the embodiments of this application; Figure 2 This is a schematic diagram of another task processing device provided in an embodiment of this application; Figure 3 A schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0010] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0011] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0012] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0013] The producer-consumer model is a concurrent computing model primarily used to address asynchronous data production and consumption, thereby improving the system's parallel processing capabilities and resource utilization efficiency. This model can include two approaches: First, the producer directly transmits the generated tasks to the consumer, which then executes them. Second, the producer writes the generated tasks into a buffer, which the consumer then reads and executes. The buffer enables task synchronization and resource sharing.

[0014] With the widespread adoption of heterogeneous computing and high-concurrency systems, the producer-consumer model has expanded from a single producer-single consumer structure to a more complex structure with multiple producers and multiple consumers. Furthermore, in some scenarios, the tasks issued by the producer can include multiple subtasks. In such cases, consumers need to possess capabilities such as task decomposition, task scheduling, and task aggregation to ensure system processing efficiency. Therefore, higher demands are placed on the construction of the entire model.

[0015] Currently, in related technologies, for the producer-consumer model built in a hardware system, the consumer can be a subtask processing unit. When the consumer divides the task issued by the producer into multiple subtasks, it mainly uses the following methods for processing.

[0016] 1) Serial execution: Subtasks are executed sequentially by the same subtask processing unit according to a preset order. However, since the task execution time increases linearly with the number of subtasks, it is difficult to meet the high throughput requirements in scenarios with a large number of subtasks.

[0017] 2) Parallel Execution: Tasks issued by the producer are typically divided into multiple subtasks, which are then executed in parallel by multiple task execution units of the consumer. For multiple task execution units executing the same task, the final task execution result can be obtained based on the output of each unit. However, due to the varying complexity of different subtasks, the completion time of different task execution units differs significantly, causing some subtasks to remain in the execution units for extended periods, thus affecting the overall processing efficiency of the system.

[0018] 3) Pipeline execution: This method divides subtasks into multiple processing stages, which are then processed sequentially by different hardware modules, forming a pipeline structure. However, when there are dependencies between multiple subtasks, this approach may lead to performance degradation due to pipeline bubbles or resource contention. For example, instruction 2 needs the result of instruction 3, but instruction 1 is still executing. In this case, a null instruction needs to be inserted to wait for instruction 1 to complete before executing instruction 2. This inserted null instruction is a pipeline bubble. Alternatively, delays can be introduced through blocking to ensure the correct execution of different subtasks. However, regardless of the method, both will result in a decrease in task processing efficiency.

[0019] 4) Optimized Scheduling: This approach involves adding different hardware logic modules based on different application scenarios to achieve the desired scheduling method. For example, assigning priorities to subtasks allows for the processing of higher-priority subtasks first; if subtasks have dependencies, the preceding subtask is completed first before executing subsequent subtasks; scheduling can also be based on the resource requirements of subtasks, prioritizing subtasks whose resource requirements match the system resources. Furthermore, different scheduling strategies can be dynamically adjusted based on the actual running status of subtasks. However, regardless of the scheduling method, additional dedicated hardware modules are required, and these modules correspond to specific scheduling strategies, limiting the versatility across different hardware architectures and resulting in high hardware overhead.

[0020] In view of this, this application provides a task processing apparatus that can solve the above problems.

[0021] It should be noted that this task processing device is a task management mechanism based on a producer-consumer model that can be implemented in hardware, and can be applied to high-concurrency task scheduling scenarios in chip-level or board-level systems.

[0022] Specifically, the task processing device can be designed and implemented based on RTL (Register Transfer Level), and modeled using a hardware description language, then deployed on a target hardware platform. The hardware description language can be SystemVerilog; the target hardware platform includes, but is not limited to, Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), or Systems on Chips (SoCs).

[0023] Furthermore, in practical applications, the producer can be a hardware module responsible for generating computational tasks, such as a central processing unit (CPU) or a direct memory access controller (DMC). The consumer can be a processing unit responsible for executing computational tasks, such as a neural network processing unit (NNUnit), a multiply-accumulator array, or a graphics processing unit (GPU). Computational tasks can be high-performance computing tasks, image and video encoding / decoding, such as matrix operations or video frame encoding / decoding.

[0024] See also Figure 1 , Figure 1 This is a schematic diagram of the structure of the task processing device provided in the embodiments of this application, such as... Figure 1As shown, the task processing device includes a task receiving module, a task parsing module, a task execution module, and a task management module, which will be described below.

[0025] 1) Task receiving module, used to receive task information of tasks to be calculated.

[0026] Specifically, the task receiving module can receive task information from the producer regarding tasks to be computed. This task information may include, but is not limited to, task type identifiers, data required for task execution, and task configuration parameters.

[0027] Optionally, the task receiving module can be implemented in the form of a task queue, which can serve as a shared buffer between producers and consumers. Furthermore, the queue depth can be dynamically configured according to different business scenarios to adapt to task loads of different scales.

[0028] Furthermore, this task queue can receive tasks to be computed from multiple producers. To prevent task overflow, the task receiving module can report the task queue status to the producers, who can then decide whether to send new tasks based on the current status. For example, when the task queue is full, the producer will pause sending new tasks; when there is free space in the queue, it will resume sending tasks.

[0029] Furthermore, the task receiving module can sort multiple tasks to be calculated according to their arrival order or task priority, and send the higher priority or earlier arriving tasks to the task parsing module for subsequent processing.

[0030] 2) The task parsing module is used to divide the task to be calculated into multiple subtasks, construct a task mask based on the number of subtasks, and send the task mask to the task management module. The task mask includes multiple bits, and each bit corresponds to a subtask.

[0031] Specifically, the task parsing module reads the task information of the task to be calculated from the task receiving module. By analyzing the task information, it can determine the processing method of the task to be calculated. After identifying the task type, the task parsing module divides the task to be calculated into multiple independently executable subtasks. The division method of subtasks can be determined according to the task type. For example, in neural network calculations, it can be divided according to input channels, output channels, or data blocks; in matrix operations, it can be divided according to rows, columns, or submatrices.

[0032] In this embodiment, the task parsing module can also construct a task mask based on the number of subtasks. The bit width of the task mask is equal to the number of subtasks, and each bit of the task mask corresponds to a subtask, representing the execution status of that subtask. For example, a task to be computed can be divided into three subtasks, meaning the task mask has three bits, and each of these three bits can correspond to a subtask.

[0033] After completing the division of subtasks and constructing the task mask, the task parsing module distributes each subtask to the corresponding subtask execution unit in the task execution module for processing. Simultaneously, the task mask is sent to the task management module, which is responsible for determining the subsequent task execution status.

[0034] 3) Task execution module, which includes multiple sub-task execution modules. The sub-task execution modules are used to execute the sub-tasks issued by the task parsing module, and when the sub-tasks are completed, they notify the task management module to update the task mask so as to record the completed sub-tasks through the task mask.

[0035] Specifically, the task execution module includes multiple sub-task execution modules, each running independently and responsible for executing its assigned sub-tasks. Upon completion of a sub-task, the corresponding sub-task execution module sends a sub-task completion notification to the task management module, triggering a task mask update operation. The sub-task completion notification may include the execution result of the sub-task.

[0036] It should be noted that each subtask execution module sends its result to the task management module after completing its current subtask. Thus, when a task to be computed is split into subtasks of varying complexity, the subtask execution module can immediately execute the remaining subtasks without waiting for them to complete, thereby improving the utilization of computing resources.

[0037] 4) The task management module is used to output the task execution result when it is determined, based on the task mask, that all subtasks of the task to be calculated have been completed.

[0038] Specifically, since each bit of the task mask corresponds one-to-one with a subtask, the task management module can determine the bits that need to be updated based on the execution results returned by the subtask execution module, and update them to specific values. For example, when the value of a bit is 1, it is used to indicate that the corresponding subtask has been completed.

[0039] In this embodiment, after all the subtasks of the task to be computed have been executed, the task management module can determine whether the task mask meets the preset completion conditions. For example, when all bits of the task mask are 1, it indicates that the task to be computed has been completed. At this time, the execution result of the task to be computed can be obtained through the execution result of the subtasks.

[0040] Regarding the task mask mentioned above, it should also be noted that since the number of bits in the task mask corresponds to the number of subtasks, and the execution status of the subtasks needs to be monitored during the execution of the task to be computed, it is necessary to determine whether the task to be computed has been completed. Therefore, different combinations of values ​​for each bit of the task mask can be used to represent the completed subtasks.

[0041] For example, suppose a task to be computed can be divided into three subtasks. The task parsing module can construct a task mask with a bit width of 3, and use different values ​​to represent the execution status of different subtasks. For example, 0 means not executing and 1 means executing. Then the task mask 001 can indicate that one of the three subtasks has been completed, and the other two subtasks have not yet been completed.

[0042] Based on the above description, it should also be noted that the different modules can perform corresponding operations simultaneously. For example, when the task execution module is executing the subtasks of the previous task to be calculated, the task parsing module can simultaneously perform the division of the remaining tasks to be calculated and the construction of the task mask.

[0043] The task processing apparatus provided in this embodiment adds a task management module after each task execution unit. The task parsing module sends the task mask to the task management module. Thus, after each subtask execution module completes its subtask, it can send the execution result to the task management module for caching. The task management module then monitors whether all subtasks of the task to be calculated have been completed based on the task mask, and outputs the task execution result only when all subtasks have been completed. This avoids subtasks remaining in the subtask execution unit, thereby improving the system's processing efficiency.

[0044] In some embodiments, the task parsing module is further configured to assign a subtask mask to each subtask, and the number of bits in each subtask mask is the same as the number of bits in the task mask. The subtask execution module sends the subtask mask of the corresponding subtask to the task management module after one of the subtasks has been executed. The task management module performs a mask operation on the received subtask mask and the latest task mask to update the task mask.

[0045] Specifically, after dividing the task to be computed into multiple subtasks, the task parsing module can assign a subtask mask to each subtask, with different subtask masks for different subtasks. The number of bits in the subtask mask is the same as the number of bits in the task mask, where the number of bits is the bit width, which is also the number of subtasks divided.

[0046] In this embodiment, after completing one of the subtasks, the subtask execution module sends the corresponding subtask mask to the task management module. The task management module performs mask operations with the latest task mask and subtask mask each time to update the task mask, and determines whether all subtasks of the task to be calculated have been completed based on the updated task mask. The mask operations may include, but are not limited to, bitwise AND, bitwise OR, XNOR, and XOR operations.

[0047] In the above embodiments, by assigning subtask masks to subtasks, the task management module can update the task mask simply by performing mask operations, that is, the mask operations can quickly determine whether all subtasks have been completed.

[0048] In other embodiments, the task parsing module is further configured to assign a subtask mask to each subtask, and the number of bits in each subtask mask is the same as the number of bits in the task mask. The subtask execution module transforms the subtask mask of the corresponding subtask after one of the subtasks has been executed, and sends the transformed subtask mask to the task management module. The task management module performs a mask operation between the transformed subtask mask and the latest task mask to update the task mask.

[0049] Specifically, after completing one of the subtasks, the subtask execution module can transform the subtask mask before sending it to the task management module. This transformation of the subtask mask can be a bitwise inversion.

[0050] For example, if the task mask is "0000", the subtask mask before execution is "0011". After execution, the subtask mask is inverted bit by bit, resulting in "1100". The transformed subtask mask "1100" is sent to the task management unit, and then a mask operation, such as a bitwise OR operation, is performed with the latest task mask in the task management unit to update the task mask. The updated task mask is then "1100".

[0051] In the above embodiments, by transforming the subtask mask, the transformation of the subtask mask is triggered after the task is completed, and the mask operation is performed based on the transformed subtask mask. In this way, the task mask is not updated before the subtask has been completed.

[0052] In some embodiments, the task parsing module is specifically used to specify initial values ​​for each bit in the task mask, and to assign values ​​to the bits in each subtask mask based on the initial values ​​of each bit in the task mask.

[0053] Specifically, the task parsing module can specify initial values ​​for each bit in the task mask, and assign values ​​to the bits in each subtask mask based on these initial values.

[0054] For example, suppose a task A to be computed can be divided into four subtasks, a1, a2, a3, and a4. A bit value of 0 in the task mask indicates that the corresponding subtask has not been executed, while a bit value of 1 indicates that the corresponding subtask has been executed. The task management module can update the task mask using an XOR operation.

[0055] Therefore, the task mask constructed by the task parsing module is 0000 (A), which means that none of the four subtasks have been executed; when the task mask is "1111", it indicates that all the subtasks of the task to be calculated have been executed.

[0056] If the subtask execution module does not perform subtask mask transformation, the constructed subtask mask can be: 0111 (a1), 1011 (a2), 1101 (a3), 1110 (a4).

[0057] If the subtask execution module needs to perform subtask mask transformation, and the transformation method is bitwise inversion, then the constructed subtask mask can be: 1000 (a1), 0100 (a2), 0010 (a3), 0001 (a4).

[0058] In some embodiments, the task parsing module is used to specify initial values ​​for each bit in the task mask according to the task information of the task to be calculated. The task information includes indication information indicating whether each subtask needs to be executed. For any bit of the task mask, if the subtask corresponding to the bit needs to be executed, the bit value is the first value; if the subtask corresponding to the bit does not need to be executed, the bit value is the second value.

[0059] Specifically, after the task parsing module divides the task to be calculated into multiple subtasks based on the task information, the task information also includes indication information indicating whether each subtask needs to be executed. The task mask is constructed using the above indication information.

[0060] For example, suppose a task B to be computed can be divided into four subtasks: b1, b2, b3, and b4. A bit value of 0 in the task mask indicates that the corresponding subtask has not been executed, and a bit value of 1 indicates that the corresponding subtask has been executed. If the task information indicates that subtasks b2 and b3 do not need to be executed, then the task mask constructed by the task parsing module is: 0110(B).

[0061] In some embodiments, for one of the subtasks, the task parsing module is used to determine the target position of the bit corresponding to the subtask in the task mask, and in the subtask mask of the subtask, the bit at the target position is taken as the valid bit, and the other bits other than the valid bit are taken as the invalid bit. The values ​​of the valid bit and the invalid bit are different.

[0062] Specifically, for one of the subtasks in the task to be computed, since the task mask and the subtask mask have the same number of bits and the same bit order correspondence, the task parsing module can determine the target position of the bit corresponding to the subtask in the task mask, and in the subtask mask, the bit at that target position is taken as the valid bit, and the remaining bits are set as invalid bits.

[0063] For example, for the task mask "0000", from the low bit to the high bit, they correspond to subtasks 1 to 4 respectively. If the value of the valid bit is defined as 1 and the value of the invalid bit is defined as 0, then the subtask masks for subtasks 1 to 4 are 0001, 0010, 0100, and 1000 respectively.

[0064] In some embodiments, if the subtask execution module sends the unchanged subtask mask to the task management module when updating the task mask, the task parsing module sets the value of the valid bits to a first value and the value of the invalid bits to a second value, and the task management module performs a mask operation between the unchanged subtask mask and the latest task mask.

[0065] For example, suppose a task C to be computed can be divided into four subtasks, namely c1, c2, c3, and c4. The bit status value of the task mask is 0 when the corresponding subtask has not been executed, and the bit status value of the task mask is 1 when the corresponding subtask has been executed.

[0066] Therefore, the task mask constructed by the task parsing module is 0000 (C), which means that none of the four subtasks have been executed; the constructed subtask masks are 0001 (c1), 0010 (c2), 0100 (c3), and 1000 (c4).

[0067] If the subtask execution module does not perform subtask mask transformation, the task management module can update the task mask through an XOR operation. Assuming the task management module receives the subtasks in the following order: c1, c4, c3, c2, the task mask update order is as follows: 1) 0000 XOR 0001 = 0001; 2) 0001 XOR 1000 = 1001; 3) 1001 XOR 0100 = 1101; 4) 1101 XOR 0010 = 1111.

[0068] When the task mask is "1111", it indicates that all subtasks of the task to be computed have been completed.

[0069] In some embodiments, if the subtask execution module sends the transformed subtask mask to the task management module when updating the task mask, the task parsing module sets the value of the valid bits to the second value and the value of the invalid bits to the first value, and the task management module performs a mask operation between the untransformed subtask mask and the latest task mask.

[0070] For example, suppose a task D to be computed can be divided into four subtasks, namely d1, d2, d3, and d4. The bit status value of the task mask is 0 when the corresponding subtask has not been executed, and the bit status value of the task mask is 1 when the corresponding subtask has been executed.

[0071] Therefore, the task mask constructed by the task parsing module is 0000 (D), which means that none of the four subtasks were executed; the constructed subtask masks are 0001 (d1), 0010 (d2), 0100 (d3), and 1000 (d4).

[0072] If the subtask execution module performs subtask mask transformation using bitwise inversion, the transformed subtask masks will be: 1110 (d1), 1101 (d2), 1011 (d3), and 0111 (d4). The task management module can update the task masks using an XOR operation. Assuming the task management module receives the subtasks in the following order: d1, d4, d3, d2, the task mask update order is as follows: 1) 0000 XNOR 1110 = 0001; 2) 0001 XNOR 0111 = 1001; 3) 1001 XNOR 1011 = 1101; 4) 1101 XNOR 1101 = 1111.

[0073] Similarly, when the task mask is "1111", it indicates that all subtasks of the task to be computed have been completed.

[0074] In some embodiments, the task parsing module is used to send the task identifier of the task to be calculated to the task management module and the subtask execution module that executes the subtask. After the subtask execution module finishes executing the subtask, it sends the task identifier to the task management module. The task management module finds the task mask for masked operation based on the task identifier.

[0075] Specifically, the task parsing module sends the task identifier of the task to be calculated to the subtask management module that executes the corresponding subtask. The task identifier is a unique identifier used to identify the task to be calculated, and all subtasks of the same task share the same task identifier.

[0076] In this embodiment, the task parsing module sends the task identifier and the corresponding task mask to the task management module so that the task management module can build a task table based on the task identifier. The task table is used to record the task identifier and the corresponding task mask, and the number of entries in the task table is the same as the number of task identifiers. Each entry in the task table corresponds to the task identifier of a task to be calculated and its current task mask status.

[0077] After the subtask execution module completes the subtask, it sends the corresponding task identifier back to the task management module. The task management module then looks up the corresponding entry in the task table based on the task identifier, obtains the current task mask, and performs a distance calculation in combination with the subtask mask to update the task mask in the entry.

[0078] In the above embodiments, the task management module can uniformly track and manage the execution progress of each subtask by using the task identifier of the task to be calculated, so as to ensure the real-time update and accurate synchronization of the task status.

[0079] In some embodiments, the task management module is further configured to return the task identifier of the task to be calculated to the task parsing module after determining that all subtasks of the task to be calculated have been completed. When the task parsing module receives the task identifier returned by the task management module, it reclaims the corresponding task identifier.

[0080] In this embodiment, for a task to be computed that has been confirmed by the task management module to have all subtasks completed, the task management module obtains a task completion signal based on the execution results of the subtasks and resends the task identifier to the task parsing module. Upon receiving the task identifier, the task parsing module reclaims the system resources associated with that task identifier and reuses the reclaimed identifier when a new task to be computed arrives to improve resource utilization.

[0081] In some embodiments, the multiple subtask execution modules include a first subtask execution module and a second subtask execution module. If the first subtask execution module is used to execute the first subtask of the task to be calculated, and the second subtask execution module is used to execute the second subtask of the task to be calculated, then when the first subtask execution module executes the first subtask, it sends the calculation result of the first subtask to the task management module. And when the second subtask execution module executes the second subtask, if it needs to use the calculation result of the first subtask, it obtains the calculation result of the first subtask from the task management module.

[0082] Specifically, there is a dependency between the first and second subtasks. The second subtask must wait for the first subtask to complete and use its calculation result as input before it can continue execution. The first subtask execution module and the second subtask execution module are used to execute the first and second subtasks respectively.

[0083] In this embodiment, after the first subtask execution module completes the execution of the first subtask, it sends the execution result of the first subtask to the task management module. When the second subtask execution module starts to execute the second subtask, it obtains the execution result of the first subtask through the task management module and uses it as input data to continue executing the second subtask, ensuring the correct handling of inter-task dependencies and the orderly transmission of data.

[0084] In some embodiments, the task execution module has a subtask queue, and the task parsing module is used to divide multiple subtasks of the task to be calculated into at least two groups and write the subtasks of different groups into different subtask queues.

[0085] Specifically, in conjunction with reference Figure 2 , Figure 2 This is a schematic diagram of another task processing device provided in an embodiment of this application, as shown below. Figure 2 As shown, the task execution module of the task processing device also includes a sub-task queue, and each sub-task execution module is connected to an independent sub-task queue.

[0086] In this embodiment, the task parsing module can group dependent subtasks into the same group and write them into the same subtask queue based on their dependencies. This ensures that dependent subtasks are executed sequentially by the same subtask execution module, avoiding data access delays and synchronization issues caused by cross-module dependencies. Simultaneously, the task parsing module dynamically allocates queue writing order based on the resource requirements and priorities of the subtasks, improving task scheduling efficiency.

[0087] In some embodiments, the task parsing module is further configured to write at least two groups of subtasks into at least two task queues with the fewest number of tasks, based on the number of tasks in each task queue.

[0088] Specifically, the task parsing module can dynamically adjust the task writing strategy for each sub-task queue based on the number of tasks currently pending in each sub-task queue, prioritizing the writing of newly divided sub-task groups to sub-task queues with lower loads, in order to achieve load balancing among execution modules.

[0089] In some embodiments, if one of the subtasks fails to execute, the task management module is also used to check if there is a failed subtask. If there is, the subtask identifier of the corresponding subtask is sent to the task parsing module, which is used to rewrite the failed subtask into one of the subtask queues.

[0090] Specifically, when a subtask execution failure is detected, the task management module records the subtask identifier and notifies the task parsing module. The task parsing module can then rewrite the subtask into a subtask queue based on the subtask identifier and mark it as needing to be re-executed.

[0091] It should be noted that if a re-executed subtask depends on a preceding subtask, the task parsing module will first verify the execution status of the preceding subtask to ensure that its result is valid and unchanged, and then rewrite the subtask into the queue to avoid calculation errors caused by changes in the preceding data.

[0092] It should also be noted that the task management module can monitor the number of retry attempts for subtasks. If the number of failures of the same subtask exceeds a preset threshold, it will be marked as an abnormal task and the return of the subtask identifier will be paused, with the abnormality being output as the task execution result.

[0093] In summary, in the technical solutions of some embodiments of this application, by adding a task management module after each task execution unit, and having the task parsing module send the task mask to the task management module, each subtask execution module can send the execution result of the subtask to the task management module for caching after completing its subtask. The task management module then monitors whether all subtasks of the task to be calculated have been completed based on the task mask, and outputs the task execution result only when all subtasks of the task to be calculated have been completed. This avoids subtasks remaining in the subtask execution unit, thereby improving the system's processing efficiency.

[0094] See also Figure 3 , Figure 3 This is a schematic diagram of the modules of the computing device 300 provided in an embodiment of this application. Figure 3 In this embodiment, the computing device 300 includes a task processing device 31. The task processing device 31 can be any of the task processing devices described above.

[0095] The foregoing has provided a detailed description of the task processing apparatus and computing device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A task processing device, characterized in that, The device includes a task receiving module, a task parsing module, a task execution module, and a task management module, wherein: The task receiving module is used to receive task information of the task to be calculated. The task parsing module is used to divide the task to be calculated into multiple subtasks, construct a task mask based on the number of subtasks, and send the task mask to the task management module. The task mask includes multiple bits, and each bit corresponds to a subtask. The task execution module includes multiple sub-task execution modules. The sub-task execution modules are used to execute the sub-tasks issued by the task parsing module, and when the sub-tasks are completed, they notify the task management module to update the task mask so as to record the completed sub-tasks through the task mask. The task management module is used to output the task execution result when, based on the task mask, all multiple subtasks of the task to be calculated have been completed.

2. The apparatus according to claim 1, characterized in that, The task parsing module is also used to assign a subtask mask to each subtask, and the number of bits in each subtask mask is the same as the number of bits in the task mask. The subtask execution module is used to send the subtask mask of the corresponding subtask to the task management module after one of the subtasks has been executed. The task management module is used to perform a mask operation on the received subtask mask and the latest task mask to update the task mask.

3. The apparatus according to claim 1, characterized in that, The task parsing module is also used to assign a subtask mask to each subtask, and the number of bits in each subtask mask is the same as the number of bits in the task mask. The subtask execution module is used to transform the subtask mask of the corresponding subtask after one of the subtasks is executed, and send the transformed subtask mask to the task management module. The task management module is used to perform a mask operation between the transformed subtask mask and the latest task mask to update the task mask.

4. The apparatus according to claim 2 or 3, characterized in that, The task parsing module is specifically used to specify initial values ​​for each bit in the task mask, and to assign values ​​to the bits in each subtask mask based on the initial values ​​of each bit in the task mask.

5. The apparatus according to claim 4, characterized in that, The task parsing module is used to assign initial values ​​to each bit in the task mask according to the task information of the task to be calculated. The task information includes indication information indicating whether each subtask needs to be executed. For any bit of the task mask, if the subtask corresponding to the bit needs to be executed, the value of the bit is a first value; if the subtask corresponding to the bit does not need to be executed, the value of the bit is a second value.

6. The apparatus according to claim 5, characterized in that, For one of the subtasks, the task parsing module is used to determine the target position of the bit corresponding to the subtask in the task mask, and in the subtask mask of the subtask, the bit at the target position is taken as the valid bit, and the other bits besides the valid bit are taken as invalid bits, wherein the value of the valid bit and the value of the invalid bit are different.

7. The apparatus according to claim 6, characterized in that, If, during the update of the task mask, the subtask execution module sends the unchanged subtask mask to the task management module, then the task parsing module sets the value of the valid bits to the first value and the value of the invalid bits to the second value, and the task management module performs a mask operation between the unchanged subtask mask and the latest task mask.

8. The apparatus according to claim 6, characterized in that, If, during the update of the task mask, the subtask execution module sends the transformed subtask mask to the task management module, then the task parsing module sets the value of the valid bits to the second value and sets the value of the invalid bits to the first value, and the task management module performs a mask operation between the untransformed subtask mask and the latest task mask.

9. The apparatus according to claim 2 or 3, characterized in that, The task parsing module is used to send the task identifier of the task to be calculated to the task management module and the subtask execution module that executes the subtask. After the subtask execution module finishes executing the subtask, it sends the task identifier to the task management module. The task management module uses the task identifier to find the task mask for masked operation.

10. The apparatus according to claim 9, characterized in that, When the task management module determines that all subtasks of the task to be calculated have been completed, it is also used to return the task identifier of the task to be calculated to the task parsing module. When the task parsing module receives the task identifier returned by the task management module, it reclaims the corresponding task identifier.

11. The apparatus according to claim 2 or 3, characterized in that, The plurality of subtask execution modules include a first subtask execution module and a second subtask execution module. If the first subtask execution module is used to execute the first subtask of the task to be calculated, and the second subtask execution module is used to execute the second subtask of the task to be calculated, then when the first subtask execution module executes the first subtask, it sends the calculation result of the first subtask to the task management module. And when the second subtask execution module executes the second subtask, if it needs to use the calculation result of the first subtask, it obtains the calculation result of the first subtask from the task management module.

12. The apparatus according to claim 2 or 3, characterized in that, The task execution module has a subtask queue, and the task parsing module is used to divide the multiple subtasks of the task to be calculated into at least two groups, and write the subtasks of different groups into different subtask queues.

13. The apparatus according to claim 12, characterized in that, The task parsing module is also used to write the subtasks of the at least two groups into the at least two subtask queues with the fewest number of tasks, based on the number of tasks in each of the subtask queues.

14. The apparatus according to claim 12, characterized in that, If one of the subtasks fails to execute, the task management module is also used to check if there is a failed subtask. If so, the subtask identifier of the corresponding subtask is sent to the task parsing module, which is used to rewrite the failed subtask into one of the subtask queues.

15. A computing device, characterized in that, The computing device is used to run the task processing device as described in any one of claims 1 to 14.

Images