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