Re: [Algorithms] General purpose task parallel threading approach

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

>Do you really think the memory overhead required will scale to the
>number of tasks people are talking about using here?
Keep in mind that the amount of memory occupied is computed as number of
executing tasks + number of suspended tasks. If you want, you can limit the
number of tasks which are active (i.e - suspended) at the same time. In this
case if you hit the limit, some amount of tasks (how many - you can control)
will be processed to free up memory for other tasks. There is a sample which
demonstrates this approach (called "allocator").


Alexander.

2009/4/13 Adrian Bentley <ad...@gm...>

> It may be that the specific state machine solution is not any faster
> because you're operating directly in the restored general stack (e.g.
> trade memory for perf).  However, jumping around to lots of different
> task stacks seems like it might have a negative effect on cache
> behavior.
>
> Do you really think the memory overhead required will scale to the
> number of tasks people are talking about using here?
>
> Cheers,
> Adrian
>
> On Sun, Apr 12, 2009 at 4:56 PM,  <asy...@gm...> wrote:
> > Explicitly coded state machines have less memory overhead indeed. But
> coding
> > them and further supporting them takes a lot of time.
> > And what slight efficiency overhead do you mean ?
> >
> > Alexander
> >
> > 2009/4/13 Adrian Bentley <ad...@gm...>
> >>
> >> It sounded like your mechanism has similar downsides as fibers (i.e.
> >> much higher memory overhead, slight efficiency overhead) vs.
> >> explicitly coded state machines and such.  Unless I'm confused, that
> >> would probably be a deal breaker for the majority of our code.
> >>
> >> Cheers,
> >> Adrian
> >>
> >> On Sat, Apr 11, 2009 at 10:23 AM,  <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?
> >> >
> >> > Alexander.
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
>
>
> ------------------------------------------------------------------------------
> 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