Re: Possible (summer of code) projects for Octave

[Søren Hauberg]

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.

Søren