Game Development Reference
In-Depth Information
to 6.68 ms. Benchmarking the tasking system separately showed about 1.5 ms
spent scheduling or about .3 ms of wall time (1.5 ms /4 cores). The animation
tasks appear to be running slower than expected. The excess execution time is
inside the animation tasks themselves. To analyze where that time is going, we can
decorate other parts of the system as we did with tasks. The most important code
to decorate is code that contains synchronization points such as memory allocation.
Withmemoryoperationsdecorated(
Figure17.5
)
,wecannowseewherethe
problem is. The model allocates memory during the animation phase. Memory
allocation is single threaded, thereby synchronizing all the various threads. There
are multiple ways to address memory allocation in tasks. The best case is to remove
the allocation. If that is not possible, perhaps the memory can be pre-allocated.
If it is memory only used in a single frame, a temporary heap could be used. The
temporary heap could allocate a fixed-size buffer and satisfy local frame allocations
and reset at the end of the frame. Also, using the context id provided by the
tasking system allows temporary per-hardware thread heaps, making them even
more ecient to allocate from.
The key take-away is to remove any OS synchronization points from inside task
functions. For this example, I will remove the allocation since it is not needed in
Figure 17.6.
Task-based versus single-threaded animation and no memory allocation.
