Re: octave vs. matlab vectorization

[Jaroslav Hajek]

On Mon, Sep 14, 2009 at 10:12 PM, Francesco Potorti`
<address@hidden> wrote:
>>ah, no! code 1 was *faster* under matlab! the ratio is 0.19:1
>>i find this result quite staggering.
>
> Mh.  That vectorised code is slower than jit compiled code is strange,
> indeed.  If your measurements are correct, this may depend on various
> things, but these are Matlab's implementation issues.
>

Not necessarily. Compiled loops will often be somewhat faster than
equivalent vectorized code. Look at the original example - in the
loopy code, there's two inner loops; one is zeros() and one the fill.
Compared to that, the semi-vectorized case comprises three loops,
which the JIT compiler may or may not (apparently not in this case) be
able to merge.

I intentionally wrote "semi-vectorized" because, from Octave's point
of view, neither code is vectorized. I'm sure that in Octave, the
"interpreter overhead" plays the major part in *both* cases. Such
example is just unrealistic for real-life coding in Octave, because it
actually failed to vectorize anything.
Vectorizing an inner loop often helps, but not when the ratio
inner:outer number of cycles is 1:1e6. To get good performance,
generally the ratio inner:outer should be at most 1 in terms of orders
of magnitude.

A final thought about the JIT compilation:
Imprecisely quoting MathWorks site, "MathWorks is committed to make
Matlab as fast as traditional HPC languages such as C, C++ and
Fortran". Besides the general unreasonability of the statement
(comparing speed of languages is usually a nonsense),
I consider this a clever marketing strategy. MathWorks surely realizes
that the MEX interface sucks. I think there were number of third-party
attempts to create an OOP interface to the Matlab engine, but
MathWorks adopted none, neither they invented their own one. And for
good reason, I think - improving interoperability with C/C++/Fortran
could make customers to invest in compilers and better C/C++/Fortran
programming skills. On the contrary, the situation where everything is
written in the Matlab language is much more favorable for the company
- in case your code is not fast enough, your best option is to buy a
newer Matlab and hope the JIT compiler has improved enough to do what
you meant to do. I think Matlab comes with little documentation on
what exactly the JIT compiler can handle, let alone any guarantees, so
you're entirely left at its mercy. In short, Matlab is now improving
in the area where C and Fortran compilers have been shining for
decades. The Matlab language was designed to be interpreted, and is
almost uniquely ill-suited for compilation. Despite that, the company
made remarkable progress in teaching the elephant to dance. Of course,
MathWorks needed some way forward, or they would lose revenues, and
they picked up this one. But that does not necessarily mean Octave
will follow. I daresay that most of those who actively contribute to
Octave *can* speak C, C++ or Fortran. And people will not stop using
C, C++ and Fortran anywhere in near future. So I don't reckon Octave
will JIT-compile in near future; I think there's just not enough
interest. Still, I might be wrong.

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz