Roger Wattenhofer Good Programming in Transactional Memory Game Theory Meets Multicore Architecture Raphael Eidenbenz ETH Zurich ISAAC 2009 Moores Law Clock speed flattening sharply Transistor count still rising ID: 472170
Download Presentation The PPT/PDF document "Raphael Eidenbenz" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Raphael Eidenbenz Roger Wattenhofer
Good Programming in Transactional Memory
Game Theory Meets
Multicore
ArchitectureSlide2
Raphael Eidenbenz, ETH Zurich. ISAAC 2009Moore‘s Law
Clock speed flattening sharply
Transistor count still rising
Advent of multi-core processors!Slide3
Raphael Eidenbenz, ETH Zurich. ISAAC 2009Multicore ArchitectureExplicit lockingParallel threadsCommunication through shared memoryDeveloper: Explicit locking of shared resources
Mark critical sectionsSystem: Guarantee exclusive execution
Transactional MemorySlide4
Raphael Eidenbenz, ETH Zurich. ISAAC 2009Contention Management
Which transaction shall I abort??Slide5
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
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
priority based
non-priority basedSlide6
Raphael Eidenbenz, ETH Zurich. ISAAC 2009Is it a Game?YesPlayers = programmersStrategy space = placing of transactionsTheir goal: fast execution
Social goal: maximize system throughput
„My thread is the fastest!“Slide7
Desired BehaviorRaphael Eidenbenz, ETH Zurich. ISAAC 2009incRingCounters(Node start){
var cur = start; transaction{ while(cur.next!=start){
cur.doSomething();
cur = cur.next; }
}
}
incRingCountersGP(Node start){
var cur = start;
while(cur.next!=start){
transaction{
cur.doSomething();
}
cur = cur.next;
}} Transactions as short as possible!
R
1R3
t
R
2
R
s
R
1
R
3
t
R
2
R
sSlide8
Raphael Eidenbenz, ETH Zurich. ISAAC 2009Simulation Setup„Free-riding“ threads in DSTM2 Coarse transaction granularity ( ¸ 20 accesses per transaction)
Collaborative threadsGranularity =116 threads on 16 cores do random updates on shared ordered list or red-black tree during 10 s.
1 or 8 free-riders
High contentionSlide9
Raphael Eidenbenz, ETH Zurich. ISAAC 2009SimulationResults
Karma
Polka
Timestamp
throughput collaborators (updates/s)
throughput collaborators (updates/s)
throughput collaborators (updates/s)
Randomized
throughput collaborators (updates/s)
throughput free-riders (updates/s)
throughput free-riders (updates/s)
throughput free-riders (updates/s)
throughput free-riders (updates/s)Slide10
Good Programming IncentivesA CM is GPI compatible iff it punishes unnecessary locking and rewards partitioning.Raphael Eidenbenz, ETH Zurich. ISAAC 2009Slide11
Priority Based CMCM associates with each thread Ji a priority !iThread 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
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Theorem:
Polite, Greedy, Karma, Timestamp and Polka are not GPI compatible.Slide12
What is wrong?Raphael Eidenbenz, ETH Zurich. ISAAC 2009
R
1
R
3
t
R
2
R
s
R
1
R
3
t
R
2
R
sSlide13
What is wrong?
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Snatching up resources pushes priority
R
1
R
3
t
R
2
R
s
R
1
R
3
t
R
2
R
sSlide14
More ResultsRaphael Eidenbenz, ETH Zurich. ISAAC 2009
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 2
: Quasi priority accumulating CMs are not GPI compatible.Theorem 4: Any priority-accumulating CM that is based only on time is GPI compatible.Slide15
Ti
T
i1
T
i2
Randomized CM
Not priority based
„Choose random winner“
Proof Intuition
Unnecessary Locks: Stupid because only risk conflict (no priority gain)
Partitioning:
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Lemma 3
:
Randomized CM is GPI compatible.
T
i
T
i1
T
i2Slide16
Ti
T
i1
T
i2
Randomized CM
Not priority based
„Choose random winner“
Proof Intuition
Unnecessary Locks: Stupid because only risk conflict (no priority gain)
Partitioning:
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Lemma 3
:
Randomized CM is GPI compatible.
T
i
T
i2Slide17
Raphael Eidenbenz, ETH Zurich. ISAAC 2009Conclusion & Open ProblemsFurther work:Relax GPI compatibilityTrace effect in „real“ software
Thank you!