Data risk elimination method and system, computer equipment and storage medium

Abstract

The embodiment of the invention provides a data risk removing method and system, computer equipment and a storage medium, and the method comprises the steps: intercepting instruction emission in an execution domain where a risk monitoring unit is located in real time through the risk monitoring unit, and detecting a risk during instruction execution based on a dependency table; when an adventure is detected, writing a conflict event corresponding to the adventure into an event queue; reading the conflict event from the event queue by using an event scheduler, sending a removal request to an execution domain related to the conflict event or an external accelerator, and marking a corresponding dependency item as removed in a dependency table; and when the execution domain or the external accelerator receives the release request, determining a thread or a thread bundle corresponding to the conflict event, waking up and rescheduling the thread or the thread bundle, and performing risk release on the conflict event, supporting accurate wakeup according to a dependency identifier, only suspending the thread or the thread bundle corresponding to a conflict instruction, and releasing the risk of the conflict event. Other instructions continue to be executed, and local unlocking and high-precision synchronization are achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of heterogeneous computing architecture, in particular, to a data hazard resolution method and system, a computer device and a storage medium. BACKGROUND

[0002] In a heterogeneous computing architecture, in a system-on-a-chip supporting AI training and inference, a common architecture includes a central processing unit (CPU), a graphics processing unit (GPU) (very long instruction word (VLIW) / single instruction multiple thread (SIMT) hybrid domain), a tensor processing unit (TPU), and other accelerators. Asynchronous kernel scheduling and data exchange between different domains are prone to read-after-write (RAW), write-after-write (WAW), and other data hazards, resulting in pipeline conflicts and performance degradation.

[0003] In related technologies, an event-driven resolution mechanism is usually used to break the data dependency between instructions through asynchronous processing, such as using CUDA (Compute Unified Device Architecture) events, semaphores, or global barriers to synchronize inter-domain dependencies, or polling for event completion at the software level, which has the disadvantages of high latency and large resource occupation.

[0004] Software events often have high latency due to polling queries or interrupt overhead; and a tightly coupled barrier approach blocks the entire domain, wasting pipeline cycles. SUMMARY

[0005] The present application provides a data hazard resolution method, system, computer device, and storage medium.

[0006] In a first aspect, the present application provides a data hazard resolution method applied to a heterogeneous computing system, the heterogeneous computing system including a plurality of cores and an event scheduler, each core internally integrating at least two execution domains, each execution domain being provided with a corresponding hazard monitoring unit, and the method comprising: intercepting, by each hazard monitoring unit, instruction emission in the execution domain in which it is located in real time, and detecting read-after-write hazards, write-after-write hazards, and write-after-read hazards during instruction execution based on a dependency table; in the case of detecting a hazard, writing a conflict event corresponding to the current hazard into an event queue, wherein the conflict event includes a conflict type and a dependency identifier; reading, by the event scheduler, the conflict event from the event queue, and sending a resolution request to an execution domain or an external accelerator related to the conflict event, and marking the corresponding dependency in the dependency table as resolved; In the case that the execution domain or the external accelerator receives the release request, the corresponding thread or thread bundle is determined according to the conflict type and the dependency identifier in the conflict event, the thread or thread bundle is woken up and rescheduled, and the conflict event is released.

[0007] In an optional embodiment of the present application, the real-time interception of the instruction emission in the execution domain by each of the conflict monitoring units and the detection of the read-after-write conflict, the write-after-write conflict and the write-after-read conflict during the instruction execution based on the dependency table comprise: The real-time interception of the instruction emission in the execution domain by each of the conflict monitoring units, for each of the intercepted instructions, the target address corresponding to the execution of the current target instruction is acquired; The last instruction related to the target address is detected based on the dependency table; In the case that the target instruction is a read instruction, the last instruction is a write instruction and the state of the last instruction is conflict, if the current target instruction is executed, it is determined that the current situation is read-after-write conflict; In the case that the target instruction is a write instruction, the last instruction is a write instruction and the state of the last instruction is conflict, if the current target instruction is executed, it is determined that the current situation is write-after-write conflict; In the case that the target instruction is a write instruction, the last instruction is a read instruction and the state of the last instruction is conflict, if the current target instruction is executed, it is determined that the current situation is write-after-read conflict.

[0008] In an optional embodiment of the present application, the dependency table is constructed by the following steps: The unique dependency identifier is allocated for the asynchronous kernel between different execution domains, the source operand and the destination operand are associated with the dependency identifier when the instruction is emitted in each of the execution domains, the entry of the dependency table is generated, and the dependency table is composed of at least one entry of the dependency table, wherein the source operand comprises the dependency identifier, the target address, the instruction content, the execution domain to which the instruction belongs, and the destination operand comprises the instruction state.

[0009] In an optional embodiment of the present application, the reading of the conflict event from the event queue by the event scheduler and the sending of the release request to the execution domain or the external accelerator related to the conflict event comprise: The conflict event is read by the event scheduler, and the execution domain or the external accelerator related to the conflict event is acquired; The release request is sent to the execution domain or the external accelerator related to the conflict event through the sideband message or the write signal mode.

[0010] In an optional embodiment of the present application, in the case that the detected conflict is read-after-write conflict, the release of the conflict event comprises: The current write instruction is executed, and the previous read instruction is notified to read the updated data after the current write instruction is completed.

