JP6957528B2 - Redundant thread fingerprinting with compiler insert translation code - Google Patents

Description

Processing units such as central processing units (CPUs), graphics processing units (GPUs), and accelerated processing units (APUs) include multiple computing units (APUs) to process multiple instructions simultaneously or in parallel. For example, a processor core) is implemented. For example, a GPU may be implemented using a plurality of computing units, each containing a plurality of processing elements for executing instruction streams (conventionally referred to as "work items" or "threads") simultaneously or in parallel. A computer operating according to a single instruction multiple data (SIMD) architecture executes the same instruction with different data sets. The number of threads that can be executed simultaneously or in parallel on a processing device such as a GPU can range from tens to thousands of threads, and engineers can use two-dimensional (2D) or three threads that are typically implemented on a GPU. We would like to use this function for applications other than two-dimensional (3D) graphics applications. However, general purpose applications require a higher level of fault tolerance than traditional graphics applications to avoid application errors and system crashes.

By referring to the accompanying drawings, the present disclosure will be better understood and many features and advantages thereof will be apparent to those skilled in the art. Similar or identical items are indicated when the same reference code is used in different drawings.

It is a block diagram of the acceleration processing apparatus according to some embodiments. It is a block diagram which shows the hierarchical structure of the group of threads which can be executed on the acceleration processing apparatus shown in FIG. 1 by some embodiments. FIG. 3 is a block diagram of an acceleration processor that selectively bypasses redundant thread fingerprint comparisons based on the number of event triggers that have occurred since the previous comparison of fingerprints, according to some embodiments. It is a figure which shows the modification of the program code by the conversion code inserted by the compiler during the compilation of the program code by some embodiments. FIG. 5 is a flow diagram of a method of selectively bypassing or performing sharing and comparison operations between redundant threads to detect errors, according to some embodiments. FIG. 5 is a flow chart of a method of executing an end check to determine whether to execute a sharing and comparison operation between redundant threads before terminating the program code according to some embodiments.

Processing device reliability by using Redundant multithreading (RMT) to run two or more redundant threads on different processing elements and then comparing the results of the redundant threads to detect errors. Can be improved. By detecting the difference between the results produced by two redundant threads executing the same instruction on the same data, it is indicated that at least one redundant thread has an error. Using similarities and differences between results generated by three or more redundant threads executing the same instructions on the same data, for example by using a voting system that applies to three or more results. It can detect errors and, in some cases, correct them. The mechanism for passing data between redundant threads to support RMT error detection or correction introduces considerable overhead. For example, a spinlock mechanism may be used to synchronize the passing of data and messages between redundant threads. The performance of the RMT system is redundant, at least in part, before each store instruction (or other event trigger) to avoid the traditional RMT system storing data that may contain errors. Overhead can be significantly reduced as the results produced by the threads are compared.

It was executed by the redundant thread depending on whether the event trigger for comparison (for example, execution of the store instruction by the redundant thread) occurred a set number of times (for example, two or more times) from the comparison of the previous result. By selectively bypassing the comparison of the calculation results, the overhead of the software-implemented RMT error detection or correction mechanism can be reduced without degrading the error detection accuracy. By hashing the thread-generated results with previously encoded values or thread-related initial values and generating encoded values for each redundant thread, the probability of detecting an error is greatly reduced. Without having to, the overhead associated with storing the results of previous operations for subsequent comparisons can be reduced. The encoded value forms a fingerprint of each thread that represents multiple results associated with multiple event triggers. Redundant thread fingerprint values are shared and compared after several event triggers have occurred in the redundant thread. If the redundant thread fingerprint values are different, an error is detected, which triggers error recovery processing depending on the variation. Redundant threads can include three or more redundant threads, in which case error correction is performed by using a voting method to select the most frequent fingerprint value as the correct value. In some embodiments of the fingerprint, it is calculated by hashing the address of the stored result and the stored value with the value of the previous fingerprint.

