automatically exploiting cross-invocation parallelism using runtime ...
automatically exploiting cross-invocation parallelism using runtime ... automatically exploiting cross-invocation parallelism using runtime ...
4.2 SPECCROSS Runtime System4.2.1 Misspeculation DetectionThe runtime system of SPECCROSS implements a software-only speculative barrier. Nonspeculativebarriers guarantee all code before a barrier executes before any code after thebarrier. Speculative barriers violate this guarantee to achieve higher processor utilizationand thus higher performance. However, to maintain the same semantics as non-speculativebarriers, speculative barriers check for runtime dependence violations. Upon detecting aviolation, the runtime system triggers a misspeculation and rolls back to non-speculativestate using the most recent checkpoint.SPECCROSS uses signature-based violation detection [12, 42, 68, 77], which avoidsthe overhead of logging each memory access. A signature is an approximate summary ofmemory accesses, providing a customizable tradeoff between signature size and false positiverates. SPECCROSS provides a general API for users to provide their own signaturegenerators. However, our experiments have shown very simple signatures are effective inpractice. By default, SPECCROSS summarizes the accesses by saving the minimum andmaximum addresses speculatively accessed. In this signature scheme, threads are independentif their signatures do not overlap. Range-based signature schemes work well whenmemory accesses are clustered. For random access patterns, a Bloom filter-based signatureoffers lower false positive rates.To determine when checking is needed, SPECCROSS assigns each thread an epoch numberand a task number. An epoch is defined as the code region between two consecutivespeculative barriers, and the epoch number counts how many speculative barriers a threadhas passed. A task is the smallest unit of work that can be independently assigned to athread, and the task number counts how many tasks a thread has executed since the lastbarrier. For many parallel programs, a task is one loop iteration. When a thread begins anew task, it reads the current epoch and task numbers of all other threads and later com-60
municates these numbers to the checker thread. The checker compares the task’s accesssignature with all signatures from epochs earlier than the signature’s epoch, but at least asrecent as the epoch-task number pair recorded when the task began. Signatures from thesame epoch are safely ignored since they are not separated by a barrier. This avoids unnecessarycomparisons between two tasks in the same epoch to reduce the runtime overheadof the checker thread.Figure 4.6 is a timing diagram for speculative barrier execution. In the timing diagram,a task marked as indicates that the thread updates its epoch number to A and tasknumber to B when the task starts executing. Epoch number-task number pairs are notunique across threads, since each thread counts tasks independently. When worker thread3 starts task , the other worker threads are still executing task in the secondepoch. The access signatures of these three tasks need to be checked against that of task. Before task finishes, all other threads have already begun the fourth epoch.As a result, the access signatures of task in threads 1, 2, and 4 and in thread4 need to be checked against that of task .Figure 4.7 shows the order of operations for worker threads. At the beginning of a task,the worker thread updates the epoch and task numbers, then records the current epoch andtask numbers for the other threads. Next, the worker executes the task. While executingthe task, the worker computes the memory access signature. Finally, the worker threadsaves its signature in a signature log and sends information to the checker thread so thechecker thread can detect misspeculation asynchronously. Figure 4.8 demonstrates the datastructure used for signature logging. Each worker threads has one thousand entries in thesignature log because checkpointing is operated every thousandth epochs. Worker threadssynchronize at the checkpoint and signature log entries can be re-used after checkpointing.Each entry of the signature log contains a pointer to an array used for saving signatureswithin a single epoch. The size of the array is initialized to store 1024 signatures andexpand if the number of tasks exceeds the array size. For 24 threads, this signature log61
- Page 24 and 25: 1.3 Dissertation OrganizationChapte
- Page 26 and 27: alias the array regular via inter-p
- Page 28 and 29: 1 for (i = 0; i < M; i++){2 node =
- Page 30 and 31: 1 cost = 0;2 node = list->head;3 Wh
- Page 32 and 33: example which cannot benefit from e
- Page 34 and 35: These techniques are referred to as
- Page 36 and 37: unnecessary overhead at runtime.Tab
- 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 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 88 and 89: CROSS, since SPECCROSS can be appli
- 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
4.2 SPECCROSS Runtime System4.2.1 Misspeculation DetectionThe <strong>runtime</strong> system of SPECCROSS implements a software-only speculative barrier. Nonspeculativebarriers guarantee all code before a barrier executes before any code after thebarrier. Speculative barriers violate this guarantee to achieve higher processor utilizationand thus higher performance. However, to maintain the same semantics as non-speculativebarriers, speculative barriers check for <strong>runtime</strong> dependence violations. Upon detecting aviolation, the <strong>runtime</strong> system triggers a misspeculation and rolls back to non-speculativestate <strong>using</strong> the most recent checkpoint.SPECCROSS uses signature-based violation detection [12, 42, 68, 77], which avoidsthe overhead of logging each memory access. A signature is an approximate summary ofmemory accesses, providing a customizable tradeoff between signature size and false positiverates. SPECCROSS provides a general API for users to provide their own signaturegenerators. However, our experiments have shown very simple signatures are effective inpractice. By default, SPECCROSS summarizes the accesses by saving the minimum andmaximum addresses speculatively accessed. In this signature scheme, threads are independentif their signatures do not overlap. Range-based signature schemes work well whenmemory accesses are clustered. For random access patterns, a Bloom filter-based signatureoffers lower false positive rates.To determine when checking is needed, SPECCROSS assigns each thread an epoch numberand a task number. An epoch is defined as the code region between two consecutivespeculative barriers, and the epoch number counts how many speculative barriers a threadhas passed. A task is the smallest unit of work that can be independently assigned to athread, and the task number counts how many tasks a thread has executed since the lastbarrier. For many parallel programs, a task is one loop iteration. When a thread begins anew task, it reads the current epoch and task numbers of all other threads and later com-60
Change language