[plt-scheme] llvm and all that

From: Eli Barzilay (eli at barzilay.org)
Date: Thu Aug 10 13:54:21 EDT 2006

On Aug 10, Matthias Felleisen wrote:
> 
> On Aug 10, 2006, at 9:27 AM, Noel Welsh wrote:
> 
> > What tools are available for writing compilers from (subsets of)
> > MzScheme to something faster?  For example, is there a binding to
> > LLVM?  I know someone was working on a LLVM compiler a while ago.
> 
> Eli and Alex Friedman (basically his undergrad thesis) were working
> on this LLVM compiler. I suspect that with enough work, this
> compiler would be significant better on the kind of code that you
> have than Matthew's JIT compiler. But the work is Incomplete. (The
> capital I is for Americans who know what this implies.) I am
> wondering whether enough public pressure may make Eli work on this
> again "-)

Well, the LLVM thing suffered from a few major problems.  First, there
were a few problems that they did not get around to fix -- like broken
tail calls.  Second, there was the size issue -- with LLVM being big
enough that it's basically like linking GCC in.  Since they're
focusing on a plain compiler-like interface, it's a question whether
this will have a solution.  Also there were problems getting it built
on Windows.

In the meanwhile, Matthew started to use GNU Lightning, which made a
good solution.  LLVM would be much better, mainly because it can do
low-level optimizations on the generated code -- in contrast to the
simple spit-assembly-code facility that Lightning gives you.  So if
the LLVM project solves those problems, it will be worth it to try
again.


> For your current situation, I could imagine using Eli's foreign
> function library. I'd write the code, use the profiler to figure out
> where the time goes, and descend into C at that point. It's your
> best short term bet, assuming you don't want to switch to PL for
> your MSc.

Right.  The advantage in using the foreign interface like that is that
it is more flexible than using plain C-extensions for mzscheme.  You
don't need to deal with the glue code, and you only need a single
.so/.dll that can be used with any mzscheme version -- and since
you're writing the C code, then it is guaranteed to be ffi-friendly.

I think that these advantages are important: it makes it much easier
to mix Scheme and C code because the automatic glue layer is easy, and
it's even powerful enough to deal with higher order functions so
you're not limited to C code that doesn't go back to Scheme.  For
example, it's easy to write a C loop that invokes a Scheme function.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!


Posted on the users mailing list.