Presentation is loading. Please wait.

Presentation is loading. Please wait.

Maths & Technologies for Games Optimisation for Games 1 CO3303 Week 4.

Similar presentations


Presentation on theme: "Maths & Technologies for Games Optimisation for Games 1 CO3303 Week 4."— Presentation transcript:

1 Maths & Technologies for Games Optimisation for Games 1 CO3303 Week 4

2 Today’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

3 What 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

4 Optimisation 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

5 Optimisation 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

6 When (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…

7 Performance 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…

8 Compiler 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

9 Basic 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

10 Basic 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

11 Basic 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 2 nd case above, if the simple condition is true, then the complex condition will be skipped – saving time

12 Basic Language Optimisations Passing by reference –Convert: void DoStuff( BigStruct myStruct ) {...} –Into: void DoStuff( BigStruct& myStruct ) {...} or void 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)

13 Basic 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

14 Basic 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

15 Basic 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

16 Basic Language Optimisations Write in assembly language –Convert: void SuperTimeCriticalFn(); –Into: MOV DX, 12 ADD BX, CX Etc… 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

17 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 Choices

18 Algorithmic 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

19 Algorithmic 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)

20 Optimisation Quotes Words of wisdom, in case you feel like starting optimising straight away "Premature optimization is the root of all evil.“ Hoare and KnuthHoareKnuth "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

21 My 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


Download ppt "Maths & Technologies for Games Optimisation for Games 1 CO3303 Week 4."

Similar presentations


Ads by Google