Lightweight Software Transactions for Games

1. Lightweight Software Transactions for Games Sebastian Burckhardt Alexandro Baldassin • Special thanks to Tom Ball, Jim Larus, Patrice Godefroid and Trishul Chilimbi

2. Motivation: Multicores • Sequential programs no longer run faster on each new chip generation • Difficult to use classic methodology (locks, critical sections) efficiently & correctly • Need better programming model.

3. Our Project • Start with existing sequential game • SpaceWars3D! (Dave Weller et al.) • Add asteroids • Prepare for concurrency: • Restructure code into MVC architecture • Break Game Loop into Individual Tasks • Separate shared data (model) from local data (views) • Execute tasks concurrently • Use automatic concurrency control • AVOID / RESOLVE conflicts using user specifications

4. Demo: Single-Threaded Game Loopvs.Concurrent Task Execution

5. Game’s MVC Architecture • Controllers issue Tasks to Runtime • Runtime schedules Tasks • Tasks access both local and shared data Controllers Update Contr. NetworkContr. Screen Contr. Audio Contr. Input Contr. Tasks UpdateWorld Snd Rcv Refresh PlaySnd ProcInp Views NetworkData Screen Data Audio Data Input Data Model World Shared Data

6. Replicating the World • Each task has its local replica of world • At end of each frame, copies are synced Controllers Update Contr. NetworkContr. Screen Contr. Audio Contr. Input Contr. Tasks UpdateWorld Snd Rcv Refresh PlaySnd ProcInp Views NetworkData Screen Data Audio Data Input Data Model World Copy 1 W. C2 W. C3 World Copy 4 World Copy 5 World Copy 6

7. Concurrent Independent Tasks • Runtime executes tasks concurrently(dynamic, not fixed static schedule) • Independence -> good performance Controllers Update Contr. NetworkContr. Screen Contr. Audio Contr. Input Contr. Tasks UpdateWorld Snd Rcv Refresh PlaySnd ProcInp Views NetworkData Screen Data Audio Data Input Data Model World Copy 1 W. C2 W. C3 World Copy 4 World Copy 5 World Copy 6

8. Concurrent Independent Tasks • Performance can be improved byfurther splitting the tasks Controllers Update Contr. NetworkContr. Screen Contr. Audio Contr. Input Contr. Tasks U1 U2 U3 Snd Rcv Refresh PlaySnd ProcInp U4 Views NetworkData Screen Data Audio Data Input Data W1 Model W2 W3 W. C2 W. C3 World Copy 2 World Copy 3 World Copy 4 W4

9. Concurrent Task Execution • User may constrain order of tasks • User may specify thread affinity of tasks • Each Task has private snapshot of model • Managed automatically // specify global task ordering runtime.AddBarrier("ProcInp","UpdateWorld"); runtime.AddBarrier("UpdateWorld", "CollSnd"); runtime.AddBarrier("UpdateCollisions", "CollSnd"); runtime.AddBarrier("ProcInp", "CollSnd");

10. Sharing Fields public class Ship { publicShipState state; … public void Shoot(Context c) { if (state != ShipState.Normal) { return; } … state := newState; } … }

11. Sharing Fields public class Ship { publicVersioned<ShipState> state; … public void Shoot(Context c) { if (state.get(c) != ShipState.Normal) { return; } … state.set(c,newState); } … }

12. Sharing Objects public class Ship { public 3DMatrix worldmatrix; public void Rotate(Context c, 3DMatrix rotation) { worldmatrix.multiply(rotation); } … public void Render(Context c) { scene.setCamera(worldmatrix); } }

13. Sharing Objects public class Ship { publicRVersioned<3DMatrix>worldmatrix; public void Rotate(Context c, 3DMatrix rotation) { worldmatrix.openForWrite(c).multiply(rotation); } … public void Render(Context c) { scene.setCamera(worldmatrix.open(c)); } }

14. Sharing Collections public class Ship { public List<Photon> shots; public void Shoot(Context c, Photon p) { shots.Add(p); } … public void Render(Context c) { foreach (Photon p in shots) p.Render(c); } }

15. Sharing Collections public class Ship { publicCVersioned<List<Photon>, Photon> shots; public void Shoot(Context c, Photon p) { shots.openForWrite(c).Add(p); } … public void Render(Context c, Photon p) { foreach (Photon p in shots.open(c)) p.Render(c); } }

16. Conflict Handling • Read-Write • Default: read does not see write • Barrier propagates updates between tasks • Write-Write • Default: throw runtime exception • User can specify merge function to resolve conflict // specify merge function world.playerShip.Score.AddMerge( "UpdateWorld", “UpdateCollisions", (int o, int v1, ref int v2) => v2 += (v1 – o) );

17. Runtime Internals: Optimize… • Allocate replicas in array, reuse entries • Avoids cost of construction / garbage collection • Minimize synchronization between threads • Each task uses fixed index into array • Copy on Write • Logical copy != Physical copy • More seems possible • Reduce number of replicas • Improve cache locality

18. Measurements Using 4 cores(Intel Q9550)

19. Conclusion: Looks Promising • Easy on Programmer • No critical sections needed • Automatic synchronization • Abstracts hardware details • Path to Performance • Easier to understand performance • Easier to improve performance • Programming Model Generalizes to… • Heterogeneous processors • Non-coherent memory • Distributed state