[m-dev.] for review: MLDS back-end: library fixes

Fergus Henderson fjh at cs.mu.OZ.AU
Wed Dec 8 01:29:27 AEDT 1999


On 07-Dec-1999, Mark Anthony BROWN <dougl at cs.mu.OZ.AU> wrote:
> Fergus Henderson writes:
> > +++ library/benchmarking.m	1999/12/06 14:40:18
> > +		(time_at_last_stat - time_at_start) / 1000.0
> > +
> 
> There is an extra line here.

Fixed.

> > +:- impure pred benchmark_det_loop(pred(T1, T2), T1, T2, int).
> > +:- mode benchmark_det_loop(pred(in, out) is det, in, out, in) is cc_multi.
> 
> I don't understand why this is cc_multi.  Couldn't you make
> this procedure det, and call cc_multi_equal in benchmark_det/5
> before returning the time?

Yes, that is a much better idea.  Well spotted.
I changed the code exactly as you suggest.
The new code looks like this ("|" in the left column
denotes the changed lines):

	benchmark_det(Pred, In, Out, Repeats, Time) :-
		impure get_user_cpu_miliseconds(StartTime),
		impure benchmark_det_loop(Pred, In, Out, Repeats),
		impure get_user_cpu_miliseconds(EndTime),
|		Time0 = StartTime - EndTime,
|		cc_multi_equal(Time0, Time).

	:- impure pred benchmark_det_loop(pred(T1, T2), T1, T2, int).
|	:- mode benchmark_det_loop(pred(in, out) is det, in, out, in) is det.

And likewise for benchmark_nondet_loop.

The fact that it was cc_multi in my original code was in fact
a cut-and-paste error: I wrote the mode declaration for
benchmark_det_loop by copying the mode declaration for
benchmark_det and deleting the last argument, and I forgot
to consider whether the determinism `cc_multi' was appropriate
for the new procedure.

Perhaps we should enable full determinism inference all the time,
ignoring the declared determinism during the inference process,
and then warn if the declared determinism is less general than
then inferred determinism.  That would have caught this mistake.

(Currently for procedures which have their determinism declared,
we do only a single pass of determinism inference, using the
declared determinism for recursive calls.  That means that we
don't catch these kinds of problems for recursive procedures.
We do however catch them for non-recursive procedures.)

Thanks for the reviewing.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list