performance evaluation of adaptivity in stm
play

Performance Evaluation of Adaptivity in STM Mathias Payer and - PowerPoint PPT Presentation

Performance Evaluation of Adaptivity in STM Mathias Payer and Thomas R. Gross Department of Computer Science, ETH Zrich Motivation STM systems rely on many assumptions Often contradicting for different programs Statically tuned to


  1. Performance Evaluation of Adaptivity in STM Mathias Payer and Thomas R. Gross Department of Computer Science, ETH Zürich

  2. Motivation ● STM systems rely on many assumptions ● Often contradicting for different programs ● Statically tuned to a baseline ● Use self-optimizing systems ● Adapt to different workloads ● What parameters can be adapted? ● How to measure effectiveness? ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 2

  3. Outline ● Introduction ● STM System ● STM Baseline ● Adaptive Parameters ● Evaluation ● Related work ● Conclusion ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 3

  4. Introduction ● Software Transactional Memory (STM) applies transactions to memory ● (Optimistic) concurrency control mechanism ● Alternative to lock-based synchronization ● Multiple concurrent threads run transactions ● Concurrent memory modifications ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 4

  5. Introduction ● Concurrent transactions modify memory without synchronization ● Transaction is verified after completion ● Conflicts are detected and resolved ● Changes committed for conflict-free transactions ● Modifications only visible after commit ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 5

  6. Introduction TX starts balance in read-set withdraw { deposit { balance in tmp = balance; tmp = balance; write-set tmp = tmp – 100 tmp = tmp + 100 Conflict detection, balance = tmp; balance = tmp; data committed } } ● What happens when balance is accessed concurrently? ● Either locking or STM needed to ensure correct end balance ● STM system decides which tx is executed first ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 6

  7. STM Baseline ● Many efficient STM implementations agree on important design decisions: ● Word-based locking ● Global locking / version table ● Eager locking ● (Almost) no contention management ● Simple write-set and read-set implementations ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 7

  8. STM Baseline Combined global write lock / version array Read Read Lock Lock Write Write list / list / list list list / list / buffer buffer buffer buffer Write Write Read Read Hash Hash Hash Hash Transaction Transaction ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 8

  9. Adaptive STM Parameters ● Global adaptivity ● Synchronization needed ● Optimizes to global optimum ● Averages over all concurrent transactions ● (Thread-) local adaptivity ● No synchronization needed ● Limits adaptable parameters ● Best parameters for each thread/transaction ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 9

  10. Adaptive STM Parameters ● Different adaptive parameters measured: ● Size of global locking/version-table *G ● Size of local hash-tables *L ● Write strategy *L ● Locality tuning for hash-functions *L ● Contention management *L *L – local, *G – global ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 10

  11. Adaptive Hash-Table ● Global hash-table: trade-off between over- locking and locality ● Global strategy: coordinate lock collisions and over- locking between threads ● Adapt size based on global information ● Local hash-table: trade-off between reset cost, and # hash-collisions ● Local strategy: sample moving average of unique write locations ● Adapt size based on trend ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 11

  12. Adaptive Write Strategy ● Different costs depending on strategy ● Write-back: cheap abort, expensive commit ● Write-through: expensive abort, cheap commit ● Adapt strategy to per-thread workload ● Measure abort rate ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 12

  13. Adaptive Locality Tuning ● Different applications have different data access patterns ● No optimal hash function for all data accesses ● Measure number of hash collisions for thread- local hash tables ● Circle through different hash functions ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 13

  14. Adaptive Contention Management ● No single strategy works in all environments ● Measure contention and implement an adaptive back-off strategy ● Wait and retry ● Abort later ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 14

  15. Local Adaptive STM Parameters (for local hash-table) # writes vs. hash-table space enlarge write-hash no change shrink write-hash 0 ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 15

  16. Local Adaptive STM Parameters (for local hash-table) no change change hash-function 0 # hash collisions ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 16

  17. Local Adaptive STM Parameters (for local hash-table) # writes vs. hash-table space enlarge write-hash enlarge write-hash & change hash-function no change change hash-function shrink write-hash & shrink write-hash change hash-function 0 # hash collisions ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 17

  18. AdaptSTM ● Adaptive STM system built on presented features ● Statically tuned competitive baseline – Static global hash function and hash table ● Mature and stable implementation ● Different local adaptive parameters – Write-set hash function and size of hash table – Write-through and write-back write strategy – Adaptive contention management ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 18

  19. Evaluation ● Benchmark: STAMP 0.9.10 ● ++ configuration (increased workload for kmeans) ● AdaptSTM version 0.5.1 ● Intel 4-core Xeon E5520 CPU ● 8 cores @ 2.27GHz, 12GB RAM ● 64bit Ubuntu 9.04 ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 19

  20. Evaluation: Global Hash-Table kmeans Genome 4 Threads 4 Threads 80 4.5 4 70 2^16 2^16 3.5 60 2^18 2^18 3 2^20 2^20 50 2^22 2^22 2.5 Time [s] 2^24 Time [s] 2^24 40 2^26 2^26 2 30 1.5 20 1 10 0.5 0 0 0 2 4 6 8 10 0 2 4 6 8 10 # Shifts # Shifts ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 20

  21. Evaluation: Global Adaptivity ● Global optimizations have limited potential ● Small optimization potential ● High synchronization cost ● Reasonable baseline outperforms global optimization ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 21

  22. Evaluation: Local Adaptivity ● Different configurations: ● naWB: no adaptivity, use write-back ● aWBT: adaptivity, adjust write-through / write-back ● aWWH: aWBT plus an adaptive hash-table for the write-set ● aWHH: aWWH plus different hash functions ● aALL: all adaptive parameters plus Bloom filter for write-entries ● Adaptation system starts with best 'average' parameters, improves from there ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 22

  23. Evaluation: Local Adaptivity kmeans Labyrinth 15.00% 3.00% 2.00% 10.00% Speedup to non adaptive Speedup to non adaptive 1.00% 5.00% aWBT 0.00% aWBT aWWH 0.00% aWWH aWHH aWHH -1.00% aALL aALL -5.00% -2.00% -10.00% -3.00% -15.00% -4.00% 1 2 4 8 16 1 2 4 8 16 Threads Threads aWBT: adaptive, write-back/-through ● aWWH: adaptive, write-back/-through, write-hash ● aWHH: adaptive, write-back/-through, write-hash, hash-function ● aALL: adaptive, write-back/-through, write-hash, hash-function, Bloom filter ● ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 23

  24. Evaluation: Local Adaptivity Genome Vacation 6.00% 5.00% 5.00% 4.00% 4.00% Speedup to non adaptive Speedup to non adaptive 3.00% 3.00% aWBT 2.00% 2.00% aWBT aWWH aWWH 1.00% aWHH aWHH 1.00% aALL aALL 0.00% 0.00% -1.00% -1.00% -2.00% -3.00% -2.00% 1 2 4 8 16 1 2 4 8 16 Threads Threads aWBT: adaptive, write-back/-through ● aWWH: adaptive, write-back/-through, write-hash ● aWHH: adaptive, write-back/-through, write-hash, hash-function ● aALL: adaptive, write-back/-through, write-hash, hash-function, Bloom filter ● ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 24

  25. Evaluation: Local Adaptivity ● No single optimization works for all benchmarks ● Combination of all options leads to best performance ● Impressive speed-ups for individual benchmarks compared to the globally optimized case ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 25

  26. Related Work ● TL2 (Dice et al.): baseline STM system ● Different related work on static tuning of global parameters (Harris, Dice, Ennals, Felber) ● Crucial for efficient baseline ● TinySTM (Felber et al.): adapts size and hash function of global locking table ● ASTM (Marathe et. al.): adapts lazy-eager locking strategies and different meta-formats ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 26

  27. Conclusions ● Adaptivity in STM is important for good performance ● Speedups up to 10% possible ● Global optimization are limited ● Low potential, high synchronization cost ● Local optimizations tune thread-local parameters ● High correlation with workload ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 27

  28. Questions ? ● Contact: mathias.payer@nebelwelt.net ● Source: http://nebelwelt.net/projects/adaptSTM/ ISPASS'11 / 2011-04-12 Mathias Payer / ETH Zürich 28

Recommend


More recommend