[0011] In an optional embodiment of the present application, in the case where the detected hazard is a write-after-write hazard, the conflict event is resolved by: Before the current write instruction is executed, the dependency table is queried, and in the case where the previous write instruction is determined to be not completed according to the query result, the current write instruction is registered in the dependency table, the state of the current write instruction is set as conflict, an entry corresponding to the current write instruction is generated, and the entry is suspended. After the previous write instruction is completed, the dependency table is queried, the state of the current write instruction in the suspended entry is modified as conflict resolution, and the current write instruction is re-issued.

[0012] In an optional embodiment of the present application, in the case where the detected hazard is a write-after-read hazard, the conflict event is resolved by: Before the current read instruction is executed, the dependency table is queried, and in the case where the previous write instruction is determined to be not completed according to the query result, the current read instruction is registered in the dependency table, the state of the current read instruction is set as conflict, an entry corresponding to the current read instruction is generated, and the entry is suspended. After the previous read instruction is completed, the dependency table is queried, the state of the current read instruction in the suspended entry is modified as conflict resolution, and the current read instruction is re-issued.

[0013] A second aspect of the embodiments of the present application provides a heterogeneous computing system, comprising a plurality of cores and an event scheduler, each core internally integrating at least two execution domains, and each execution domain being provided with a corresponding hazard monitoring unit, wherein Each hazard monitoring unit is configured to intercept the instruction emission in the execution domain in which the hazard monitoring unit is located in real time, detect read-after-write hazard, write-after-write hazard and write-after-read hazard during instruction execution based on the dependency table, and in the case where a hazard is detected, write a conflict event corresponding to the current hazard into an event queue, wherein the conflict event comprises a conflict type and a dependency identifier. The event scheduler is configured to read the conflict event from the event queue, send a resolution request to an execution domain or an external accelerator related to the conflict event, and mark the corresponding dependency in the dependency table as resolved; in the case where the execution domain or the external accelerator receives the resolution request, determine a corresponding thread or thread bundle according to the conflict type and the dependency identifier in the conflict event, wake up and reschedule the thread or the thread bundle, and resolve the conflict event.

[0014] In a third aspect, the embodiment of the present application provides a computer device, comprising a memory and a processor, the memory stores a computer program, and the processor implements the steps of the data hazard resolution method according to any one of the above when executing the computer program.

[0015] In a fourth aspect, the embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the data hazard resolution method according to any one of the above.

[0016] The above technical solution provided by the embodiment of the present application has at least some or all of the following advantages compared with the prior art. The data hazard resolution method provided by the embodiment of the present application has at least some or all of the following advantages compared with the prior art. BRIEF DESCRIPTION OF DRAWINGS

[0017] The accompanying drawings, which are incorporated herein and constitute a part of the specification, illustrate the embodiments of the present application and serve to explain the present application, and are used to provide a further understanding of the present application, and shall not be construed as an improper limitation of the present application. In the drawings: Figure 1 The flowchart of the data hazard resolution method provided by an embodiment of the present application is shown in FIG. 2; Figure 2 The flowchart of detecting the hazard during the execution of the instruction provided by an embodiment of the present application is shown in FIG. 3; Figure 3 The schematic diagram of the heterogeneous computing system structure provided by an embodiment of the present application is shown in FIG. 4; Figure 4 The schematic diagram of the computer device structure provided by an embodiment of the present application is shown in FIG. 5. DETAILED DESCRIPTION

[0018] In the process of implementing the present application, the inventors find that the current data hazard resolution method has high delay and large resource occupation.

[0019] To address the aforementioned issues, this application provides a data hazard resolution method, system, computer device, and storage medium to resolve the problems of high latency and high resource consumption.

[0020] The solutions in this application embodiment can be implemented using various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.

[0021] To make the technical solutions and advantages of the embodiments of this application clearer, the exemplary embodiments of this application will be described in further detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not an exhaustive list of all embodiments. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0022] Please see Figure 1 The data hazard removal method provided in this application is applied to a heterogeneous computing system. This heterogeneous computing system includes multiple cores and an event scheduler. Each core integrates at least two execution domains, and each execution domain is equipped with a corresponding hazard monitoring unit. The method includes the following steps S100~S400: S100 uses each hazard monitoring unit to intercept instruction issuance in its execution domain in real time, and detects read-after-write hazard, write-after-write hazard, and write-after-read hazard during instruction execution based on the dependency table; S200, if an hazard is detected, write the conflict event corresponding to the current hazard into the event queue, wherein the conflict event includes the conflict type and dependency identifier; S300, the event scheduler reads conflict events from the event queue, sends a release request to the execution domain or external accelerator related to the conflict event, and marks the corresponding dependency as released in the dependency table; S400, when the execution domain or external accelerator receives the resolution request, the corresponding thread or thread bundle is determined according to the conflict type and dependency identifier in the conflict event, the thread or thread bundle is woken up and rescheduled, and the conflict event is resolved.

[0023] In an optional embodiment of this application, step S200 further includes: If no hazard is detected, in the thread corresponding to the current hazard, for multiple memory banks in the target system where the thread resides, obtain the memory occupancy and memory capacity of each memory bank; The total utilization rate and utilization range of all memory banks are determined based on the memory bank occupancy and memory bank capacity of each memory bank. Memory pressure metrics are determined based on the total utilization and utilization range of all memory modules. Compare memory pressure metrics with preset threshold metrics, and determine the appropriate task types for scheduling the target system based on the comparison results.

