Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!im4u!milano!mcc-pp!patrick
From: patrick@mcc-pp.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: LISP floating point performance
Message-ID: <2774@mcc-pp.UUCP>
Date: Fri, 13-Mar-87 09:46:29 EST
Article-I.D.: mcc-pp.2774
Posted: Fri Mar 13 09:46:29 1987
Date-Received: Sat, 14-Mar-87 09:24:52 EST
References: <1368@hplabsc.UUCP> <31800002@ccvaxa> <150@utah-orion.UUCP>
Organization: MCC, Austin, TX
Lines: 43
Summary: efficiency and self-fulfilling prophecy

In article <150@utah-orion.UUCP>, shebs@utah-orion.UUCP (Stanley T. Shebs) writes:
> In article <31800002@ccvaxa> aglew@ccvaxa.UUCP writes:
> >Using foreign functions as an excuse for not providing efficient floating
> >in LISP is a cop-out.
> 
> There's one place where I'd definitely want to use foreign functions -
> to call the irrational and transcendental functions in the 4.3 BSD libraries.
> They are *hot*.  Certified performance and everything - ...
> so efficiency of Lisp floating point is not as important.
> 
> 							stan shebs
> 							shebs@cs.utah.edu
I agree that good foreign function interfaces is a good thing.
However, it is not a substitute for in-line floating point performance.
There should be no reason that a good Lisp compiler could not
be made to generate identical code to a good Fortran or C compiler for
performance critical portions of a program, given enough type declarations,
etc.  The failure of Lisp compilers to match this performance
continues to give numerical hackers excuse to poo-poo Lisp as
a language for doing "serious" work in.  Thus, the attitude that
floating point performance is not important because noone uses
Lisp for floating point stuff becomes a self-fulfilling prophecy.

While we are on the subject of performance, I have noticed that
defstructs are implemented as arrays in a number of Lisp environments.
This approach means that several bounds/limit/type checks are necessary
for each structure access.  A special type for structures would
allow all of these checks to be replaced by a single check for
structure type.  If the structure type matches then by definition
the structure field would be a legal access.  Even Lisp machines
with all their supporting hardware require several memory references
to access an array.  With hardware type checking, only one reference
would be required, while without it, two references might be needed.
(While I may be a little off on the exact details, I expect such
a change could cut the average time for a structure access in half.)

This feature may be overlooked by compiler writers since
the Gabriel benchmarks do not include structure accesses.

However, current programming style for objects and frames indicates
structure accesses could occur even more frequently than list access.

- Patrick McGehearty (McGehearty@MCC.COM)