[plt-scheme] Performance Targets for MzScheme
On Wed, 12 May 2004 21:47:37 -0700, Brent Fulgham <bfulgham at debian.org> wrote:
>
> 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
>
>
Brent,
Why not use regexp-split? That's faster than string-tokenize. Plus,
method dispatch is slow enough in Python that the difference in this
one primitive should be amortized.
Daniel