automatically exploiting cross-invocation parallelism using runtime ...
automatically exploiting cross-invocation parallelism using runtime ... automatically exploiting cross-invocation parallelism using runtime ...
CROSS, since SPECCROSS can be applied on code that has already been optimized usingstatic barrier removal techniques.Some techniques speculatively remove barriers using specialized hardware. Nagarajanand Gupta [45] speculatively execute parallel programs past barriers and detect conflictsby re-designing the Itanium processor’s Advanced Load Address Table (ALAT) hardware.Martínez and Torrellas [40] apply thread level speculation [49, 70] to speculatively removebarriers. A speculative synchronization unit (SSU) is designed to detect conflict and recoverfrom misspeculation at runtime. ECMon [44] exposes cache events to software so thatbarrier speculation could efficiently detect violations at runtime.These techniques arenot limited by complicated dependence patterns; however, they require special hardwaresupport.By contrast, SPECCROSS is a software-based technique that runs on existingmulti-core machines.4.5.2 Alternative SynchronizationsThe Fuzzy Barrier [24] specifies a synchronization range rather than a specific synchronizationpoint. However, it also relies on the static analysis to identify instructions that can besafely executed while a thread is waiting for other threads to reach the barrier. Fuzzy barrierscannot reduce the number of barriers; it can only reschedule barriers for more efficientexecution.4.5.3 Transactional Memory Supported Barrier-free ParallelizationTransactional Memory (TM) [27] was first introduced as a hardware technique providing away to implement lock-free data structures and operations. The idea was later implementedas a software-only construct [67]. The key idea behind TM is to make a sequence of memoryreads and writes appear as a single transaction; all intermediate steps are hidden fromthe rest of the program. A log of all memory accesses is kept during the transaction. If atransaction reads memory that has been altered between the start and end of the transac-74
tion, execution of the transaction is restarted. This continues until the transaction is ableto complete successfully, and its changes are committed to memory. Original TM systemsdo not support inter-loop speculation since it does not enforce the commit order betweentransactions from different loop invocations. Grace [4] and TCC [25] extend existing TMsystems to support inter-loop speculation. Grace automatically wraps code between forkand join points into transactions, removing barrier synchronizations at the join points. Eachtransaction commits according to its order in the sequential version of code. TCC [25]relies on programmers to wrap concurrent tasks into transactions. It requires special hardwaresupport for violation checking and transaction numbering, which ensures the correctcommit order of each transaction. As discussed in Section 4.1, both systems ignore theimportant fact that large amounts of independent tasks do not need to be checked for accessviolations. Instead, SPECCROSS is customized for this program pattern, thus it avoidsunnecessary overhead in checking and committing.4.5.4 Load Balancing TechniquesWork stealing techniques, implemented in many parallel subsystems like Cilk [8], IntelTBB [63], and X10 [13], balance load amongst parallel threads by allowing one thread tosteal work from another thread’s work queue. Balancing workloads in turn reduces the impactof barrier synchronization on program performance. However, existing work stealingimplementations only allow workers to steal work from the same epoch at any given time.This is because these implementations do not leverage knowledge about program dependencesto steal work from multiple epochs (across barriers) at the same time. As a result,programs that have a limited number of tasks in a single epoch (for example, CG in our evaluation)do not benefit from work stealing techniques. In contrast, SPECCROSS allows tasksfrom different epochs to overlap and achieve better load balance across epochs. Other loadbalancing techniques such as guided-self scheduling [52], affinity-based scheduling [39],and trapezoidal scheduling [73] also suffer from the same limitations as the work stealing75
- Page 38 and 39: Chapter 3Non-Speculatively Exploiti
- Page 40 and 41: for a variety of reasons. For insta
- Page 42 and 43: 12x11x10xDOMOREPthread Barrier9xLoo
- Page 44 and 45: Algorithm 1: Pseudo-code for schedu
- Page 46 and 47: Algorithm 2: Pseudo-code for worker
- Page 48 and 49: 3.3 Compiler ImplementationThe DOMO
- Page 50 and 51: to T i . DOMORE’s MTCG follows th
- Page 52 and 53: Outer_Preheaderbr BB1ABB1A:ind1 = P
- Page 54 and 55: Algorithm 3: Pseudo-code for genera
- Page 56 and 57: Scheduler Function SchedulerSync Fu
- Page 58 and 59: SchedulerWorker1 Worker2Worker3Work
- Page 60 and 61: 3.5 Related Work3.5.1 Cross-invocat
- Page 62 and 63: ations during the inspecting proces
- Page 64 and 65: for (t = 0; t < STEP; t++) {L1: for
- Page 66 and 67: sequential_func() {for (t = 0; t <
- Page 68 and 69: Workerthread 1Workerthread 2Workert
- Page 70 and 71: library provides efficient misspecu
- Page 72 and 73: Workerthread 1TimeFigure 4.6: Timin
- Page 74 and 75: 4.2 SPECCROSS Runtime System4.2.1 M
- Page 76 and 77: takes up to 200MB memory space.To d
- Page 78 and 79: checkpoint, the child spawns new wo
- Page 80 and 81: Operation DescriptionFunctions for
- Page 82 and 83: Main thread:main() {init();create_t
- Page 84 and 85: implemented in the Liberty parallel
- Page 86 and 87: Algorithm 5: Pseudo-code for SPECCR
- Page 90 and 91: techniques.Synchronization via sche
- Page 92 and 93: Source Benchmark Function % of exec
- Page 94 and 95: applied to the outermost loop, gene
- Page 96 and 97: 5.2 SPECCROSS Performance Evaluatio
- Page 98 and 99: and the number of checking requests
- Page 100 and 101: 8x7xno misspec.with misspec.Geomean
- Page 102 and 103: This thesisPrevious workSpeedup (x)
- Page 104 and 105: Program Speedup6x5x4x3x2xLOCALWRITE
- Page 106 and 107: for DOMORE and SPECCROSS. Others (e
- Page 108 and 109: programs and it achieves a geomean
- Page 110 and 111: Bibliography[1] R. Allen and K. Ken
- Page 112 and 113: [15] R. Cytron. DOACROSS: Beyond ve
- Page 114 and 115: [31] T. B. Jablin, Y. Zhang, J. A.
- Page 116 and 117: [47] A. Nicolau, G. Li, A. V. Veide
- Page 118 and 119: [62] L. Rauchwerger and D. Padua. T
- Page 120: national conference on Parallel Arc
CROSS, since SPECCROSS can be applied on code that has already been optimized <strong>using</strong>static barrier removal techniques.Some techniques speculatively remove barriers <strong>using</strong> specialized hardware. Nagarajanand Gupta [45] speculatively execute parallel programs past barriers and detect conflictsby re-designing the Itanium processor’s Advanced Load Address Table (ALAT) hardware.Martínez and Torrellas [40] apply thread level speculation [49, 70] to speculatively removebarriers. A speculative synchronization unit (SSU) is designed to detect conflict and recoverfrom misspeculation at <strong>runtime</strong>. ECMon [44] exposes cache events to software so thatbarrier speculation could efficiently detect violations at <strong>runtime</strong>.These techniques arenot limited by complicated dependence patterns; however, they require special hardwaresupport.By contrast, SPECCROSS is a software-based technique that runs on existingmulti-core machines.4.5.2 Alternative SynchronizationsThe Fuzzy Barrier [24] specifies a synchronization range rather than a specific synchronizationpoint. However, it also relies on the static analysis to identify instructions that can besafely executed while a thread is waiting for other threads to reach the barrier. Fuzzy barrierscannot reduce the number of barriers; it can only reschedule barriers for more efficientexecution.4.5.3 Transactional Memory Supported Barrier-free ParallelizationTransactional Memory (TM) [27] was first introduced as a hardware technique providing away to implement lock-free data structures and operations. The idea was later implementedas a software-only construct [67]. The key idea behind TM is to make a sequence of memoryreads and writes appear as a single transaction; all intermediate steps are hidden fromthe rest of the program. A log of all memory accesses is kept during the transaction. If atransaction reads memory that has been altered between the start and end of the transac-74
Change language