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

by Mike Gleicher on September 20, 2012

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
Print Friendly, PDF & Email

Previous post:

Next post: