jwb@CIVE.RI.CMU.EDU (John Baugh) (12/10/87)
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 (jwb@cive.ri.cmu.edu) Always remember: eschew obfuscation.
malcolm@spar.SPAR.SLB.COM (Malcolm Slaney) (12/10/87)
In article <477@PT.CS.CMU.EDU> jwb@CIVE.RI.CMU.EDU (John Baugh) writes: >Anyone using Common Lisp for numerical programming? Yes, we (the speech understanding group at Schlumberger) are doing all of our number crunching in Common Lisp. We have a very extensive environment written in Common Lisp that is currently running on Symbolics, Suns (both Franz and Lucid) and Xerox D machines. As far as performance goes......I have seen some floating point benchmarks that show Lucid Lisp (on a Sun-3/160) doing FFT's within 20% of the speed of a Symbolics machine or the same algorithm written in C (on the 160.) Unfortunately, you have to put declarations in the right spot and if you use displaced arrays you might have problems. As it stands now our package is running about 100 times slower on a Sun than it does on a Symbolics machine. Lucid (and I assume Franz) and SPAR are working on this. For more information on this package drop me a note or see: Kopec, Gary, "The Signal Representation Language SRL", IEEE Transactions on Acoustics, Speech and Signal Processing, Vol ASSP-33, August 1985. Kopec, Gary, "The Integrated Signal Processing System ISP", IEEE Transactions on Acoustics, Speech and Signal Processing, Vol ASSP-32, August 1984. Cheers. Malcolm
malcolm@spar.SPAR.SLB.COM (Malcolm Slaney) (12/15/87)
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