Improving STM Performance with Transactional Structs 1

Transcription

1 Improving STM Performance with Transactional Structs 1 Ryan Yates and Michael L. Scott University of Rochester IFL, This work was funded in part by the National Science Foundation under grants CCR , CCF , CCF , and CCF , and by support from the IBM Canada Centres for Advanced Studies. 1/31

2 Outline Haskell STM TStruct Performance results Future work Slides: Paper: 2/31

3 What is Transactional Memory? Transactional memory is the joining of two ideas: The ability to express what should be atomic without saying how. An implementation that uses speculation to optimistically execute and try again if needed. 3/31

4 Existing Haskell STM Implementation In STM execution, reads and writes to TVars are tracked in a transactional record (TRec). Execution continues under the assumption that there have been no conflicts. A conflict is where two threads access the same location and at least one is a write. 4/31

5 Existing Haskell STM Implementation At the end of the transaction: The RTS validates that reads still match the values in the TVars. And commits by performing writes atomically. If validation fails, start over. Similar to OSTM [Fraser, 2004]. No global bottlenecks. Read-only transactions do not acquire locks. OSTM is non-blocking, GHC s STM can livelock. 5/31

6 Motivation Haskell STM concurrent data structures suffer bloat from indirection. TVar version watch-list value Node key value color parent left right TVar version watch-list value value Int# 6/31

7 Our Work TStruct Removes indirection required by TVars. Mutable unboxed values paired with mutable pointer values. Increases locality of data structure nodes. Maintains properties: Commit parallels TVar commit. No global bottleneck. Read-only transactions do not acquire locks. Avoids conflating lock and value. Flexible transactional variable granularity. 7/31

8 Data Structures Red-Black Tree Skip List Cuckoo Hash Table Hashed Array Mapped Trie (HAMT) 8/31

9 Red-Black Tree Rebalancing TVar Extra Indirection No mutable unboxed values (Color field) TStruct Node initialization Nil node and indirection Accesses at constant offsets 9/31

10 Extra Indirection -- TVar data Node k v = Node { _key ::!k, _value ::!v, _color :: TVar Color, _parent :: TVar (Node k v), _left :: TVar (Node k v), _right :: TVar (Node k v) } Nil 10/31

