Re: [Algorithms] General purpose task parallel threading approach

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

On Sat, Apr 11, 2009 at 2:44 AM, Jon Watte <jw...@gm...> wrote:

> So I'm saying you, as the component writer, don't need to worry about
> spawning at all. Tasks are created by the system, to resolve the
> semantics as described by the system.


I do need to worry about specifying what's parallel and what isn't (unless
I'm in a language where this can be automatically deduced - which C/C++
isn't), and if since I can't do that in a dynamic way your system isn't
flexible enough to run generic code.


> Having the programmer create
> deadlocks and races and global dependencies willy-nilly sounds to me a
> lot like writing your code in assembly. Very last-century, and not where
> the industry is going. I believe the computer can actually make more
> sense, and schedule your dependencies better, than you can.


I don't believe the computer can violate the laws of mathematics to do it,
which means that in order for your ahead-of-time scheduler to work it *must*
severely restrict the kinds of control flow I can have.


> >     Which is why the scheduler must be dynamic!
> >
> >
> > Precisely!
> >
>
> At least we agree on something :-)


Yes, unfortunately I can't seem to explain adequately to you that a system
that requires all dependencies to be known up front is not actually dynamic
in any meaningful sense of the word.


> If you're not doing at least some AI reasoning each frame, then you're
> not using your cores right :-)


I'm doing AI reasoning every frame, but every frame each task will only go
through exactly one trace through my AI processing routine (not both
branches of an if-else for example), which means that there might be many
*potential* dependencies, that are not *actual* dependencies. I may cast a
ray to an off-screen object to see if my laser hits, but if I miss the
bounding sphere I don't actually need to spawn a task for computing the
animation of the object - and even if that animation is needed for something
else and will be computed anyway, at least I won't be blocked for it to
finish, improving throughput.


> . I don't think
> I'll convince you that your problem is "too old-school to solve," and I
> don't think you'll convince me that my problem is "too high-level to be
> useful."


My criticism of your approach is hardly that it's too high level. Quite the
opposite! I'm saying that it is, as a matter of mathematical fact, not
flexible enough to run code with dynamic control flow, because by definition
you can not know dependencies ahead of time for such code. Dynamic control
flow *requires* an on-line scheduler - yours isn't.
Restricting the use of dynamic control flow is the opposite of "high level"
as it restricts the use of fairly ubiquitous things like virtual functions
(when you call a virtual function you can't know what dependencies that call
will have ahead of time as virtual functions are dynamically dispatched -
you just have to make the call and see where you end up).

That might be fine for some parts of your program, however, saying "I'm fine
with restricting expressiveness/abstraction for code that needs to run in
parallel" might be okay today, but in the future that will be synonymous
with "I'm fine with restricting expressiveness/abstraction everywhere",
which IMO would be a big mistake.

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