[m-users.] Parallel Mercury
paul at bone.id.au
Tue Nov 29 12:18:16 AEDT 2016
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
> >>>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
> 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.
More information about the users