[plt-scheme] Who is working on improving PLT performance?

At Sun, 19 Apr 2009 16:19:55 -0700 (PDT), rw wrote:
> Who is doing the work, if anyone?
> What are you trying to do?
> Are you looking for help?

I see two directions for general performance improvements:

 * Unsafe operations: add operations like `unsafe-fx+', `unsafe-fl+',
   `unsafe-vector-ref', `unsafe-apply-struct-accessor', etc. where some
   run-time checks can be usefully skipped if unsafe mode (i.e. unsafe
   from the JIT's perspective) is enabled.

   This one is relatively straightforward, and I'd welcome help.

 * Cross-module inlining.

   The challenge here is fitting into the existing bytecode model. I
   don't yet know how to make it work, and it's probably too hard for
   someone not already deep into the runtime system.

Of course, we'd also welcome general improvements to the GC or JIT, but
I think we're approaching a local maximum in our current architecture.


Here's a related idea that would be easier to work on: a tool that
takes a starting module and combines all imported code into a single
module, stripping away all macro definitions and other compile-time
code. This would be suitable for producing stand-alone applications
that don't need to expand any code at run time (since macros have been
stripped away completely). Depending on how it's implemented, you might
get cross-module inlining for free.

We created a one-off tool for the programs that we provided during the
2005 ICFP programming contest. That tool worked by `expand'ing all the
source modules, and then shuffling S-expressions into a single `module'
form. A general version of that tool might be the right thing. Or,
since we now have tools to decompile a ".zo" file, it might work better
to decompile files instead of starting over with `expand'. It may even
make sense to generate new bytecode directly, instead of decompiling
and going back through `compile'.


[Follow-ups should probably go to the plt-dev list.]