automatically exploiting cross-invocation parallelism using runtime ...
automatically exploiting cross-invocation parallelism using runtime ... automatically exploiting cross-invocation parallelism using runtime ...
checkpoint, the child spawns new worker threads, and each newly spawned thread executeslongjmp to inherit the program state of an original thread.SPECCROSS explicitly allocates worker threads’ stacks to ensure they will not be deallocatedby fork.This is necessary, because the POSIX standard allows processes todeallocate the stacks of associated threads after forking. Explicitly allocating the workerthreads’ stacks ensures that longjmp will restore a valid stack.Experiments show recovering from misspeculation requires about one millisecond.The execution time for recovering non-speculative state is dominated by the kill andclone syscalls. The main thread invokes kill to asynchronously terminate misspeculatingthreads and awaken the checkpoint process, then invokes clone (internally calledby pthread create) to create new worker threads. The number of syscalls scales linearlywith the number of threads, but performance is not affected by the program’s memoryfootprint or the size of speculative state.Some epochs contain irreversible operations (for example I/O) which must be executednon-speculatively. Before entering an irreversible epoch, all worker and checker threadssynchronize. Just like checkpointing, synchronizing all threads ensures non-speculativeexecution. After exiting the irreversible region, the program checkpoints. Otherwise, latermisspeculation could cause the irreversible region to be repeated.There are three conditions which trigger misspeculation. First, the checker thread triggersmisspeculation if it finds a pair of conflicting signatures. Second, misspeculationoccurs if any of the worker threads triggers a segmentation fault. Third, misspeculationcan be triggered in response to a user defined timeout. Timeouts are necessary, since speculativeupdates to the shared memory may change the exit condition of a loop and causeinfinite execution. After detecting misspeculation, the most recent checkpoint is restored.After restoring the checkpoint, the misspeculated epochs are re-executed with all speculativebarriers replaced with their non-speculative counterparts.64
4.2.3 Runtime InterfaceThis section describes the runtime interface exposed by SPECCROSS. Table 4.1 lists theinterface functions along with a short description of each function’s semantics. Figure 4.9shows an instantiation of these functions in a parallel program which will serve as a runningexample. In the example, each inner loop invocation is treated as an epoch, and each innerloop iteration is considered a task. SPECCROSS provides the same interface functions forboth profiling and speculation purposes. As a result, these function calls only need to beinserted once for both profiling run and speculative execution. Whether to do profilingor speculation is decided by defining the environment variable MODE. Depending on thecurrent MODE, functions will either speculate or profile. The MODE value can also be set toNON-SPECULATIVE. In non-speculative mode, most interface functions do nothing andspeculative barriers are replaced with non-speculative ones. This non-speculative mode isenabled when re-executing the misspeculated epochs after recovering from misspeculation.The details of SPECCROSS’s profiling and speculation functions are as follows:65
- 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 74 and 75: 4.2 SPECCROSS Runtime System4.2.1 M
- Page 76 and 77: takes up to 200MB memory space.To d
- 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
checkpoint, the child spawns new worker threads, and each newly spawned thread executeslongjmp to inherit the program state of an original thread.SPECCROSS explicitly allocates worker threads’ stacks to ensure they will not be deallocatedby fork.This is necessary, because the POSIX standard allows processes todeallocate the stacks of associated threads after forking. Explicitly allocating the workerthreads’ stacks ensures that longjmp will restore a valid stack.Experiments show recovering from misspeculation requires about one millisecond.The execution time for recovering non-speculative state is dominated by the kill andclone syscalls. The main thread invokes kill to asynchronously terminate misspeculatingthreads and awaken the checkpoint process, then invokes clone (internally calledby pthread create) to create new worker threads. The number of syscalls scales linearlywith the number of threads, but performance is not affected by the program’s memoryfootprint or the size of speculative state.Some epochs contain irreversible operations (for example I/O) which must be executednon-speculatively. Before entering an irreversible epoch, all worker and checker threadssynchronize. Just like checkpointing, synchronizing all threads ensures non-speculativeexecution. After exiting the irreversible region, the program checkpoints. Otherwise, latermisspeculation could cause the irreversible region to be repeated.There are three conditions which trigger misspeculation. First, the checker thread triggersmisspeculation if it finds a pair of conflicting signatures. Second, misspeculationoccurs if any of the worker threads triggers a segmentation fault. Third, misspeculationcan be triggered in response to a user defined timeout. Timeouts are necessary, since speculativeupdates to the shared memory may change the exit condition of a loop and causeinfinite execution. After detecting misspeculation, the most recent checkpoint is restored.After restoring the checkpoint, the misspeculated epochs are re-executed with all speculativebarriers replaced with their non-speculative counterparts.64
Change language