[Top][All Lists]

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

Re: Type estimating Octave Compiler

From: David Bateman
Subject: Re: Type estimating Octave Compiler
Date: Thu, 21 Apr 2005 09:16:51 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Jens Ruecknagel wrote:

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.

The fact is I see the JIT as much more important than the compiler. In matlab, compiled code has a different license status than the original code and can be run without a license to matlab, and to me that is the essential use of the matlab compiler... However as octave doesn't have this issue, if the JIT can be made to give essentially the same speed as the compiled code, then the compiled versions have much less interest.

I'm sure if type estimation is done in the parser without compilation like in MAJIC, then that would give a large speed up in octave. Furthermore if the compiler is not directly related to the JIT effort, it would be better to do that than the compiler....

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 don't think matlab has fewer types than octave. In any case, even if some types and optimized and the other types compiled to dynamically typed code then this would still be a major step forward.

> 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.

If the code goes in, I'm sure there are several people that would want to add the missing features...

> 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.

This seems to be the best approach, as long as dynamically typed code can be generated for untreated case. I wouldn't bother with optimizing streamoff :-)

> 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]