In some variations, a compiler is used to translate the program code executed by redundant threads into a fingerprint scheme. The translation code selectively bypasses the sharing and comparison operations and bundles the encoded values for the bypassed sharing and comparison operations into a single coded fingerprint. For example, if the shared and compare operation event trigger is a store instruction, the compiler can insert code to hash the result stored by the redundant thread with the corresponding previous fingerprint value. Generate a lookup table of the code to be compiled. The compiler also initializes the counter for each redundant thread. Counters are incremented in response to redundant threads performing event triggers and are used to determine how many times sharing and comparison operations have been bypassed. The compiler also executes the hash, checks whether to bypass or compare the values of the fingerprint variables of the redundant threads, shares and compares the values of the fingerprint variables of the redundant threads, and before terminating the program code. Insert a conversion code in to determine whether to perform unprocessed sharing and comparison operations.

FIG. 1 is a block diagram of the acceleration processing apparatus 100 according to some embodiments. Various types of processing devices (eg, central processing unit (CPU), graphics processing unit (GPU), general-purpose GPU (GPGPU), integrated circuits for specific applications) using an accelerated processing device (APD) 100. (ASIC), field programmable gate array (FPGA), digital signal processor (DSP), etc.) can be implemented. The APD100 may be configured to implement one or more fake machines, such as a low-level virtual machine (LLVM) that emulates the behavior of a computer system and provides a platform for running applications. The APD100 is also configured to implement an operating system, and in some embodiments, each masquerade machine runs a separate instance of the operating system. Further, the APD 100 is configured to execute, for example, a kernel that performs operations such as pixel operations, geometric calculations, such as graphics pipeline operations including image rendering and the like. In addition, the APD100 can perform non-graphics processing operations such as video operations, physics simulation, and computational fluid dynamics.

The APD 100 includes a plurality of calculation units 101, 102, 103, which are collectively referred to herein as "calculation units 101-103". Computational units 101-103 can be configured to operate as a pipeline running different instances of the same kernel at the same time. For example, some variants of compute units 101-103 may be a single instruction multiple data (SIMD) processor core that executes the same instruction in parallel using different data. Some embodiments of the APD100 may implement more or less computational units 101-103.

The calculation unit 101 includes processing elements 105, 106, 107 (collectively referred to herein as "processing elements 105-107"). Some embodiments of processing elements 105-107 are configured to perform arithmetic and logical operations indicated by instructions scheduled for execution by processing elements 105-107 in calculation unit 101. Further, the calculation unit 101 includes a memory such as a local data store (LDS) 110 or the like. The instructions or data stored in the LDS 110 are visible to the processing elements 105-107 but not to the entities on the compute units 102, 103. Therefore, the LDS 110 enables sharing between the processing elements 105 to 107 of the calculation unit 101. The LDS 110 can be implemented using a dynamic random access memory (DRAM), an embedded DRAM (eDRAM), a phase change memory (PCM), or the like. For clarity, only the processing elements 105-107 and LDS 110 mounted on the compute unit 101 are shown in FIG. However, the calculation units 102, 103 also include corresponding processing elements and corresponding LDSs.

Each processing element 105-107 executes a separate instance of the kernel. An instance of the kernel executed by processing elements 105-107 may be called a work item, task or thread. In some variants, the instructions executed by the thread and the data manipulated by the instructions are accessed from the LDS 110. Then, the result of the operation executed by the thread is stored in the LDS 110. Further, the processing elements 105 to 107 include private memories 115, 116, 117, which are collectively referred to as "memory 115 to 117" in the present specification. The memory 115-117 of each processing element 105-107 is visible only from the corresponding processing element 105-107. For example, the memory 115 is visible only to the processing elements 105 and not from the processing elements 106, 107. The memories 115 to 117 can be implemented by using a dynamic random access memory (DRAM), an embedded DRAM (eDRAM), a phase change memory (PCM), or the like.

