Pitfalls of Object Oriented Programming GCAP 09

5/22/2018 Pitfalls of Object Oriented Programming GCAP 09

1/114

Tony Albrecht Technical

Develo

Sony Computer Entertainment Europe

Research & Development Division

Pitfalls of Object Oriented Program


2/114Slide 2

A quick look at Object Oriented (OOprogramming

A common example

Optimisation of that example Summary

What I will be covering


3/114Slide 3

What is OO programming?

a programming paradigm that uses "objects" data structuconsisting of datafields and methods together with their intdesign applications and computer programs.(Wikipedia)

Includes features such as

Data abstraction Encapsulation

Polymorphism

Inheritance

Object Oriented (OO) Programmi


4/114Slide 4

OO programming allows you to think aproblems in terms of objects and theirinteractions.

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 bla

Whats OOP for?


5/114

Slide 5

If objects are self contained then they c Reused. Maintained without side effects.

Used without understanding internalimplementation/representation.

This is good, yes?

Objects


6/114

Slide 6

Well, yes

And no.

First some history.

Are Objects Good?


7/114

Slide 7

A Brief History of C++

C++ development started

1979 200


8/114

Slide 8


Named C++

1979 2001983


9/114

Slide 9


First Commercial release

1979 2001985


10/114

Slide 10


Release of v2.0

1979 2001989


11/114

Slide 11


Release of v2.0

1979 2001989

Added multiple inherita abstract classe static member f const member f protected mem


12/114

Slide 12


Standardised

1979 2001998


13/114

Slide 13


Updated

1979 2002003


14/114

Slide 14


1979 200


15/114

Slide 15

Many more features havebeen added to C++

CPUs have become muchfaster.

Transition to multiple cores Memory has become faster.

So what has changed since 1979

http://www.vintage


16/114

Slide 16

CPU performance

Computer architecture: a quantitative approach

By John L. Hennessy, David A. Patterson, Andrea C


17/114

Slide 17

CPU/Memory performance

Computer architecture: a quantitative approachBy John L. Hennessy, David A. Patterson, Andrea C


18/114

Slide 18

One of the biggest changes is that memaccess speeds are far slower (relativel 1980: RAM latency ~ 1 cycle

2009: RAM latency ~ 400+ cycles

What can you do in 400 cycles?

What has changed since 1979?


19/114

Slide 19

OO classes encapsulate code and d So, an instantiated object will genera

contain all data associated with it.

What has this to do with OO?


20/114

Slide 20

With modern HW (particularly consoexcessive encapsulation is BAD.

Data flow should be fundamental to design (Data Oriented Design)

My Claim


21/114

Slide 21

Base Object class Contains general data

Node Container class

Modifier

Updates transforms Drawable/Cube

Renders objects

Consider a simple OO Scene Tre


22/114

Slide 22

Each object Maintains bounding sphere for culling

Has transform (local and world)

Dirty flag (optimisation)

Pointer to Parent

Object


23/114

Slide 23

Objects

Class Definition Memory Layou

Each square is

4 bytes


24/114

Slide 24

Each Node is an object, plus Has a container of other objects

Has a visibility flag.

Nodes


25/114

Slide 25

Nodes

Class Definition Memory Layo


26/114

Slide 26

Consider the following code

Update the world transform and wo

space bounding sphere for each ob


27/114

Slide 27


Leaf nodes (objects) return transfor

bounding spheres


28/114

Slide 28



bounding spheresWhats wrong with thiscode?


29/114

Slide 29



bounding spheresIf m_Dirty=false then we get branchmisprediction which costs 23 or 24

cycles.


30/114

Slide 30



bounding spheresCalculation of the world bounding spheretakes only 12 cycles.


31/114

Slide 31



bounding spheresSo using a dirty flag here is actuallyslower than not using one (in the case

where it is false)


32/114

Slide 32

Lets illustrate cache usage

Main Memory L2 Cache

Each cache line is

128 bytes


33/114

Slide 33

Cache usage

Main Memory

parentTransform is already

in the cache (somewhere)

L2 Cache


34/114

Slide 34

Cache usage

Main Memory

Assume this is a 128byte

boundary (start of cacheline) L2 Cache


35/114

Slide 35

Cache usage

Main Memory

Load m_Transform into cache

L2 Cache


36/114

Slide 36

Cache usage

Main Memory

m_WorldTransform is stored via

cache (write-back)

L2 Cache


37/114

Slide 37

Cache usage

Main Memory

Next it load

L2 Cache


38/114

Slide 38

Cache usage

Main Memory

Then a pointer is pulled from

somewhere else (Memory

managed by std::vector)

L2 Cache


39/114

Slide 39

Cache usage

Main Memory

vtbl ptr loaded into Cache

L2 Cache


40/114

Slide 40

Cache usage

Main Memory

Look up virtual function

L2 Cache


41/114

Slide 41

Cache usage

Main Memory

Then branch to that code(load in instructions)

L2 Cache


42/114

Slide 42

Cache usage

Main Memory

New code checks dirty flag then

sets world bounding sphere

L2 Cache


43/114

Slide 43

Cache usage

Main Memory

Nodes World Bounding Sphere

is then Expanded

L2 Cache


44/114

Slide 44

Cache usage

Main Memory

Then the next Object is

processed

L2 Cache


45/114

Slide 45

Cache usage

Main Memory

First object costs at least 7

cache misses

L2 Cache


46/114

Slide 46

Cache usage

Main Memory

Subsequent objects cost at least

2 cache misses each

L2 Cache


47/114

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

Performance


48/114

Slide 48

Performance

This is the time

taken just to

traverse the tree!


49/114

Slide 49

Why is it so slow?~22ms


50/114

Slide 50

Look at GetWorldBoundingSpher

Samples can be a little


51/114

Slide 51

misleading at the source

code level


52/114

Slide 52

if(!m_Dirty) comparison


53/114

Slide 53

Stalls du

instructio


54/114

Slide 54

Similarly

multiply


55/114

Slide 55

Some rough calculations

Branch Mispredictions: 50,421 @ 23 cycles each ~= 0.36ms


56/114

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/114

Slide 57

From Tuner, ~ 3 L2 cache misses pe

object These cache misses are mostly seque

(more than 1 fetch from main memoryhappen at once)

Code/cache miss/code/cache miss/co


58/114

Slide 58

How can we fix it?

And still keep the same functionality

interface?

Slow memory is the problem he


59/114

Slide 59

Use homogenous, sequential sets o

The first step

S


60/114

Slide 60

Homogeneous Sequential Data

G ti C ti D t


61/114

Slide 61

Use custom allocators

Minimal impact on existing code

Allocate contiguous Nodes

Matrices Bounding spheres

Generating Contiguous Data

Performance


62/114

Slide 62

19.6ms -> 12.

35% faster jusmoving things

memory!

Wh t t?


63/114

Slide 63

Process data in order

Use implicit structure for hierarchy Minimise to and fro from nodes.

Group logic to optimally use what is alr

cache. Remove regularly called virtuals.

What next?

Hi h


64/114

Slide 64

Hierarchy

Node

We start with

a parent Node

Hi h


65/114

Slide 65

Hierarchy

Node

Node NodeWhich has children

nodes

Hierarch


66/114

Slide 66

Hierarchy

Node

Node Node

And they have a

parent

Hierarchy


67/114

Slide 67

Hierarchy

Node

Node Node

Node Node NNode Node Node Node

And they have

children

Hierarchy


68/114

Slide 68

Hierarchy

Node

Node Node


And they all have

parents

Hierarchy


69/114

Slide 69

Hierarchy

Node

Node Node


A lot of this

information can be

inferred

Node Node Node NodeNode Node Node Node

Hierarchy


70/114

Slide 70

Hierarchy

Node

Node Node


Use a set of arrays,

one per hierarchy

level

Hierarchy


71/114

Slide 71

Hierarchy

Node

Node Node


Parent has 2children:2

:4:4

Children have 4

children

Hierarchy


72/114

Slide 72

Hierarchy

Node

Node Node


Ensure nodes and their

data are contiguous inmemory

:2

:4:4


73/114

Slide 73

Make the processing global rather th

local Pull the updates out of the objects.

No more virtuals

Easier to understand too all code inplace.

Need to change some things


74/114

Slide 74

OO version

Update transform top down and expa

bottom up

Need to change some things


75/114

Slide 75

Node

Node Node


Update

transform


76/114

Slide 76

Node

Node Node


Update

transform


77/114

Slide 77

Node

Node Node


Update transform and

world bounding sphere


78/114

Slide 78

Node

Node Node


Add bounding sphere

of child


79/114

Slide 79

Node

Node Node





80/114

Slide 80

Node

Node Node


Add bounding sphere

of child


81/114

Slide 81

Node

Node Node





82/114

Slide 82

Node

Node Node


Add bounding sphere

of child


83/114

Slide 83

Hierarchical bounding spheres pass

Transforms cascade down

Data use and code is striped.

Processing is alternating

Conversion to linear


84/114

Slide 84

To do this with a flat hierarchy, brea

into 2 passes Update the transforms and bounding

spheres(from top down)

Expand bounding spheres (bottom up

Transform and BS updates


85/114

Slide 85

p

Node

Node Node


For each node at each level (top down){

multiply world transform by parents

transform wbs by world transform

}

:2

:4:4

Update bounding sphere hierarch


86/114

Slide 86

p g p

Node

Node Node


For each node at each level (bottom up{

add wbs to parents

}

:2

:4:4

For each node at each level (bottom up{

add wbs to parents

cull wbs against frustum

}

Update Transform and Bounding Sp


87/114

Slide 87

g

How many children nodes

to process



88/114

Slide 88

For each child, u

transform and b

sphere



89/114

Slide 89

Note the contig

So, whats happening in the cach


90/114

Slide 90

Parent

Children

Parent Data

Childrens Data

Childrens nodedata not needed

Unified L2 C

Load parent and its transform


91/114

Slide 91

Parent

Parent Data

Childrens Data

Unified L2 C

Load child transform and set world tra


92/114

Slide 92

Parent

Parent Data

Childrens Data

Unified L2 C

Load child BS and set WBS


93/114

Slide 93

Parent

Parent Data

Childrens Data

Unified L2 C



94/114

Slide 94

Parent

Parent Data

Childrens Data

Next child is calculated with

no extra cache misses ! Unified L2 C



95/114

Slide 95

Parent

Parent Data

Childrens Data

The next 2 children incur 2

cache misses in total Unified L2 C

Prefetching


96/114

Slide 96

Parent

Parent Data

Childrens Data

Because all data is linear, we

can predict what memory will

be needed in ~400 cyclesand prefetch

Unified L2 C


97/114

Slide 97

Tuner scans show about 1.7 cache m

per node. But, these misses are much more fre

Code/cache miss/cache miss/code

Less stalling

Performance


98/114

Slide 98

19.6 -> 12

Prefetching


99/114

Slide 99

Data accesses are now predictable

Can use prefetch (dcbt) to warm the ca Data streams can be tricky

Many reasons for stream termination

Easier to just use dcbt blindly (look ahead x number of iterations)

Prefetching example


100/114

Slide 100

Prefetch a predetermined number of

iterations ahead Ignore incorrect prefetches

Performance


101/114

Slide 101

19.6 -> 12.9 -

A Warning on Prefetching


102/114

Slide 102

This example makes very heavy use

cache This can affect other threads use of

cache

Multiple threads with heavy cache usethrash the cache

The old scan~22ms


103/114

Slide 103

~22ms

The new scan


104/114

Slide 104

~16.6ms

Up close


105/114

Slide 105

~16.6ms

Looking at the code (samples)


106/114

Slide 106

Performance countersBranch mispredictions: 2,867 (cf. 47,000)


107/114

Slide 107

p , ( , )

L2 cache misses: 16,064 (cf 36,000)

In Summary


108/114

Slide 108

Just reorganising data locations was

Data + code reorganisation= dramatimprovement.

+ prefetching equals even more WIN

B f l t t d i lf i t

OO is not necessarily EVIL


109/114

Slide 109

Be careful not to design yourself into a

Consider data in your design Can you decouple data from objects?

code from objects?

Be aware of what the compiler and HWdoing

O ti i f d t fi t th d

Its all about the memory


110/114

Slide 110

Optimise for data first, then code.

Memory access is probably going to bbiggest bottleneck

Simplify systems

KISS

Easier to optimise, easier to parallelis

Keep code and data homogenous

Homogeneity


111/114

Slide 111

Keep code and data homogenous

Avoid introducing variations Dont test for exceptions sort by the

Not everything needs to be an objec

If you must have a pattern, then consiusing Managers

You are writing a GAME

Remember


112/114

Slide 112

You are writing a GAME

You have control over the input data Dont be afraid to preformat it drasti

need be.

Design for specifics, not generics(generally).

B tt f

Data Oriented Design Delivers


113/114

Slide 113

Better performance

Better realisation of code optimisatio

Often simpler code

More parallelisable code

Q estions?

The END


114/114

Slide 114

Questions?

Pitfalls of Object Oriented Programming GCAP 09

Documents

Transcript of Pitfalls of Object Oriented Programming GCAP 09