Re: julia language

[Levente Torok]

Hi Max,

On Sun, May 13, 2012 at 6:13 AM, Max Brister <address@hidden> wrote:
> On Sat, May 12, 2012 at 2:29 PM, Levente Torok <address@hidden> wrote:
>> 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.
>
> These are both cases in which JIT compilation should help. For the
> randmatstat function n is only 5, so I expect that the interpreter
> still dominates execution time.
>
>> However what is really frustrating is the quicksort speed difference.
>
> I do not think this is such a big issue, as Octave has an builtin sort
> method implemented in C++. You should use this method instead of
> implementing your own sort in any production code.
>
> That being said, performance on the benchmark could be increased by
> making the matrix a global variable. The problem is that when the
> matrix is mutated in a child function, the parent function still has a
> reference to it. This forces the child function to create a copy. The
> next version of Octave will support nested functions. Using nested
> functions prevents the need for a global variable.
>
> It is also theoretically possible (using live range analysis) for the
> JIT compiler to detect that matrix which is passed to the recursive
> quicksort call is no longer used. Implementing this optimization is
> currently not a very high priority for me.

Are you confident that guys didn't test octave's merge sort while
erroneously calling it quicksort but
their own recursive implementation of quicksort?
In the latter case, the only problematic thing for me is the
comparison with matlab speed of quicksort
which I suspect comes from the their JIT.

>
>> 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)?
>
> unique is implemented as a script which relies on the builtin sort
> method. The builtin sort method is a merge sort which is optimized for
> partially sorted matrices. This means the unique methods in Octave and
> Julia should have similar speeds.

I see. Thanks.

>> I am also thinking if octave could introduce reference type of
>> variables (matlab doesn't have this).
>> This would be a great thing, indeed.
>
> I don't think that introducing a reference type in Octave is a good
> idea. Doing this would require a major rework of the interpreter, and
> it is not clear what the syntax should look like. If call by value is
> really causing performance issues, I advocate using live range
> analysis to further reduce copies instead of a reference type.

Well. I can imagine it in a way that wouldn't imply rewriting the interpreter.
This first thing that comes to my mind is to have a cast-like type
modifier similar to  uint32, for example.
ie.:
  a = ref(a)

> Also, I think matlab new style classes are pass by reference. Octave
> does not current support them.
I see.
Thanks for letting me know you thoughts.

And what do you think of this<

And what do you think of julia arithmetic as such:
nheads = @parallel (+) for i=1:100000000
  randbit()
end
which would call all computing nodes and sum results together.

Levente