[mercury-users] How efficient is mercury?

Ralph Becket rafe at cs.mu.OZ.AU
Tue Apr 13 11:00:24 AEST 2004


Maurizio Colucci, Sunday, 11 April 2004:
> Hi everybody,
> 
> Could someone please tell me how efficient is Mercury compared to Objective 
> Caml? I need to write a videogame (I will be writing some predicates in C for 
> interfacing with Opengl and Qt).

That's a tricky question to answer.  First off, please *don't* use Doug
Bagley's now-defunct "Great Computer Programming Language Shootout" web
site to compare languages: the benchmark implementations for some
languages (e.g. many of the Mercury ones) are somewhat naive, depending
upon the implementer's familiarity with the language, and in many cases
the site even compares different algorithms with different complexities
(although you have to read the source code to see that this is the
case.)

The main difference between OCaml and Mercury is that Mercury is a
purely declarative language whereas OCaml makes it easy to mix
imperative and functional programming styles.  The Mercury philosophy is
that combining the two styles makes it more likely that programs will
contain bugs (it's much harder for the compiler to automatically
identify errors), can inhibit optimisation (for similar reasons), and
can reduce reusability (shared state has a tendency to spread throughout
a program.)  That said, Mercury does allow you to embed impure code in
your program provided you explicitly label it as such.  Mercury also has
a world class foreign language interface and works very well with a
number of C compilers, including Visual C.  You can use imperative
structures such as arrays and pointer graphs in Mercury, but being
purely declarative means that doing so incurrs some syntactic overhead
(i.e. your programs will be a little longer, but should run just as
quickly.)

In terms of raw performance, I would expect Mercury and Clean to be very
close to one another, with Clean perhaps having a slight edge: I believe
the OCaml compiler generates its own object code and hence may use a
more efficient calling convention and garbage collection scheme than is
possible when compiling via C (which is what the Mercury compiler does
at present.)  How this affects linking with other C programs and
libraries, I don't know.

To give you some anecdotal evidence, about three or four years ago I
rewrote the SPEC95 LZ compression benchmark from C to Mercury.  The
resulting program was vastly simpler, as you'd expect, and the highly
tuned C program was only 30% faster than the Mercury program.  Today we
might even do better than that.

Hope this helps,
-- 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
--------------------------------------------------------------------------



More information about the users mailing list