About octave performance...

[David Bateman]

Jaroslav Hajek wrote:
> On Wed, Jul 30, 2008 at 10:52 AM, David Bateman
> <David.Bateman at motorola.com> wrote:
>   
>> Francesco Riganti wrote:
>>     
>>> Dear All,
>>> first of all, a very big "tank you" for this wonderful project. I have a
>>> little question: in the next feature of octave, it will be an
>>> improvement versus matlab performance?
>>> Actually, i think this is the most immediate problem to solve. Infact,
>>> despite the use of vectorization, matlab is more fast then octave. In my
>>> university, I would like to build a cluster system for octave using
>>> instead of matlab sofware. However, the not yet good performance of
>>> octave versus matlab, not encourage the cluster project. Can you tell me
>>> something about it?
>>> Best Regards
>>>
>>> Francesco Riganti Fulginei
>>> Department of Applied Electronics
>>> Roma Tre University
>>> Rome
>>>
>>> _______________________________________________
>>> Help-octave mailing list
>>> Help-octave at octave.org
>>> https://www.cae.wisc.edu/mailman/listinfo/help-octave
>>>
>>>
>>>       
>> Take a look at the thread
>>
>> https://www.cae.wisc.edu/pipermail/octave-maintainers/2008-April/006984.html
>>
>> in short FreeMat has started implementing LLVM JIT in their development
>> tree and I imagine we'll copy their code once they make some progress. I
>> therefore expect this to be a target for the 3.4.x (or will that release
>> be 4.0) of Octave sometime in about a years time.
>>
>>     
>
> Interesting. But you do expect that the "copy" operation will actually
> be quite complex, don't you? Or are FreeMat internals that close to
> Octave's?
>   
I've already taken a brief look at it. FreeMat splits the problem into 
an abstraction of the LLVM/JIT into a FreeMat specific class appropriate 
to the matlab language, and a second part in the parser that hooks into 
this if certain criteria are meet in the parsed code. The LLVM/JIT 
classes they use don't depend on the FreeMat internals and so can be 
copied directly. The parser hooks would need to be entirely rewritten. 
I'm not a expert in the Octave parser and so if I took on this project 
it would be a learning experience and there might be someone better 
capable of doing it.

In any case the FreeMat LLVM is under evolution and we are probably 
better off waiting till it stabilizes a bit before embarking on this 
development ourselves. That is we can let the FreeMat development work 
out many of the bugs and make our life easier :-)

See the FreeMat TODO list at

http://freemat-blog.blogspot.com/

> In any case, I'm still not much assured that the Matlab's way is the good way.
> As John once noted, the key problem in JIT is about type inference,
> not the code compilation itself. How do you know that the JIT compiler
> will be smart enough? If you know (or assume) that a variable is of
> certain type, why not let the compiler know? Perhaps some kind of type
> declaration or "type assertion" directives would enable much better
> JIT optimization, without black magic like "if you use complex value
> here, the code will run 2x slower" etc.
>   
Yes, it would be nice if variables in the matlab language might be 
explicitly typed to avoid the need for type inferencing. This would make 
the JIT much better.

D.

-- 
David Bateman                                David.Bateman at motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary