Identifying Inter-task Communication in Shared Memory Programming Models. Per Larsen, Sven Karlsson and Jan Madsen

Size: px

Start display at page:

Download "Identifying Inter-task Communication in Shared Memory Programming Models. Per Larsen, Sven Karlsson and Jan Madsen"

Sheena Banks
6 years ago
Views:

1 Identifying Inter-task Communication in Shared Memory Programming Models Per Larsen, Sven Karlsson and Jan Madsen

2 Motivation Identifying dependencies between serial parts of OpenMP programs is necessary to derive task graphs compiler analysis by itself is insufficient directives is an alternative Use example 1 to demonstrate limits of program analysis, and show potential of programmer declarations struct list {int data; list *next}; list *createlist(void); void processlist(list *l); void splitclone(list *l, list **a, list **b); int main(void) { list *l, *a, *b; l = createlist(); splitclone(l, &a, &b); #pragma omp parallel sections { #pragma omp section processlist(a); #pragma omp section processlist(b); } } main proc a 1. example was adapted from C. Lattner, et al. Data-Structure Analysis, PLDI '05? proc b 2 DTU Informatics, Technical University of Denmark

3 Aliasing If two symbols refer to the same memory location, they are said to be aliases. focus of this talk! *p There are two major sources of aliasing: pointers and arrays. *q future work a[i] a[j] 3 DTU Informatics, Technical University of Denmark

4 Aliasing in the SplitClone Example 1) different aliases are created on different paths struct list {int data; list *next}; list *createlist(void); void processlist(list *l); void splitclone(list *l, list **a, list **b) { } if(l == NULL) { a = b = NULL; return; } if(pred){ *a = l; splitclone(l->next,&(*a)->next,b);} else { *b = l; splitclone(l->next,a,&(*b)->next);} int main(void) { } list *l, *a, *b; l = createlist(); splitclone(l, &a, &b); #pragma omp parallel sections { } #pragma omp section processlist(a); #pragma omp section processlist(b); 2) different aliases are created on different call sites simple example requires alias analysis more advanced than those used in production compilers! - and - alias results will always be approximate due to undecidability! 4 DTU Informatics, Technical University of Denmark

5 Outline Motivation Aliasing Task graph extraction from OpenMP programs Using directives to specify dependencies Runtime checking approach cost Wrap-up 5 DTU Informatics, Technical University of Denmark

6 Task Graph Synthesis from OpenMP Programs serial code goal: avoid over-approximating data dependencies when synthesizing task graphs control flow dependencies task data dependencies τ 1 τ 2 τ 3 τ 4 τ 5 τ 6 τ 7 τ 8 6 DTU Informatics, Technical University of Denmark compiler analysis conservatively creates superfluous dependencies

7 Superfluous dependencies leads to poor mapping choices the two solutions seem equally good to mapping tool... (assuming all dependencies have equal weights) τ 1 τ 1 τ 2 τ 3 τ 2 τ 3 τ 4 τ 5 τ 4 τ 5 τ 6 τ 7 τ 6 τ 7 processor 0 τ 8 leftmost solution clearly achieves better data-locality τ 8 processor 1 7 DTU Informatics, Technical University of Denmark

8 SplitClone Example with Declarations goal: compute data-dependencies between tasks at compile-time struct list {int data; list *next}; list *createlist(void); void processlist(list *l); void splitclone(list *l, list **a, list **b); label each task and use the labels to describe dependencies among tasks - variables may alias - labels may not! #pragma dep main out(a,proc_a) out(b,proc_b) int main(void) { } list *l, *a, *b; l = createlist(); splitclone(l, &a, &b); #pragma omp parallel sections { } #pragma dep proc_a in(a,main) #pragma omp section processlist(a); #pragma dep proc_b in(b,main) #pragma omp section processlist(b); 8 DTU Informatics, Technical University of Denmark

9 Runtime Checks of Declarations goal: detect mismatch between declarations and observable program behavior: mark objects as: 1) output of task main 2) input of task proc_a check that objects are: 1) originating from task main 2) destined for proc_a struct list {int data; list *next}; list *createlist(void); void processlist(list *l); void splitclone(list *l, list **a, list **b) { if(l == NULL) { a = b = NULL; return; } if(pred){ *a = l; splitclone(l->next,&(*a)->next,b);} else { *b = l; splitclone(l->next,a,&(*b)->next);} } #pragma dep main out(a,proc_a) out(b,proc_b) int main(void) { list *l, *a, *b; l = createlist(); splitclone(l, &a, &b); #pragma omp parallel sections { #pragma dep proc_a in(a,main) #pragma omp section processlist(a); #pragma dep proc_b in(b,main) #pragma omp section processlist(b); } } 9 DTU Informatics, Technical University of Denmark

10 Runtime Operations Runtime operations all access a global hash table which associates pointers (addresses) with the tasks that read and write them. Synchronization is necessary since modifications may happen concurrently. operation arguments read-lock write-lock check_input ptr, curr_task check_output ptr, curr_task register_input ptr, tasks_reading_ptr ( ) register_output ptr, tasks_writing_ptr ( ) update_input ptr, tasks_reading_other_ptr ( ) update_output ptr, tasks_reading_other_ptr ( ) unregister ptr 10 DTU Informatics, Technical University of Denmark

11 Micro-benchmark of Runtime Operations Testbench: Intel Core i7 920, Ubuntu Linux 8.10, gcc 4.3.2, -O2 execution time in microseconds Overhead can be small compared to the cost of entering a parallel section 11 DTU Informatics, Technical University of Denmark