Further, the APD 100 includes a global data store (GDS) 120 which is a memory visible from all the calculation units 101 to 103 mounted on the APD 100. As used herein, the term "visible" means that compute units 101-103 perform a store to write information to memory, or a load to read information from memory, for example. This indicates that the information in the GDS 120 can be accessed. Therefore, by using the GDS 120, it becomes possible to facilitate sharing between threads executed by the processing elements of the calculation units 101 to 103. Some embodiments of the GDS 120 are also visible to other processing devices that may be interconnected to the APD 100. For example, the GDS 120 may be visible to a CPU (not shown in FIG. 1) connected to the APD 100. The GDS 120 can be implemented using a dynamic random access memory (DRAM), an embedded DRAM (eDRAM), a phase change memory (PCM), or the like.

Redundant threads are executed by processing elements 105-107 in the APD100. A fingerprint can be generated for each redundant thread by encoding the result of the operation performed by the redundant thread. Then, the result of the operation executed by the redundant thread or the fingerprint of the redundant thread can be compared to detect (or correct in some cases) an error generated during execution of the redundant thread. Comparison of results or associated fingerprints is typically performed in response to a trigger event such as a store instruction, which detects or corrects an error before storing the result in memory. In some embodiments of the APD100, the comparison of redundant thread fingers is selectively performed depending on whether the event trigger for comparison has occurred a configurable number of times from the previous comparison of the resulting coded values. It is configured to bypass. The number of times that can be set can be set to a value of 2 or more.

FIG. 2 is a block diagram showing a hierarchical structure 200 of a group of threads according to some embodiments. Some variants of the hierarchical structure 200 represent threads that are executed simultaneously or in parallel by the APD 100 shown in FIG. The hierarchical structure 200 includes a kernel 205 that represents program code that can be executed by processing elements such as the processing elements 105 to 107 shown in FIG. Instances of kernel 205 are grouped into workgroups 210, 211,212, which are collectively referred to herein as "workgroups 210-212". Each workgroup 210-212 has a local size that defines the number of threads in the workgroup and a group identifier that uniquely identifies each of the workgroups 210-212. In some embodiments, workgroups 210-212 are a collection of related threads that are executed simultaneously or in parallel. For example, workgroup 210 includes threads 215, 216, 217, which are collectively referred to herein as "threads 215-217". Threads 215-217 are assigned different local identifiers that identify threads 215-217 within the workgroup 210. Threads 215 to 217 are also assigned a global identifier that globally identifies threads 215 to 217 across the threads assigned to all workgroups 210 to 212. Threads in each workgroup 210-212 can be synchronized with other threads in the corresponding workgroup 210-212.

Workgroups 210-212 are assigned to run in the corresponding compute units. For example, the workgroup 210 may be executed in the calculation unit 101 shown in FIG. 1, the workgroup 211 may be executed in the calculation unit 102 shown in FIG. 1, and the workgroup 212 may be executed in the calculation unit 103 shown in FIG. .. Threads in workgroups 210-212 are scheduled to run on the corresponding processing elements in the assigned compute unit. For example, thread 215 can be scheduled to be executed by the processing element 105 shown in FIG. 1, thread 216 can be scheduled to be executed by the processing element 106 shown in FIG. 1, and thread 217 can be executed. Can be scheduled to be executed by the processing element 107 shown in FIG.

Redundant multithreading (RMT) is performed by the APD100 to detect and, in some cases, correct errors that occur during the processing of threads such as threads 215-217. Redundant threads are created by instantiating multiple threads to execute the same instruction with the same data. Redundant threads run on different processing elements. The global identifier, or combination of group and local identifiers, indicates the data processed by the corresponding thread. For example, the thread's global identifier can be used to calculate the memory address and determine thread control. Therefore, by mapping the global identifiers (or combinations of group and local identifiers) of multiple threads to a single global identifier so that two threads execute the same kernel code for the same data, it is redundant. Threads can be spawned. Software-implemented RMT technology is disclosed in US Pat. No. 9,274,904, which is incorporated herein by reference in its entirety. The coded value (also known as the fingerprint) of the result of an operation performed by a redundant thread, depending on whether the event trigger for comparison has occurred a set number of times since the previous comparison of the coded value of the result. By selectively bypassing the (obtain) comparison, the overhead caused by software-implemented RMT technology can be reduced.

