Intel Threading Building Blocks

Improving on the First Solution

Naturally, we wondered what we could do to improve our newly parallel program.

What’s wrong with using parallel_for in this example, you ask? The problem is that the applications that would use ODE are dynamic: the number of objects in the scene changes, the number of islands also changes over time, and so on. It’s hard to come up with a good grainsize parameter for parallel_for. Also, the more objects you have, the more time you spend searching for islands. What if we could make the island processing overlap with other operations? Our prototype does not allow this to happen, and it becomes a major problem.

The task scheduler interface is a natural place to go when you have a dynamic ability to find more tasks. Islands make good tasks, but in the parallel_for structure they are not balanced well because they pop up as surprises.

We created yet another class, process_one_island (Example 11-60), that has a class task as a parent. We overrode the pure virtual execute method where we just called dInternalIslandStepFast for the given island. So, we just described our own logical task.

Tip

Aha! Slipping in a task when you can identify work is easy and can be very powerful.

We wanted processIslandsFast to spawn tasks. To do this we needed to create a root task. We wrote a new class for this root task, process_world, which would just call a modified processIslandsFast (processIslandsFastTask, shown in Example 11-61). The modified processIslandsFast needed to be ...