1 / 17

Good Programming in Transactional Memory Game Theory Meets Multicore Architecture

Good Programming in Transactional Memory Game Theory Meets Multicore Architecture. Raphael Eidenbenz Roger Wattenhofer. Moore‘s Law. Transistor count still rising. Clock speed flattening sharply. Advent of multi-core processors!. Multicore Architecture. Explicit locking

patch
Download Presentation

Good Programming in Transactional Memory Game Theory Meets Multicore Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Good Programming in Transactional MemoryGame Theory Meets Multicore Architecture Raphael Eidenbenz Roger Wattenhofer

  2. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Moore‘s Law Transistor count still rising Clock speed flattening sharply Advent of multi-core processors!

  3. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Multicore Architecture • Explicit locking • Parallel threads • Communication through shared memory • Developer: Explicit locking of shared resources • Mark critical sections • System: Guarantee exclusive execution Transactional Memory

  4. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Contention Management Which transaction shall I abort??

  5. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 priority based non-priority based Contention Managers • Timestamp • Oldest transaction wins • Polite • Exponential backoff • Karma • Transaction with most locked resources wins • Priority is carried over to next attempt when aborted • Polka • Karma with exponential backoff • Randomized • Pick a random winner

  6. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Is it a Game? • Yes • Players = programmers • Strategy space = placing of transactions • Their goal: fast execution • Social goal: maximize system throughput „My thread is the fastest!“

  7. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Desired Behavior incRingCountersGP(Node start){ var cur = start; while(cur.next!=start){ transaction{cur.doSomething();} cur = cur.next; }} incRingCounters(Node start){ var cur = start; transaction{ while(cur.next!=start){ cur.doSomething(); cur = cur.next; } }} • Transactions as short as possible! R1 R1 R2 R2 R3 R3 Rs Rs t t

  8. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Simulation Setup • „Free-riding“ threads in DSTM2 • Coarse transaction granularity ( ¸ 20 accesses per transaction) • Collaborative threads • Granularity =1 • 16 threads on 16 cores do random updates on shared ordered list or red-black tree during 10 s. • 1 or 8 free-riders • High contention

  9. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Karma Polka SimulationResults throughput free-riders (updates/s) throughput free-riders (updates/s) throughput collaborators (updates/s) throughput collaborators (updates/s) Timestamp Randomized throughput free-riders (updates/s) throughput free-riders (updates/s) throughput collaborators (updates/s) throughput collaborators (updates/s)

  10. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Good Programming Incentives • A CM is GPI compatible iff it • punishes unnecessary locking • and rewards partitioning.

  11. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Priority Based CM • CM associates with each thread Ji a priority !i • Thread with highest priority wins conflicts • Rationale: • „Don‘t discard the transaction who has done most“ • Underlying assumption: Priority measures the amount of work done • E.g. Timestamp CM • The oldest transaction has done the most work • Theorem: Polite, Greedy, Karma, Timestamp and Polka are not GPI compatible.

  12. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 What is wrong? R1 R1 R2 R2 R3 R3 Rs Rs t t

  13. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 What is wrong? • Snatching up resources pushes priority R1 R2 R3 Rs t R1 R2 R3 Rs t

  14. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 More Results Theorem 2: Quasi priority accumulating CMs are not GPI compatible. Theorem 3: Any priority-accumulating CM M is not GPI compatible if one of the following holds: M increases a job’s priority on W-events . M increases relative priority on R-events. M schedules transactions gapless and increases priorities on C-events. M restarts aborted transactions immediately and increases priorities on A-events Theorem 4: Any priority-accumulating CM that is based only on time is GPI compatible.

  15. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Randomized CM • Not priority based • „Choose random winner“ • Proof Intuition • Unnecessary Locks: Stupid because only risk conflict (no priority gain) • Partitioning: Lemma 3: Randomized CM is GPI compatible. Ti Ti Ti1 Ti2 Ti1 Ti2

  16. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Randomized CM • Not priority based • „Choose random winner“ • Proof Intuition • Unnecessary Locks: Stupid because only risk conflict (no priority gain) • Partitioning: Lemma 3: Randomized CM is GPI compatible. Ti Ti Ti1 Ti2 Ti2

  17. Raphael Eidenbenz, ETH Zurich. ISAAC 2009 Conclusion & Open Problems • Further work: • Relax GPI compatibility • Trace effect in „real“ software Thank you!

More Related