[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Type-based Optimizatoins? [was: tail calls [was: Vanishing MrEd]]



Greg P:
> > I can explain to people how the simpler version works --- i.e. how
> > a simple tail call is replaced with a goto and hence avoids using
> > extra stack opperations. Can someone explain why this is so profound?
> 
Shriram:
> It's not the underlying semantics that is profound: it's the
> programming styles that it engenders, *especially* in the context of
> Scheme (or any other language with lexical closures).
> 

Just following on to Shriram's (and later Matthias's comments), one of
the more interesting areas for future work with Scheme (IMHO) is towards
improving its performance.  Now, MzScheme has probably the best overall
performance of any of the Scheme implementations I've played with, but
it still has some progress to make before it reaches the speeds of C or C++.

Those of you who are familiar with the ML-family of languages might also
be aware of Objective Caml.  OCaml is extremely efficient -- approaching
or exceeding even C++, which is about as good as you would ever really
need.

I originally thought that some of the performance differences might be
due to Scheme's "typeless" behavior, in which virtually all objects are
represented as boxed values.  I thought that the overhead of boxing and
unboxing might be quite inefficient.

The academics on this list are probably already aware of Xavier Leroy's
paper on this topic:  Xavier Leroy. "The effectiveness of type-based 
unboxing." (In Workshop Types in Compilation '97. Technical report
BCCS-97-03)
Reading this recently, I was somewhat suprised to see his conclusion
that untyped boxing/unboxing "... optimizations perform as well on the best
case and significantly better in the worst case" when compared to typed.

So, I'm left wondering if there isn't room for improvement in MzScheme's
internal representation of data types.  For example, I wonder if Andrew
Wright's soft type system could be used in an optimization pass in
the "scheme-to-c" mode of the compiler to perhaps create fast-paths for
native C data types?

Is anyone aware of fundamental reasons why Scheme must necessarily be slower
than, say, C++?

Curious,

-Brent