[0024] In an optional embodiment of this application, determining the total occupancy rate and occupancy range of all memory banks based on the memory bank occupancy and memory bank capacity of each memory bank includes: The total utilization rate of all storage units is determined based on the storage unit occupancy and storage capacity of each storage unit, as well as the total number of all storage units. The occupancy range of all memory banks is determined based on the occupancy of each memory bank.

[0025] In an optional embodiment of this application, the total utilization rate of all memory banks is determined by the following expression, based on the memory bank occupancy and capacity of each memory bank and the total number of memory banks:

[0026] in, The total utilization rate of all memory units. The storage space occupied by the i-th storage unit. The number of all storage units, The storage capacity of each memory bank.

[0027] In an optional embodiment of this application, the occupancy range of all memory banks is determined based on the memory bank occupancy of each memory bank using the following expression:

[0028] in, The occupancy of all memory banks is extremely poor. This is the largest storage volume among all storage volumes. It represents the smallest storage volume among all storage volumes.

[0029] In an optional embodiment of this application, the memory pressure index is determined based on the total occupancy and occupancy range of all memory banks using the following expression:

[0030] in, The total utilization rate of all memory units. The occupancy of all memory banks is extremely poor. The storage capacity of each memory bank. and All are preset values.

[0031] In an optional embodiment of this application, the step of comparing memory pressure indicators with preset indicator thresholds and determining the task types suitable for scheduling by the target system based on the comparison results includes: The memory pressure index is compared with the first preset index threshold and the second preset index threshold respectively; If the memory pressure index exceeds the first preset threshold, the task type to be scheduled is determined to be a memory-constrained task. If the memory pressure index is less than the second preset index threshold, the task type to be scheduled is determined to be a computationally restricted task. When the memory pressure index is less than or equal to the first preset index threshold and greater than or equal to the second preset index threshold, the total occupancy rate and occupancy range of all storage units used to determine the current memory pressure index are compared with the preset occupancy rate threshold and the preset occupancy range threshold, respectively. If the total utilization rate of all storage units under the current memory pressure index is greater than the preset utilization rate threshold and the utilization range of all storage units under the current memory pressure index is less than or equal to the preset utilization range threshold, increase the number of task cores or increase scheduling for computationally constrained tasks. If the total utilization rate of all storage units under the current memory pressure metric is less than or equal to the preset utilization rate threshold and the utilization range of all storage units under the current memory pressure metric is greater than the preset utilization range threshold, schedule the memory-constrained task with the highest memory consumption.

[0032] In an optional embodiment of this application, after determining the task type suitable for scheduling by the target system based on the comparison results, the method further includes: The target system selects the task type that is suitable for scheduling as the target task type. The target task is selected according to the priority and waiting time of each task in the preset ready queue corresponding to the target task type. The preset ready queue consists of multiple tasks, and the status of the multiple tasks is ready. The target task is scheduled and executed. If the target task fails to execute, the target task is set to a suspended state, removed from the ready queue and moved to the suspended queue, and the target task is monitored in real time to see if the preset rescheduling conditions are met. If the target task meets the preset rescheduling conditions, the target task's status is set to ready, the target task is removed from the suspended queue and moved into the ready queue, and the target task is rescheduled and executed until the target task is successfully executed.

[0033] In an optional embodiment of this application, the preset rescheduling condition is a cooldown period or a preset number of retries, and the real-time monitoring of whether the target task meets the rescheduling condition includes: Record the timestamp of the target task failing. With the preset rescheduling condition being a cooldown period, the timer starts from the timestamp of the target task's execution failure. If the timer reaches the cooldown period, the target task is determined to meet the rescheduling condition. If the preset rescheduling condition is the number of retries, the number of retries for the target task is accumulated starting from the timestamp of the target task's execution failure. If the accumulated number of retries reaches the preset number of retries, the target task is determined to meet the rescheduling condition.

[0034] In an optional embodiment of this application, the step of selecting a target task based on the priority and waiting time of each task in a preset ready queue includes: Following the order of scheduling from front to back, all tasks are sorted according to the priority and waiting time of each task in the preset ready queue to obtain the sorted queue. The task at the front of the sorted queue is taken as the target task.

[0035] In an optional embodiment of this application, the step of sorting all tasks according to the priority and waiting time of each task in the preset ready queue to obtain a sorted queue includes: The following expression determines the queue sorting value based on the priority and waiting time of each task in the preset ready queue:

[0036] Where O is the queue sorting value of the current task, P is the priority of the current task, T is the waiting time of the current task, and α and β are the weights of priority and waiting time, respectively, both of which are positive numbers. Sort all tasks in the preset ready queue according to the queue sorting value to obtain the sorted queue.

[0037] In an optional embodiment of this application, the method further includes: For the first task that fails to execute, obtain the initial priority of the first task. During the process of removing the first task from the suspended queue and moving it into the ready queue, reduce the initial priority of the first task. Use the reduced priority as the priority of the first task after it is moved into the ready queue. For the second task in the ready queue, obtain the initial priority of the second task. If the waiting time of the second task exceeds the preset time threshold, increase the initial priority of the second task and use the increased priority as the updated priority of the second task.

