[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Type estimating Octave Compiler

From: Jens Ruecknagel
Subject: Re: Type estimating Octave Compiler
Date: Tue, 19 Apr 2005 11:01:47 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]