[plt-scheme] Performance Targets for MzScheme

On 2004-05-12 18:10:39 -0700 Matthias Felleisen <matthias at ccs.neu.edu> 
wrote:

> [I was hoping you'd read the thread.]
> 
> So this shows that the problem is with srfi's. They are coded in 
> Scheme, and 
> what you're measuring is the interpretation time for each call to 
> split and 
> all the Scheme calls within. For each function call, the interpreter 
> "loops" 
> once (roughly). If, on the other hand, you call a "native" C 
> function, you do 
> ONE function call. Period. Period.

Interesting.  IIRC, there's nothing about an SRFI that *requires* it 
to be implemented in Scheme.
In fact, I'm pretty sure MzScheme satisfies a few SRFI's 
"out-of-the-box" as part of its core
system.

So we have a few options:

1.  Code SRFI's as C code that can be linked into MzScheme.
2.  Extend/complete the mzc compiler so that it can produce libraries 
with C-ish speed.
3.  Wave our hands at this "simple matter of programming" and continue 
on with our lives.

Matthias, you say "Until we have a compiler."  Does this mean work 
progresses on a compiler, or
are you just referring to an unknown future?

Matthew -- the OpenGL bindings seem to consist of a mixture of C and 
Scheme code.  Would
a reasonable approach be to identify low-hanging fruit like 
"string-tokenizer" and include them
as native modules for the SRFI's?

MzScheme is a great system -- but to be competitive for real world 
work we need to keep performance
at a reasonable level.  If we can't use the tools that exist in the 
system (e.g., SRFI's) we lose a
good deal of the elegance and utility of the language.

I think I'll play benchmarks for a bit, then see if I can help with 
some library additions (assuming that
won't be soon swept away by a blazing new PLT compiler, that is!)  :-)

-Brent