[mercury-users] New to mercury: structure reuse and efficiency

[diffense]

Ralph Becket <rafe at cs.mu.OZ.AU> wrote:

>A few years ago I re-implemented the SPEC95 LZ compression benchmark
>(129.compress, IIRC) which ran at about 66-77% of the speed of the C
>implementation (the Mercury compiler might even do better than that
>these days), which is so highly hand tuned that it might as well be in
>assembly language.  If you need that level of performance, it's quite
>possible to obtain it in a Mercury program.

>You can code in an imperative fashion in Mercury (see e.g. the array.m
>and store.m library modules, which should run at the same speed as
>arrays and pointer graphs in C, modulo bounds checking etc.), although
>it isn't necessarily comfortable to do so.  The thing is that then you
>have all the problems that go with imperative programming, which often
>necessitates making *explicit* copies of data structures.

I agree, and I am relucatant to program imperatively in mercury. That gives up
many of the advantages I'm trying to gain. 

>Except for rare cases we simply don't notice performance as a problem in
>practice.

>Nancy Mazur has been working on structure reuse for her PhD and I
>believe this work is nearly complete; this work currently resides in an
>experimental branch of the compiler source tree.

>My next major project is to fix mode analysis so that the compiler
>properly supports uniqueness.  The challenge here is to make the
>analysis fast enough that it doesn't make the compiler unacceptably
>slow.  We've had two previous attempts at tackling the problem (the
>analyses worked, but were too slow) and I believe I now know how to do
>it efficiently.  My aim is to have this working by the end of the year.

It's great to hear that work is still continuing. I was wondering how active
the mercury development community is now. 

>My sincerest advice is to not worry about efficiency: if you're going to
>use a purely declarative language, we reckon Mercury is as good as
>anything else that's out there.  

As I began looking for a functional/logic language to use it just turned out
that mercury (which I had overlooked initially) fit the criteria of speed,
purity, minimalism and expressiveness that I had set. Unfortunately there is a
much larger volume of information on how to program in ML, Haskell, Clean or
Scheme making mercury a bit more of a challenge to learn. If I ever manage to
understand it enough I'll have to help change that.

A little more information on mercury's operational semantics would have been
great. For instance, in the example below, is the not(X=Y) necessary? IMO, it
is very important (from a programmers perspective) to understand how the
execution environment attempts to prove predicates.

member([H|T], H).

member([H|T], X) :- not(X=Y), member(T, X).

>In my experience, success comes from
>first getting a naive, working program, then using the profiler to
>identify where optimization effort should be spent.

Thanks for the advice and the prompt response.

-- Ralph
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------





--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------