Re: The -O option

On 19/02/2014, at 10:13 PM, Jan Wielemaker wrote:
> 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.

Glad to hear that.
> 
> 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.

If the difference is typically small, there can be little
harm in using -O.  The problem is that anyone coming from
say SICStus (or Quintus before it) is going to expect
arithmetic on immediate integers like this:

	S /\ (S - 1) =:= 0
	S1 is S0 /\ M, S2 is S0 /\ \(M)

to do no allocation, and the performance difference is NOT small.
In fact the code I'm trying to improve works with two (kinds of)
sets, both of which could use the set-as-bits technique.  The
30% slowdown caused by the lack of -O with just one set done
that way could well look a lot bigger if the rest of the
allocation mostly went away.

Even with -O, the program is limited by the allocation rate,
which on this Core 2 Duo Mac came out as 72 MB/second.
> 
> Another bad reason is that many benchmarks are small programs doing
> a remarkable amount of arithmetic and there -O really helps ...

This was not a benchmark.
> 
> 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.

There are two problems:

(1) My non-benchmark program ran badly because -O wasn't the default.

    -O and :- set_prolog_flag work around that.

(2) This came as a nasty *surprise*.  Once the surprise happened,
    I then remembered -O (but not :- set_prolog_flag, so had to
    quit and recompile the program), tried an experiment, and
    found that was the cause.  If I hadn't been aware of the
    issue, I would probably never have figured out what to do
    about it.

    -O and :- set_prolog_flag(optimise, true) are _not_ a
    workaround for this problem, having to know about them
    _is_ the problem.


I do agree that programs that are hit as hard as this one
are likely to be rare.  But this exacerbates problem (2).




(1) The serious cost if a program legitimately does do a
    lot of arithmetic.
(2) The fact that you *have* to do something to get a
    compilation mode which doesn't violate your
    expectations.