Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!ut-sally!utah-cs!utah-orion!shebs
From: shebs@utah-orion.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: LISP floating point performance
Message-ID: <151@utah-orion.UUCP>
Date: Fri, 13-Mar-87 15:31:47 EST
Article-I.D.: utah-ori.151
Posted: Fri Mar 13 15:31:47 1987
Date-Received: Sat, 14-Mar-87 09:22:13 EST
References: <1368@hplabsc.UUCP> <31800002@ccvaxa> <150@utah-orion.UUCP> <2774@mcc-pp.UUCP>
Reply-To: shebs@utah-orion.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 85

In article <2774@mcc-pp.UUCP> patrick@mcc-pp.UUCP (Patrick McGehearty) writes:

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

There is one reason - interactive capability.  If you add enough type
declarations to make the code pass around raw floating point numbers,
then your poor old READ-EVAL-PRINT loop isn't going to be able to deal
with the raw number.  This means that the compiler must be very careful
to add type info when talking to the non-optimized parts of the system.
For instance, suppose I have a function (in CL)

(defun foo (x y)
  (declare (float x y))
  (let ((z (* x y)))
    (if (< z 0.0) (error "~S is the wrong number" z))
    (* z z)))

Yes, I can optimize the multiplications, infer that z is a float, and
optimize the comparison - BUT the reference to z in the error message
must be to a typed object!  Getting this right is hard, and could easily
double the size of the compiler.  If instead of (error ...) I called, say,
(foo z), then I must know ahead of time that foo takes only floats, or
I'll have to add the type info in order to ensure correct behavior.
This requires more declarations than a C program would have, because
C assumes ints, and most everything in C looks like an int :-).

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

Obviously you should use PSL/PCLS, in which a structure reference turns
into one or two machine instructions if all the optimizations are turned
on.  Forget debugging in that situation though!

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

Check out TRAVERSE.  Granted, there could be more and better benchmarks,
but after all the abuse RPG took for the incredible work he did,
I doubt anybody else is going to stick their necks out for quite a while!

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

Amen!  but change "could" to "do".  Unfortunately, much of current Lisp
Machine designs are based on performance studies by Clark and Green about
ten years ago, in which their sample programs were using lists to simulate
arrays and structures (such things not being available then).  Needless
to say, cdr-coding to speed up cadddr etc looked like a good thing to do
at the time....

>- Patrick McGehearty (McGehearty@MCC.COM)

I wonder if people generally appreciate the amount of work that goes into a
Lisp system.  It's easy to write a small Lisp compiler in Lisp - we even
gave one as a two-week assignment in last fall's intro Lisp class.  It's
not too much harder to write a fairly good C compiler - compiler classes
do it all the time.  However, a good Lisp compiler is *much* harder, partly
because the language is higher-level, and partly because there are more
conflicting requirements.  I've alluded to interfacing vs efficiency
above, there is also the issue of safety.  If in a C system you add two
integers that overflow and wrap around and cause a core dump, everybody just
sort of shrugs and comments on how the program core dumped so quickly :-).
Similar behavior in a Lisp system is met with howls about brain-damaged
compilers and incorrect semantics... this is just the compiler, the runtime
system is bigger and just as complex!  The sensitive implementor gets gray
hairs trying to find a compromise, while many others get truculent and
suggest that you should be using specialized hardware, or that people
doing floating point deserve to use Fortran, or even that you should never
care about execution speed.  I've heard everything, at one time or another.

The moral is that really efficient high-level language implementations (I'm
including Prolog, Smalltalk, etc here too) are still research projects, and
if you want them, you're going to have to shell out a few extra bucks to
researchers (like me :-) ) to come up with the best techniques...

							stan shebs
							shebs@cs.utah.edu

PS I wasn't kidding about the money - we've got a hot successor to PSL
in the works, but are running on an eyedropper-full funding-wise...