Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!hplabs!hplabsc!kempf
From: kempf@hplabsc.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: LISP floating point performance
Message-ID: <1368@hplabsc.UUCP>
Date: Mon, 2-Mar-87 11:23:33 EST
Article-I.D.: hplabsc.1368
Posted: Mon Mar  2 11:23:33 1987
Date-Received: Tue, 3-Mar-87 21:43:08 EST
References: <16921@glacier.STANFORD.EDU>
Organization: Hewlett-Packard Laboratories
Lines: 38
Keywords: floating point, efficiency, LISP
Summary: foreign function calling

In article <16921@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU (John B. Nagle) writes:
> 
>     Floating point computations in current LISP implementations tend to
> be unnecessarily slow.  While PDP-10 MACLISP may have exhibited excellent
> floating point performance, several of today's popular LISP implementations
> definitely do not.  Although Common LISP contains means of providing the
> compiler with enough information to permit the generation of in-line code
> for floating point operations, many compilers do not use this information
> effectively.
> 
>     So I pose the following question:
>     Is there a Common LISP for SUN or VAXen which, given enough declarations,
> will generate code for, say, a matrix multiply which does not contain any
> subroutine calls, boxing, unboxing, storage allocation, type checking, tests,
> stack manipulation, or other unwanted fooling around within the inner loop?
> I'm not asking for the strength reductions for nested loops one expects from
> a good FORTRAN compiler; just good clean code.
>     
> 					John Nagle

I think most people who want to do good floating point would tend to
want to code the numerical part in C or FORTRAN, or, better yet,
use an existing FORTRAN library, like IMSL, where they don't need
to code anything at all, but simply reuse an existing library.
The existence of good foreign function calling capabilities in
modern Lisps makes this an attractive option to coding the entire
application in Lisp. This allows developers to use Lisp for symbolic
processing, which most existing implementations do well, and use
C, FORTRAN, or a FORTRAN library for numerical code, which these
implementations tend to stress. This would argue for improving
foreign function calling to make it as fast and as CONSless as
possible.

Not that good floating point optimization for Lisp isn't an interesting
problem, but, as a practical matter, there are other ways to achieve
the same result which may be less expensive in the end.

		Jim Kempf	kempf@hplabs.hp.com