Do I need batched parallel programming?

Viewed 46

I'm writing a raytracer with EM-processing (radar application). The following is done for many different simulation locations of the radar:

  1. raytracing, generates a lot of data
  2. EM-postprocessing, generates a scalar and then deletes the raytrace data

Each simulation point will be encapsulated in its own instance of a class (all grouped in a std::vector) with a specification of the radar location for that simulation point, references to data it will only read (shared by all simulation points), and properties for storing its results (so each simulation point has its own). Because of this setup I thought I could benefit of using a for_each loop with std::execution::par_unseq policy without taking further measures. Correct?

The problem however is that the raytracing generates so much data that, when for example having 10 thousand simulation locations, I may run out of memory when the scheduler decides to do all the raytracing first because it is allowed to do so with par_unseq. So my idea was to write a normal for loop which feeds an inner parallel for_each loop with, say, 100 simulation points at the time. Is this an optimal solution for my case? Or did I totally misinterpret how parallel things work?

1 Answers

Quoting the standard, §25.3.3/8, one can find (emphasis mine):

The semantics of invocation with execution​::​unsequenced_­policy, execution​::​parallel_­policy, or execution​::​parallel_­unsequenced_­policy allow the implementation to fall back to sequential execution if the system cannot parallelize an algorithm invocation, e.g., due to lack of resources.

So implementations are allowed by the standards to fall back to sequential execution if they hit a resource hog.

Related