[m-dev.] Large MR_join_and_continue() macros in runtime.
pbone at csse.unimelb.edu.au
Fri Nov 20 10:36:43 AEDT 2009
On Thu, Nov 19, 2009 at 11:00:31AM +1100, Peter Wang wrote:
> On 2009-11-18, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> > There's a less obvious argument against doing this. MR_join_and_continue uses
> > MR_GOTO to jump to the join label, or to tailcall MR_do_runnext (via the
> > MR_runnext macro). This means that this code can't easily be made into a C
> > function, not without returning from it and then using MR_GOTO.
> Right, the C function won't work.
> > Alternatively we can use the asm_fast execution model and make this a low-level
> > C mercury procedure, (see MR_do_runnext for an example). This is also
> > non-trivial, since MR_join_and_continue takes arguments we would want to place
> > these arguments in abstract machine registers, this requires changes to the
> > code generation for MR_join_and_continue and doesn't look like too much effort.
> > This is my preferred option.
> > What do you think? Which option(s) do you prefer? Leaving it as a macro,
> > making it a C function or making it a Mercury low level C procedure?
> It's up to you. Probably the Mercury low level procedure is best, and
> easier to work on. On micro-benchmarks the overhead of a parallel
> conjunction *might* increase.
I'll be making this a mercury procedure today. I won't bother benchmarking it
as the effect on performance will be negligable when compared to other work I'm
yet to do such as work stealing. If parallel conjunctions seem slow at a later
stage we can investigate why.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 489 bytes
Desc: Digital signature
More information about the developers