Re: Type estimating Octave Compiler

[Jens Ruecknagel]

To all who are interested.

Thanks for your interest,

David Bateman wrote:
> This is great, and I really think it has to go into the 2.9.x tree
> asap.
> I'm sick of speed comparison with the other brand that point up the
> absence of JIT in octave.

This work is just a start. There are some questions left:
For a JIT like in Matlab we need a compiler to Binary (not C++) and a 
code repository like in MAJIC.
But there might be a more clever way:

Just do type estimation on the tree and than replace the dynamically 
typed op node with a statically typed node. Do you understand? Imagine a 
plus node, it works on all types of operands, if we find out we just 
need the plus for real scalars, we replace the dynamically typed node 
with the plus node for real scalars.
On this simplified tree the interpreter is started.
Do you think that will speed up the operations? It is easy to implement 
and does not interfeer to much with the interpreter.


There is another problem: Maybe Octave can never be as fast as Matlab, 
since there are so many types in Octave - with many possible types, type 
estimation becomes hard to do - and maybe impossible. What do you think? 
Maybe we have to simplify Octave. Sorry I do not know Octave well enough 
to give an answer.


> I notice a couple of points. Firstly, this is a compiler and not a IT,
> so the functions have to be compield before use. Would it be possible 
> to
> incorporate the code directly in the interpret in the same way as the
> JIT in matlab?

Yes but there are more things to the matlab JIT than a compiler. The 
Code repository.

> Also I see that you seem to only have implemented the
> add, mul and le operators, and the do-until loop structure. What is
> the
> workload to implement the rest, relative to where you're at?

This was an academic work - I did not get credit for coding but for 
researching. So I only coded what was necessary to proof my research.
The rest should be simple to code. It just work that needs to be done. 
The thing I have not jet thought about are Cells.

> Could there
> be a fallback to the old means of parsing the code for the cases that
> aren't implemented, rather than a compilation failure as currently
> happens?

No it is easier to implement the rest features into the compiler.
But you can always call the interpreter.

> You also only treat complex/real scalars and matrices, there
> are a large number of additional types that were added after 2.1.57,
> and
> it seems that these will cause problems with the way the code is
> currently structured..

The type estimation rules have to be more general, i.e. In the 
Interpreter, the operand of a + can be a complex matrix or a streamoff 
(whatever a steramoff is). I just implemented complex matrix. If the 
type estimator cannot find out the types, the compiler has to emit 
dynamically typed code.

> Finally, you use the matrix_value() method of the
> octave_value class to get a Matrix. However, as octave_matrix is now
> based on the NDArray class, by doing this you loose NDArray support? I
> used for the mul operator this is needed, but not for the add
> operator....

This is just a detail. lets postpone this question.

>
> Great Work
Thanks


Jens