[plt-scheme] Experience Using Mz(Dr)Scheme for Numerical Work

From: Will M. Farr (farr at MIT.EDU)
Date: Sun Apr 17 15:29:23 EDT 2005

Hello all,

I'm interested in coding some advanced n-body gravitational integrators 
for a research project.  I would really like to do this in scheme (as 
opposed to C or Fortran, which would be the standard choices for this 
type of work).  I have considered Bigloo scheme due to its optimizing 
compiler; it seems fast enough to do real science with (and to do real 
science here, I will eventually need quite a bit of speed), but I don't 
like the non-interactive development cycle (it's definitely designed to 
produce a.out's, not for incremental development).  I have considered 
common lisp (using SBCL), and that seems like a very attractive 
possibility; it is a bit faster than bigloo on some of my simple 
benchmarks (about 1.5 times slower than C on some very simple 
integrators), and it's as interactive as they come.  However, I would 
really like to use DrScheme and MzScheme for the coding.  I thought I 
would be able to write the inner loops of my code (such integrators 
spend most of their number-crunching time essentially computing 
m1*m2/r12^2) in C, and then use Dr. Barzilay's excellent FFI to access 
it, and do all the steering, grouping, timestep adjusting, etc. from 

Unfortunately, after writing the same simple integrators in C, common 
lisp, and scheme, I find that, even with a C-coded inner loop, 
DrScheme/MzScheme are about 10 times slower than SBCL, and 15 times 
slower than straight C.  The difficulty seems to be that computing 
m1*m2/r12^2 isn't enough work to offset the baggage that comes with a 
FFI call, and the looping overhead.  I have considered writing my code 
by hand as an external module, but that is a lot of (mechanical and 
boring) work and based on what I have read about the FFI, I don't 
expect better than a 1.5 times speedup for the effort.  I could try to 
write the whole loop in C, but the guts of an advanced integrator are 
basically a complicated decision mechanism for which pairs to advance 
when, so if I'm going to compute the looping order in C, I might as 
well just do the whole thing in C, and I don't want to do that.  I'm 
afraid I am now leaning toward SBCL (not that I have anything against 
it---it's an excellent system, with a great compiler---but I like the 
mzscheme module system much better than common lisp packages, I like 
scheme macros better, and I think I prefer DrScheme to Emacs + SLIME).  
Also, once something is written in common lisp, it seems much harder to 
get it to talk to the remainder of the scientific community (which runs 
C or Fortran) than it would be with MzScheme.

So, I am writing this email seeking "inspiration:" is there anyone who 
reads this list and could comment on his/her experience doing something 
numerically intensive with MzScheme?  If so, I am particularly 
interested in where you chose to draw the line between foreign code and 
native code (I assume that anyone doing a lot of floating-point 
processing wouldn't do it in MzScheme due to boxing/unboxing/generic 
arithmetic issues); mostly I'm seeking ideas for innovative ways to 
break up such a computation to achieve acceptable performance at modest 

Thanks for reading this somewhat long email; I appreciate whatever 
advice you can give me.

Will Farr

Posted on the users mailing list.