[0038] In an optional embodiment of this application, the priority of each task in the preset ready queue is determined according to the system state used for scheduling and executing tasks; The waiting time for each task in the preset ready queue is the time it takes for the task to enter the preset ready queue.

[0039] In an optional embodiment of this application, the system state is determined by the following steps: For multiple storage banks in the target system, the memory pressure index of the target system is determined based on the total occupancy rate and occupancy range of all storage banks. The target task types suitable for scheduling are determined based on the target system's memory pressure indicators and preset indicator thresholds. The task corresponding to the target task type is designated as the highest priority task.

[0040] In an optional embodiment of this application, the computationally constrained task includes URLLC and eMBB services, and the method further includes a method for scheduling URLLC and eMBB service resources, wherein the method for scheduling URLLC and eMBB service resources includes: Upon receiving a URLLC service request, the raw URLLC service data is obtained, and the time-domain and frequency-domain features of the URLLC service are extracted from the raw URLLC service data. The URLLC service is an ultra-reliable low-latency communication service. The time-domain and frequency-domain features of URLLC services are input into a pre-trained time-frequency domain joint prediction model to obtain the time-frequency domain joint prediction results. The prediction confidence level is determined based on the joint prediction results in the time and frequency domains, and the prediction threshold is determined based on the resource utilization and packet loss rate of the URLLC service obtained in real time. The prediction confidence level and prediction threshold are compared, and the resource status is determined based on the comparison results. Based on the resource status, it is determined whether to preempt the resources occupied by the eMBB service. If the resources occupied by the eMBB service are preempted, the eMBB service compensation mechanism is triggered. The eMBB service is an enhanced mobile broadband service.

[0041] In an optional embodiment of this application, the joint time-frequency domain prediction model is trained through the following steps: Obtain the raw data of URLLC services, and extract the time-domain and frequency-domain features of URLLC services from the raw data of URLLC services; The temporal domain characteristics of URLLC services are used as input, and the arrival probability of URLLC services on a specified symbol in a specified time slot is used as output to train a temporal prediction model. Based on the frequency domain characteristics of URLLC services, frequency domain hotspots are identified, and a physical resource block association graph of the frequency domain hotspots is constructed. The physical resource block association features in the physical resource block association graph are used as input, and the usage probability of a specified physical resource block of a specified symbol in a specified time slot of the URLLC service is used as output to train the frequency domain prediction model.

[0042] In an optional embodiment of this application, the time-domain and frequency-domain features of the URLLC service are input into a pre-trained time-frequency domain joint prediction model to obtain the time-frequency domain joint prediction result: Input the temporal features of the URLLC service into a pre-trained temporal prediction model to obtain the arrival probability of the URLLC service on a specified symbol in a specified time slot; Input the frequency domain features of URLLC service into a pre-trained frequency domain prediction model to obtain the usage probability of URLLC service in a specified physical resource block of a specified symbol in a specified time slot. The time-frequency domain joint prediction result is determined based on the arrival probability of URLLC services on a specified symbol in a specified time slot and the usage probability of URLLC services on a specified physical resource block in a specified symbol in a specified time slot.

[0043] In an optional embodiment of this application, the prediction confidence is determined based on the joint time-frequency domain prediction results using the following expression:

[0044] in, To predict confidence levels, The result is a joint prediction in the time and frequency domains. This is a resource utility function.

[0045] In an optional embodiment of this application, the prediction threshold is determined based on the resource utilization and packet loss rate of the URLLC service obtained in real time using the following expression:

[0046]

[0047]

[0048]

[0049] in, This is the upper limit of the predicted threshold after the update. The upper limit of the predicted threshold before the update. The target resource utilization rate for URLLC services. This represents the current resource utilization rate for URLLC services. The target packet loss rate for URLLC services, The current packet loss rate for URLLC service. This is the lower limit of the predicted threshold before the update. This is the lower limit of the predicted threshold after the update. All of these are hyperparameters. This represents the total number of URLLC services. The total number of delays and rejections for URLLC services. The number of material resource blocks. For the number of time slots, This represents an idle state where resources are not allocated. It is a time-frequency domain resource unit.

[0050] In an optional embodiment of this application, the step of comparing the prediction confidence and the prediction threshold, and determining the resource status based on the comparison result, includes: If the prediction confidence is greater than the upper limit of the prediction threshold, the resource is set as a dedicated time-frequency domain resource unit; If the prediction confidence is greater than the lower limit of the prediction threshold and less than or equal to the upper limit of the prediction threshold, the resource is set as a shared time-frequency domain resource unit. If the prediction confidence is less than or equal to the lower limit of the prediction threshold, the resource status is set to idle.

[0051] In an optional embodiment of this application, the step of determining whether to preempt the resources occupied by the eMBB service according to the resource status, and triggering the eMBB service compensation mechanism in the event of preemption of the eMBB service resources, includes: In the presence of a dedicated time-frequency domain resource unit, a dedicated time-frequency domain resource unit shall be allocated for URLLC service requests; In the absence of a dedicated time-frequency domain resource unit, but in the presence of a shared time-frequency domain resource unit that is not occupied by eMBB services, a shared time-frequency domain resource unit shall be allocated for URLLC service requests. In the absence of a dedicated time-frequency domain resource unit, but the existence of a shared time-frequency domain resource unit that is occupied by an eMBB service, the URLLC service request will preempt the shared time-frequency domain resource unit and trigger the eMBB service compensation mechanism. If neither a dedicated time-frequency domain resource unit nor a shared time-frequency domain resource unit exists, an adjacent resource is allocated for the URLLC service request. If the allocation fails, the URLLC service request is rejected.

