Re: Possible (summer of code) projects for Octave

[Daniel Kraft]

Søren Hauberg wrote:
> tir, 04 01 2011 kl. 19:35 +0100, skrev Daniel Kraft:
> > Søren Hauberg wrote:
> > > man, 03 01 2011 kl. 21:49 +0100, skrev Daniel Kraft:
> > > > I'm also not really an expert or experienced with JIT technology of 
> > > > related stuff, unfortunately.  What I do for gfortran/GCC is basically 
> > > > front-end stuff (like implementation of Fortran 2003 OOP features) and I 
> > > > did not yet touch any optimization or code-generation in GCC.  But on 
> > > > the other hand, I guess that using existing frameworks like LLVM the 
> > > > main concern is not compilation technology and code generation but more 
> > > > about how to translate Octave into a more static form.
> > > The simplest thing (according to the compiler people I hang out with
> > > from time to time) would most likely be to output C++ code. Then the
> > > missing part is essentially "just" type estimation. I don't think this
> > > is particularly easy, but I'm really no expert here...
> > But this then means we would try to compile a whole function by writing 
> > out a generated C++ implementation of it and then running mkoctfile?  Or 
> > a little more sophisticated?
> >
> > I think it would possibly also be useful to JIT only certain blocks of 
> > code (like loops which have a large number of iterations but do not 
> > contain any complicated (or any at all) function calls).  Or do you mean 
> > we should/could output also C++ code only for such a loop and have it 
> > compiled into a function which is then called instead of interpreting 
> > the loop?
> >
> > BTW, my impression is that mkoctfile takes rather long times to complete 
> > -- on the order of some seconds on my system usually.  This is not 
> > really what I expect as comile-times for JIT'ing code.
>
> For many applications it would be just to be able to generate C++ code
> and compile it even if that process would take a couple of minutes. This
> could be done for the m-files distributed with Octave and people could
> do it manually if needed. Obviously an automatic solution would be
> nicer, but this would solve many practical problems.

Up to now, I only thought about real JIT-compiling in the sense that it 
is done transparently in the background possibly without the user ever 
knowing which code is compiled and which interpreted.  But the idea with 
providing some (easy to use) tools for the user to have his m-code 
compiled seems also nice -- particularly because it puts some burden 
back on the user and we do not necessarily have to guarantee that stuff 
like our type-inference "just works" in every possible case.

I think I read in an old thread about JIT the idea to do type-inference 
by some kind of "profiling":  It seems to me that for most code, types 
do not change that dynamically at all, and probably most of the time 
each variable can be assigned a fixed type, or at least at each "line" 
in the code we have a fixed type.  E.g., for stuff like

a = get_some_data ();
a = uint8 (a);

which seems also somewhat reasonable to do (to me).  And for code like 
that, one can get around with replacing the "one a" by two different 
variables at compile-time.  So here's a first idea:

We could implement functionality in the interpreter to interpret a 
function or program execution and track the types of all symbols during 
that in addition.  And if it finds that (possibly after the variable 
duplication mentioned above) each symbol can be assigned a single type, 
we can use this information to write out a C++ version of the function 
or code run.  It would then be the user's responsibility to ensure that 
his "test run" (with smaller data, for instance) really exhibits all 
corner cases that may apply and hence that the type-inference done is 
correct for all future runs, but at least from experience with code I've 
written this can easily be done most of the time (not fully 
automatically but by myself as author of the code).

This would then be more a semi-automatic tool helping in conversion of 
critical functions to C++ rather than an automagically solution while 
running code, but I think this would and would already have been very 
useful to me in the past at some times.

What do you think about that?  Does it sound doable?  Would it be useful 
in that way?

Yours,
Daniel

--
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri