🚀 go-pugleaf

Tim Lindholm writes

>Bart Demoen writes:

>> The implementation of ProLog by BIM has no "unsafe" variables (this wasn't true
>> in 1984, otherwise there wouldn't have been the need to invent the trick). It
>> was the idea of Herman Crauwels (no longer at BIM) to get rid of them. Some
>> people claim that not having "unsafe" variables, is a bad idea. Anybody
>> interested in discussing this in this news group ?

>Quintus has (and likes) unsafe variables.  Years ago as a study for release
>3.0 I modified a QP system to get rid of unsafe variables (by immediately
>globalizing them -- I hope that's what we are talking about!).  The system
>also recorded stack "high water marks", the maximum size of the stacks for
>a given run.  We expected to see additional global stack required, and were interested in >getting some estimates of how much more would be used.

>We were quite surprised that on a range of examples (compiling code, running
>our test suite, running CHAT-80 and various other tests) that global stack 
>usage increased substantially, by 50-100% across the majority of examples we tested.  This >increase also caused runtime penalties due to increased stack shifting and GC.

>This seemed so unacceptable that we didn't even bother to tune the system to
>measure what performance increase we might expect.  Bart, do you have any estimate of the >performance BIM gained (and Quintus gave up) by abandoning
>unsafe variables?

Since about three years the VAM (Vienna Abstract Machine) stores unbound variables
on the global Stack. In the optimized version the stack size grow by about 15%
(4.44% to 26.40% depending on the benchmark (small benchmarks, prolog compiler,
meta interpreter, theorem prover)). The optimized version eliminates the creation
of unbound variables for builtin predicates like for the result of is. If the bips
creates unbound variables too the stack size grows by additional 36% (1.37 to 94%).

Storing unbound variables on the global stack was a great win for the VAM. The
optional trail test was simplified (only one comparison). The last call optimization
speeded up due to the elimination of checking the stack frame for unbound variables
and self references. The number of unbound variables is smaller in the VAM than in
the WAM (Warren Abstract Machine). So the grow of stack sizes can not compared
directly.

-- Andi
-- 
Andreas Krall, andi@mips.complang.tuwien.ac.at
+431 58801/4477  fax +431 5057838
Technische Univ. Wien, Inst.f. Computersprachen E185/1
Argentinierstr.8/4, A-1040 Wien Austria