[0052] In an optional embodiment of this application, the first preset threshold is the memory pressure index when the total occupancy rate and occupancy range of all memory banks are at their maximum values. The second preset threshold is the memory pressure indicator when the total occupancy rate and occupancy range of all storage units are at their minimum values.

[0053] In an optional embodiment of this application, the core may be a chip die.

[0054] In an optional embodiment of this application, the execution domain includes, but is not limited to, a Very Long Instruction Word (VLIW) domain and a Single Instruction Multithreaded (SIMT) domain. Hazard monitoring units are arranged within both the VLIW and SIMT domains to monitor read / write conflicts to on-chip registers or off-chip memory during instruction execution in real time.

[0055] In an optional embodiment of this application, each core integrates a VLIW domain and a SIMT domain. The static VLIW domain (Domain-V) is for deterministic tasks and supports multiple VLIW instruction issuances. The dynamic SIMT domain (Domain-S) is for branch-intensive or massively parallel tasks and supports thread-beam-level SIMT scheduling. The cores are interconnected via a D2DLink direct device link and connected to the CPU and other accelerators (Tension Processing Units, Application-Specific Integrated Circuits, and Integrated Circuits, or ASICs) via a PCIe high-speed bus for peripheral components. The Domain-V hazard monitoring unit is implemented using: dependency table lookup based on CAM (Content Addressable Memory); interception logic integrated with the VLIW issuance pipeline; and an event generation register and an event queue FIFO write interface. The Domain-S hazard monitoring unit, in addition to having the same design as the Domain-V hazard monitoring unit, is coupled with the SIMT thread-beam scheduler: it supports batch detection of thread-beam-level addresses; and each thread-beam entry has a pending flag. The event scheduler is based on the programmable direct memory access engine (DMA Engine): the event queue FIFO depth and wake-up unit are configurable; and it supports message encapsulation and decapsulation mechanisms across NVIDIA high-speed interconnect buses NVLink / PCIe.

[0056] In an optional embodiment of this application, an example flow of the data hazard resolution method of this application is as follows: VLIW domain transmit command. Write to register R; detect conflicting read dependencies on R in the SIMT field → generate → Wake up the SIMT domain thread bundle ; After continuing execution, a new value for R is read, triggering a dependency table update → Event handling. Done.

[0057] In an optional embodiment of this application, a dependency table, an hazard monitoring unit, and an event generation unit are deployed simultaneously in Domain-V and Domain-S, respectively. Dependency Table: The entry format can be <Dependency ID, Source Address SrcAddr, Target Address DestAddr, Status>, used to track the read and write addresses and dependency status of each instruction.

[0058] Adventure monitoring unit: intercepts command issuance, queries dependency tables to detect potential read-after-write (RAW), write-after-write (WAW), and write-after-read (WAR) adventures; Event Generation Unit: When encountering an adventurous event, write the Conflict event <Dependency ID, Conflict Type> to the Event FIFO queue and mark the instruction status as "suspended".

[0059] In one optional embodiment of this application, the event-driven deactivation mechanism is performed through the following steps: First, hazard detection: Instruction I is executed in Domain-V, writing to the target register R, SharedMemory, or Global Memory; if there are pending read instructions (from Domain-S or external kernel) for R, SharedMemory, or Global Memory that have not yet been completed in the Dependency Table, a RAW hazard is detected.

[0060] Second, event generation: When Domain-V completes a write operation on a thread bundle data block, the hazard monitoring unit writes an event with thread bundle data granularity, <DependencyID,RAW>, to the event queue Event FIFO.

[0061] Third, asynchronous notification: The event scheduler reads the event from the event queue FIFO and sends the release request to the SIMT domain thread bundle scheduler involving the DependencyID via the message bus (with signal on the D2DLink / PCIe side); the corresponding thread in the thread bundle is partially awakened and continues execution.

[0062] Fourth, partial recovery: only the entries corresponding to the conflicting instructions are recovered to avoid global barriers; and the entry status in the DependencyTable is set to "conflict resolved".

[0063] The data hazard removal method of this application can integrate a hybrid architecture such as static VLIW domain and dynamic SIMT domain within a single computing core; outside the core, it can coordinate with the CPU and other accelerators to perform tasks through high-speed interconnects (such as NVLink) and PCIe links, supporting unified dependency management between the core and outside, different execution domains and different accelerators, improving the overall system throughput, and can simultaneously achieve partial unlocking, hardware-level events and heterogeneous cross-domains.

