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

The Cliche' applies here:  Make it work.  Make it right.  Make it fast.

I like using DrScheme for the first two steps since I am hopelessly 
attracted to rearranging programs to make them easier to read.  When 
speed becomes an issue (is loosing benchmarks truly an issue?), then I 
refine the Scheme programs as much as possible before committing to 
writing C-extensions.  C-coding well defined processes is not 'boring'; 
it's experimental development that is so unbearable compared to Scheme. 
  If I find that I am annoyed with developing C-programs, then it is 
likely because I didn't 'make it right' first in Scheme.

I do some work as you describe, but haven't schemed very much of it 
since it was written years ago in C.  However, I find it hard to 
believe that you can't pass parameters into C and achieve acceptable 
performance.  Integrations typically involve computational functions, 
convergence tests, and some bail-out mechanisms.  If you arrange your 
Scheme to specifically use these as parameters, then a C-interface 
seems natural and efficient.

Perhaps your computational functions are not classifiable enough to 
write suites of them in C, and you want to write them in Scheme.  This 
would be ironic; most programmers want to write math in C or Fortran.

rac


On Apr 17, 2005, at 1:29 PM, Will M. Farr wrote:

>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> 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 scheme.
>
> 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 effort.
>
> Thanks for reading this somewhat long email; I appreciate whatever 
> advice you can give me.
>
> Will Farr
>