How to Measure Performance
Measuring performance in a scalable game is very easy from an end user’s point of view. The gaming experience keeps getting better as more cores are added. But it is more important here to look at the developer’s point of view, which is much more complex and will allow us to understand scalability in the full game.
Two types of overhead must be considered. The first overhead is observed in the threading primitives used. Here, there are also two types: when it recurs on every frame, synchronizations are an example, and when it depends on game play, task stealing is an example.
The second overhead concerns the additional computation needed in the threaded version. For example, if a game did not have a k-d tree and it was added just to provide a spatial decomposition, all computations with this tree would be overhead. In the ideal case, this type of overhead would vary no more than linearly with the number of threads. If this is the case, the overhead for one thread would be zero or almost zero.
Table 11-3 summarizes the aforementioned techniques in terms of the four-tiered overhead scale: not-good (the best of the four), bad, terrible, and worst.
Table 11-3. Summary of the techniques examined
|
Cost scale |
Description |
|---|---|
|
Not-good |
Creating a task and executing it on the same thread |
|
Not-good |
Getting an uncontended lock |
|
Bad |
Getting a contended lock |
|
Bad |
Creating a task graph |
|
Terrible |
Task stealing; if it occurs, it will disrupt cached data |
|
Terrible |
Data parallel ... |