Maths & Technologies for GamesOptimisation for Games 1

CO3303

Week 4

Today’s LectureToday’s Lecture

1. What is Optimisation

2. Optimisation Tradeoffs

3. Performance Analysis

4. Compiler Optimisations

5. Basic Language Optimisations

6. Data Structure Choices

7. Algorithmic Improvements

What is OptimisationWhat is Optimisation

• Most important requirement of a program is that it functions correctly– But what about its performance?

• For many applications this is not an issue– The program is fine as first compiled

• But for demanding applications initial performance can be unsatisfactory– E.g. too slow or too much memory usage

• Optimisation is the process of rewriting critical parts of the code to improve performance– Ideally without reducing functionality

Optimisation for GamesOptimisation for Games

• Games are very demanding applications– Need high performance in many different areas– Optimisation is a significant concern

• Optimisation directly affects the sales of a game– Better performance means:

• More complex environments

• More characters on screen

• More complex AI

• Better graphical effects

• Lower minimum specs

• There is often direct competition between developers on optimisation issues

Optimisation TradeoffsOptimisation Tradeoffs

• Several types of optimisation, e.g:– Speed – same functionality, running faster– Memory – use less memory for same result– Storage – minimise use of disk-space– Network – improve bandwidth / latency

• Will focus on the first two: speed & memory

• These often work against each other– Reducing memory use can decrease speed– Increased speed might be at the expense of memory

• Often a tradeoff between optimisations

When (not) to OptimiseWhen (not) to Optimise

• NEVER optimise code unless you are sure that it is affecting performance– Keep optimisations as localised as possible

• Optimisations often harm readability/maintainability• They might reduce the functionality of your program• Can make your architecture less flexible

• First do some form of performance analysis to find where optimisation is needed…

Performance AnalysisPerformance Analysis

• In general about 90% of processor time is spent in just 10% of the code

• To optimise for speed, need to identify this 10%– Little benefit in optimising the other 90%

• Several performance analysis tools can report on run-time performance to assist in this:– Simple timing functions (example in the lab)– Profiler – a component of most compilers

• Reports on time/calls spent in different functions

– Specialist tools such as:• Intel – VTune, PTU: CPU performance• NVidia – PerfHUD, PerfKit : GPU performance• Console specific tools etc…

Compiler OptimisationsCompiler Optimisations

• Compilers can perform some optimisation– For speed and/or memory

• Some code optimisations we might add are already performed by the compiler– Hand optimisation is tricky because of this

• There are usually several compiler settings, e.g: – Compile for fast code or small executable size– Floating point accuracy

• In Visual Studio, many optimisations are enabled by simply switching to “Release” mode– Others can be found in the project settings

Basic Language OptimisationsBasic Language Optimisations

• Loop unrolling (saves loop processing)– Convert:

for (int i=0; i<3; i++)

{

DoStuff(i);

}

– Into:DoStuff(0);

DoStuff(1);

DoStuff(2);

• Compiler usually does this already when using optimisations - so may have no apparent effect

Basic Language OptimisationsBasic Language Optimisations

• Remove repeated constant calculations– Convert:

for (int i=0; i<100; i++) {

DoCircleThing(2*Pi*R, i);

}

– Into:float circum = 2*Pi*R;

for (int i=0; i< 100; i++) {

DoCircleThing(circum , i);

}

– This kind of thing occurs very often

• Compilers will pick up simple cases– But you can often identify more complex ones

Basic Language OptimisationsBasic Language Optimisations

• Order of conditions– Convert:

if(ComplexRareCondition || SimpleCommonCondition)

{...}

– Into:if(SimpleCommonCondition || ComplexRareCondition)

{...}

• Conditions are evaluated in the order given– The program won’t evaluate conditions unnecessarily

• Put simpler / more frequent conditions first– In the 2nd case above, if the simple condition is true, then the

complex condition will be skipped – saving time

Basic Language OptimisationsBasic Language Optimisations

• Passing by reference– Convert:

void DoStuff( BigStruct myStruct ) {...}

– Into:void DoStuff( BigStruct& myStruct ) {...} orvoid DoStuff( const BigStruct& myStruct ) {...}

• First case (pass by value) creates a copy of the big structure, potentially wasting time/memory

• Latter cases (pass by reference) refer to the original copy of the structure and don’t need to copy– Be careful about changing the original data– Use const version whenever possible (can’t change data)

Basic Language OptimisationsBasic Language Optimisations

• Early function return– Convert:

bool result = false;

for (int i=0; i<100; i++) {

if (condition) result = true;

}

return result;

– Into:for (int i=0; i<100; i++) {

if (condition) return true;

}

return false;

• Avoid extra processing when result is known

Basic Language OptimisationsBasic Language Optimisations

• Inline functions – Convert:

void SmallCommonFn() {...};

– Into:inline void SmallCommonFn() {...};

• Calls are expensive for small frequent functions• Inline functions are expanded where they are used

– But compiler can ignore inline (especially large functions)

• Conflicts with cache optimisation– Try it and test performance – don’t use too much

• Put inline functions in .h files for best usage– Methods declared within a class are automatically declared inline

Basic Language OptimisationsBasic Language Optimisations

• Break into smallest steps– Convert:

if ((2*f / (j+10)) * pow(x,2) > 1) {...}

– Into:f *= 2; j += 10; float y = pow(x,2); f /= j;

if (f * y > 1) {...}

• Doesn’t specifically speed code up• But can clarify code for the compiler

– So it can do a better job of optimising the machine code

• Another case where you should try it and see

Basic Language OptimisationsBasic Language Optimisations

• Write in assembly language– Convert:

void SuperTimeCriticalFn();

– Into:MOV DX, 12ADD BX, CXEtc…

• If absolutely necessary, we could consider hand coding low-level functions in assembly

• However, modern CPU’s have very complex constraints for perfectly efficient code

• Compilers can produce better machine code than all but the most experienced humans

• Choice of data structures can have a more significant impact than code tweaks

• Use a structure that closely suits your needs– Need random access, but little or no resizing – use a vector or

array– Frequent addition/removal of nodes from anywhere, don’t need

random access – use a list– Only adding at the ends – use a queue– Also other data structures: e.g. (hash) maps

• Static structures (e.g. fixed arrays) might improve performance over dynamic ones– But check (e.g. vector has close performance to array)

Data Structure ChoicesData Structure Choices

Algorithmic ImprovementsAlgorithmic Improvements

• In nearly all complex cases, the best performance increase is a better algorithm– Unfortunately, difficult to give particular advice– Depends on specific problem

• Very simple cases:float f=a/2.0f; => float f=a*0.5f; // * is faster

int sum=0;

for (i=1; i<=N; i++) { sum += i; }

=>

int sum = (N*(N+1))/2; // Math simplification

Algorithmic ImprovementsAlgorithmic Improvements

• Research your problem first– Find existing solutions– Don’t reinvent the wheel (badly!)

• Then consider if you can:– Reduce nesting of loops (try to avoid 3 or more deep)– Reduce range of loop counters– Sort data into more convenient orders– Cluster similar cases into one case– Manipulate maths to reduce operations– Pre-calculate formulae (look-up tables)– Remove the code completely! (Do something different)

Optimisation QuotesOptimisation Quotes

Words of wisdom, in case you feel like starting optimising straight away

"Premature optimization is the root of all evil.“ Hoare and Knuth

"The First Rule of Program Optimization:Don't do it.

The Second Rule of Program Optimization (experts only):Don't do it yet.”

Michael A. Jackson

My ThoughtsMy Thoughts

• Optimising too much or too early is a problem

• Yet initial program design & architecture has a major impact on optimisation opportunities later

• Must at least consider, architecturally, what will need to be optimised later in development– And loosely how it will be done

• Put in place a flexible, yet optimisable framework– A major challenge to achieve both of these simultaneously

• However, don’t spend too much time early on considering optimising your project– Most projects don’t require it