🚀 go-pugleaf

In article <755@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <1703@sics.se>, seif@sics.se (Seif Haridi) writes:
>> Of course I was using the original Prolog program written by Evan.
>> The results are as follows:
>> 
>> 1. Quintus Prolog compiled in 14 seconds
>> 2. The FIRST SURPRISE: SICStus Prolog compiled in 10 seconds
>> 
>Clarification please:  do you really mean "compiled" or did you mean
>"executed"?  While the time it takes to compile something is of very great
>practical interest, that's not the point of this particular example.
>
>A general note:  a few easy measurements will show you that a large chunk of
>the time it takes Quintus Prolog to compile a file actually goes into reading
>the characters.  This is due to Quintus Prolog's support of user-defined
>streams.  If SICStus Prolog doesn't support user-defined streams, the result
>ceases to be surprising.  (Not that we don't find such results motivating!)

Hi Richard

I am sorry that I was not clear in my description. I was not really
interested in the behaviour of the program on sequential Prologs. Here is
a clarification:

The time it took to execute the program after compiling it with Quintus
Prolog is 14 seconds while the execution time of the same program using
SICStus is 10 seconds. Quintus compiler is much faster than SICStus compiler
on this problem. The reason why SICStus execution time for this program is
better than Quintus, I guess, is because the program creates large
structures with many common substructures. SICStus Prolog deep unification
which supports unification of cyclic structures handles this situation
better than usual unification algorithms. For any common substructure
SICStus unification will usually  be performs once regardless of the number of
occurrences of the common substructure.

	Seif