[Larceny-users] turning on optimizations

[William D Clinger]

Marijn wrote:
> Am I doing it wrong or is there something that is just not
> implemented yet here?

Larceny's benchmark-block-mode doesn't work, and hasn't for
some time.  The incremental compiler just ignores that switch,
but compile-file reports the error you encountered if that
switch is turned on.  We should delete that switch until we
fix it again.  I apologize for the time you wasted on it.

For a small program like the one you posted, you can get the
effect of block compilation by enclosing the definitions of
your program within a let, like this:

(define main
  (let ()
    (define (SPIN+) +1)
    ...
    (define (main delta-t measurements)
      ...)
    main))

For your program, in Larceny, that made little difference.
Gambit is probably performing some optimizations that Larceny
isn't.  For example, Gambit's compiler may notice that (N)
always returns the same result; Larceny's compiler doesn't.

In Larceny, you can profile your code like this:

> (require 'Debugger/profile)
> (profile (main 10 100))

That profile told me your program was spending a quarter of
its time in half-delta-E-for-flip and another quarter in expt.

Changing (N) to compute (expt (L) (D)) only once made your
program run 20% faster.

I noticed some mixed-mode arithmetic, so I used fixnum-specific
and flonum-specific operations to detect and then to eliminate
(most of) the mixed-mode arithmetic.  I also replaced the two
uses of the (apply + (map ... ...)) idiom with loops.  Those
changes made your program run about 40% faster in Larceny, and
would probably improve its performance in Gambit as well.

After those changes, Larceny's profiler told me the program was
spending 90% of its time in the init-sample procedure, which
includes the time spent in random-real.  That probably means
its performance in Larceny, following those changes, is limited
by the speed of Larceny's implementation of random-real.

Will