🚀 go-pugleaf

In article <458@laas.laas.fr> paul@orion.laas.fr (Paul Freedman) writes:
>
>what i'd really like are stats for database manipulations 
>such as assert/1, retract/1, bagof/3, setof/3, retractall/1, etc.
>
>(yes, i'm aware that comparing interpreted and compiled Prologs
>isn't fair

If your program uses assert/retract heavily then compiled Prologs may
well be as slow or slower than interpreted Prologs.  However, the good
news is that getting rid of the side effects by rewriting the program
generally results in a significant speedup in compiled Prolog, and code
which is easier to debug, transform, parallelize etc, etc.

One example I looked at when I visited SICS last (northern) winter was a
little theorem prover called Satchmo.  It used assert in a very neat way
- if there are nice uses of assert this is one of them!  I rewrote it
so it passed around a data structure everywhere and updated that
instead of using assert.  The timings for MU-Prolog (an interpreter
which is ~20% slower than CProlog) seem to totally vindicate the use of
assert (a factor of more than 5):

	version with assert and retract
MU-Prolog				163

	version with structure passed around
MU-Prolog				849

However, even with this particularly nice use of assert, the faster
Prolog systems perform better when assert is avoided:

	version with assert and retract
Sicstus emulated			 79
Sicstus native code			 88
Quintus					148

	version with structure passed around
Sicstus emulated			133
Sicstus native code			 41
Quintus					 61
BC Prolog (or-parallel Sicstus)		153	77	32	19
				#cpus =	1	2	4	7

One of the many advantages of the "clean" version was that is was
trivial to get it running on an or-parallel version of Sicstus and get
7 times the speed of normal emulated Sicstus using 7 processors (there
was consistent "super-linear" speedup).

	lee