benchmarking Mercury vs Visual Prolog

Fergus Henderson fjh at cs.mu.oz.au
Sat Nov 8 07:47:11 AEDT 1997


Hi,

I downloaded the demo (30-day) version of Visual Prolog the other day.
It's a very nice environment.  The compiler is very fast, turn-around
time for small modules is basically instantaneous (fast enough for
me to recompile each time after fixing the first error).
There's lots of support for Windows resources, generating different
sorts of executables (DOS, DOS-Extended, Win-16, Win-32, even OS/2).

I noticed a few changes to the language since I last looked at Turbo
Prolog 1.0.  One is that they have extended their determinism
categories to match Mercury's; as well as their previous `nondeterm'
(nondet) and `determ' (semidet) categories, they have added `procedure'
(det), `multi', `erroneous', and `failure'.

Another is that they now have higher-order procedures.
And functions (although the syntax they use for defining
functions is as if the function was a predicate, and
also they don't support tail recursion optimization for
functions -- it seems to be a bit of a kludge, mainly
intended for interfacing with C functions).

So it looks like our work has not been ignored ;-)

The most striking weakness is that their type system is still
monomorphic except for a few special cases (e.g. lists, findall/3,
write/N).

I ran only one benchmark, time to find one solution to 9-queens.
Obviously we should run some more benchmarks before jumping to
any conclusions, but if the results are anything like these
initial results, then we don't have anything to fear from them
as far as performance goes.

				
	System		OS	Compilation model	Speed ratio
	------          --      ----------------- 	-----
	Visual Prolog	Win95	DOS (16-bit)		1.0
	Mercury		Linux	asm_fast.gc		5
	Mercury		Linux	asm_fast		23

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



More information about the developers mailing list