1 / 15

Enhancing Automatic Parallelism by Exploiting Cross-Invocation Techniques

This study explores innovative strategies for automatic parallelization by exploiting cross-invocation parallelism using runtime information. We address the limitations of thread-level parallelism (TLP) and propose a method that minimizes barrier penalties through an advanced synchronization model. Our approach ensures fast, safe, robust, and graceful parallel execution across multicore systems, ultimately leading to improved performance with minimal misspeculation impacts. Through various examples, including case studies on algorithms like LLUBENCH and BLACKSCHOLES, we demonstrate substantial gains in execution efficiency.

spiro
Télécharger la présentation

Enhancing Automatic Parallelism by Exploiting Cross-Invocation Techniques

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automatically Exploiting Cross-Invocation Parallelism Using Runtime Information Jialu Huang, Thomas B. Jablin, Stephen R. Beard, Nick P. Johnson, and David I. August

  2. Parallel Resources (CPUs, Cores, …) hot_function(){ loop { work(i); } } Multicore “Free lunch” is over. Great successes in TLP. Missed opportunities… Automatic Parallelization? Time

  3. The Problem Parallel Resources (CPUs, Cores, …) hot_function(){ loop { work(i); } } 1st … loop { hot_function(); } … 2nd Synchronization necessary, but not the full barrier! Barrier Penalty! Time

  4. Parallel Resources (CPUs, Cores, …) 1st 2nd 2nd Savings

  5. Design Goals Parallel Resources (CPUs, Cores, …) Fast: exploit parallelism between invocations. Safe: fine-grained synchronization. Robust: insensitive to static analysis. Graceful: avoid misspeculation penalties. Automatic. 1st 2nd Savings

  6. Ideal Solution: outer-loop parallelism • Use it if you can. • Not always applicable. … loop { hot_function(); } …

  7. Not a solution: work stealing • Re-order iterations from different invocations. • Need synchronization for safety. Worker 1 Queue Worker 2 Queue Front A Y Z C X B Z Y C Z Rear

  8. Partial solution: speculation • Validation overhead in the common case (STM). • Performance degrades upon misspeculation. • Failure mode not probabilistic. Transactional memories Speculative lock elision

  9. Our approach • Isolate a scheduler thread. • Compute synchronization at runtime. • Scheduler directs workers to stop or go: • Worker T0: begin task i • Worker T1: wait for worker T0 to complete task i. • Workers avoid locks by publishing their progress.

  10. Parallel Resources (CPUs, Cores, …) Pipeline filling… Pipeline full. Wait

  11. The scheduler • Sequential execution without side-effects. • cf. Inspector-Executor[Salz et al. ‘91] • Shadow memory for efficient detection. • cf. Memory profiling • Acyclic communication. • cf. pipeline processors

  12. Separating the scheduler from the worker. Original Code loop: field = &ptr->next ptr = load field if( ptr == null ) goto exit body: call doWork(ptr) br loop exit: loop: field = &ptr->next ptr = load field if( ptr == null ) goto exit body: call doWork(ptr) br loop exit: loop: field = &ptr->next ptr = load field if( ptr == null ) goto exit body: call doWork(ptr) br loop exit: field field ptr ptr Reverse-slice of all pointers: Compute PDG Mark vertices that compute pointers Mark theirpredecessors, transitively Based on Multi-Threaded Code Generation [Ottoniet al. ’05] Replicate branches Add communication. Shadow memory checks if if br call Scheduler Worker loop: ptr = consume if( ptr == null) goto exit body: call doWork(ptr) br loop exit: loop: field = &ptr->next ptr = load field produce(ptr) if( ptr == null ) goto exit body: br loop exit:

  13. Dependence detection with shadow memory. Shadow Memory … ptr3→ ptr3→ ptr1→ ptr2→ T2, iter 2 T T0, iter 0 Iteration: 2 Iteration: 1 Iteration: 0 Iteration: 3 loop i { report_iter(i) report_store(ptr1) store tmp1 → ptr1 … report_load(ptr2) tmp2 = load ptr2 … report_load(ptr3) tmp3 = load ptr3 } ptr1→ T T0, iter 0 ptr2→ T T0, iter 0 ptr2→ T T1, iter 1 ptr1→ T1, iter 1 T Memory Address ptr2→ ptr1→ T T3, iter 3 ptr3→ ptr3→ T3, iter 3 T T1, iter1 … IPC Queues Worker T0 Scheduler GO: iteration 0 GO: iteration 1 Worker T1 GO: iteration 2 Wait: T0, iter 0 Worker T2 Worker T3 GO: iteration 3 Wait: T1, iter 1

  14. CG ECLAT MGRID Put it all together: how much does it help? LLUBENCH FLUIDANIMATE BLACKSCHOLES

  15. Conclusions • Lots of inter-invocation parallelism available. • Barrier penalty can be significant. • We can do better, automatically. http://liberty.princeton.edu/

More Related