Re: The -O option

On 02/19/2014 01:40 AM, Richard A. O'Keefe wrote:
> Recently I've been trying to improve the performance
> of some Prolog code.  One part of it manipulated
> subsets of a small known universe as lists.  I decided
> to replace this by bitwise operations.  For example,
>	Set /\ (Set - 1) =\= 0
> lets you test whether a set has 2 or more elements.
> To my astonishment, this made the code take *more*
> time and *more* memory.
>
> Then the light-bulb went on.  "I need the -O option!"
>
> That made all the difference: the code now ran 30%
> faster, allocating 30% less memory.
>
> As long as version 7 is making major changes to the
> core language, this might be a good time to make
> the -O option the default.
>
> I do appreciate that SWI wants to recover the original
> term representing a clause, but it could be done like
> this:
>
>	begin_fast_arithmetic L1
>	<optimised code>
>	end_fast_arithmetic L2
>     L1:  <unoptimised code>
>     L2:
>
> The execution engine can treat begin_fast_arithmetic
> as a no-nop and end_fast_arithmetic as an unconditional
> branch, while the decompiler can do it the other way
> around.

In fact, the problem with -O is not that it cannot be decompiled. It can
(although the body might come out a bit different from what went in).
The problem is that the tracer cannot act on it. Of course, the trick
above can solve that too.

Surely worth considering. In my experience the difference between -O and
not is typically small and sometimes even reverse. The latter is odd
because -O definitely does less work. It might be caused by more cache
misses because the active part of the VM gets bigger.

Another bad reason is that many benchmarks are small programs doing
a remarkable amount of arithmetic and there -O really helps ...

Note that :- set_prolog_flag(opmtimise,true). enables optimization for
(the remainder of) the file in which it appears.  That should be a good
work around.

	Cheers --- Jan