Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!cornell!batcomputer!pyramid!decwrl!spar!malcolm
From: malcolm@spar.SPAR.SLB.COM (Malcolm Slaney)
Newsgroups: comp.lang.lisp
Subject: Re: Numerical Programming in Common Lisp
Summary: Lisp on Suns is Sometimes Slow (Reasons)
Message-ID: <485@spar.SPAR.SLB.COM>
Date: 14 Dec 87 20:36:55 GMT
References: <477@PT.CS.CMU.EDU> <168700008@uiucdcsb>
Reply-To: malcolm@spar.UUCP (Malcolm Slaney)
Organization: SPAR - Schlumberger Palo Alto Research
Lines: 30

In article <168700008@uiucdcsb> mccaugh@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