[mercury-users] Is Mercury as fast as C?

[Ralph Becket]

> I was impressed with the section "Determinism" in the manual. The
> ability of the compiler to know about the number of solutions in
> advance is a huge step forward from a blind interpreter chasing
> unification after unification without any expectations on the outcome
> of the search.

Just to be precise here, the compiler only checks for upper and lower
bounds (0, 1, some, any) on the number of solutions a predicate can 
have for a given mode.

> The question therefore arises: although it is well-known that Mercury
> is several times faster than any Prolog that has ever been written,
> does it solve problems that we have C programs for as fast as C? If
> not, why not?

I reimplemented a SPEC'95 benchmark doing memory-to-memory LZW
compression.
The program was less than 30% the size of the C code, far more readable,
and was less than 50% slower.  The best guess reason for the 50% penalty
is the current use of a conservative garbage collector; a native GC that
understood the types of the objects would have a negligible impact on
performance (a native GC exists, but there are issues to do with using
such
a thing with programs that link against code written in other
languages.)

In practice, however, you'll probably find that the difference between
Mercury and C on programs of any size is fairly small.  I wouldn't be at
all surprised to see Mercury outperform C++ and Java on several
benchmarks.

Cheers,

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
--------------------------------------------------------------------------