This application is directed, in general, to parallel processors and, more specifically, to a system and method for executing sequential code using a group of threads and a single-instruction, multiple-thread (SIMT) processor incorporating the system or the method.
As those skilled in the pertinent art are aware, applications may be executed in parallel to increase their performance. Data parallel applications carry out the same process concurrently on different data. Task parallel applications carry out different processes concurrently on the same data. Static parallel applications are applications having a degree of parallelism that can be determined before they execute. In contrast, the parallelism achievable by dynamic parallel applications can only be determined as they are executing. Whether the application is data or task parallel, or static or dynamic parallel, it may be executed in a pipeline which is often the case for graphics applications.
A SIMT processor is particularly adept at executing data parallel applications. A pipeline control unit in the SIMT processor creates groups of threads of execution and schedules them for execution, during which all threads in the group execute the same instruction concurrently. In one particular processor, each group has 32 threads, corresponding to 32 execution pipelines, or lanes, in the SIMT processor.
Parallel applications typically contain regions of sequential code and parallel code. Sequential code cannot be executed in parallel and so is executed in a single thread. When parallel code is encountered, the pipeline control unit splits execution, creating groups of worker threads for parallel execution of the parallel code. When sequential code is again encountered, the pipeline control unit joins the results of the parallel execution, creates another single thread for the sequential code, and execution proceeds.
It is important to synchronize the threads in a group. Synchronizing in part involves conforming the states of local memories associated with each lane. It has been found that synchronizing can be made faster if, while executing sequential code, a counterpart thread of the sequential code is executed in each of the lanes. The local memory states are thus assumed to be already conformed if execution is later split.
One aspect provides a system for executing sequential code. In one embodiment, the system includes: (1) a pipeline control unit operable to create a group of counterpart threads of the sequential code, one of the counterpart threads being a master thread, remaining ones of the counterpart threads being slave threads and (2) lanes operable to: (2a) execute certain instructions of the sequential code only in the master thread, corresponding instructions in the slave threads being predicated upon the certain instructions and (2b) broadcast branch conditions in the master thread to the slave threads.
Another aspect provides a method of executing sequential code. In one embodiment, the method includes: (1) creating a group of counterpart threads of the sequential code, one of the counterpart threads being a master thread, remaining ones of the counterpart threads being slave threads, (2) executing certain instructions of the sequential code only in the master thread, corresponding instructions in the slave threads being predicated upon the certain instructions and (3) broadcasting branch conditions in the master thread to the slave threads.
Yet another aspect provides a SIMT processor. In one embodiment, the SIMT processor includes: (1) lanes, (2) local memories associated with corresponding ones of the lanes, (3) shared memory device by the lanes and (4) a pipeline control unit operable to create a group of counterpart threads of the sequential code and cause the group to be executed in the lanes, one of the counterpart threads being a master thread, remaining ones of the counterpart threads being slave threads. The lanes are operable to: (1) execute certain instructions of the sequential code only in the master thread, corresponding instructions in the slave threads being predicated upon the certain instructions and (2) broadcast branch conditions in the master thread to the slave threads.
Reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
As stated above, it has been found that the process of synchronizing among the lanes, or cores, of a SIMT processor can be made faster if a counterpart thread of the sequential code is executed in each of the lanes. Because the counterpart threads are of the same code (i.e., the same instructions in the same order), and because the local memory states are conformed when the counterpart threads of the code begin execution, the assumption that the local memory states will remain conformed seems a foregone conclusion. However, it is realized herein that conditions may exist under which the memory states diverge.
Assume, as one example, the counterpart threads of the sequential code are to execute the same load instruction. The location of the memory to load is specified by either a register or an address. If by a register, the value of the register may vary per thread because each thread has its own copy of the register. If by an address, the address value may point to different thread-local memory locations in the system. In either case, each thread may load different values from a variety of memory locations, causing thread-local memory states to diverge. Were the counterpart threads then to branch based upon the loaded data, some branches taken would be correct, and others would be erroneous.
Similarly, assume the counterpart threads of the sequential code are to execute the same store instruction. The memory being stored to varies per thread for the same reasons as described for the load instruction above. Memory locations not modified in the sequential execution would be erroneously modified in the parallel execution.
As another example, assume that the counterpart threads of the sequential code are to store data concurrently to the same location in shared memory. The shared memory could again be overwhelmed and corrupted as a consequence. The problems highlighted in both of these examples are sometimes experienced in vector operations.
As yet another example, assume an exception handler is a shared resource among the various lanes. Regions of sequential code often include numerous instructions that could potentially cause exceptions to occur. While executing these instructions in parallel, were an exception to arise, the parallel processes could throw simultaneous exceptions and overwhelm the shared exception handler, which would expect one exception, at most, and possibly none at all.
It is therefore realized herein that the assumption that the local memory states will necessarily remain conformed while counterpart threads of sequential code are executing is untenable. It is further realized herein that certain operations, including not only loads from and stores to shared memory but divisions and other instructions that potentially cause exceptions, can corrupt shared memory or cause local memory states to diverge as a “side effect.” It is yet further realized herein a mechanism is needed to ensure semantics of sequential code are not distorted by diverging thread-local memory states.
Accordingly, introduced herein are various embodiments of a system and method for executing sequential code using a group of threads. Viewed at a very high level, the various embodiments cause counterpart-thread execution of sequential code to emulate master-thread execution of sequential code.
According to the various embodiments, one of the counterpart threads is designated a master thread, and the other threads are designated slave threads. Certain instructions (typically those that may or do employ shared resources) in the slave threads are then predicated on corresponding instructions in the master thread, and only the corresponding instructions in the master thread are executed. If a branch instruction is encountered in the master thread, the branch conditions in the master thread are then broadcast to the slave threads.
SIMT processor 100 further includes a pipeline control unit 108, shared memory 110 and an array of local memory 112-1 through 112-J associated with thread groups 104-1 through 104-J. Pipeline control unit 108 distributes tasks to the various thread groups 104-1 through 104-J over a data bus 114. Pipeline control unit 108 creates, manages, schedules, executes and provides a mechanism to synchronize thread groups 104-1 through 104-J. Certain embodiments of SIMT processor 100 are found within a graphics processing unit (GPU). Some GPUs provide a group synchronization instruction, such as bar.sync in GPUs manufactured by Nvidia Corporation of Santa Clara, Calif. Certain embodiments support execution of divergent conditional branches by thread groups. Given a branch, some threads within a thread group 104 will take the branch because a branch condition predicate evaluates to “true,” and other threads fall through to the next instruction because the branch condition predicate evaluates to “false.” Pipeline control unit 108 tracks active threads by first executing one of the paths, either the branch taken or the branch not-taken, and then the alternate path, enabling the appropriate threads for each.
Continuing the embodiment of
The embodiment of
Thread group 104 is coupled to memory 208, which is allocated into sections correlating to each of the cores 106-1 through 106-K. Thread launcher 214 creates processing threads in cores 106-1 through 106-K. One core, often the first, core 106-1, is designated to execute the master thread. The remaining threads are worker threads. Traditionally, the master thread executes the sequential region 204 of the program 202, and the parallel region 206 is traditionally executed in the worker threads. When the parallel region 206 is reached, thread launcher 214 creates the necessary worker threads to execute the parallel processing.
In the embodiment of
The method begins in a start step 310. In a step 320, a group of counterpart threads of the sequential code is created, one of the counterpart threads being a master thread, remaining ones of the counterpart threads being slave threads. In a step 330, certain instructions of the sequential code are executed only in the master thread, corresponding instructions in the slave threads being predicated upon the certain instructions. In various embodiments, the certain instructions may be load instructions, store instructions, divide instructions, or any other instruction that may produce, or may be perceived as producing, side effects. In one embodiment, the corresponding instructions are predicated using a condition based on a thread identifier.
In a step 340, branch conditions in the master thread are broadcast to the slave threads. In one embodiment, the branch conditions are broadcast before execution of a branch instruction in the master thread, and the corresponding branch instructions are executed in the slave threads only after the broadcast. The method ends in an end step 350.
Those skilled in the art to which this application relates will appreciate that other and further additions, deletions, substitutions and modifications may be made to the described embodiments.
This application claims the benefit of U.S. Provisional Application Ser. No. 61/722,661, filed by Lin, et al., on Nov. 5, 2012, entitled “Executing Sequential Code Using a Group of Threads,” commonly assigned with this application and incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
5875464 | Kirk | Feb 1999 | A |
6088770 | Tarui et al. | Jul 2000 | A |
6609193 | Douglas et al. | Aug 2003 | B1 |
7086063 | Ousterhout et al. | Aug 2006 | B1 |
7856541 | Kaneda et al. | Dec 2010 | B2 |
8250555 | Lee et al. | Aug 2012 | B1 |
8335892 | Minkin et al. | Dec 2012 | B1 |
8397013 | Rosenband et al. | Mar 2013 | B1 |
8516483 | Chinya et al. | Aug 2013 | B2 |
8547385 | Jiao | Oct 2013 | B2 |
8615646 | Nickolls et al. | Dec 2013 | B2 |
8683132 | Danilak | Mar 2014 | B1 |
20020029357 | Charnell et al. | Mar 2002 | A1 |
20030018684 | Ohsawa et al. | Jan 2003 | A1 |
20050125774 | Barsness et al. | Jun 2005 | A1 |
20060095675 | Yang et al. | May 2006 | A1 |
20070136523 | Bonella et al. | Jun 2007 | A1 |
20070143582 | Coon et al. | Jun 2007 | A1 |
20070294512 | Crutchfield et al. | Dec 2007 | A1 |
20080052466 | Zulauf | Feb 2008 | A1 |
20080126716 | Daniels | May 2008 | A1 |
20090006758 | Chung et al. | Jan 2009 | A1 |
20090013323 | May et al. | Jan 2009 | A1 |
20090031290 | Feng et al. | Jan 2009 | A1 |
20090100244 | Chang et al. | Apr 2009 | A1 |
20100079454 | Legakis et al. | Apr 2010 | A1 |
20100281230 | Rabii et al. | Nov 2010 | A1 |
20110022672 | Chang et al. | Jan 2011 | A1 |
20110072214 | Li et al. | Mar 2011 | A1 |
20110072438 | Fiyak et al. | Mar 2011 | A1 |
20110125974 | Anderson | May 2011 | A1 |
20110191522 | Condict et al. | Aug 2011 | A1 |
20110265068 | Elnozahy et al. | Oct 2011 | A1 |
20110320804 | Chan et al. | Dec 2011 | A1 |
20120072652 | Celis et al. | Mar 2012 | A1 |
20120089792 | Fahs et al. | Apr 2012 | A1 |
20120131309 | Johnson et al. | May 2012 | A1 |
20120137055 | Lee et al. | May 2012 | A1 |
20120137099 | Shibayama et al. | May 2012 | A1 |
20120151179 | Gaertner et al. | Jun 2012 | A1 |
20120191953 | Eichenberger et al. | Jul 2012 | A1 |
20120204065 | Tsafrir et al. | Aug 2012 | A1 |
20120254530 | Tagaya | Oct 2012 | A1 |
20130263153 | Gschwind | Oct 2013 | A1 |
20140007114 | Wang et al. | Jan 2014 | A1 |
20140129783 | Marathe et al. | May 2014 | A1 |
20140130021 | Lin et al. | May 2014 | A1 |
20140130052 | Lin et al. | May 2014 | A1 |
Number | Date | Country |
---|---|---|
1725176 | Jan 2006 | CN |
101176066 | May 2008 | CN |
101819675 | Sep 2010 | CN |
201140447 | Nov 2011 | TW |
201220246 | May 2012 | TW |
Number | Date | Country | |
---|---|---|---|
20140129812 A1 | May 2014 | US |
Number | Date | Country | |
---|---|---|---|
61722661 | Nov 2012 | US |