[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Tue, 12 Oct 2004 17:48:08 +0000 (UTC) 
Subject:Ackermann shootout (subject changed) 
From:A . Sloman 
Volume-ID: 

Brent

> As it turns out, it wasn't necessary to run the tests
> as they currently stand.  Certainly it will become
> more of a problem if we increase the size of 'N', but
> for now the default stack is sufficient.
>
> If you look at
> http://shootout.alioth.debian.org/bench/ackermann/,
> you can see that Poplog falls somewhere in the middle
> as far as CPU use, even beating such tail-call
> optimizing languages such as MzScheme, Guile, and even
> the byte-compiled implementation of Objective Caml!

Thanks for doing that. It's very interesting.

However, I think it would be best to replace the name
'poplog' in the 'shootout' test reports with 'pop11'
because the actual language you were using was pop11,
and poplog is the whole environment which includes
several languages.

> In general, the Pop11 Poplog versions of the tests
> tend to be slightly faster than the Lisp Poplog
> versions, but not by much.  I think that's quite
> amazing, and indicates that there is very little
> overhead in using a language implemented in Pop11 on
> top of Poplog.

Poplog Lisp compiles to the same virtual machine as Pop11 does.
As far as I recall the main reason why poplog CL is slower than
Pop11 is that the Common Lisp designers took the (bad) decision
not to have a boolean data-type and instead used the empty list
as false (for efficiency of list processing programs), whereas
Pop11 has false as a special entity.

This means that conditionals in Lisp have to be handled specially
in the poplog virtual machine.

Poplog common lisp does have some optimisation declarations.
(See LISP help optimize    == $usepop/pop/lisp/help/optimize )

When I looked at your pop11 code the only possible optimisations
that occurred to me were
    o remove output locals,
    o use the non-checking fast integer arithmetic operations,
    o declare the procedure name to be of procedure constant
        type:

I.e. instead of

define fast_ack (m, n) -> result;
   if m == 0 then
      n + 1 -> result
   elseif n == 0 then
      fast_ack(m - 1, 1) -> result
   else
      fast_ack(m - 1, fast_ack(m, n - 1)) -> result
   endif
enddefine;

use

define constant procedure fast_ack (m, n);
   if m == 0 then
      n fi_+ 1
   elseif n == 0 then
      fast_ack(m fi_- 1, 1)
   else
      fast_ack(m fi_- 1, fast_ack(m, n fi_- 1))
   endif
enddefine;

On a 1.5 Ghz pentium 4 running redhat linux, and
using calls of timediff the first version took
me 2.73 seconds cpu time for

    fast_ack (3, 10)
i.e.
    timediff() ->;fast_ack (3, 10),timediff() =>
    ** 8189 2.73

and 10.94 seconds for
    fast_ack (3, 11)

The optimised version was about 55% faster

    fast_ack (3, 10) took 1.52 seconds
    fast_ack (3, 11) took 6.19 seconds

(all times averaged over a small number of runs).

[Also the first version required pop_callstack_lim to be
inceased, for the longer test, presumably because of the
extra stack frame size with the output local.]

If the pop11 compiler were more intelligent it could get rid of the
output local from the compiled code.

> Another interesting outcome of this testing is that I
> achieved very good performance using very naive Pop11
> implementations of the tests.  I am no guru Pop11
> hacker; I basically tooko the Java implementations of
> various tests, launched the Emacs pop-mode and
> pop-help modes, and did a simple transalation.  So, it
> would seem that Poplog is a very forgiving system (you
> don't need to know a lot of ancient Poplog lore to get
> decent performance.)

And if you know what you are doing (and are careful) you
can get even better results. But never as good as the
best compiled lisp systems, or C.

On the other hand, the pop11 compiler is much faster than
most, which helps interactive development and testing, and
the garbage collector is very fast. Both of these contribute
to the fact that it takes less than 4 seconds on my machine
to compile all the source code for the common lisp extension
to poplog.

> I'm sure that the many Poplog experts on this list
> will have little trouble identifying ways of improving
> the performance of my simple implementations (and I
> sincerely hope that they do!).  What I think is very
> interesting is that Poplog performs so well,
> considering that many of the best performers are at
> their current scores because of the work of dozens of
> developers tweaking and adjusting the programs until
> they reached their current levels.

Well I'd be interested to see if my tweaks above can be
bettered!

Aaron
--
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )