Re: [Algorithms] General purpose task parallel threading approach

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

 >> That's not really true, you can still execute other tasks the same way
in a
>> recursive manner (but keep away of dependencies on something up the
worker
>> thread's stack).
>I'm sorry, that statement makes little sense to me.
When a task gets blocked by a dependency, worker thread can start executing
other tasks recursively.


>that takes only a few hours to
>write/debug/test I'd always go for the later, so yes, that is
>*certainly* a generalization overhead I cannot afford.
I could always provide a special build without the stuff you are not going
to use. But if you think that the rest of functionality would really take
you a couple of hours to write/debug/test then of course you'd better go
with your own solution.


Alexander.



>~2k loc have a tendency to muck up performance, and other such things.
2009/4/15 Nicholas "Indy" Ray <ar...@gm...>

> On Tue, Apr 14, 2009 at 3:26 PM,  <asy...@gm...> wrote:
> > That's not really true, you can still execute other tasks the same way in
> a
> > recursive manner (but keep away of dependencies on something up the
> worker
> > thread's stack).
>
> I'm sorry, that statement makes little sense to me.
>
> > Besides, even if it would be fully true, then "the vast majority of the
> > functionality" is actually a ~2k of code which you never execute, is this
> a
> > "generalization" overhead you can't afford?
>
> ~2k loc have a tendency to muck up performance, and other such things.
> But alas, when I have to include 2k useless loc for functionality
> better provided by a specific library that takes only a few hours to
> write/debug/test I'd always go for the later, so yes, that is
> *certainly* a generalization overhead I cannot afford.
>
> Indy
>
>
> ------------------------------------------------------------------------------
> 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