Re: julia language

[Max Brister]

Hi Levente,

> Hi Max,
>
> [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.
>
> Iff there is parallel execution present, right?

This does not depend on parallel execution (but maybe we are assuming
ref has different semantics?). Take the following code for example

bar0 = [1 2 3];
bar = ref (bar0);
foo (bar);

In foo we would then get both a and b as references to bar0. The line
a(1) = b(1) + 1
then changes bar0(1) to 2. We then have a(1) == b(1) and get a
failure. Without the ref function we will never see a(1) == b(1) and
there will be no 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.
>
> Plus, if a function operates on the variable in a read only way, and
> we exclude async access (multi thread/core) to the data we can use
> reference w/o any worry, I think.

We are already using a reference internally in this case. A copy is
only created if you mutate the argument that.

> [snip]
>>>
>>> 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.
>
> I don't think octave really needs to sport on parfor since interpreted
> languages are well known for effectively running (for) cycles.
> Currently, I am quite happy with the parcellfun but I can imagine
> something that is easier to use in daily life.

Actually, parfor does support reduction (like @parallel in Julia).
Writing the Julia example with parfor looks like
nheads = 0;
parfor i=1:100000000
  nheads = nheads + randbit ();
end

It should currently be possible to create a function like parcellfun
that does reductions like Julia's @parallel (I haven't taken a look at
the code for parcellfun though).


Max Brister