From: John Baugh
Subject: Numerical Programming in Common Lisp
Date: 
Message-ID: <477@PT.CS.CMU.EDU>
Anyone using Common Lisp for numerical programming?  I'm about to embark
on a project that involves writing equation solvers (linear and nonlinear),
eigen-solvers, and the like in Common Lisp.  Any words of advice?  I'll
probably be using either Lucid or KCL, but I'm more interested in some
kind of gross measure of the capabilities of Common Lisp in general versus
other languages (Fortran, C) for numerical programming.  BTW, pointers to
any existing numerical packages in Common Lisp would be appreciated.

John Baugh (···@cive.ri.cmu.edu)

Always remember: eschew obfuscation.

From: ·······@uiucdcsb.cs.uiuc.edu
Subject: Re: Numerical Programming in Common Lis
Date: 
Message-ID: <168700008@uiucdcsb>
 I was intrigued by your remark that your "number-crunching" runs 100 times
 slower on a SUN than on a Symbolics, and wa just curious to know if
 1) your SUN lacked a numeric co-processor assist;
 2) the Symbolics benefited from similar assists.

 -- Thank you.

 Scott (·······@uiucmsl)
From: Douglas J Roberts
Subject: Re: Numerical Programming in Common Lis
Date: 
Message-ID: <13334@beta.UUCP>
In article <·········@uiucdcsb>, ·······@uiucdcsb.cs.uiuc.edu writes:
> 
>  I was intrigued by your remark that your "number-crunching" runs 100 times
>  slower on a SUN than on a Symbolics, and wa just curious to know if
>  1) your SUN lacked a numeric co-processor assist;
>  2) the Symbolics benefited from similar assists.
> 
We have also run comparisons between Symbolics and Suns. We have a
large discrete event simulation running on top of KEE (Knowledge
Engineering Environment) that was developed on Symbolics hardware (an old,
upgraded 3600 with an IFU). There is a fair amount of floating-point
computation as well as a lot of symbolic computation in this
application. When we loaded up the application on a Sun 3/260 we found
that it ran ~1.2 times slower (80% as fast) as it did on the Symbolics. 

I was therefore surprised that someone else had noticed a 100-fold speed
difference in LISPs between the two machines. We found that the Sun
run-time was very sensitive to the paging space and the application
memory image size. If either of these was too small, the application
would garbage-collect itself into the ground. Perhaps this was a
contributing factor to the above-mentioned 100-fold speed difference.

--Doug
-- 
---------------------------------------------------------------
			Doug Roberts
			····@lanl.gov
---------------------------------------------------------------
From: Malcolm Slaney
Subject: Re: Numerical Programming in Common Lisp
Date: 
Message-ID: <485@spar.SPAR.SLB.COM>
In article <·········@uiucdcsb> ·······@uiucdcsb.cs.uiuc.edu writes:
>
> I was intrigued by your remark that your "number-crunching" runs 100 times
> slower on a SUN than on a Symbolics, and wa just curious to know if
> 1) your SUN lacked a numeric co-processor assist;
> 2) the Symbolics benefited from similar assists.

My Sun has a FPA but the last time I checked neither Franz or Lucid would
generate code for it.  This is not really surprising since the overhead 
involved in their current floating point code swamps any benefits of using
the FPA.

The benchmarks I have done of the Symbolics FPA and IFU show it to only
speed up our applications by 40% each.  This is a long way from a couple
orders of magnitude.

The problem with the old Sun Lisp compilers is that they had a lot of
overhead when dealing with floating point numbers.  Lucid has shown us
a compiler that for simple arrays and the Barrow/Gabriel FFT benchmark
generates code that runs nearly as fast in Lisp as it does in C (within
about 20%)!  Unfortunately, we have had problems seeing this speedup on
our real programs.  Lucid is working with us on this problem.  Franz also
claims to have solved this problem but I haven't had a chance to play
with their code yet.

Now, I wonder when they are going to do something about complex arithmetic?

Cheers.

								Malcolm