Challenges for synchronization and scalability on manycore: a Software Transactional Memory approach

Transcription

1 Challenges for synchronization and scalability on manycore: a Software Transactional Memory approach Maurício Lima Pilla André Rauber Du Bois Adenauer Correa Yamin Ana Marilza Pernas Fleischmann Gerson Geraldo Homrich Cavalheiro Renata Hax Sander Reiser Laboratory of Ubiquitous and Parallel Systems Federal University of Pelotas pilla@inf.ufpel.edu.br March 2015 Manycore of 40

2 INTRODUCTION Manycore of 40

3 Introduction Rise of Multicore/Manycore processors Hard to code Usage of locks becomes complex Deadlocks Software composition Transactional Memories (TM) Access to shared memory inside transactions Similar to those of databanks Manycore of 40

4 TRANSACTIONAL MEMORY S BASICS Manycore of 40

5 Properties Atomicity Consistency Isolation Durability Manycore of 40

6 Transactional Memory Constructs Atomic Declares that operations must be executed in an atomic way Retry If transaction cannot be executed, try again later when variable changes atomic { } i f ( l a s t == 0) r e t r y ; l a s t ; r e t u r n b u f f e r [ l a s t ] ; Manycore of 40

7 TM Constructs OrElse Alternative transaction if first one fails atomic { } { x = b u f f e r 1. remove ( ) ; } orelse { x = b u f f e r 2. remove ( ) ; } Manycore of 40

8 Locks x Transactions Suppose a global counter bool m; / / mutex lock (&m) counter : = counter + 1 unlock(&m) atomic { counter : = counter + 1 } Manycore of 40

9 Composing Software What can go wrong? v = hash1. d e l e t e (A) ; hash2. i n s e r t (A, v ) ; Use an extra lock? What if we insert into another hash, like hash3? Manycore of 40

10 Composing Software with STM The Atomic keyword atomic { } v = hash1. d e l e t e (A) ; hash2. i n s e r t (A, v ) ; Runtime is responsible for making it atomic Manycore of 40

11 PROJECT DIMENSIONS (OR THE KNOBS WE CAN TWIST) Manycore of 40

12 Classification of TMs Originally a hardware concept Hardware Transactional Memory Software Transactional Memory Hibrid Transactional Memory Transactional Synchronization Extensions (TSX) on Intel s Haswell processors Uses cache coherence protocol Bug fixed in later Broadwell processors Manycore of 40

13 Isolation Levels Related to the interaction between transactional and non-transactional codes Strong Atomicity Accesses outside transactions are consistent with accesses inside them Weak Atomicity Accesses to shared data outside transactions may cause race conditions Manycore of 40

14 Implementation Two mechanisms are basic to provide atomicity, consistency, and isolation Conflict Detection and Resolution Detects if two or more transactions conflict (race condition) Then, ideally one of them will succeed Data Versioning Original and speculative data Manycore of 40

15 Conflict Granularity Different granularities for detecting conflicts Objects Less overhead Allows for detection of false conflicts Word More overhead No false conflicts (unless variables are smaller than words) Cache line Compromise Requires hardware support (Intel) False conflicts if variables in the same cache line or even in another Challenges for synchronization set and scalability on manycore: a Software Transactional Memory approach Manycore of 40

16 Conflict Detection Early Detection Also called Pessimistic Everytime there is an access, conflicts are checked If check fails, stop there Late Detection Or Optimistic Verifies for conflicts in the end of the transaction Manycore of 40

17 Early Detection Trans1 read A Trans2 Trans1 read A Trans2 Trans1 read A write A Trans2 time commit write C write B commit disjunct data sets, no conflicts abort commit write A commit conflict and restart of transaction 1 abort abort read A write A read A write A read A write A livelock abort Manycore of 40

18 Late Detection Trans1 read A Trans2 Trans1 write A Trans2 Trans1 read A Trans2 write B read A write A time write C commit commit read A abort commit commit commit commit disjunct data sets, no conflicts conflict and restart of transaction 1 no conflicts Manycore of 40

19 Late Detection Trans1 read A write A read A write A Trans2 Trans3 abort read A write A commit read A write A commit abort conflicts, may cause starvation if transaction keeps getting aborted by shorter ones Manycore of 40

20 Contention Manager Decides what to do in case of conflict Must guarantee progress Timid Avoiding starvation Avoiding livelock (when transactions keep avoiding one to be committed) Aborts transactions that generated a conflict Backoff Freezes a transaction for a while Greedy Oldest transaction continues execution Manycore of 40

21 Data Versioning Eager Versioning Variables are modified in place with speculative data Original values are copied to an undo log Lazy Versioning Speculative data are stored in a buffer Only committed data are stored in the variables Manycore of 40

22 Examples of Data Versioning E A G E R data x:10 undo log transaction writes 77 x:77 x:10 commit x:77 x:10 abort x:10 x:10 Manycore of 40

23 Examples of Data Versioning E A G E R data x:10 undo log transaction writes 77 x:77 x:10 commit x:77 x:10 abort x:10 x:10 commit L A Z Y data x:10 buffer transaction writes 77 x:10 x:77 x:77 x:77 abort x:10 x:77 Manycore of 40

