Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site mit-bug.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!mit-bug!dove
From: dove@mit-bug.UUCP (Web Dove)
Newsgroups: net.lang,net.lang.lisp
Subject: Re: Re: Using LISP for scientific programming? (gasp!)
Message-ID: <375@mit-bug.UUCP>
Date: Mon, 21-Oct-85 12:53:28 EDT
Article-I.D.: mit-bug.375
Posted: Mon Oct 21 12:53:28 1985
Date-Received: Tue, 22-Oct-85 06:25:55 EDT
References: <1057@sdcsvax.UUCP> <1418@umcp-cs.UUCP> <1071@sdcsvax.UUCP> <3785@garfield.UUCP> <86@mit-eddie.UUCP> <2018@hcrvax.UUCP>
Reply-To: dove@mit-bugs-bunny.UUCP (Web Dove)
Distribution: net
Organization: MIT Digital Signal Processing Group
Lines: 25
Xref: watmath net.lang:1863 net.lang.lisp:587

In article <2018@hcrvax.UUCP> petera@hcrvax.UUCP (Smith) writes:
>
>	One thing that is ineffecient when using LISP for numeric computations
>is that on many machines a new cell is created for a new value of any numeric
>type. This means that any loops etc that increment values or do any kind of
>numeric computations will result in a trail of old values waiting to be 
>collected. I suspect that unless you specificially request that the cell 
>itself be modified any LISP implementation of a lengthy numerical operation
>will have to do a fair bit of garbage collection.  Bottom Line? A simply
>coded numerical algorithm in LISP will require as much or more garbage 
>collection than any other LISP program and certainly more garbage collection
>than most FORTRAN programs do (ie none).
>
>		Peter Ashwood-Smith
>		Human Computing Resources,
>		Toronto, Ontario.


You should be aware that the SYMBOLICS 3600 fits 32bit floats directly in
the pointer field of objects, so for single precision there is no 
garbage.  Such a capability does seem to be essential for fast numerical
analysis in lisp.

For your info, I have seen a 1024 complex fft on a 3600 take 120 ms
versus 90 ms for an equivalent C program on a vax 785.