[m-dev.] Large MR_join_and_continue() macros in runtime.

[Paul Bone]

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.

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20091120/d62aecec/attachment.sig>