Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

On Mon, Apr 13, 2009 at 6:42 PM, Mat Noguchi <mat...@bu...> wrote:

>  Again, there is a tremendous difference between allowing dynamic task
> dependencies within a frame vs. between frames vs. not at all.
>
>
>
> Although it’s really a matter of whether you can separate how you generate
> dependencies between tasks from running the task. If you can, then it
> doesn’t matter when you spawn them, so you should spawn them where you can
> get the most benefit with the least complexity. If you can’t, then you have
> to make an even better scheduler just to take into account intra-frame
> tasks.
>

I agree completely with this. I'm not saying that a system like Jon
describes is useless (indeed I've already explained that I've written
something similar, even more restricted in fact, myself), I'm just pointing
out that it's rather limited in some important ways that other systems
aren't.

> Of course it doesn’t work with a C++-vtable-dispatch mechanism; that does
> not allow you to separate the behavior of the task from the structure (i.e.,
> dependencies) of the task. What Jon is talking about (I presume) is that
> tasks are not just vtables or function pointers; they have information
> associated with them that allows for higher order reasoning without running
> them.
>

Yeah sure, and that's kind of the point, that kind of code (which is
fairly ubiquitous IME), and even simple if-statements (where the two
branches spawn different tasks) couldn't be written in such a system. You
may not need to, which I fully accept, but if you could have the option of
doing it without losing anything significant (again, performance for
cilk-style dynamic parallelism seems to be bounded by the theoretical
parallelism of the app, i.e. critical path etc., not implementation
overheads) that would seem like a very attractive option.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862