11 Avoiding Sum Type Indirection -- TStruct with sum type data Node k v = Node { _tstruct :: TStruct# RealWorld (Node k v) } Nil -- TStruct without sum type data Node k v = Node { _tstruct :: TStruct# RealWorld Any } 11/31

12 Skip List No rebalancing needed Random number source TVar Pure node with TArray of next pointers Extra indirection TStruct TStruct containing both values and next pointers Node initialization 12/31

13 Node Initialization When a new node is made in a transaction no other thread can see it until the transaction has committed. We take advantage of this and access these nodes non-transactionally. In the skip list, this happens on insertion. The new node is created and the next pointers are written to match the previous node at that level. 13/31

14 Cuckoo Hash Table Only insert needs to do significant work. TVar TStruct TArray of immutable buckets Immutable array of TStruct buckets 14/31

15 Cuckoo Hash Table TStruct size... TArray version watch-list value version watch-list value size entry... Array size entry... Array lock lock-count version watch-list count key1 key2... keyn value1 value2... valuen 15/31

16 Hashed Array Mapped Trie (HAMT) No rebalancing TVar TStruct Extra indirection Node initialization Immutable fields Node tags 16/31

17 Immutable fields Fields that are immutable can be safely be read non-transactionally. No bookkeeping needed! Two primitive read functions: Transactional readtstruct# implemented in Cmm and C. Non-transactional readtstructnt# implemented in code generator. Things can go wrong in very unexpected ways! 17/31

18 Node tags -- TVar data Node a = Nodes (TVar (WordArray a)) Leaf Hash a Leaves Hash (SizedArray a) data WordArray a = WordArray Bitmap (Array (Node a)) data SizedArray a = SizedArray Size (Array a) 18/31

19 Node tags -- TStruct data Node a = WordArray Size Bitmap (Array (Node a)) SizedArray Size Hash (Array a) data Node a = Node { _tstruct :: TStruct# RealWorld Any } 19/31

20 HAMT Nodes tvar size entry... Node tag=nodes TVar version watch-list value WordArray bitmap array SizedArray tag=nodes tvar version watch-list value WordArray bitmap array SizedArray size entry... Node TVar tag=leaves hash array SizedArray size entry... Node 20/31

21 HAMT Nodes TVar version watch-list value WordArray lock lock-count version watch-list tag=0 size bitmap entry... WordArray lock lock-count version watch-list tag=0 size bitmap entry... SizedArray lock lock-count version watch-list tag=1 size hash entry... 21/31

22 Code Example Example from lookup in the TVar-based HAMT. Pattern matching ensures we do not handle a leaf as a node. lookuptvar... = do arr <- readtvar... case wordarraylookup i arr of Nothing ->... Just (Nodes ns) ->... Just (Leaves h la) ->... 22/31

23 Code Example In the TStruct-based HAMT lookup we lose safety. No bounds check in readtstructwordnt#. Nodes can be confused with leaves. readtagnt (WordArray arr#) = STM $ \s1# -> case readtstructwordnt# arr# 0# s1# of (# s2#, w# #) -> (# s2#, W# w# #) lookuptstruct... arr = do t <- readtagnt arr case t of 0 -> do... readindicesnt arr > do... readhashnt arr... 23/31

24 Benchmarks Machine Intel c Xeon TM E v3 two socket, 36-core, 72-thread Tests Data structure with concurrent inserts (5%), deletes (5%), and lookups (90%) measuring throughput at steady state. Structure initially has 50,000 entries in a key space of 100,000 keys. 24/31

25 TVar (Intel c Xeon TM E v3 two socket, 36-core) 10 7 Operations per second 4 2 RBTree SkipList Cuckoo HAMT Threads 25/31

26 HAMT (Intel c Xeon TM E v3 two socket, 36-core) Operations per second TVar TStruct CTrie Threads 26/31

27 Cuckoo Hash (Intel c Xeon TM E v3 two socket, 36-core) 10 7 Operations per second TVar TStruct Threads 27/31

28 Skip List (Intel c Xeon TM E v3 two socket, 36-core) Operations per second 2 1 TVar TStruct Threads 28/31

29 Red-Black Tree (Intel c Xeon TM E v3 two socket, 36-core) Operations per second 2 1 TVar TStruct Threads 29/31

30 Future Work Continue to improve performance and understand what factors contribute to good performance. Recover safety for TStruct features Node initialization Node tagging Accesses at constant offsets Other data structures 30/31

31 Thanks! Slides: Paper: 31/31

32 32/31

33 Haskell STM Metadata Structure Node key value parent left right color TVar value watch Watch Queue thread next prev Watch Queue thread next prev prev index tvar old new tvar old new... TRec tvar old new 33/31

34 Haskell Before TStruct Node key value parent left right color TVar value watch Node key value parent left right color 34/31

35 Haskell with TStruct Node lock watch key value color parent left right Node lock watch key value color parent left right 35/31

36 Haskell STM commit commit(trec* trec) { if (validate(trec)) { if (read_check(trec)) { update(trec) return true } } return false } 36/31

37 Haskell STM commit bool validate(trec* trec) { for (e in trec) { if (is_write(e)) { if (!lock(e) e->value!= e->tvar->value) { release_locks(trec) return false; } } else { e->version = e->tvar->version } } } 37/31

38 Haskell STM commit bool read_check(trec* trec) { for (e in trec) { if (is_read(e)) { if (e->value!= e->tvar->value e->version!= e->tvar->version) { release_locks(trec) return false } } } } 38/31

39 Haskell STM commit update(trec* trec) { for (e in trec) { if (is_write(e)) { e->tvar->version++ e->tvar->value = e->new_value } } } 39/31

40 References [Fraser, 2004] Fraser, K. (2004). Practical lock-freedom. PhD thesis, University of Cambridge Computer Laboratory. 40/31