24 STM Libraries STM Versioning Conflict Detection Contention Manager AdaptSTM Eager (low contention) Early Timid (low contention) Lazy (high contention) Expon. backoff (high cont.) SwissTM Lazy Early (write-write) Timid (shor trans. and reads) Late (read-write) Linear backof (write-write) TinySTM Lazy Early Timid TL2 Lazy Late Timid Linear backoff (after 3 aborts) Manycore of 40

25 EXPERIMENTS Manycore of 40

26 Objectives Find out how different STM libraries behave in terms of performance and energy Different contention scenarios Number of threads in excess of cores Scalability trends Manycore of 40

27 Benchmarks STAMP Stanford Transactional Applications for Multi-Processing Minh et al, IISWC 2008 Set of 8 applications Portable Widely used for evaluation of STMs Manycore of 40

28 Characteristics of STAMP Apps Application Transaction Read-write Time in Contention length set transactions Genome Medium Medium High Low Intruder Short Medium Medium High Kmeans Short Small Low Low Labyrinth Long Large High High Vacation Medium Medium High Medium Yada Long Large High Medium Manycore of 40

29 CHARACTERIZATION OF PERFORMANCE AND ENERGY Manycore of 40

30 Simulation Environment SGI Altix with two Xeon E5620 (4 cores plus HT), 6 GB RAM Baseboard Management Controler (BMC) data for energy extracted using FreeIPMI SUSE Linux SP11, GNU G to 64 threads Each experiment was executed 10 times Manycore of 40

31 Execution time (seconds) Energy consumption (Joules) Introduction Basics Project Dimensions Results Current and Future Work genome TL2 TinySTM SwissTM AdaptSTM TL2 TinySTM SwissTM AdaptSTM Threads Threads Manycore of 40

32 Execution time (seconds) Energy consumption (Joules) Introduction Basics Project Dimensions Results Current and Future Work intruder TL2 TinySTM SwissTM AdaptSTM TL2 TinySTM SwissTM AdaptSTM Threads Threads High contention. Manycore of 40

33 Execution time (seconds) Energy consumption (Joules) Introduction Basics Project Dimensions Results Current and Future Work kmeans TL2 TinySTM SwissTM AdaptSTM TL2 TinySTM SwissTM AdaptSTM Threads Threads Manycore of 40

34 Execution time (seconds) Energy consumption (Joules) Introduction Basics Project Dimensions Results Current and Future Work labyrinth TL2 TinySTM SwissTM AdaptSTM TL2 TinySTM SwissTM AdaptSTM Threads Threads Manycore of 40

35 Execution time (seconds) Energy consumption (Joules) Introduction Basics Project Dimensions Results Current and Future Work vacation-high TL2 TinySTM SwissTM AdaptSTM TL2 TinySTM SwissTM AdaptSTM Threads Threads Manycore of 40

36 Execution time (seconds) Energy consumption (Joules) Introduction Basics Project Dimensions Results Current and Future Work yada TL2 TinySTM SwissTM AdaptSTM TL2 TinySTM SwissTM AdaptSTM Threads Threads High contention. Manycore of 40

37 Discussion TL2 presents lowest conflict rate grow Followed by AdaptSTM, SwissTM, TinySTM AdaptSTM shows better scalability for short transactions Exponential backoff is good for higher contention SwissTM is better for longer transactions Greedy contention manager, late conflict detection for r-w TL2 is better for long transactions and more than low contention Late conflict detection TinySTM is efficient for small abort rates Timid contention manager Manycore of 40

38 Discussion TL2 presents lowest conflict rate grow Followed by AdaptSTM, SwissTM, TinySTM AdaptSTM shows better scalability for short transactions Exponential backoff is good for higher contention SwissTM is better for longer transactions Greedy contention manager, late conflict detection for r-w TL2 is better for long transactions and more than low contention Late conflict detection TinySTM is efficient for small abort rates Timid contention manager Borderline No one excels in all cases! Manycore of 40

39 CURRENT AND FUTURE WORK Manycore of 40

40 Current and Future Work on Manycore at UFPEL Optimization of STM libraries for higher number of cores/threads Better benchmarks for higher number of cores? STMs for Distributed Memory/Cloud Study and adaptation of STM behavior over future memory technologies (Phase-Change Memory) Scheduling for manycore (Anahy) Quantum Computing simulation on manycore/gpus/clusters/cloud/toasters Manycore of 40

41 Current and Future Work on Manycore at UFPEL Optimization of STM libraries for higher number of cores/threads Better benchmarks for higher number of cores? STMs for Distributed Memory/Cloud Study and adaptation of STM behavior over future memory technologies (Phase-Change Memory) Scheduling for manycore (Anahy) Quantum Computing simulation on manycore/gpus/clusters/cloud/toasters All about Green Computing Manycore of 40

42 Reviews of this Work Manycore of 40

43 Challenges for synchronization and scalability on manycore: a Software Transactional Memory approach Maurício Lima Pilla André Rauber Du Bois Adenauer Correa Yamin Ana Marilza Pernas Fleischmann Gerson Geraldo Homrich Cavalheiro Renata Hax Sander Reiser Laboratory of Ubiquitous and Parallel Systems Federal University of Pelotas pilla@inf.ufpel.edu.br March 2015 Manycore of 40