Re: julia language

[Max Brister]

On Sat, May 12, 2012 at 12:03 AM, Levente Torok <address@hidden> wrote:
> Hi Max,
>
> I see. So it means if I dont partition code into functions and pass
> big data into it instead use global variables, it will resolve this
> speed issue mostly?

In general no. While Octave is call by value, Octave delays making
copies until it absolutely has to. I was mentioning this as an example
as to why we can not directly apply the Julia code.

Most of the Julia benchmarks have to do with testing the speed of the
interpreter, which is an entirely different issue. In Octave there is
a lot of overhead for the execution of each instruction. The current
solution to this is to vectorize your code [1].

After looking further into the Julia benchmarks, it looks like they do
not include the JIT overhead in their numbers. So these benchmarks are
biased against interpreters. It is also interesting to note that in
the only test that did not directly test the interpreter,
rand_mat_mul, Octave preformed reasonably well in.

> What output you expect from JIT by the end of the supported period?

My project plan has me completing JIT compilation of scalar code and
loops by the end of the summer [2].

[1] - 
http://www.gnu.org/software/octave/doc/interpreter/Vectorization-and-Faster-Code-Execution.html
[2] - 
http://www.google-melange.com/gsoc/project/google/gsoc2012/max_brister/23001#

Max Brister