automatically exploiting cross-invocation parallelism using runtime ...
automatically exploiting cross-invocation parallelism using runtime ... automatically exploiting cross-invocation parallelism using runtime ...
5.2 SPECCROSS Performance EvaluationEight programs are evaluated for SPECCROSS. As DOMORE evaluation, We comparedtwo parallel versions of these programs: (a) pthreads-based [9] parallelization with nonspeculativepthread barriers; and (b) pthreads-based parallelization with SPECCROSS.SPECCROSS is used with a pthreads-based implementation, since the recovery mechanismrelies on the properties of POSIX threads. For the performance measurements, the bestsequential execution of the parallelized loops is considered the baseline.For most of these programs, the parallelized loops account for more than 90% of theexecution time. When parallelizing using SPECCROSS, each loop iteration is regarded as aseparate task and the custom hash function used for calculating the access signatures keepstrack of the range of memory locations (or array indices) accessed by each task. This choiceis guided by the predominantly array-based accesses present in these programs. Each parallelprogram is first instrumented using the profiling functions provided by SPECCROSS.The profiling step recommends a minimum dependence distance value for use in speculativebarrier execution. All benchmark programs have multiple input sets. We chosethe training input set for profiling run. Table 5.3 shows the minimum dependence distanceresults for the evaluated programs using two different input sets (a training input set for profilingrun and another reference input set for performance run). Four of the eight programshad runtime dependences detected by profiling functions while the rest do not. The minimumdependence distance between two inner loops in program FLUIDANIMATE varies alot. Some of the loops do not cause any runtime access conflicts while others have a verysmall minimum dependence distance. For the latter case, SPECCROSS basically serves asa non-speculative barrier. The results of the profiling run were passed to speculative barrierexecution which used the minimum dependence distance value to avoid misspeculation.Figure 5.2 compares the speedups achieved by the parallelized loops using pthreadbarriers and SPECCROSS. It demonstrates the benefits of reducing the overhead in barriersynchronization. The best sequential execution time of the parallelized loops is considered82
# of MinimumBenchmark # of tasks # of epochs checking Distancerequests train refCG 63000 7000 40609 * *EQUAKE 66000 3000 55181 * *FDTD 200600 1200 96180 599 799FLUIDANIMATE-2 1379510 1488 295000 54 / * 54 / *JACOBI 99400 1000 67163 497 997LLUBENCH 110000 2000 81965 * *LOOPDEP 245000 1000 98251 500 800SYMM 500500 2000 369731 * *Table 5.3: Details of benchmark programs. * indicates no access conflicts are detected inprofiling.as the baseline. The original execution with pthread barriers does not scale well beyond asmall number of cores. Among the eight programs in barriers, CG performs the worst sinceeach of its epochs only contains nine iterations. With higher thread counts, the overheadcaused by barriers increases without any gains in parallelism.The speculative barrier solution provided by SPECCROSS enables all programs to scaleto higher thread counts when compared to an equivalent execution with pthread barriers.At lower thread counts, pthread barrier implementation for some programs yields betterperformance than SPECCROSS. This happens for two reasons: (a) SPECCROSS requires anextra thread for violation detection. At lower thread counts, one fewer thread is availableto do actual work which is significant when total number of threads is small; (b) the overheadof barrier synchronization increases with increasing thread counts. As a result, theeffectiveness of SPECCROSS is more pronounced at higher thread counts.In our evaluation, the program state is checkpointed once every 1000 epochs. For theeight programs evaluated, profiling results are accurate enough to result in high-confidencespeculation and no misspeculation is recorded at runtime. As a result, the operations thatcontribute to major runtime overheads include computing access signatures, sending checkingrequests, detecting dependence violation, and checkpointing.Table 5.3 shows for each program, the number of tasks executed, the number of epochs,83
- 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 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 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
# of MinimumBenchmark # of tasks # of epochs checking Distancerequests train refCG 63000 7000 40609 * *EQUAKE 66000 3000 55181 * *FDTD 200600 1200 96180 599 799FLUIDANIMATE-2 1379510 1488 295000 54 / * 54 / *JACOBI 99400 1000 67163 497 997LLUBENCH 110000 2000 81965 * *LOOPDEP 245000 1000 98251 500 800SYMM 500500 2000 369731 * *Table 5.3: Details of benchmark programs. * indicates no access conflicts are detected inprofiling.as the baseline. The original execution with pthread barriers does not scale well beyond asmall number of cores. Among the eight programs in barriers, CG performs the worst sinceeach of its epochs only contains nine iterations. With higher thread counts, the overheadcaused by barriers increases without any gains in <strong>parallelism</strong>.The speculative barrier solution provided by SPECCROSS enables all programs to scaleto higher thread counts when compared to an equivalent execution with pthread barriers.At lower thread counts, pthread barrier implementation for some programs yields betterperformance than SPECCROSS. This happens for two reasons: (a) SPECCROSS requires anextra thread for violation detection. At lower thread counts, one fewer thread is availableto do actual work which is significant when total number of threads is small; (b) the overheadof barrier synchronization increases with increasing thread counts. As a result, theeffectiveness of SPECCROSS is more pronounced at higher thread counts.In our evaluation, the program state is checkpointed once every 1000 epochs. For theeight programs evaluated, profiling results are accurate enough to result in high-confidencespeculation and no misspeculation is recorded at <strong>runtime</strong>. As a result, the operations thatcontribute to major <strong>runtime</strong> overheads include computing access signatures, sending checkingrequests, detecting dependence violation, and checkpointing.Table 5.3 shows for each program, the number of tasks executed, the number of epochs,83
Change language