[comp.lang.prolog] Speed comparison between Quintus and BIMProlog

phant@cpsc.ucalgary.ca (Thong Phan) (10/17/89)

We have Quintus Prolog version 2.4.2, and using Naive Reverse, 
its peak performance is about 288 KLIPS (for Sun-4 computers).
Recently, we heard claims that BIMProlog (sp?) have ~400 KLIPS
when running under SparcStations (no mention of CPU speed).
Which leads to the following questions about the performance of 
Quintus Prolog and BIMProlog (newest version)

1) Are there significant differences between Quintus and BIMProlog?

2) What are their peak performances in KLIPS (for SparcStations)?
   Using Naive Reverse? Using Concat/Append? 
   (Is there any reference to the exact/accepted definition of LIPS?)

3) How about their memory requirements?

4) Generally, which one is faster for large program with lots of
   asserts and unifications (runtime approx. 2-3 days)?

I'm greatly appreciate answers from people with experience with
either one, especially with BIMProlog, running under SparcStations
and/or Sun-4.

Thong.

--
 Thong H. Phan 				Dept of Cpsc, Univ of Calgary
 phant@cpsc.UCalgary.CA			Alberta, Canada, T2N 1N4

ok@cs.mu.oz.au (Richard O'Keefe) (10/18/89)

In article <1932@cs-spool.calgary.UUCP>, phant@cpsc.ucalgary.ca (Thong Phan) writes:
> We have Quintus Prolog version 2.4.2, and using Naive Reverse, 
> its peak performance is about 288 KLIPS (for Sun-4 computers).
> Recently, we heard claims that BIMProlog (sp?) have ~400 KLIPS
> when running under SparcStations (no mention of CPU speed).

> 1) Are there significant differences between Quintus and BIMProlog?

Probably.  BIM have a native code compiler, Quintus haven't.
There are tradeoffs involved:  native code tends to be faster, lots
bigger, and non-portable.  (Yes, I do mean that you can use the
same Quintus ".qof" files on a Sun-3, a Sun-4, and a VAX.)  You
have to decide which factors are more important to you.  Depends on
how much memory your system has, whether you have a heterogeneous
network, and so on.


> 2) What are their peak performances in KLIPS (for SparcStations)?
>    Using Naive Reverse? Using Concat/Append? 
>    (Is there any reference to the exact/accepted definition of LIPS?)

The exact definition of LI/s is "496 divided by the time in seconds to
reverse a 30-element list using naive reverse".  Any other purported
"LIPS" rating is bogus.  This one is pretty well useless.  The different
LI/s rating tells you that BIM_Prolog runs naive reverse about twice as
fast as Quintus Prolog, but it doesn't tell you what the relative speed
of YOUR program will be.

> 3) How about their memory requirements?

BIM native-compiled code is likely to be quite a bit bigger than Quintus
compiled code.  Whether this matters depends on how much other memory
your program needs; if you are building huge dynamic structures on the
stacks it may not make much difference, if you have an enormous program
with very little run-time data it may be critical.

> 4) Generally, which one is faster for large program with lots of
>    asserts and unifications (runtime approx. 2-3 days)?

It depends.  The most significant feature is likely to be the quality
of your code:  making it purer and doing fewer asserts and retracts is
going to help both Quintus Prolog and BIM_Prolog.

If you want to know which of the two Prolog systems is likely to perform
better with your code, there is only one thing which you can do to find
out:  get an evaluation copy of each (Quintus provide 30-day evaluation
copies, I imagine BIM do something similar) and try the actual systems
you are considering on your own actual program on real data.  Amongst
other things, the relative speed of two systems may depend on the amount
of paging they do, and the cost of that depends on whether you are paging
to local disc (how big? how fast?) or over the network (how heavily loaded
is the swap space server? how much contention for the net?), and that is
going to depend on the general configuration and workload of your site.
Someone else's experience may be misleading.

Get evaluation copies and TRY them.