Re: [Algorithms] General purpose task parallel threading approach

[<asy...@gm...>]

>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?

That's true, each task by default runs in its own stack space. But you can
always switch to thread's stack and execute your code there, in this case
you only need 32 bytes for the task and you loose magic task-suspending
ability.  There is a minimal task sample demonstrating this behavior

>majority of tasks will not do any "real" blocking
By "blocking" I mean any kind of a way to control task behavior in regard to
other tasks and resources. This can be anything from shared resource access
to task dependency resolving. There are also many exotic situations, for
example where you would like limit number of tasks running simultaneously on
some region of the code, or you want to explicitly switch a set of tasks on
some code region, or you want to process a set of tasks which have reached
some place in the code at some point in time.
Apparently, even in games, I have seen many situations where it proved to be
really useful (especially in the background asset streaming code), and
improved task throughput by a significant amount.

>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).
You should also know that there is no cost for a feature if you don't use
it. If you don't use blocking, don't wait on other tasks to finish - there
is no overhead. Task startup (after scheduler decides what to execute) is a
matter of several assembly instructions in itself.

>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
That's exactly what I target, except that I also optimize rare cases as well
(since "rare" for games is not that rare for some other problem). If you
decide to try the library out, and will suspect some part of it speedwise -
just let me know.

>but I don't think each task needs to be suspendable if it implies *any*
amount of extra cost in spawning them (however slight).
No extra cost, really ;).


Alexander



2009/4/11 Sebastian Sylvan <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
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Regards,
Alexander Karnakov