[0064] In an optional embodiment of this application, see [link to relevant documentation]. Figure 2In step S100, the step of using each hazard monitoring unit to intercept instruction emissions in its execution domain in real time, and detecting read-after-write hazard, write-after-write hazard, and write-after-read hazard during instruction execution based on the dependency table, includes: S210 utilizes each adventure monitoring unit to intercept instruction emissions in its execution domain in real time. For each intercepted instruction, it obtains the target address corresponding to the current target instruction execution. S220, Detect the previous instruction related to the target address based on the dependency table; S230, if the target instruction is a read instruction, the previous instruction is a write instruction, and the state of the previous instruction is conflicting, if the current target instruction is executed, the current situation is determined to be a read-after-write hazard; S240, if the target instruction is a write instruction, the previous instruction is a write instruction, and the state of the previous instruction is conflicting, if the current target instruction is executed, the current situation is determined to be a write-after-write hazard; S250: If the target instruction is a write instruction, the previous instruction is a read instruction, and the state of the previous instruction is conflicting, then if the current target instruction is executed, the current situation is determined to be a write-after-read hazard.

[0065] The data hazard resolution method in this application introduces a hazard monitoring unit to detect read / write conflicts between the VLIW / SIMT domain and external accelerators in real time. It tracks dependencies at the kernel level through an event queue-driven approach. Once a hazard risk is detected, a specific event is triggered to notify the relevant execution domain to delay or reschedule, thereby resolving data hazards safely and efficiently. Compared with traditional global barriers or polling event waiting, this method reduces synchronization overhead and improves pipeline utilization and system throughput.

[0066] In an optional embodiment of this application, in step S100, the dependency table is constructed through the following steps: A unique dependency identifier is assigned to the asynchronous kernels between different execution domains. When an instruction is issued in each execution domain, the source operand and the destination operand are associated with the dependency identifier to generate entries in the dependency table. The dependency table is composed of at least one entry in the dependency table. The source operand includes the dependency identifier, the target address, the instruction content, and the execution domain to which the instruction belongs. The destination operand includes the instruction status, which includes Pending, Complete, and Resolved.

[0067] In an optional embodiment of this application, each entry includes the following: Unique ID (DepID): Assign a unique ID to each registered piece of information to facilitate searching and updating; Target address (Addr): This record corresponds to which memory address or register address, such as A, B, or C.

[0068] Status: Pending: A conflict occurred with the instruction. Complete: The instruction has been executed successfully. Resolved: The conflict has been resolved, and subsequent execution can proceed normally or has already completed.

[0069] Instruction content: For example, the read instruction load or the write instruction store.

[0070] Execution Domain: Indicates which execution domain this instruction comes from, such as the SIMT domain (GPU Thread Bundle) or VLIW domain, etc.

[0071] The data hazard removal method in this application retrieves the corresponding thread or thread bundle based on the dependency identifier by querying the record content of each entry in the dependency table, thereby removing the hazard. It eliminates the need for software polling or high-overhead interrupts. The Event FIFO and message bus achieve sub-periodic notification latency, which reduces synchronization overhead and improves pipeline utilization and system throughput compared to traditional global barriers or polling-style event waiting.

[0072] In an optional embodiment of this application, step S300, which involves using an event scheduler to read conflicting events from an event queue and sending a resolution request to the execution domain or external accelerator associated with the conflicting event, includes: Use the event scheduler to read conflict events and obtain the execution domain or external accelerator associated with the conflict events; The resolution request is sent to the execution domain or external accelerator associated with the conflict event via side-band messaging or write signaling.

[0073] The data hazard removal method in this application effectively solves the problem of cross-domain and cross-core instruction dependencies and data hazards in heterogeneous systems by combining hardware-level data hazard monitoring with an event-driven local unlocking mechanism. It significantly reduces synchronization latency and system overhead, and improves pipeline and multi-accelerator collaborative execution efficiency.

[0074] In an optional embodiment of this application, in step S400, if the detected hazard is a read-after-write hazard, the hazard resolution for the conflict event includes: Execute the current write instruction. Once the current write instruction is complete, notify the previous read instruction to read the updated data.

[0075] In an optional embodiment of this application, the hazard resolution mechanism employs the following strategy in the following scenario: Scenario: A read instruction arrives first, followed by a write instruction that also needs to access the same address A. Strategy: The write end does not wait, executes directly, and notifies the earlier read instruction that it can obtain the updated data after the write is complete. The specific process is as follows: First, read the instruction. The SIMT domain issued a read instruction load [A], which queries the dependency table: DepID=100: Address = A, Status = Complete Instruction = Store [A], domain = VLIW If not found, record: DepID=100: Address = A, Status = Pending Command = Load [A], Domain = SIMT Second, write instructions arrive and are executed directly. Subsequently, the VLIW domain issued a write command: store [A]←X.

[0076] Regardless of whether there are any records to read in the dependency table, this write operation is issued and executed directly without waiting in the issuance phase.

[0077] Third, after writing, send an event to release the read dependency. When the write operation is complete and the storage system is back in operation, the VLIW domain retrieves a record from the dependency table: DepID=100: Address = A, Status = Pending Command = Load [A], Domain = SIMT If found, change the status to Resolved.

[0078] If not found, write this record.

[0079] DepID=100: Address = A, Status = Complete Instruction = Store [A], domain = VLIW Note that you need to resolve the conflict of entering DepID=100 in the same table field.

[0080] In this way, if the earliest read instruction has not yet received the data, it will be re-executed after receiving the Resolved command to obtain the correct new value.

