From bjl@cs.purdue.edu Wed Jun 11 14:37:34 EST 1997 Article: 22035 of comp.lang.scheme Path: purdue!not-for-mail From: bjl@cs.purdue.edu (Bradley J Lucier) Newsgroups: comp.lang.scheme Subject: Scheme and Numerical Programs Date: 11 Jun 1997 14:35:53 -0500 Organization: Department of Computer Science, Purdue University Lines: 95 Distribution: world Message-ID: <5nmump$ime@arthur.cs.purdue.edu> NNTP-Posting-Host: arthur.cs.purdue.edu There has been some discussion in this group about whether one can use Scheme for numerical codes. To study this question, I compiled all the benchmarks distributed with Gambit-C 2.6 that used floating-point in any way with both Gambit-C 2.6 and Stalin 0.7. There are several larger codes (fft, simplex, nucleic), two smaller codes (mbrot and pnpoly, recently distributed in this group), and some small, artificial kernels (fibfp, sumfp). I compared the compile and run times of these codes in Scheme with C versions (simplex.scm is based on the code in Numerical Recipes, so I compared the Scheme code with the NR in C code). The results are below. Gambit-C offers programmers several tools to speed numeric codes, chiefly declarations of the types of operation arguments and uniform vectors of single- or double-precision floating point vectors. Stalin does extensive type analysis and optimizations that eliminate the need to "box" and "unbox" most floating point variables, and it can store vectors of floats in native C format. It appears to me that Gambit-C is viable if one is working with a code that mixes symbolic and numerical processing; Stalin generates faster code than Gambit-C, at the expense of (much) longer compile times. The ratio of Scheme run times to C run times is often no greater than what one sees when going from C to C++. Gambit-C (still) has one great weakness---small loops that pass floating point variables as arguments. I believe that Feeley intends to remedy this in the next release. Of course, Siskind intends to reduce the compile times of Stalin so that it can compile larger codes. Benchmark Stalin Gambit-C C Compile Run Size Compile Run Size Compile Run Size fft 181 1.9 8052 3.4 2.5 21496 0.3 1.0 5728 fibfp 94 3.1 6852 3.1 5.7 21392 0.2 3.3 5152 mbrot 108 0.5 7564 3.2 6.2 21220 0.2 0.5 5552 nucleic 51744 *** 298800 57.2 9.2 222192 238.4 4.4 130808 pnpoly 108 0.4 7612 3.4 0.6 22088 0.6 0.3 6336 simplex 533 3.7 16798 6.8 5.2 31084 0.8 1.6 9652 sumfp 91 4.7 6744 2.9 40.7 20276 0.2 2.9 5088 Note: ***: runtime aborted with message "Segmentation Fault" Brad Lucier lucier@math.purdue.edu Rules of the game: 1. Used gcc version 2.7.2.1, -O2, on a Sparc Ultra 3000 server, 167 Mhz processors, running Solaris 2.5.1. 2. Gambit-C 2.6 (dynamically linked library), Stalin 0.7. 3. Stalin compile times are with csh's time, all others are with /usr/bin/time. 4. Compile and run user times are in seconds, sizes are in bytes. 5. fft and simplex are inspired by Numerical Recipes in C; fibfp is a floating point doubly-recursive fibonacci; mbrot does the Mandelbrot set iteration; nucleic finds the energy-minimizing configuration of a nucleic acid; pnpoly tests whether a series of points is within a given polygon; sumfp simply calculates the sum of the numbers from 1 to 10000. 6. C and Scheme programs were written in the same style except for nucleic, for which the Scheme version is more functional than the C version. 7. All floating point operations in Gambit-C were annotated. Gambit's new #f64 uniform 64-bit floating-point vectors were used instead of generic vectors. Stalin did its own type inference. 8. The benchmarks are available in the misc subdirectory of the Gambit-C distribution: ftp://ftp.iro.umontreal.ca/pub/parallele/gambit 9. Stalin can be found at http://www.emba.uvm.edu/~qobi/software.html 10. Declarations for Gambit-C: (declare (standard-bindings) (extended-bindings) (block) (not safe) (not interrupts-enabled) (fixnum) (inlining-limit 500) ) 11. Declarations for Stalin: -d1 -d5 -d6 -d7 -cc gcc -copt -O2 -Ob -Om -On -Or -Ot 12. Because Stalin does arithmetic using floats rather than doubles, it gets a different answer for sumfp.