Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[shebs@utah-cs.UUCP (Stanley Shebs)]

In article <473@harvard.ARPA> Stavros Macrakis writes:

>The point was simply that in fact MacLisp numeric code is not all that
>it's cracked up to be, and indeed if you want efficient number-crunching
>you use some other language.  Fortran happens to be the language in
>terms of which the original argument was couched.  Given what I know of
>the internals and the I/O behavior of both the Maclisp compiler and the
>Intermetrics AIE Ada compiler (I work part-time there), I suspect that
>it too will produce better numeric code but also non-numeric code
>(including handling recursion, linked lists, etc.) than Maclisp.
>Regrettably, garbage collection was not funded in the AIE.
>
>Having worked with Lisp for 14 years now, I think I have some idea of
>its strengths, which in my opinion are being diluted by pretending it is
>just a general-purpose language with a funny syntax and poor
>type-checking.

There were a lot of people at AAAI that had worked with Lisp for a long
time and whose Lisps were beaten by PSL in the Gabriel timing tests.
Lisp is a sufficiently high-level language that implementation tricks
buy you a lot.  The problem seems to be that really efficient Lisp
requires so MANY tricks that it strains normal hacking practice to
include them all (thus my own research on accountable knowledge-based
implementations).

>Here's an example of the `wealth' of datatypes from a member of the
>Common Lisp committee: "Common Lisp arrays are incredibly complex....
>The resulting tangle of types...is clearly a political compromise and
>not something that would exist after careful design". [RA Brooks and RP
>Gabriel (an very experiencied Lisp implementer), "A Critique of Common
>Lisp", 1984 ACM Symposium on Lisp and Func. Prog.; an excellent paper,
>by the way]

Actually, I was just pointing out that real Lisps have more than
just integers, symbols, and pairs.  In any case, I think it's 
interesting that languages intended for many different uses get 
so large - PL/I, Common Lisp, Ada...  Everybody complains about
it, but I don't know that it's such a bad thing.  At least in CL,
90% of the hair can be coded using a simpler Lisp - the purpose
of the standard is just to ensure that everybody's utilities look
alike, and that portable programs don't need to carry 10,000 lines
of libraries around (including a 69th implementation of defstruct,
looping macros, formatting functions, ad nauseam).  CL is about the
same size and complexity as a PSL (which is generally considered 
to be a "small" Lisp) with all the loadable stuff brought in.

>>  For many years, the Maclisp compiler on the DEC-20 has produced
>> numerical code superior to Fortran. -- stan shebs
>
>This is not and never was true.  See my previous posting.  As for poor
>Common Lisp, "it requires either specially micro-coded machines, a
>fantastically complex compiler (which relies on copious declarations
>from the poor incompetant user), or very slow running time." [ibid]

I was wrong and I apologize if I misled anyone.  However, I personally
don't believe the statement about CL (except maybe the part about the 
compiler being complex!).  After all, didn't people used to believe 
that Lisp is inherently a very slow language?

>Lisp is a wonderful language, but it has never run numbers fast.  It is
>even less likely to run numbers, or anything else, fast, in its current
>PL/I-like phase of development.

The PSL group here has a pretty good compiler under development.  The
old PSL compiler (which did so well on the Gabriel timing tests) is
pretty crude by comparison...  We're also looking at ways to make
CL run as fast as PSL.

One final note:  an Ada person accusing Common Lisp of being too
big and complex is definitely a pot calling the kettle black.

						stan shebs