[0081] The data hazard resolution method in this application, when encountering a read-after-write hazard where the previous read instruction has not been completed while the next write instruction has been completed, first writes the previous read instruction to the dependency table, and after the write instruction is completed, queries the dependency table to re-execute only the incomplete read instruction. It supports precise wake-up, suspending only the thread or thread bundle corresponding to the conflicting instruction, while other instructions continue to execute, achieving partial unlocking and high-precision synchronization.

[0082] In an optional embodiment of this application, in step S400, if the detected hazard is a write-after-write hazard, the hazard resolution for the conflict event includes: Before executing the current write instruction, query the dependency table. If the query result determines that the previous write instruction has not been completed, register the current write instruction in the dependency table, set the status of the current write instruction to conflict, generate the entry corresponding to the current write instruction, and suspend the entry. After the previous write command is completed, query the dependency table, change the status of the current write command in the pending entries to conflict resolved, and reissue the current write command.

[0083] In an optional embodiment of this application, in the following scenario (there are two write instructions at address B, and it must be ensured that they are completed in program order), the hazard resolution mechanism consists of the following steps: First, the first write instruction arrives and is executed immediately. The VLIW domain emits store [B]←Y, without querying dependency tables or registering, and directly emits and executes.

[0084] Because there are no prior writes or reads to synchronize with it, it can be completed without blocking.

[0085] Second, the handling of the arrival of the second write instruction. VLIW domain emits store [B]←X, at which point the first write may not yet be completed or may have already been completed: Query dependency tables: If there is no "Complete" record for B in the table, it means that it needs to be queued. Record this new record as Pending and suspend it. DepID=201: Address = B, Status = Pending Command = store [B]←X, domain=VLIW If there is already a DepID=201 Complete entry in the table, you can execute it directly.

[0086] After completing the first step, check and remind yourself to write the second step. Once the first write operation is successfully written back, the hardware query dependency table is executed: If a previously pending DepID=201 (second write) is found, its status is changed from "Pending" to "Resolved", and the event entry is re-emitted to allow the second write to actually be written to B.

[0087] If no pending writes are found, no action is required and no new entry is created.

[0088] For subsequent writes, the same applies to the third and fourth entries: query the table once for each entry; if there are no pending entries in the table, register and suspend them; then resume writing when the write is complete.

[0089] The data hazard resolution method in this application, when encountering a write-after-write hazard where the previous write instruction is not completed before the next write instruction arrives, writes the next write instruction into the dependency table. After completing the previous write instruction, the dependency table is queried again to re-execute only the incomplete next write instruction. It supports precise wake-up, suspending only the thread or thread bundle corresponding to the conflicting instruction, while other instructions continue to execute, achieving partial unlocking and high-precision synchronization.

[0090] In an optional embodiment of this application, in step S400, if the detected hazard is a read-after-write hazard, the hazard resolution for the conflict event includes: Before executing the current read instruction, the dependency table is queried. If the query result determines that the previous write instruction has not been completed, the current read instruction is registered in the dependency table, the status of the current read instruction is set to conflict, the entry corresponding to the current read instruction is generated, and the entry is suspended. After the previous read instruction is completed, query the dependency table, change the status of the current read instruction in the pending entries to conflict resolved, and reissue the current read instruction.

[0091] The data hazard resolution method in this application, when encountering a read-after-write hazard, where the previous write instruction is not completed before the next read instruction arrives, writes the next read instruction into the dependency table. After completing the previous write instruction, the dependency table is queried again to re-execute only the incomplete next read instruction. It supports precise wake-up, suspending only the thread or thread bundle corresponding to the conflicting instruction, while other instructions continue to execute, achieving partial unlocking and high-precision synchronization.

[0092] It should be understood that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order constraint on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the diagram may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0093] Please see Figure 3 One embodiment of this application provides a heterogeneous computing system, including multiple cores and an event scheduler. Each core integrates at least two execution domains, and each execution domain is configured with a corresponding hazard monitoring unit. Each hazard monitoring unit is used to intercept instruction issuance in its execution domain in real time, and detect read-after-write hazard, write-after-write hazard, and write-after-read hazard during instruction execution based on the dependency table; when a hazard is detected, the conflict event corresponding to the current hazard is written to the event queue, wherein the conflict event includes the conflict type and dependency identifier; The event scheduler is used to read conflict events from the event queue, send a resolution request to the execution domain or external accelerator associated with the conflict event, and mark the corresponding dependency as resolved in the dependency table. When the execution domain or external accelerator receives the resolution request, it determines the corresponding thread or thread bundle according to the conflict type and dependency identifier in the conflict event, wakes up and reschedules the thread or thread bundle, and resolves the hazard of the conflict event.

[0094] For specific limitations regarding the aforementioned system 300, please refer to the limitations on the data hazard removal method described above, which will not be repeated here. Each module in the aforementioned system 300 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in a computer device, or stored in software in the memory of a computer device, so that the processor can call and execute the operations corresponding to each module.

[0095] In one embodiment, a computer device is provided, the internal structure of which can be as shown in the figure. Figure 4As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a data hazard removal method as described above. It includes: memory and a processor; the memory stores a computer program; and the processor executes the computer program to implement any step of the data hazard removal method described above.

[0096] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, can perform any of the steps in the data hazard removal method described above.

[0097] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0098] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0099] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1The function specified in one or more boxes.

