automatically exploiting cross-invocation parallelism using runtime ...
automatically exploiting cross-invocation parallelism using runtime ... automatically exploiting cross-invocation parallelism using runtime ...
Source Benchmark Function % of execution Parallelization DOMORE SPECCROSSsuite program time plan for inner loop applicable applicableFDTD main 100 DOALL × ̌PolyBench [54] JACOBI main 100 DOALL × ̌SYMM main 100 DOALL ̌ ̌OMPBench [20] LOOPDEP main 100 DOALL × ̌BLACKSCHOLES bs thread 99 Spec-DOALL ̌ ×Parsec [6]FLUIDANIMATE-1 ComputeForce 50.2 LOCALWRITE ̌ ×FLUIDANIMATE-2 main 100 LOCALWRITE × ̌SpecFP [69] EQUAKE main 100 DOALL × ̌LLVMBENCH [37] LLUBENCH main 50.0 DOALL ̌ ̌NAS [48] CG sparse 12.2 LOCALWRITE ̌ ̌MineBench [46] ECLAT process inverti 24.5 Spec-DOALL ̌ ×Table 5.1: Details about evaluated benchmark programs.Benchmark Program % of Scheduler/WorkerBLACKSCHOLES 4.5CG 4.1ECLAT 12.5FLUIDANIMATE-1 21.5LLUBENCH 1.7SYMM 1.5Table 5.2: Scheduler/worker ratio for benchmarksable to achieve better or at least competitive performance results than previous works. Thenin section 5.4, we provide a detailed case study of program FLUIDANIMATE, whose performanceimprovement requires the integration of both DOMORE and SPECCROSS techniques.Finally, a discussion is given in section 5.5 about the next step to be done to furtherimprove the applicability of the Liberty parallelizing compiler infrastructure.5.1 DOMORE Performance EvaluationSix programs are chosen to evaluate the DOMORE system (as shown in Table 5.1). Wecompare the performance of inner loop parallelization with pthread barriers [9] with theperformance of outer loop parallelization with DOMORE. Figure 5.1 shows the evaluationresults for the outer loop speedup relative to the best sequential execution. For the originalparallelized version with pthread barriers between inner loop invocations, none scalebeyond a small number of cores. DOMORE shows scalable performance improvements78
for CG, LLUBENCHMARK and BLACKSCHOLES because their scheduler threads arequite small compared to the worker threads (< 5% runtime, as shown in Table 5.3) andprocessor utilization is high. ECLAT, FLUIDANIMATE and SYMM do not show as muchimprovement. The following paragraphs provide details about those programs.ECLAT from MineBench [46] is a data mining program using a vertical database format.The target loop is a two-level nested-loop. The outer loop traverses a graph of nodes.The inner loop traverses a list of items in each node and appends each item to correspondinglist(s) in the database based upon on the item’s transaction number. Since two items mightshare the same transaction number, and the transaction number is calculated non-linearly,static analysis cannot determine the dependence pattern. Profiling information shows thatthere is no dynamic dependence in the inner loop. For the outer loop, the same dependencemanifests in each iteration (99%). As a result, Spec-DOALL is chosen to parallelize theinner loop and a barrier is inserted after each invocation. Spec-DOALL achieves its peakspeedup at 3 cores. For DOMORE, a relatively large scheduler thread (12.5% scheduler/-worker ratio) limits scalability. As we can see in Figure 5.1, DOMORE achieves scalableperformance up to 5 processors. After that, the sequential code becomes the bottleneck andno more speedup is achieved.FLUIDANIMATE from the PARSEC [6] benchmark suite uses an extension of theSmoothed Particle Hydrodynamics (SPH) method to simulate an incompressible fluid forinteractive animation purposes. The target loop is a six-level nested-loop. The outer loopgoes through each particle while an inner loop goes through the nearest neighbors of thatparticle. The inner loop calculates influences between the particle and its neighbors andupdates all of their statuses. One particle can be neighbor to multiple particles, resultingin statically unanalyzable update patterns. LOCALWRITE chooses to parallelize the innerloop to attempt to reduce some of the computational redundancy. Performance resultsshow that parallelizing the inner loop does not provide any performance gain. Redundantcomputation and barrier synchronizations negate the benefits of parallelism. DOMORE is79
- 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 88 and 89: CROSS, since SPECCROSS can be appli
- Page 90 and 91: techniques.Synchronization via sche
- 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
Source Benchmark Function % of execution Parallelization DOMORE SPECCROSSsuite program time plan for inner loop applicable applicableFDTD main 100 DOALL × ̌PolyBench [54] JACOBI main 100 DOALL × ̌SYMM main 100 DOALL ̌ ̌OMPBench [20] LOOPDEP main 100 DOALL × ̌BLACKSCHOLES bs thread 99 Spec-DOALL ̌ ×Parsec [6]FLUIDANIMATE-1 ComputeForce 50.2 LOCALWRITE ̌ ×FLUIDANIMATE-2 main 100 LOCALWRITE × ̌SpecFP [69] EQUAKE main 100 DOALL × ̌LLVMBENCH [37] LLUBENCH main 50.0 DOALL ̌ ̌NAS [48] CG sparse 12.2 LOCALWRITE ̌ ̌MineBench [46] ECLAT process inverti 24.5 Spec-DOALL ̌ ×Table 5.1: Details about evaluated benchmark programs.Benchmark Program % of Scheduler/WorkerBLACKSCHOLES 4.5CG 4.1ECLAT 12.5FLUIDANIMATE-1 21.5LLUBENCH 1.7SYMM 1.5Table 5.2: Scheduler/worker ratio for benchmarksable to achieve better or at least competitive performance results than previous works. Thenin section 5.4, we provide a detailed case study of program FLUIDANIMATE, whose performanceimprovement requires the integration of both DOMORE and SPECCROSS techniques.Finally, a discussion is given in section 5.5 about the next step to be done to furtherimprove the applicability of the Liberty parallelizing compiler infrastructure.5.1 DOMORE Performance EvaluationSix programs are chosen to evaluate the DOMORE system (as shown in Table 5.1). Wecompare the performance of inner loop parallelization with pthread barriers [9] with theperformance of outer loop parallelization with DOMORE. Figure 5.1 shows the evaluationresults for the outer loop speedup relative to the best sequential execution. For the originalparallelized version with pthread barriers between inner loop <strong>invocation</strong>s, none scalebeyond a small number of cores. DOMORE shows scalable performance improvements78
Change language