🚀 go-pugleaf

In article <488@dcl-csvax.comp.lancs.ac.uk>, simon@comp.lancs.ac.uk (Simon Brooke) writes:
> In article <776@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
> >Xerox Lisp uses lists for bignums to this very day.
> 
> Yes, true. But please don't assume this means it is efficient.

Well, no, I didn't assume that.  I was replying to a message which claimed
that "Lisp" didn't use lists for bignums any more.

> For
> example, I recently benchmarked a Xerox 1186 running Interlisp (Koto)
> against the new Acorn Archimedes running Arthur Norman's Cambridge Lisp.
> Generally the Arch was a bit faster, reflecting the simpler lisp and
> faster processor. But running (fact 1000) it was 321 (three hundred and
> twenty one) times faster - and this must reflect grotesque inefficiency in
> Xerox' bignum code.

If it was "recently", didn't you have the Lyric release?

I am shocked to hear that the Archimedes was only "a bit faster".
As you can easily find out if you have Xerox Quintus Prolog, it is a _lot_
faster at list processing than Xerox Lisp is.  I would have expected
Cambridge Lisp on a RISC to be about as fast as XQP.  What's wrong?

The (fact 1000) test may reflect only the simple fact that the
Archimedes has a 32-bit ALU, whereas the Xerox 1186 has a basically
16-bit ALU.  It is easy to pull apart an Interlisp bignum and see what
is inside.  It is a list of FOURTEEN-bit 2-s complement integers.  It
works out at about 0.4 data bits per stored bit.  The vector approach
should get about 1 data bit per stored bit.

Another possible consideration is storage turnover.  (fact 1000) requires
over 8500 bits to represent [about 266 32-bit words, but about 610 list
cells].  The Xerox D-machines are not noted for their paging performance.
Did you make sure that all the relevant code was paged in before
measuring the performance of (fact 1000)?