Recommended
Recommended
More Related Content
What's hot
What's hot (6)
Similar to Pitfalls of Object Oriented Programming
Similar to Pitfalls of Object Oriented Programming (20)
More from Slide_N
More from Slide_N (20)
Recently uploaded
Recently uploaded (20)
Pitfalls of Object Oriented Programming
- 1. Tony Albrecht – Technical Consultant Developer Services Sony Computer Entertainment Europe Research & Development Division Pitfalls of Object Oriented Programming
- 2. Slide 2 • A quick look at Object Oriented (OO) programming • A common example • Optimisation of that example • Summary What I will be covering
- 3. Slide 3 • What is OO programming? – a programming paradigm that uses "objects" – data structures consisting of datafields and methods together with their interactions – to design applications and computer programs. (Wikipedia) • Includes features such as – Data abstraction – Encapsulation – Polymorphism – Inheritance Object Oriented (OO) Programming
- 4. Slide 4 • OO programming allows you to think about problems in terms of objects and their interactions. • Each object is (ideally) self contained – Contains its own code and data. – Defines an interface to its code and data. • Each object can be perceived as a „black box‟. What’s OOP for?
- 5. Slide 5 • If objects are self contained then they can be – Reused. – Maintained without side effects. – Used without understanding internal implementation/representation. • This is good, yes? Objects
- 6. Slide 6 • Well, yes • And no. • First some history. Are Objects Good?
- 7. Slide 7 A Brief History of C++ C++ development started 1979 2009
- 8. Slide 8 A Brief History of C++ Named “C++” 1979 20091983
- 9. Slide 9 A Brief History of C++ First Commercial release 1979 20091985
- 10. Slide 10 A Brief History of C++ Release of v2.0 1979 20091989
- 11. Slide 11 A Brief History of C++ Release of v2.0 1979 20091989 Added • multiple inheritance, • abstract classes, • static member functions, • const member functions • protected members.
- 12. Slide 12 A Brief History of C++ Standardised 1979 20091998
- 13. Slide 13 A Brief History of C++ Updated 1979 20092003
- 14. Slide 14 A Brief History of C++ C++0x 1979 2009 ?
- 15. Slide 15 • Many more features have been added to C++ • CPUs have become much faster. • Transition to multiple cores • Memory has become faster. So what has changed since 1979? http://www.vintagecomputing.com
- 16. Slide 16 CPU performance Computer architecture: a quantitative approach By John L. Hennessy, David A. Patterson, Andrea C. Arpaci-Dusseau
- 17. Slide 17 CPU/Memory performance Computer architecture: a quantitative approach By John L. Hennessy, David A. Patterson, Andrea C. Arpaci-Dusseau
- 18. Slide 18 • One of the biggest changes is that memory access speeds are far slower (relatively) – 1980: RAM latency ~ 1 cycle – 2009: RAM latency ~ 400+ cycles • What can you do in 400 cycles? What has changed since 1979?
- 19. Slide 19 • OO classes encapsulate code and data. • So, an instantiated object will generally contain all data associated with it. What has this to do with OO?
- 20. Slide 20 • With modern HW (particularly consoles), excessive encapsulation is BAD. • Data flow should be fundamental to your design (Data Oriented Design) My Claim
- 21. Slide 21 • Base Object class – Contains general data • Node – Container class • Modifier – Updates transforms • Drawable/Cube – Renders objects Consider a simple OO Scene Tree
- 22. Slide 22 • Each object – Maintains bounding sphere for culling – Has transform (local and world) – Dirty flag (optimisation) – Pointer to Parent Object
- 23. Slide 23 Objects Class Definition Memory Layout Each square is 4 bytes
- 24. Slide 24 • Each Node is an object, plus – Has a container of other objects – Has a visibility flag. Nodes
- 25. Slide 25 Nodes Class Definition Memory Layout
- 26. Slide 26 Consider the following code… • Update the world transform and world space bounding sphere for each object.
- 27. Slide 27 Consider the following code… • Leaf nodes (objects) return transformed bounding spheres
- 28. Slide 28 Consider the following code… • Leaf nodes (objects) return transformed bounding spheres What‟s wrong with this code?
- 29. Slide 29 Consider the following code… • Leaf nodes (objects) return transformed bounding spheres If m_Dirty=false then we get branch misprediction which costs 23 or 24 cycles.
- 30. Slide 30 Consider the following code… • Leaf nodes (objects) return transformed bounding spheresCalculation of the world bounding sphere takes only 12 cycles.
- 31. Slide 31 Consider the following code… • Leaf nodes (objects) return transformed bounding spheresSo using a dirty flag here is actually slower than not using one (in the case where it is false)
- 32. Slide 32 Lets illustrate cache usage Main Memory L2 Cache Each cache line is 128 bytes
- 33. Slide 33 Cache usage Main Memory parentTransform is already in the cache (somewhere) L2 Cache
- 34. Slide 34 Cache usage Main Memory Assume this is a 128byte boundary (start of cacheline) L2 Cache
- 35. Slide 35 Cache usage Main Memory Load m_Transform into cache L2 Cache
- 36. Slide 36 Cache usage Main Memory m_WorldTransform is stored via cache (write-back) L2 Cache
- 37. Slide 37 Cache usage Main Memory Next it loads m_Objects L2 Cache
- 38. Slide 38 Cache usage Main Memory Then a pointer is pulled from somewhere else (Memory managed by std::vector) L2 Cache
- 39. Slide 39 Cache usage Main Memory vtbl ptr loaded into Cache L2 Cache
- 40. Slide 40 Cache usage Main Memory Look up virtual function L2 Cache
- 41. Slide 41 Cache usage Main Memory Then branch to that code (load in instructions) L2 Cache
- 42. Slide 42 Cache usage Main Memory New code checks dirty flag then sets world bounding sphere L2 Cache
- 43. Slide 43 Cache usage Main Memory Node‟s World Bounding Sphere is then Expanded L2 Cache
- 44. Slide 44 Cache usage Main Memory Then the next Object is processed L2 Cache
- 45. Slide 45 Cache usage Main Memory First object costs at least 7 cache misses L2 Cache
- 46. Slide 46 Cache usage Main Memory Subsequent objects cost at least 2 cache misses each L2 Cache
- 47. Slide 47 • 11,111 nodes/objects in a tree 5 levels deep • Every node being transformed • Hierarchical culling of tree • Render method is empty The Test
- 48. Slide 48 Performance This is the time taken just to traverse the tree!
- 49. Slide 49 Why is it so slow? ~22ms
- 50. Slide 50 Look at GetWorldBoundingSphere()
- 51. Slide 51 Samples can be a little misleading at the source code level
- 53. Slide 53 Stalls due to the load 2 instructions earlier
- 54. Slide 54 Similarly with the matrix multiply
- 55. Slide 55 Some rough calculations Branch Mispredictions: 50,421 @ 23 cycles each ~= 0.36ms
- 56. Slide 56 Some rough calculations Branch Mispredictions: 50,421 @ 23 cycles each ~= 0.36ms L2 Cache misses: 36,345 @ 400 cycles each ~= 4.54ms
- 57. Slide 57 • From Tuner, ~ 3 L2 cache misses per object – These cache misses are mostly sequential (more than 1 fetch from main memory can happen at once) – Code/cache miss/code/cache miss/code…
- 58. Slide 58 • How can we fix it? • And still keep the same functionality and interface? Slow memory is the problem here
- 59. Slide 59 • Use homogenous, sequential sets of data The first step
- 60. Slide 60 Homogeneous Sequential Data
- 61. Slide 61 • Use custom allocators – Minimal impact on existing code • Allocate contiguous – Nodes – Matrices – Bounding spheres Generating Contiguous Data
- 62. Slide 62 Performance 19.6ms -> 12.9ms 35% faster just by moving things around in memory!
- 63. Slide 63 • Process data in order • Use implicit structure for hierarchy – Minimise to and fro from nodes. • Group logic to optimally use what is already in cache. • Remove regularly called virtuals. What next?
- 64. Slide 64 Hierarchy Node We start with a parent Node
- 65. Slide 65 Hierarchy Node Node NodeWhich has children nodes
- 66. Slide 66 Hierarchy Node Node Node And they have a parent
- 67. Slide 67 Hierarchy Node Node Node Node Node Node NodeNode Node Node Node And they have children
- 68. Slide 68 Hierarchy Node Node Node Node Node Node NodeNode Node Node Node And they all have parents
- 69. Slide 69 Hierarchy Node Node Node Node Node Node NodeNode Node Node Node A lot of this information can be inferred Node Node Node NodeNode Node Node Node
- 70. Slide 70 Hierarchy Node Node Node Node Node Node NodeNode Node Node Node Use a set of arrays, one per hierarchy level
- 71. Slide 71 Hierarchy Node Node Node Node Node Node NodeNode Node Node Node Parent has 2 children:2 :4 :4 Children have 4 children
- 72. Slide 72 Hierarchy Node Node Node Node Node Node NodeNode Node Node Node Ensure nodes and their data are contiguous in memory :2 :4 :4
- 73. Slide 73 • Make the processing global rather than local – Pull the updates out of the objects. • No more virtuals – Easier to understand too – all code in one place.
- 74. Slide 74 • OO version – Update transform top down and expand WBS bottom up Need to change some things…
- 75. Slide 75 Node Node Node Node Node Node NodeNode Node Node Node Update transform
- 76. Slide 76 Node Node Node Node Node Node NodeNode Node Node Node Update transform
- 77. Slide 77 Node Node Node Node Node Node NodeNode Node Node Node Update transform and world bounding sphere
- 78. Slide 78 Node Node Node Node Node Node NodeNode Node Node Node Add bounding sphere of child
- 79. Slide 79 Node Node Node Node Node Node NodeNode Node Node Node Update transform and world bounding sphere
- 80. Slide 80 Node Node Node Node Node Node NodeNode Node Node Node Add bounding sphere of child
- 81. Slide 81 Node Node Node Node Node Node NodeNode Node Node Node Update transform and world bounding sphere
- 82. Slide 82 Node Node Node Node Node Node NodeNode Node Node Node Add bounding sphere of child
- 83. Slide 83 • Hierarchical bounding spheres pass info up • Transforms cascade down • Data use and code is „striped‟. – Processing is alternating
- 84. Slide 84 • To do this with a „flat‟ hierarchy, break it into 2 passes – Update the transforms and bounding spheres(from top down) – Expand bounding spheres (bottom up) Conversion to linear
- 85. Slide 85 Transform and BS updates Node Node Node Node Node Node NodeNode Node Node Node For each node at each level (top down) { multiply world transform by parent‟s transform wbs by world transform } :2 :4 :4
- 86. Slide 86 Update bounding sphere hierarchies Node Node Node Node Node Node NodeNode Node Node Node For each node at each level (bottom up) { add wbs to parent‟s } :2 :4 :4 For each node at each level (bottom up) { add wbs to parent‟s cull wbs against frustum }
- 87. Slide 87 Update Transform and Bounding Sphere How many children nodes to process
- 88. Slide 88 Update Transform and Bounding Sphere For each child, update transform and bounding sphere
- 89. Slide 89 Update Transform and Bounding Sphere Note the contiguous arrays
- 90. Slide 90 So, what’s happening in the cache? Parent Children Parent Data Childrens‟ Data Children‟s node data not needed Unified L2 Cache
- 91. Slide 91 Load parent and its transform Parent Parent Data Childrens‟ Data Unified L2 Cache
- 92. Slide 92 Load child transform and set world transform Parent Parent Data Childrens‟ Data Unified L2 Cache
- 93. Slide 93 Load child BS and set WBS Parent Parent Data Childrens‟ Data Unified L2 Cache
- 94. Slide 94 Load child BS and set WBS Parent Parent Data Childrens‟ Data Next child is calculated with no extra cache misses ! Unified L2 Cache
- 95. Slide 95 Load child BS and set WBS Parent Parent Data Childrens‟ Data The next 2 children incur 2 cache misses in total Unified L2 Cache
- 96. Slide 96 Prefetching Parent Parent Data Childrens‟ Data Because all data is linear, we can predict what memory will be needed in ~400 cycles and prefetch Unified L2 Cache
- 97. Slide 97 • Tuner scans show about 1.7 cache misses per node. • But, these misses are much more frequent – Code/cache miss/cache miss/code – Less stalling
- 98. Slide 98 Performance 19.6 -> 12.9 -> 4.8ms
- 99. Slide 99 • Data accesses are now predictable • Can use prefetch (dcbt) to warm the cache – Data streams can be tricky – Many reasons for stream termination – Easier to just use dcbt blindly • (look ahead x number of iterations) Prefetching
- 100. Slide 100 • Prefetch a predetermined number of iterations ahead • Ignore incorrect prefetches Prefetching example
- 101. Slide 101 Performance 19.6 -> 12.9 -> 4.8 -> 3.3ms
- 102. Slide 102 • This example makes very heavy use of the cache • This can affect other threads‟ use of the cache – Multiple threads with heavy cache use may thrash the cache A Warning on Prefetching
- 103. Slide 103 The old scan ~22ms
- 104. Slide 104 The new scan ~16.6ms
- 106. Slide 106 Looking at the code (samples)
- 107. Slide 107 Performance counters Branch mispredictions: 2,867 (cf. 47,000) L2 cache misses: 16,064 (cf 36,000)
- 108. Slide 108 • Just reorganising data locations was a win • Data + code reorganisation= dramatic improvement. • + prefetching equals even more WIN. In Summary
- 109. Slide 109 • Be careful not to design yourself into a corner • Consider data in your design – Can you decouple data from objects? – …code from objects? • Be aware of what the compiler and HW are doing OO is not necessarily EVIL
- 110. Slide 110 • Optimise for data first, then code. – Memory access is probably going to be your biggest bottleneck • Simplify systems – KISS – Easier to optimise, easier to parallelise Its all about the memory
- 111. Slide 111 • Keep code and data homogenous – Avoid introducing variations – Don‟t test for exceptions – sort by them. • Not everything needs to be an object – If you must have a pattern, then consider using Managers Homogeneity
- 112. Slide 112 • You are writing a GAME – You have control over the input data – Don‟t be afraid to preformat it – drastically if need be. • Design for specifics, not generics (generally). Remember
- 113. Slide 113 • Better performance • Better realisation of code optimisations • Often simpler code • More parallelisable code Data Oriented Design Delivers
- 114. Slide 114 • Questions? The END