12 Overhead in NPB Integer Sort Benchmark [4] Benchmark kernel performing large integer sort on arrays Important operation in particle method codes [5] We conservatively overestimate dependencies between tasks working on the same array, as data-decomposition is left for future work [4] H. Jin, et al. NPB-OpenMP 3.0, 1999 [5] D. H. Bailey, et al. The NAS Parallel Benchmarks, DTU Informatics, Technical University of Denmark

13 Overhead in Integer Sort Benchmark Cont'd Testbench: Intel Core i7 920, Ubuntu Linux 8.10, gcc 4.3.2, -O2 Code contains: 5 parallel sections 7 barriers Corresponds to 12 tasks Eight pointers to objects shared between tasks Runtime calls: 19 to check_input 11 to check_output 19 for initialization...no measurable overhead! (used GNU time utility and averages from 30 runs) 13 DTU Informatics, Technical University of Denmark

14 Summary Applicability of compiler analysis in extracting task graphs has practical as well as theoretical limitations Programmer declarations can address problem of pointer aliasing Programmer must think carefully about data sharing - so why not document this in the source code? Benchmarks indicate that the overhead of runtime checks can be acceptable We are currently extending our work to handle data-decomposition 14 DTU Informatics, Technical University of Denmark

15 Questions Thanks for your attention! Reach me at 15 DTU Informatics, Technical University of Denmark

16 Program Analysis is Inevitably Approximate Determining which statements are executable in a program is undecidable [1] Control-flow assumption Approximation by compile time analysis [1] H. G. Rice, Classes of Recursively Enumerable Sets and Their Decision Problems, Trans. of AMS, 1953 [2] G. Ramalingam, undecidability of aliasing, TOPLAS 1994 Actual behavior of programs w/o pointers and arrays 16 DTU Informatics, Technical University of Denmark

17 Program Analysis is Inevitably Approximate Determining which statements are executable in a program is undecidable [1] Control-flow assumption Determining the targets of pointers is undecidable [2] even under the control-flow assumption Approximation by compile time analysis [1] H. G. Rice, Classes of Recursively Enumerable Sets and Their Decision Problems, Trans. of AMS, 1953 [2] G. Ramalingam, undecidability of aliasing, TOPLAS 1994 Actual behavior of programs with pointers and arrays 17 DTU Informatics, Technical University of Denmark

18 Program Analysis is Inevitably Approximate Determining which statements are executable in a program is undecidable [1] Control-flow assumption Determining the targets of pointers is undecidable [2] even under the control-flow assumption Arbitrary type conversions means that pointers can point almost anywhere Strong typing can be used at the cost of some efficiency Approximation by compile time analysis [1] H. G. Rice, Classes of Recursively Enumerable Sets and Their Decision Problems, Trans. of AMS, 1953 [2] G. Ramalingam, undecidability of aliasing, TOPLAS 1994 Actual behavior of programs with weak typing, pointers and arrays 18 DTU Informatics, Technical University of Denmark

19 Trade-offs in runtime checking pointerbased data structures check = O(n) split = O(1) update = O(n) check = O(n) split = O(1) update = O(1) *part *part check = O(1) split = O(n) update = O(1) permissions C object check = O(1) split = O(1) update = O(1) part objects can only cross task boundaries as part of a non-part object 19 DTU Informatics, Technical University of Denmark

20 Runtime Operations Pseudocode hashtable: ptr ptr_permissions ptr_permissions: (readers: set, writers: set) # tasks are compile time constants so # the function below can be precomputed def all_writers(task) return decl_writers(task) post_writers(task) def check_input(ptr, curr_task) acquire_read_lock() (readers, writers) = hashtable[ptr] if not(readers.contains(curr_task)) or writers eq all_writers(curr_task) raise_error() release_read_lock() def get_or_insert(ptr) : ptr_permissions acquire_read_lock() if hashtable.contains(ptr) release_read_lock() else upgrade_to_write_lock() hashtable[ptr] = (, ) release_write_lock() return hashtable[ptr] def register_input(ptr, decl_writers) (readers, writers) = get_or_insert(ptr) hashtable[ptr].writers = decl_writers def update_input(ptr, decl_writers_of_ptr2) (readers, writers) = get_or_insert(ptr) hashtable[ptr].writers decl_writers_of_ptr2 20 DTU Informatics, Technical University of Denmark

21 Task Graph Synthesis from OpenMP Programs serial fragment control-flow dependencies task τ 1 data dependencies τ 2 τ 3 τ 4 τ 5 parallel region τ 6 τ 7 τ 8 τ 9 barriers τ 10 challenge: determine data-dependencies between tasks in the presence of aliasing 21 DTU Informatics, Technical University of Denmark

22 Points-to Analysis Computes aliasing relations between pointers at compile time. Points-to analysis is undecideable [1] if language supports: if statements, loops, dynamic storage and recursive data structures [1] G. Ramalingam, undecideability of aliasing, TOPLAS 1994 [2] accessed 11/03/09 Language popularity [2] 22 DTU Informatics, Technical University of Denmark

Identifying Inter-task Communication in Shared Memory Programming Models

Identifying Inter-task Communication in Shared Memory Programming Models Per Larsen, Sven Karlsson, and Jan Madsen DTU Informatics Technical University of Denmark {pl,ska,jan}@imm.dtu.dk Abstract. Modern