Re: octave and LLVM google summer of code project

[John W. Eaton]

On  8-Apr-2008, David Bateman wrote:

| Duncan Sands wrote:
| > Hi, over at the LLVM project (http://llvm.org) we've just received
| > a google summer of code project proposal from Max Rietmann who wants
| > to use LLVM's just-in-time optimizers and code generation to speed
| > up octave's interpreter.  I've pasted his application at the end of
| > this email.  While some of us have used octave, none of the LLVM
| > people know anything about its internals so it is hard for us to tell
| > if this project makes sense or not.  Is this something octave would
| > be interested in?  Is it do-able in 10 weeks?  Finally, if the project
| > looks good it would be helpful to have an octave expert as a mentor
| > as well as someone from LLVM - any suggestions?
|
| This not only makes sense but is probably one of the major stumbling
| blocks for widespread acceptance of Octave relative to Matlab (ie Matlab
| has a JIT). Whether its doable in 10 weeks, well he'd have to be good to
| have a chance, but even a good start that supplies a template of how to
| modify the rest of the code would be a major help.. I'm sure that any
| help that is requested on the Octave internals would be supplied rapidly
| on the address@hidden, though as this will necessarily impact
| the parser, its John Eaton who has the best understanding of how that
| works..

I also think a JIT compiler for Octave would be useful, but I have some
doubts about whether someone new to Octave could deliver something
working in just 10 weeks.  But maybe it would be worth it just to have
a starting point.

Additional comments below.

| >   Unfortunately I have found Octave to be
| >   noticeably slower than Matlab (up to an order of magnitude),
| >   which has caused me to use Matlab exclusively.

If you can write vectorized code, then it is not always so slow.

| >   From discussions on the
| >   mailing list, its clear that Octave's speed problems do not lie
| >   in its lack of ability in numerical operations, but instead are
| >   due to slow interpretation of the base language. I specifically
| >   notice the biggest speed issues when looping. In some cases, JIT
| >   compilation could be used to vectorize the looping code. But
| >   this still does not account for its relatively slow looping over
| >   non-vectorizeable code.

As has also been discussed on the lists, you won't get much speed up
if you simply transform the code into something that is compiled but
still relies on dispatching in the octave_value class (the object that
serves as a container for Octave matrix, scalar, cell array, struct,
etc. data types).  You will only get a significant speedup if you can
effectively infer data types from the Octave code itself (which has no
type declarations).  So the hard part is type inferencing, not
compiling to machine code that uses a library to implement the type
dispatching.

| >   The first big step will be to write a parser for the Octave
| >   code.

Octave already has a parser that constructs a tree structured
representation of the code and also provides methods for walking the
tree that I expect could be used to transform it to something suitable
for LLVM.  I don't see the point in writing a separate parser.  For
this effort to be useful for Octave users, it will need to be
integrated in Octave.  That is much more likely to happen if you use
Octave's existing parser rather than starting a separate project that
may not even use Octave's libraries.

jwe