Re: [Algorithms] General purpose task parallel threading approach
Brought to you by:
vexxed72
Menu
▾
▴
Re: [Algorithms] General purpose task parallel threading approach
|
From: <asy...@gm...> - 2009-04-13 22:11:06
|
>4 MB feels like a lot given console memory limits, but allowing 2000 >tasks in flight sounds pedantic You have full and complete control over memory. There is no limit on the number of tasks (there is a limit on minimum and maximum task size - 32 bytes minimum and about 4megs maximum per task) >This mechanism can't support SPUs, >right? You mean task suspension or complete library port? In general only windows x86 and x64 platforms are supported now. Other platform support will start appearing as soon as people will start showing interest in it. Alexander 2009/4/13 Adrian Bentley <ad...@gm...> > 4 MB feels like a lot given console memory limits, but allowing 2000 > tasks in flight sounds pedantic. This mechanism can't support SPUs, > right? > > Cheers, > Adrian > > On Mon, Apr 13, 2009 at 11:08 AM, <asy...@gm...> wrote: > >>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 > > > > > ------------------------------------------------------------------------------ > > 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 |
