Re: julia language

[Max Brister]

On Sun, May 13, 2012 at 4:42 AM, Levente Torok <address@hidden> wrote:
> 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.

The Julia benchmark relies on quicksort implemented as an Octave
function [1]. The Julia language implementation is the equivalent code
implemented as  a Julia function [2]. It is also interesting to note
that their benchmark times do not include the JIT compile time for
Julia (just the execution time).

> [snip]
>
>>> 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)

That would end up breaking most existing scripts. For example,

function foo (a)
  b = a
  a(1) = b(1) + 1
  if a(1) == b(1)
    error ("My script is broken!")
  endif
endfunction

If a were passes to foo as a reference, we would see an unexpected
failure. We could instead introduce a new keyword for function
arguments like in C++. Something like

function foo (ref a)
  # now a is a reference
endfunction

But this makes the Octave language significantly more complex, as
users now must check function signatures to see if their input
variables are modified. Instead, if we make the interpreter recognize
patterns like:
a = foo (a);
We can get the same performance benefit of pass by reference in the
current system without having to change the language at all.

If you want a scientific computing language that uses pass by
reference instead of pass by value, might I suggest using Julia? I
quite like the language (but haven't seriously used it).

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

I really like how Julia supports parallel computation. Matlab has
something similar, parfor, but we currently don't parallelize it in
Octave. There are several underlying technical issues in the
interpreter which make this sort of parallel execution difficult.

There exists Octave Forge packages that provide some parallelization
support [3] [4]. However, it would be nice to parallelize the
interpreter.

[1] - https://github.com/JuliaLang/julia/blob/master/test/perf/perf.m
[2] - https://github.com/JuliaLang/julia/blob/master/test/perf/perf.jl
[3] - http://octave.sourceforge.net/general/index.html
[4] - http://octave.sourceforge.net/openmpi_ext/index.html

Max Brister