FIG. 3 is a block diagram of the APD 300 that selectively bypasses fingerprint comparisons based on the number of event triggers that have occurred since the previous comparison of fingerprints, according to some embodiments. The APD 300 is used to implement some embodiments of the APD 100 shown in FIG. The APD300 is configured to run kernel 305. Threads 310 and 315 represent redundant instances of kernel 305 that execute the same instructions for the same data. In some embodiments, threads 310,315 are identified by the same identifier (eg, the same global identifier, group identifier or local identifier). Although two threads 310,315 are shown in FIG. 3, other embodiments may include more redundant threads.

The APD 300 includes processing elements 320, 325 for executing redundant threads. Each processing element 320,325 includes a corresponding private memory 330,335. Although two processing elements 320,325 are shown in FIG. 3, some embodiments of the APD 300 may include more processing elements. Further, the APD 300 includes a memory 340 that can be seen from both the processing elements 320 and 325. For example, when the processing elements 320 and 325 are mounted in the same calculation unit, the memory 340 can be a local data storage unit such as the LDS 110 shown in FIG. In another example, when the processing elements 320 and 325 are mounted in different calculation units, the memory 340 can be a global data storage unit such as the GDS 120 shown in FIG.

The compiler implemented by APD300 inserts the conversion code into the program code defined by kernel 305 during compilation. When the translation code is executed by threads 310,315, it selectively bypasses threads 310,315 to compare the fingerprints generated by threads 310,315 based on the execution result of part or block of the program code. Let me. Threads 310,315 selectively bypass the fingerprint comparison, depending on whether the comparison event trigger has occurred a setable number of times since the previous fingerprint comparison. In some embodiments, the compiler inserts a translation code that causes one or more of threads 310,315 to have a lookup table 345 containing code values used to hash the results to generate fingerprints. do. For example, an 8-bit array of 256 elements can be allocated to the thread group's local shared memory space to form a lookup table 345. Further, the conversion code can initialize the code value in the lookup table 345 to one or more of threads 310 and 315. For example, one or more of threads 310,315 can insert 256 8-bit unique cache elements into the array forming the lookup table 345. Alternatively, some embodiments perform hashing using another algorithm that does not require the use of a lookup table 345 (eg, a hash algorithm based on an exclusive OR or the like).

The conversion code inserted into the program code includes a register initialization code that initializes the corresponding registers 350,355 to threads 310,315 to store the fingerprint value. For example, threads 310,315 can allocate registers 350,355 in the corresponding private memories 330,335. In addition, threads 310 and 315 can use the code values stored in the lookup table 345 to initialize the fingerprint values stored in the registers 350 and 355. The conversion code also provides threads 310,315 with corresponding counters 360,365 used to count the number of times threads 310,315 bypassed the comparison of fingerprint values in response to event triggers such as store instructions. Includes a counter initialization code to initialize to. Threads 310, 315 can initialize counters 360, 365 to default values such as zero.

The conversion code has the current result value (and, in some cases, the address of the location where the result is stored) stored in threads 310,315 and the current fingerprint value stored in the corresponding registers 350,355. Includes the hash code to make. For example, if threads 310,315 have not bypassed the comparison of previous fingerprint values, the current result value (eg, a value stored in memory, etc.) and the address of the storage location will be in the corresponding registers 350,355. Hashed with the initial value of the fingerprint stored in. In another example, if threads 310,315 have already bypassed the previous fingerprint value comparison more than once, the current result value and address will be hashed with the current fingerprint value. The current fingerprint value is previously generated based on the value and address of the previous result hashed with the fingerprint in response to bypassing the previous comparison. The skip check is included in the conversion code and is used to compare the value of counters 360,365 with a configurable value that indicates whether to bypass or perform the comparison. The value that can be set is set to a value greater than 1. The larger the configurable value, the less overhead the sharing and comparison algorithms used to perform error detection with the APD300.

