Lately, I've been thinking of ways to use multi-threading to improve the speed of different parts of a game engine. What confuses me is the appropriate granularity of threads, especially when dealing with single-instruction-multiple-data (SIMD) tasks.

Let's use line-of-sight detection as an example. Each AI actor must be able to detect objects of interest around them and mark them. There are three basic ways to go about this with multithreading:

  1. Don't use threading at all.
  2. Create a thread for each actor.
  3. Create a thread for each actor-object combination.

Option 1 is obviously going to be the least efficient method. However, choosing between the next two options is more difficult. Only using one thread per actor is still running through every object in series instead of in parallel. However, are CPU's able to create and join threads in the granularity posed in Option 3 efficiently? It seems like that many calls to the OS could be really slow, and varying enormously between different hardware.


1 Answer 1


You forgot a very important variant in your list:

#4 Create a threadpool (size = number of physical CPUs) and distribute small tasks to them (e.g. each actor-object combination).

This assumes that the task at hand is CPU-bound. Hence there is nothing to win if you use more threads than there are CPUs. Using more threads only adds the overhead of thread scheduling. This also assumes, that you can split / join your tasks without to much locking overhead.

  • \$\begingroup\$ Makes sense, seeing as pretty much all these super-granular tasks are purely calculation. \$\endgroup\$
    – jmegaffin
    Dec 11, 2012 at 20:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .