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

[macrakis@harvard.ARPA (Stavros Macrakis)]

I don't mean this to go on forever, but Maroney's gross distortion of my
point forces me to:

> That seems like some pretty dumb code to put in Lisp.  Iteration, setq --
> yech!  I don't think any person in their right mind would disagree that
> Fortran-like or Algol-like languages are far better suited to this style of
> programming than Lisp.
> Now, let's see you write a recursive linked-list program in Fortran, which
> doesn't have stack-based calling, pointers, or anything remotely like
> structured data types.... -- Tim.Maroney@CMU-CS-K

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.

> The most sophisticated Lisps (such as Common Lisp) include a wealth of
> other datatypes intended for high efficiency in applications. -- shebs

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]

>  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]

> There was an informal experiment done in the early-mid seventies at
> MIT [: a] translator was written to translate (say) FORTRAN into
> MACLISP....  In every case the lisp versions ran faster and took up
> less memory....  The programs being used were purely [numerical]. --
> sasaki@harvard

This is the same error being repeated.  Fateman's 1974 SIGSAM Notes
article seems to be the source.  There was exactly one example given,
and my previous posting discusses why it did well.

Indeed, Macsyma has both a Fortran-to-Lisp translator (written by Kent
Pitman) and a numerical-Fortran-code-generator.  They are both useful:
F-L to import numerical libraries into Lisp (unfortunately the runtime
conventions apparently clashed too much to allow Fortran code simply to
be linked in); Macsyma-F to use symbolic results to generate Fortran
programs which were then run on other machines.

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.

	-s