[m-users.] Parallel Mercury

[Paul Bone]

On Tue, Nov 29, 2016 at 12:15:06PM +1100, Julien Fischer wrote:
> 
> 
> On Tue, 29 Nov 2016, Paul Bone wrote:
> 
> >On Tue, Nov 29, 2016 at 11:43:36AM +1100, Julien Fischer wrote:
> >>
> >>Hi Paul,
> >>
> >>On Tue, 29 Nov 2016, Paul Bone wrote:
> >>
> >>>On Tue, Nov 29, 2016 at 11:23:13AM +1100, Julien Fischer wrote:
> >>
> >>>>Although it's not hugely useful for fib, is '--par-loop-control' in a
> >>>>usable state?  (i.e. could it be enabled by default, or at least
> >>>>documented?)
> >>>
> >>>To the best of my memory, it worked with our tests so far, but it had not
> >>>been tested widely.
> >>
> >>It's not going to be tested widely if nobody knows it exists.  I suggest
> >>we at least publicly document it (perhaps marking it as experimental).
> >>
> >>'--control-granularity' and '--implicit-parallelism' are also options
> >>that those experimenting with parallel conjuction should be aware
> >>(although they are at least documented).
> >
> >I don't remeber exactly what --control-granularity does, it may have been
> >relevant to Jerome's work which mine replaced wholesale.
> 
> Jeromes' work is controlled by the '--distance-granularity' option.
> '--control-granularity' was implemented by Zoltan, and does the
> following:
> 
>      Find every parallel conjunction G1 & G2 & G3 & ... & Gn in the given
>      module, and replace it with a goal that tests at runtime whether there
>      are enough free CPUs to make parallel execution worthwhile, and if not,
>      executes the conjunction sequentially instead.
> 

Ah, that's right!

This also means that this is the one that _should be_ compatible with
--implicit-parallelism, that is, it should run after implicit parallelism
introduces its parallel conjunctions.

It's worth taking another look at the runtime condition.  I probably changed
it as I changed how the runtime worked/organised its work queues.


-- 
Paul Bone
http://paul.bone.id.au