[m-rev.] for review: Implement unify/compare of tuples in Mercury.
Peter Wang
novalazy at gmail.com
Mon Jul 7 17:58:27 AEST 2014
On Mon, 7 Jul 2014 17:39:56 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>
> Hi Peter,
>
> I haven't had time to review this fully, but there's one rather obvious
> thing wrong with. In principle the change is fine by me -- can you now
> deep profile prince?
Yes (not heavily tested).
> On Mon, 7 Jul 2014, Peter Wang wrote:
>
> > Branches: master
> >
> > The hand-written C unify and compare predicates for tuples did not preserve
> > deep profiler invariants correctly across the recursive unify/compare of
> > tuple arguments. I tried to do so, and failed. Instead, implement the
> > predicates in Mercury so the compiler can perform the deep profiling
> > transformation on them. Bug #3.
> >
> > A micro-benchmark on my machine is about twice as fast in asm_fast.gc
> > after this patch, and equally fast in hlc.gc. The change to the
> > high-level C backend is only to reduce code duplication.
> >
> > I seem to have hit an unrelated bug in compare_representation so I did
> > not implement the compare_representation predicate for tuples yet.
> >
> > library/builtin.m:
> > Add `unify_tuple' and `compare_tuple' predicates.
> >
> > Add module initialisation predicate which sets
> > `MR_special_pred_hooks' to point to those predicates.
>
> That won't work. You need to ensure that they are registered *before*
> any user code (such as module local initialisers) can be called. So the
> right way to do it is as part of io.init_state.
Oh, right.
Perhaps there should be an overall library initialiser in library.m
which then calls initialisers in builtin.m and io.m?
Peter
More information about the reviews
mailing list