>>109679312
I'm reading this and either it's silly or I simply don't get it. It sounds like a Big Idea for a New Paradigm, but what he describes is very standard and just like the job systems he eschews at the start of it.
>let me write the most complicated example of parallel_for to sum an array. see how bad it is?
If your code is more complicated than
const Integrator = struct {
bodies: []Body,
dt: f32,
fn step(self: *Integrator, range: Range, context: Context) void {
_ = context;
for (range.begin..range.end) |i| {
const body = &self.bodies[i];
const velocity = add(body.velocity, mul(dt, body.acceleration));
body.velocity = velocity;
body.position = add(body.position, mul(dt, velocity));
}
}
};
// later
var work: Integrator = .{ .bodies = bodies, .dt = dt };
scheduler.run(Integrator.step, "integrate bodies", &work, .{ .count = bodies.len, .min_grain = 256 });
you're probably doing something wrong.
there can then be one main thread that continually fans out these "bursts" and is otherwise serial. context contains a worker ID if you're running over a colored graph or something.
A bigger problem that seems unaddressed is latency-bound tasks. If you "go narrow" and block that's a wasted compute worker for however long it takes. a barrier at the end makes the frame stall.
