1. View-Oriented Parallel Programming for multi-core systems Dr Zhiyi Huang World 45 Univ of Otago

2. An age of CMT • CMT offers us the power of parallel computing • To harness the power relies on good parallel applications and competent parallel programmers • Sound parallel programming methodology is the key

3. Two camps • Message passing vs. shared memory • Message passing style is complex • Communication with shared memory is simple and easy, but…

4. Problems for SM-based PP (1) • Data race condition is a pain • Data race: there are concurrent accesses to the same memory location, and at least one of them is write access • To debug a data race condition is difficult since a parallel execution is normally not repeatable

5. Problems for SM-based PP (2) • Deadlock is another pain • Mutual exclusive primitives such as locks are required to prevent data races, but • it may result in deadlock, a situation where multiple threads/processes wait for each other due to competing for locks • Mutual exclusion has complicated the mental model of parallel programming

6. Problems for SM-based PP (3) • Poor portability is yet another pain • Parallel applications are system dependent • Mutual exclusive primitives such as lock are not standardized • Synchronization primitives such as barrier are not standardized • Shared memory allocation is not standardized

7. Solutions? • A parallel programming style with the following features • Data race free • Mutual exclusion free • Deadlock free • Portable to any systems with shared memory

8. View-Oriented Parallel Programming

9. What is a view? • Suppose M is the set of data objects in shared memory • A view is a group of data objects from the shared memory •  V, VM • Views must not overlap each other •  Vi, Vj, i  j, Vi  Vj =  • Suppose there are n views in shared memory • ∑ Vi=M

10. VOPP Requirements • The programmer should divide the shared data into a number of views according to the data flow of the parallel algorithm. • A view should consist of data objects that are always processed as an atomic set in a program. • Views can be created and destroyed anytime. • Each view has a unique view identifier

11. VOPP Requirements (cont.) • View primitives such as acquire_view and release_view must be used when a view is accessed. acquire_view(View_A); A = A + 1; release_view(View_A); • acquire_Rview and release_Rview can be used when a view is only read by a processor.

12. VOPP Requirements (cont.) • When a process/thread accesses multiple views at the same time, only one acquiring primitive is used. acquire_3_views(V_A, V_B, V_C); C = A + B; release_views();

13. Example • A VOPP program for a producer/consumer problem If(prod_id == 0){ acquire_view(1); produce(x); release_view(1); } barrier(0); acquire_Rview(1); consume(x); release_Rview(1);

14. VOPP features • No concern of data race condition • The programmer is only concerned about views, not mutual exclusion • Mutual exclusion is implemented by the system which detects potential data races as well by checking view boundaries • Deadlock free • Mutual exclusion is implemented by the system and can be implemented data race free and deadlock free • Portability? • By standardization of API

15. Requirements for the system • Keep track of view locations • Capable to check view boundaries • Guarantee deadlock free when implementing mutual exclusion

16. Advantages of VOPP • Keep the convenience of shared memory programming • Focus on data partitioning and data access instead of data race and mutual exclusion • View primitives automatically achieve mutual exclusion • View primitives are not extra burden • The programmer can finely tune the parallel algorithm by careful view partitioning

17. Advantages of VOPP (cont.) • Implementation independent • View access can be based on mutual exclusion or Transactional Memory (TM) • TM is a memory system that checks access conflicts • Programming language independent • Can be implemented as a user space library • Performance advantage • Cache pre-fetching when a view is acquired • Can cache a view until the view is not acquired by any other threads/processes

18. Philosophy of VOPP • Shared memory is a critical resource that needs to be used with care • If there is no need to use shared memory, don’t use it • Justification is wanted before a view is created • Compatible with Throughput Computing which encourages multiple independent threads running in a chip

19. VOPP vs. MPI • Easier for programmers than MPI • For problems like task queue, programming with MPI is horrific. • Can mimic any finely-tuned MPI program • Shared message  view • Send/recv  acquire_view • Essential differences • View is location transparent • More barriers in VOPP

20. Implementation • VOPP is supported by our DSM system called VODCA • DSM: Distributed Shared Memory system provides a virtual shared memory on multi-computers • VODCA: View-Oriented, Distributed, Cluster-based Approach to parallel computing • VODCA version 1.0 • Will be released as an open source software • A library run at the user space • Its implementation will be published on DSM06

21. Experiment • Use a cluster computer • The cluster computer, in Tsinghua Univ., consists of 128 Itanium 2 running Linux 2.4, connected by InfiniBand. Each node has two 1.3 GHz processors and 4 Gbytes RAM. We run two processes on each node. • We used four applications, Integer Sort (IS), Gauss, Successive Over-Relaxation (SOR), and Neural Network (NN).

22. Related systems • TreadMarks (TMK) is a state-of-the-art Distributed Shared Memory system based on traditional parallel programming. • Message Passing Interface (MPI) is a standard for message passing-based parallel programming. We used LAM/MPI.

23. Performance of NN

24. Performance of IS

25. Performance of SOR

26. Performance of Gauss

27. Future work on VOPP • API for multi-core systems • Implementation on Niagara • More benchmarks/applications, especially telecommunication applications • Performance evaluation on CMT • A view-based debugger for VOPP

28. Questions?