Re: [Algorithms] General purpose task parallel threading approach

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

On Sat, Apr 11, 2009 at 6:23 PM, <asy...@gm...> wrote:

> But guys, I would really like to have your feedback on asynclib which I'm
> trying to make as generic as I can.
>  I need to know what functionality you want which I don't have. Would you
> like to override the scheduling part of the library ? Is there a
> functionality which you don't like how it was presented and so on?
>

I'm sorry, I guess we got side tracked.

I still haven't looked at the code (again, apologies), but if I understand
this correctly each task must have its own stack, rather than just executing
on the stack of the worker thread, is that right?
This seems expensive to me, and my point very early on that if you take the
approach of having lots of latent parallelism (for scaling, and to sort of
"smooth out" semi-random bubbles), the vast majority of tasks will not do
any "real" blocking (at a sync point, they'll usually just start executing
the tasks on their queue, and even if another threads steals a task you're
blocking on, it's not unlikely that it will be done by the time you need to
wait), meaning that optimizing for efficient blocking shouldn't be the
priority if it causes an additional cost on the spawning of the task itself
(i.e. having to allocate and fill-in a much bigger task frame then you'd
otherwise need).
I believe that the combined cost of spawning and running a task to be *the*
most crucial thing to optimize for, as it can never be parallelized and sits
squarely in the bottle neck.

That said, it would obviously be beneficial if the underlying threading
system running these tasks was as efficient as possible at switching for the
rare cases when you do get completely blocked, but I think that should be
handled at a different level (i.e. at the thread level). Perhaps using
Windows 7's user-mode scheduling (which I believe ConcRT is doing), or even
using your own system, but I don't think each task needs to be suspendable
if it implies *any* amount of extra cost in spawning them (however slight).


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