The conversion code also includes a sharing and comparison code that causes threads 310 and 315 to share the values in the corresponding registers 350 and 355 so that the values can be compared for error detection or correction. For example, if the skip check performed by thread 310 indicates that the value of counter 360 is greater than or equal to the configurable value, thread 310 has implemented the fingerprint value from register 350 into memory 340. By copying to the shared buffer 370, the fingerprint stored in the register 350 can be shared. The use of shared buffer 370 may be adjusted using synchronization, spinlock or other techniques. Further, the skip check executed by the thread 315 indicates that the value of the counter 365 is equal to or greater than the settable value. Thread 315 can then access the shared fingerprint value associated with thread 310 and compare the shared fingerprint with the fingerprint value stored in register 355. If the two values are equal, the APD300 determines that no error has occurred. If the two values are different, the APD 300 can determine that an error has occurred and initiate an error procedure that includes error correction.

FIG. 4 is a diagram showing modification of the program code 400 by the conversion code inserted by the compiler during the compilation of the program code 400 according to some embodiments. The program code 400 can be a part of the code contained in the kernel such as the kernel 205 shown in FIG. 2 or the kernel 305 shown in FIG. The program code 400 includes a code block 401, an event trigger 402, a code block 403, an event trigger 404, a code block 405, and an exit code 406. Event triggers 402, 404 are instructions that trigger sharing and comparison operations used to compare the fingerprints of redundant threads to detect or correct errors. For example, event triggers 402, 404 can be store instructions used to store values in a location and in memory. Therefore, the stored value is the result of an event trigger, which can be used, for example, by hashing the stored value and the address of the storage location with the value or initial value of the previous fingerprint. Determine the fingerprint of the thread to do. The number of event triggers 402, 404 encountered by the thread executing the program code 400 may be deterministic or non-deterministic. For example, code blocks 401, 403, 405 include loops, conditional instructions, branch instructions, etc. that can result in different instances of the kernel encountering different numbers of event triggers 402,404 during the execution of program code 400. be able to.

Program code 400 is converted by the compiler during compilation. For example, some variants of the compiler insert table generation code 410 before the first code block 401 in program code 400, so that the thread that executes the modified program code 415 is shown in FIG. A table such as the lookup table 345 shown is assigned and initialized. Some embodiments of table generation code 410 implement a 32-bit Cyclic Redundancy Check (CRC) hash routine and allocate an 8-bit array of 256 elements to store the encoded values used in the CRC hash routine. For example, the table generation code 410 for allocating a table and inputting data can be described by the following pseudo code.

Further, the compiler converts the program code 400 into the modified program code 420 by inserting the counter initialization code 425 used to initialize the counters such as the counters 360, 365 shown in FIG. .. Further, the modified program code 420 includes hash codes 430 and 431 inserted after each of the event triggers 402 and 404. Hash codes 430,431 are used to hash the results associated with event triggers 402,404 and form a coded value after event triggers 402,404 that represents the fingerprint of the corresponding thread. Examples of hash codes 430 and 431 can be described by the following pseudo code.

A thread that inserts skip check codes 435 and 436 and executes program code 400 encounters event triggers 402,404 a set number of times since it was last shared and compared with one or more corresponding redundant threads. Determine if it is. Sharing and comparison codes 440,441 are inserted into a thread running program code 400 to share and compare its fingerprint value with the fingerprint value calculated by one or more redundant threads. Sharing and comparison codes 440,441 only indicate that the corresponding skip check codes 435,436 have encountered a configurable number of event triggers 402,404 since the last time the thread was shared and compared. Will be executed.

The last converted code 445 is used to determine if there are any outstanding sharing and comparison operations that need to be performed before the thread exits program code 400 in termination block 406. Generated by inserting a termination check 450.

FIG. 5 is a flow diagram of a method 500 according to some embodiments that selectively bypasses or executes sharing and comparison operations between redundant threads to detect errors. Method 500 is carried out in some embodiments of APD100 shown in FIG. 1 or APD300 shown in FIG. The APD is configured to execute multiple instances of the kernel using multiple threads assigned to the corresponding processing elements implemented in the APD. The compiler in the APD translates the program code in the kernel to generate translation code that causes the thread running the kernel instance to selectively bypass or perform sharing and comparison operations. For example, the compiler can convert the program code as shown in FIG.