[0100] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0101] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0102] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A data hazard resolution method, characterized by, The method is applied to a heterogeneous computing system comprising a plurality of cores and an event scheduler, each core internally integrating at least two execution domains, each execution domain being respectively provided with a corresponding hazard monitoring unit, and the method comprises: intercepting, by each hazard monitoring unit, instruction emission in the execution domain where the hazard monitoring unit is located in real time, and detecting read-after-write hazard, write-after-write hazard and write-after-read hazard during instruction execution based on a dependency table; in the case of detecting a hazard, writing a conflict event corresponding to the current hazard into an event queue, wherein the conflict event comprises a conflict type and a dependency identifier; reading, by the event scheduler, the conflict event from the event queue, and sending a release request to an execution domain or an external accelerator related to the conflict event, and marking a corresponding dependency in the dependency table as released; in the case that the execution domain or the external accelerator receives the release request, determining a corresponding thread or thread bundle according to the conflict type and the dependency identifier in the conflict event, waking up and rescheduling the thread or the thread bundle, and releasing the hazard of the conflict event.

2. The method of claim 1, wherein, The method comprises: intercepting, by each hazard monitoring unit, instruction emission in the execution domain where the hazard monitoring unit is located in real time, and detecting read-after-write hazard, write-after-write hazard and write-after-read hazard during instruction execution based on a dependency table; intercepting, by each hazard monitoring unit, instruction emission in the execution domain where the hazard monitoring unit is located in real time, and detecting read-after-write hazard, write-after-write hazard and write-after-read hazard during instruction execution based on a dependency table; for each intercepted instruction, obtaining a target address corresponding to execution of a current target instruction; detecting a previous instruction related to the target address based on the dependency table; in the case that the target instruction is a read instruction, the previous instruction is a write instruction, and a state of the previous instruction is conflict, if the current target instruction is executed, it is determined that the current situation is read-after-write hazard; 3. The method of claim 1, wherein, in the case that the target instruction is a write instruction, the previous instruction is a write instruction, and the state of the previous instruction is conflict, if the current target instruction is executed, it is determined that the current situation is write-after-write hazard; in the case that the target instruction is a write instruction, the previous instruction is a read instruction, and the state of the previous instruction is conflict, if the current target instruction is executed, it is determined that the current situation is write-after-read hazard.

4. The method of claim 1, wherein, The dependency table is constructed by the following steps: allocating a unique dependency identifier for an asynchronous core between different execution domains, associating a source operand and a destination operand with the dependency identifier when an instruction is emitted in each execution domain, generating an entry of the dependency table, and composing the dependency table from at least one entry of the dependency table, wherein the source operand comprises a dependency identifier, a target address, instruction content, an execution domain to which the instruction belongs, and the destination operand comprises an instruction state. The method comprises:

5. The method of claim 1, wherein, reading, by the event scheduler, the conflict event from the event queue, and sending a release request to an execution domain or an external accelerator related to the conflict event, and marking a corresponding dependency in the dependency table as released; reading, by the event scheduler, the conflict event, and obtaining the execution domain or the external accelerator related to the conflict event; sending the release request to the execution domain or the external accelerator related to the conflict event by means of a sideband message or a write signal. In the case that the detected hazard is read-after-write hazard, the method comprises: The current write instruction is executed, and the previous read instruction is notified to read the updated data after the current write instruction is completed.

6. The method of claim 1, wherein, In the case that the detected hazard is a write-after-write hazard, the conflict event is resolved by: Before executing the current write instruction, the dependency table is queried, and in the case that the previous write instruction is determined to be not completed according to the query result, the current write instruction is registered in the dependency table, the state of the current write instruction is set as conflict, an entry corresponding to the current write instruction is generated, and the entry is suspended; After the previous write instruction is completed, the dependency table is queried, the state of the current write instruction in the suspended entry is modified as conflict resolution, and the current write instruction is re-issued.

7. The method of claim 1, wherein, In the case that the detected hazard is a write-after-read hazard, the conflict event is resolved by: Before executing the current read instruction, the dependency table is queried, and in the case that the previous write instruction is determined to be not completed according to the query result, the current read instruction is registered in the dependency table, the state of the current read instruction is set as conflict, an entry corresponding to the current read instruction is generated, and the entry is suspended; After the previous read instruction is completed, the dependency table is queried, the state of the current read instruction in the suspended entry is modified as conflict resolution, and the current read instruction is re-issued.

8. A heterogeneous computing system, comprising: The data hazard resolution method comprises the following steps: Each hazard monitoring unit is configured to intercept the instruction emission in the execution domain in which the hazard monitoring unit is located in real time, detect read-after-write hazard, write-after-write hazard and write-after-read hazard during instruction execution based on the dependency table, and write a conflict event corresponding to the current hazard into an event queue in the case that a hazard is detected, wherein the conflict event comprises a conflict type and a dependency identifier. The event scheduler is configured to read the conflict event from the event queue, send a resolution request to an execution domain or an external accelerator related to the conflict event, and mark a corresponding dependency as resolved in the dependency table; in the case that the execution domain or the external accelerator receives the resolution request, the corresponding thread or thread bundle is determined according to the conflict type and the dependency identifier in the conflict event, the thread or thread bundle is woken up and rescheduled, and the conflict event is resolved.

9. A computer device comprising: A memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the data hazard resolution method in any one of claims 1 to 7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the data hazard resolution method in any one of claims 1 to 7.

Images