Re: Limiting parallelism using futures, parallel forms and fibers

[Chris Vine]

On Fri, 10 Jan 2020 01:43:18 +0100
Zelphir Kaltstahl <address@hidden> wrote:
> Hi Chris!
> 
> On 1/8/20 12:44 PM, Chris Vine wrote:
> > On Wed, 8 Jan 2020 08:56:11 +0100
> > Zelphir Kaltstahl <address@hidden> wrote:
> > [snip]
> >> So my questions are:
> >>
> >> - Is there a default / recommended way to limit parallelism for
> >> recursive calls to parallel forms?
> >>
> >> - Is there a better way than a global counter with locking, to limit the
> >> number of futures created during recursive calls? I would dislike very
> >> much to have to do something like global state + mutex.
> >>
> >> - What do you recommend in general to solve this?
> > I think you have it wrong, and that futures use a global queue and a
> > global set of worker threads.  I don't see how futures could work
> > without at least a global set of worker threads.  Have a look at the
> > futures source code.
> 
> So far I did not write any parallel code in my project. I am only
> exploring possibilities, finding out what I should be using. I also
> could not think of a good way to limit the number of threads to anything
> less than the (current-processor-count) value, but thought maybe someone
> knows something I did not see or read about Guile's futures yet : )

I still don't understand why you think you want to do that, given the
aims you set out in your earlier posts.  Why do you want to spawn less
than (processor-count - 1) threads for your algorithm, which is what
futures would use?

But if you really want to do that, and you don't want to use a
stand-alone thread pool, the parallelism keyword of fibers seems to do
what you want.