[plt-scheme] Performance Targets for MzScheme

On May 13, 2004, at 12:47 AM, Brent Fulgham 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.

I think you shouldn't. No matter what you do, you need a performance 
model of the language in your head.

> 2.  Extend/complete the mzc compiler so that it can produce libraries 
> with C-ish speed.

mzc is too independent of mzscheme.

> 3.  Wave our hands at this "simple matter of programming" and continue 
> on with our lives.

It's a "matter of programming" not a simple matter of programming. See 
1.

> 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?

One day we will be working on it ... :)

> 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.

My code was shorter than yours. And I didn't use a non-decipherable 
loop construct. How else do you want to measure performance? I bet that 
if Python started a PRFI process, their PRFI code would be at best as 
efficient as SRFI code in our world.

Now imagine we get a native code compiler for mzscheme code.

> 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!)  :-)

Ryan has been working with Will Clinger on a compiler from mzscheme to 
.Net. They have accomplished something but it isn't close enough yet. 
Moving from .Net to a native platform is within reach.

Eli has started a JIT compiler project.

Don't hold your breath but expect some progress on these fronts. One 
thing will be true, however: we cannot afford the time and money to 
create another useless compile-scheme-to-be-as-fast-as-C project.

-- Matthias