At block 505, the APD identifies the thread to be executed and creates one or more threads that are redundant to the identified thread. As described herein, redundant threads can be identified using the same identifier (eg, global identifier, group identifier, local identifier, etc.). APD allocates redundant threads to different processing elements. In block 510, redundant threads are executed with different processing elements. Redundant threads can run simultaneously or in parallel and are synchronized in some embodiments of redundant threads.

At block 515, the thread detects an event trigger (eg, a store instruction, etc.) that potentially triggers a sharing and comparison operation to detect or correct an error. At block 520, the thread increments the corresponding counter in response to detecting an event trigger. At block 525, the thread bundles the hash values of the results associated with the event trigger (eg, the data stored in response to the store instruction) into the corresponding fingerprints. For example, in some variants, the thread hashes the resulting value with the previous fingerprint generated based on the result of the previous event trigger. The thread can also hash other information (eg, the address of the location that stores the data indicated by the store instruction) with the fingerprint.

In the determination block 530, the thread compares the value of the counter with a threshold indicating a configurable number of bypassed sharing and comparing operations before performing the sharing and comparing operations between redundant threads. If the counter is below the threshold, method 500 transitions to block 510 and continues thread execution. If the counter is greater than the threshold, in block 535, the threads perform sharing and comparison operations to determine if the redundant thread fingerprints match. The APD can determine that an error has occurred if the fingerprints do not match. The APD may perform error reporting or recovery if an error is detected during the sharing and comparison operations performed in block 535. At block 540, the thread resets the value of the corresponding counter. Then, the method 500 shifts to the block 510 and continues the execution of the thread.

FIG. 6 is a flow diagram of a method 600 according to some embodiments in which an end check is performed to determine whether sharing and comparison operations between redundant threads should be performed before terminating the program code. Method 600 is performed in some embodiments of APD100 shown in FIG. 1 or APD300 shown in FIG. The APD is configured to execute multiple instances of the kernel using multiple threads assigned to the corresponding processing elements implemented in the APD. The APD compiler translates the program code in the kernel and inserts a termination check. For example, the compiler can convert the program code 400 to insert a termination check 450, as shown in FIG.

In block 605, redundant threads are executed with different processing elements. Redundant threads can run simultaneously or in parallel and are synchronized in some embodiments of redundant threads. At block 610, the thread detects the termination condition. In the determination block 615, the thread checks the value of the corresponding counter in response to detecting the termination condition. If the value of the counter is greater than zero (or any other default value), that is, if the sharing and comparison operations have been bypassed at least once since the last sharing and comparison operation between redundant threads, the method is: Move to block 620. At block 620, threads share and compare based on the current value of the fingerprint. Method 600 then transitions to block 625, where the thread executes the exit code. If the value of the counter is equal to zero (or any other default value), i.e., if there are no outstanding shared and compare operations, method 600 goes directly to block 625 and the thread executes the exit code.

In some embodiments, certain aspects of the techniques described above may be implemented by one or more processors in a processing system running software. The software includes one or more sets of executable instructions stored or tangibly embodied in a non-temporary computer-readable storage medium. When executed by one or more processors, the software can include instructions and specific data that operate on one or more processors to implement one or more aspects of the techniques described above. Non-temporary computer-readable storage media can include, for example, magnetic or optical disk storage devices, solid-state storage devices such as flash memory, caches, random access memory (RAM), or other non-volatile memory devices. Executable instructions stored on a non-temporary computer-readable storage medium may be source code, assembly language code, object code, or other instruction format that can be interpreted or executed by one or more processors. ..

Not all activities or elements mentioned above are required in the general description, and some specific activities or devices may not be required, and one or more additional activities are performed, 1 Note that one or more additional elements may be included. Moreover, the order in which activities are listed is not necessarily the order in which they are executed. The concept has also been described with reference to specific embodiments. However, one of ordinary skill in the art will appreciate that various modifications and modifications can be made without departing from the scope of the invention as described in the claims below. Therefore, the specification and drawings should be considered in an exemplary sense rather than a limiting sense, and all such modifications are intended to be within the scope of the present invention.

