Scheme Efficiency (was Re: Limitations of Inform and TADS?)


6 Nov 1995 04:53:04 GMT

In article <47jqch$3um@cantua.canterbury.ac.nz>,
Greg Ewing <greg@cosc.canterbury.ac.nz> wrote:

>More expressive languages don't necessarily need more processing
>power. Scheme, for example, is a very small language, and a very compact
>implementation ought to be possible if you're not too concerned about
>speed.

I certainly agree that Scheme can be small. I don't think it can be as
fast as a good implementation of a language like C for most tasks, though.
There's been a fairly in-depth discussion about why programs written in a
functional style (which Scheme is designed for) are harder to optimize in
comp.lang.scheme. Many people who have implemented production Scheme
systems have posted on the topic.

My experience with Scheme on the PC leads me to believe that you pay a
fairly serious performance cost. Jeff Siskind's putting a lot of work into
his Stalin Scheme to C compiler --- perhaps it will set a new performance
standard. But to use it for IF you'd really have to convert it into a
bytecode compiler so that binaries would be machine independent.

One approach I've considered is to use a modified Stalin to compile Scheme
into a fairly rich virtual instruction set, then to translate this VM code
into native machine instructions at game load time. The drawback here is
that porting the run-time to new machines would be difficult, because you'd
have to write the instruction converter all over again every time. Also,
some architectures (like 80[2]86) would be harder to write a converter for
than others.

The advantage, of course, is that (I'm guessing) you'd get performance only
slightly worse than if you'd used a direct Scheme->C->native compilation.

Dave Baggett
__
dmb@ai.mit.edu
"Mr. Price: Please don't try to make things nice! The wrong notes are *right*."
--- Charles Ives (note to copyist on the autograph score of The Fourth of July)