Re: julia language

[Levente Torok]

Hi Max,

Thanks for the detailed explanation of your reading of the story.

Well, I find it bit difficult to do vectorization on the given example
named randmatstat.m. All I could do is to concat matrix a b, and c d
which seems to mean 20% speed up to the original implementation.
Mandelbrot set is difficult to vectorize because of the branching in
the stomach but I wouldnt care in general.
However what is really frustrating is the quicksort speed difference.
In fact I do a lot of vectorization on my octave code base and
unique() is one of most used functions. I think of it as an injective
projector or mapper. This function inherently uses sorting. ( I guess
this is the quicksort that is tested in julia, but not for sure, can
anybody confirm it)?

I am also thinking if octave could introduce reference type of
variables (matlab doesn't have this).
This would be a great thing, indeed.

Bests,

Lev

On Sat, May 12, 2012 at 9:45 PM, Max Brister <address@hidden> wrote:
> 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