Benefits, other benefits and solutions to problems have been described above for a particular embodiment. However, benefits, benefits, solutions to problems, and features that can give rise to or make any benefit, benefits, solutions, as important, essential, and essential features of any or all claims. Should not be interpreted. Moreover, the particular embodiments described above are exemplified, as those skilled in the art benefiting from the teachings herein can modify and implement the disclosed inventions in a different but equivalent manner apparent to those skilled in the art. Not too much. No limitation is intended to limit the configuration or design details presented herein, other than those described in the claims below. Therefore, it is clear that the particular embodiments disclosed above may be modified or modified, and all such variants are considered to be within the scope of the disclosed invention. be. Therefore, the protection required herein is as described in the claims below.

Claims (15)

One or more processing elements of a compute unit respond to an event trigger on the one or more processing elements.
The selective bypass is to selectively bypass at least one comparison of the results of operations performed by the redundant thread of the compute unit, and the selective bypass is at least one previously performed by the redundant thread. It is performed based on the determination that the event trigger has occurred a set number of times since the previous comparison of the results of one operation.
Method. The number of times that can be set is greater than 1.
The method of claim 1. The event trigger is a store instruction executed by the redundant thread to store the result in memory.
The method of claim 1 or 2. Further comprising generating a coded value of the result by hashing the result with at least one of a previous coded value and an initial value.
The method according to any one of claims 1 to 3. Further comprising modifying the program code executed by the redundant threads by inserting code during compilation to generate a look-up table of code values used to hash the results.
The method according to any one of claims 1 to 4. Modifying the program code during the compilation further includes initializing the counters for each redundant thread, each counter being incremented in response to the redundant thread executing the event trigger, and the counters of the counter. The value is compared to the configurable number of times to determine whether to selectively bypass the at least one comparison.
The method of claim 5. Modifying the program code during the compilation hashes the result to generate a coded value, compares the value of the counter with the configurable number of times, and selectively bypasses the at least one comparison. A code for sharing and comparing the coded value among the redundant threads is inserted according to the determination of whether or not to perform the event trigger and the determination that the event trigger for comparison has occurred the settable number of times. Including more to do,
The method of claim 6. Modifying the program code during the compilation further means inserting code to determine whether the redundant thread will perform unprocessed sharing and comparison operations before terminating the program code. include,
7. The method of claim 7. The first processing element for executing the first thread and
It includes at least one second processing element for executing at least one second thread that is redundant with respect to the first thread.
The first thread and the at least one second thread selectively bypass the comparison of the results of operations performed by the first thread and the at least one second thread, and selectively bypass the comparison. That is, in response to the event trigger for comparison , it is determined that the event trigger has occurred a set number of times since the previous comparison of the results of at least one operation previously executed by the redundant thread. Based on ,
Device. The event trigger is a store instruction executed by the redundant thread to store the result.
The device of claim 9. The first thread and the at least one second thread generate a coded value by hashing the result with at least one of a previous coded value and an initial value.
The device of claim 9 or 10. A plurality of processing elements including the first processing element and at least one second processing element are further provided.
The first thread and the plurality of processing elements include the first thread and by inserting code during compilation to generate a look-up table of code values used to hash the results and generate encoded values. Implements a compiler configured to modify the program code executed by at least one second thread.
The device according to any one of claims 9 to 11. Further comprising memory configured to implement counters for said first thread and said at least one second thread.
The compiler is configured to initialize the counter, and the first thread or at least one second thread increments the corresponding counter in response to executing the event trigger, and the counter The value of is compared to the configurable number of times to determine whether to selectively bypass the at least one comparison.
The device of claim 12. The compiler hashes the results, compares the value of the counter with the configurable number of times to determine whether to selectively bypass the at least one comparison, and the event trigger for the comparison It is configured to insert a code for sharing and comparing the encoded value between the first thread and the at least one second thread in response to the determination that the occurrence has occurred a set number of times. ing,
The device of claim 13. The compiler is to insert code to determine whether the first thread and at least one second thread perform unprocessed sharing and comparison operations before terminating the program code. It is configured,
The device of claim 14.

Images