Lecture 6: (9/20) Tech for Games (more efficiency stuff)

Last time: how to accelerate some things – but didn’t get to “concrete”
Today: why to accelerate some things (and to use fancy tech in general) – but in the abstract

Link: brainstorm about really practical things in efficiency (to be a little project related)

Start: This is the games technologies class, is is a CS class

• Is technology needed for games?
• Is technology useful for games?
• Is the technology different for games?

• Where does tech help in games?
• Why is this different  than regular CS stuff?
• Why are games hard to write? (tradeoffs are different)

Connect to project 1:

1. In project 1: WHY might you want to deal with performance issues?
2. What kinds of performance issues might you have (even w/scalability)
3. What might you do about it (specifically and in general)

You have a performance problem – your system slows with N boids

1. is it a problem? why?
2. is it a scalability problem?

What do you do about it

1. AVOID – is it really a problem? do you really need N boids?
2. UNDERSTAND – premature optimization is an evil
   • worse: different type of performance problems need different solutions
   • where is the bottleneck?
   • what kinds of bottleneck is it
   • what are my constraints
3. EXPERIMENT – part of understanding
4. Know your choices
   1. low level cleaning
   2. fancy cleverness
   3. ad hoc hacks
   4. approximation and cheating

Example:

Flocking is too slow

• at what point does it become a problem?
• does it really show n^2 behavior?
• is n big enough that n^2 –> n log n makes a difference
  • reducing computational complexity often raises constants

give collision loops

1. polish (caveat – compiler does stuff, readibility)
2. use really fancy solutions
   1. ANN
   2. beware constants and other costs
   3. beware assumptions (dynamic data structures)
3. try a hack
   1. radix sort in 1 dimension / buckets
   2. helps? – not provably, but EXPECTED / AVERAGE case?
      1. may really care about worst cases
      2. unexpected costs
   3. tricks
      1. 2nd dimension bucket only if lots in the first (pros/cons)
      2. don’t re-bucket each time (raise radii)
      3. use old buckets and hope for the best
4. try a “bad” hack
   1. subsample
   2. fairness
   3. what does this do?

What is “Correctness” – it’s not like banking software!

Performance Debugging and Correctness Tuning

1. Tradeoffs in Interactive Graphics (from 2007)

• Speed
• Quality – but what does this mean?
• Authorability
• Generality
• Scene Complexity

What Quality means changes depending on application

• Accurate modeling of reality
• Subjective realism
• The “look” that we want
• Stylization
• Avoiding artifacts

Why might this be different in games?

• Accuracy not an issue
• Generality might be a tradeoff (organize rooms a specific way)
• Artistic tradeoffs
• Need to provide specific mood/feelings (to get affect)
• Need to be attractive

Bad visuals can destroy sense of immersion / suspention of disbelief.

5. General performance tricks

Fast programming

Use performance analysis tools to find hotspots

• if you’re lucky, inner loops can be identified (or at least common ops)
• don’t optimize things that aren’t called much

Beware low-level optimizations

• architectural changes can make things become obsolete

Performance Tricks:

• Use best algorithms – beware of constants (if your data is small)
• Avoid computing what you don’t need
  • don’t compute everything
  • late filling / caching (but beware cache validation strategy)
• Avoid data conversions
• Beware memory access patterns
  • caches
  • alignment
• Avoid excessive memory accesses
• Beware excess arithmetic in inner loops (for array accesses)
• Pre-fetching (to “warm” memory caches)
• Loop unrolling
• conditional branches / prediction penalties
• the evolution of the CPU pipeline
• what can (or can’t) be in registers
• beware of memory allocation / deallocation
  • growing datastructures
  • lots of allocs (consing in the loop)
  • pre-allocation