

Of all the complaints I have heard about Octave, its slowness is the
one that stings the most painfully. Cuts deep. Real deep.
So, I'm interested to know, any idea why this is happening? Why would
a simple for loop with no code to execute except running through all
the values of its iterator take orders of magnitude more in Octave
than in Matlab?
Where are these benchmarks?
 JGH

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


In reply to this post by Jordi Gutiérrez Hermoso
On 17Mar2006, Jordi Gutierrez Hermoso wrote:
 Of all the complaints I have heard about Octave, its slowness is the
 one that stings the most painfully. Cuts deep. Real deep.

 So, I'm interested to know, any idea why this is happening? Why would
 a simple for loop with no code to execute except running through all
 the values of its iterator take orders of magnitude more in Octave
 than in Matlab?
I can think of a few possibilities:
* because Octave's author only knows how to write a naive
interpreter and is too busy with other tasks to spend a lot of
time improving the interpreter (do you have a better one?)
* no interpreter/compiler wizards have appeared on the scene with
anything better
* people who have paid actual money for Octave's development have
cared more about features, correct results, and the fact that
Octave is freely available than speed (which has apparently been
good enough for them)
* our army of programmers is damn small and underfunded
Now, what can you do about it? Would you like to help, or just
complain?
jwe

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


Hi,
lør, 18 03 2006 kl. 09:41 0500, skrev John W. Eaton:
> I can think of a few possibilities:
>
> * because Octave's author only knows how to write a naive
> interpreter and is too busy with other tasks to spend a lot of
> time improving the interpreter (do you have a better one?)
>
> * no interpreter/compiler wizards have appeared on the scene with
> anything better
>
> * people who have paid actual money for Octave's development have
> cared more about features, correct results, and the fact that
> Octave is freely available than speed (which has apparently been
> good enough for them)
>
> * our army of programmers is damn small and underfunded
>
> Now, what can you do about it? Would you like to help, or just
> complain?
I'm guessing most people using Octave aren't interpreter wizards, they
are just people who care about their data. But couldn't FSF (or is it
GNU) be helpful here? When Classpath needed programmers FSF called for
help, and it really helped the project. Now, could we have FSF call for
help from programmers interested in interpreters? I guess some people
would find it very amusing to create an interpreter for Octave.
/Søren

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


I'm going to respond to Shay Ayal, John W. Eaton, and Søren Hauberg
in the same message.
On 3/18/06, Shai Ayal < [hidden email]> wrote:
> Please try to use a descriptive subject line when posting to this list.
Sorry. I usually do put subject lines, but I simply forgot in this
instance (and I'm surprised at myself that I did).
> I think the overall conclusion is the JIT is very hard to do and octave
> project, which relies on volunteers, does not currently have the
> manpower to do it. Maybe you can help?
It's been a while since I've touched Java. I don't think I can help. :(
On 3/18/06, John W. Eaton < [hidden email]> wrote:
> On 17Mar2006, Jordi Gutierrez Hermoso wrote:
>
>  So, I'm interested to know, any idea why this is happening? Why would
>  a simple for loop with no code to execute except running through all
>  the values of its iterator take orders of magnitude more in Octave
>  than in Matlab?
>
> I can think of a few possibilities:
>
> * because Octave's author only knows how to write a naive
> interpreter and is too busy with other tasks to spend a lot of
> time improving the interpreter (do you have a better one?)
Aha. So it is an issue with the interpreter? This was my real
question. To someone who complained to me about the slowness of
Octave, I said that most of those problems could be alleviated by
using the C++ library instead and compiling. I'm glad to know that at
least in this much I wasn't lying.
No, I wish I had a better interpreter, but I don't. :(
> * people who have paid actual money for Octave's development have
> cared more about features, correct results, and the fact that
> Octave is freely available than speed (which has apparently been
> good enough for them)
By the way, who are these people?
> Now, what can you do about it? Would you like to help, or just
> complain?
I'm sorry. I would love to help too. I wasn't actually complaining
about its slowness, just lamenting how much it hurts me to listen this
sort of critique about Octave. The project is dear to me and I would
love to see it succeed. I don't have money that I can offer, and I
doubt I have the technical skill required to write a better
interpreter for it.
On 3/18/06, Søren Hauberg < [hidden email]> wrote:
> I'm guessing most people using Octave aren't interpreter wizards, they
> are just people who care about their data. But couldn't FSF (or is it
> GNU) be helpful here?
That's an interesting thought! Do you know how to go about the
formalities of asking the FSF to help?
 JGH

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


On 3/18/06, Jordi Gutierrez Hermoso < [hidden email]> wrote:
> On 3/18/06, Shai Ayal < [hidden email]> wrote:
> > I think the overall conclusion is the JIT is very hard to do and octave
> > project, which relies on volunteers, does not currently have the
> > manpower to do it. Maybe you can help?
>
> It's been a while since I've touched Java. I don't think I can help. :(
>
JIT (JustInTime) compiler for octave has nothing to do with Java language.
Regards,
Dmitri.


Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


In reply to this post by Jordi Gutiérrez Hermoso
Jordi Gutierrez Hermoso wrote:
> Of all the complaints I have heard about Octave, its slowness is the
> one that stings the most painfully. Cuts deep. Real deep.
>
> So, I'm interested to know, any idea why this is happening? Why would
> a simple for loop with no code to execute except running through all
> the values of its iterator take orders of magnitude more in Octave
> than in Matlab?
>
> Where are these benchmarks?
>
Is this really a realworld problem? Do you people often run into
situations where the interpreter speed is the limiting factor. I don't
think I do, but I guess it depend on what kind of problems you are
working on.
I just want to say that running empty forloops is certainly not the way
to test the quality of Octave as a whole and it might not be a good way
to test the interpreter either. If you really depend on tiny forloops,
you should probably rewrite your code anyway.
/Arvid

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


I think this is a realworld problem. It is probably the biggest flaw in
the matlab language, making you write programs which use unintuitive and
hard to understand tricks just to avoid forloops. As a real world
example, have a look at the code for hist.m in octave. Instead of a ~N
forloop, it uses NlogN sorting just because sort is done in C and thus
is faster.
I think that forloops are an essential part of any programming
language, and avoiding them has unfortunately become the hallmark of
good matlab programming. When conducting job interviews for positions
for which matlab/octave is relevant, one of my questions is:
how would you calculate a 10 sample running average on a 100 element vector?
The answer should be trivial with a forloop, but of course in the
octave/matlab language it is not the "recommended" way. If I get the
forloop answer I immediately understand that this person has no
reallife experience with octave/matlab.
Shai
p.s. This is not a rant against octave, rather against the matlab
language. I understand that JIT for octave is probably not an achievable
goal, and I will continue to use tricks because of the numerous other
advantages of octave.
Arvid Rosén wrote:
> Jordi Gutierrez Hermoso wrote:
>> Of all the complaints I have heard about Octave, its slowness is the
>> one that stings the most painfully. Cuts deep. Real deep.
>>
>> So, I'm interested to know, any idea why this is happening? Why would
>> a simple for loop with no code to execute except running through all
>> the values of its iterator take orders of magnitude more in Octave
>> than in Matlab?
>>
>> Where are these benchmarks?
>>
> Is this really a realworld problem? Do you people often run into
> situations where the interpreter speed is the limiting factor. I don't
> think I do, but I guess it depend on what kind of problems you are
> working on.
> I just want to say that running empty forloops is certainly not the way
> to test the quality of Octave as a whole and it might not be a good way
> to test the interpreter either. If you really depend on tiny forloops,
> you should probably rewrite your code anyway.
>
> /Arvid
>
>
>
> 
> Octave is freely available under the terms of the GNU GPL.
>
> Octave's home on the web: http://www.octave.org> How to fund new projects: http://www.octave.org/funding.html> Subscription information: http://www.octave.org/archive.html> 
>

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


Many people compare octave to Matlab and don't realize that Matlab has
invested mucho $$ in the JIT (justintime or "on the fly" compiling).
While people are quick to say, "Matlab's JIT is great, why doesn't octave
have one?", I personally don't think the JIT buys you much at all. The
primary flaw in Matlab's JIT is that you cannot call any user functions
within the loop!
Must structured programming is, well, structured, and has numerous calls to
functions which call functions, etc. For a sequence of calls to builtin
functions, I will encapsulate this into a user function so that it is
readable in the calling code and maintainable. Whoops, I've just defeated
Matlab's fancy JIT, but I live with it since scattered cutandpasted code
blocks are unacceptable to me.
To put it another way: I can pretend that octave has a JIT. For my code,
the "octave JIT" is about as effective as Matlab's  meaning, it ain't. I
am happy that the people guiding this project understand that other features
are of greater use.
Paul
> Original Message
> From: John W. Eaton [mailto: [hidden email]]
> Sent: Saturday, March 18, 2006 4:41 AM
> To: Jordi Gutierrez Hermoso
> Cc: [hidden email]
> Subject: Re: octave loop slowness (was "")
>
>
> On 17Mar2006, Jordi Gutierrez Hermoso wrote:
>
>  Of all the complaints I have heard about Octave, its slowness is the
>  one that stings the most painfully. Cuts deep. Real deep.
> 
>  So, I'm interested to know, any idea why this is happening? Why would
>  a simple for loop with no code to execute except running through all
>  the values of its iterator take orders of magnitude more in Octave
>  than in Matlab?
>
> I can think of a few possibilities:
>
> * because Octave's author only knows how to write a naive
> interpreter and is too busy with other tasks to spend a lot of
> time improving the interpreter (do you have a better one?)
>
> * no interpreter/compiler wizards have appeared on the scene with
> anything better
>
> * people who have paid actual money for Octave's development have
> cared more about features, correct results, and the fact that
> Octave is freely available than speed (which has apparently been
> good enough for them)
>
> * our army of programmers is damn small and underfunded
>
> Now, what can you do about it? Would you like to help, or just
> complain?
>
> jwe
>
>
>
> 
> Octave is freely available under the terms of the GNU GPL.
>
> Octave's home on the web: http://www.octave.org> How to fund new projects: http://www.octave.org/funding.html> Subscription information: http://www.octave.org/archive.html> 

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


Doing the JIT "properly" gets to be a mess, because you end up having to
basically throw away your entire interpreter and writing a fullup
compiler which translates Matlabish code > JVM microcode. I can
understand why Mathworks didn't want to go this way  you end up
throwing away the entire interpreter in favor of relying entirely on the
JVM. A nasty side effect of this is that you end up completely breaking
your previous language bindings (i.e. all the mex files won't work
anymore) because you have to write to Java's language bindings (the only
other option is an unspeakably nasty kludge). So, instead, Mathworks
opted to compromise and use the JIT where it was easy to do without
breaking things. I can't say I blame them for this decision.
Writing fast tight loops in /any/ interpreted language is going to be
really hard unless you are excessively smart in how you design the loop
interpreting code. Unfortunately, you've got to either a) suck up the
fact that loops (barring special cases) are going to be slow or b) suck
up the fact fast loops need to be done in C/C++. The good news is that
there isn't typically much code that needs to be done in C++ to see
significant speed ups. For example, I did histogram code in C++ for
image processing, which ended up cutting the run time of my code by an
order of magnitude. I wrote a simple wrapper for libpng to do very basic
image I/O and I ended up with another factor of 2 speed up. Very little
of the original octave code was modified, yet I managed to speed things
up nearly 20 fold.
Would it be useful to produce a document explaining some of these issues
(perhaps together with some case studies showing different strategies
for speeding code up)?
Paul Billings wrote:
> Many people compare octave to Matlab and don't realize that Matlab has
> invested mucho $$ in the JIT (justintime or "on the fly" compiling).
> While people are quick to say, "Matlab's JIT is great, why doesn't octave
> have one?", I personally don't think the JIT buys you much at all. The
> primary flaw in Matlab's JIT is that you cannot call any user functions
> within the loop!
>
> Must structured programming is, well, structured, and has numerous calls to
> functions which call functions, etc. For a sequence of calls to builtin
> functions, I will encapsulate this into a user function so that it is
> readable in the calling code and maintainable. Whoops, I've just defeated
> Matlab's fancy JIT, but I live with it since scattered cutandpasted code
> blocks are unacceptable to me.
>
> To put it another way: I can pretend that octave has a JIT. For my code,
> the "octave JIT" is about as effective as Matlab's  meaning, it ain't. I
> am happy that the people guiding this project understand that other features
> are of greater use.
>
> Paul
>
>
>> Original Message
>> From: John W. Eaton [mailto: [hidden email]]
>> Sent: Saturday, March 18, 2006 4:41 AM
>> To: Jordi Gutierrez Hermoso
>> Cc: [hidden email]
>> Subject: Re: octave loop slowness (was "")
>>
>>
>> On 17Mar2006, Jordi Gutierrez Hermoso wrote:
>>
>>  Of all the complaints I have heard about Octave, its slowness is the
>>  one that stings the most painfully. Cuts deep. Real deep.
>> 
>>  So, I'm interested to know, any idea why this is happening? Why would
>>  a simple for loop with no code to execute except running through all
>>  the values of its iterator take orders of magnitude more in Octave
>>  than in Matlab?
>>
>> I can think of a few possibilities:
>>
>> * because Octave's author only knows how to write a naive
>> interpreter and is too busy with other tasks to spend a lot of
>> time improving the interpreter (do you have a better one?)
>>
>> * no interpreter/compiler wizards have appeared on the scene with
>> anything better
>>
>> * people who have paid actual money for Octave's development have
>> cared more about features, correct results, and the fact that
>> Octave is freely available than speed (which has apparently been
>> good enough for them)
>>
>> * our army of programmers is damn small and underfunded
>>
>> Now, what can you do about it? Would you like to help, or just
>> complain?
>>
>> jwe
>>
>>
>>
>> 
>> Octave is freely available under the terms of the GNU GPL.
>>
>> Octave's home on the web: http://www.octave.org>> How to fund new projects: http://www.octave.org/funding.html>> Subscription information: http://www.octave.org/archive.html>> 
>>
>
>
>
> 
> Octave is freely available under the terms of the GNU GPL.
>
> Octave's home on the web: http://www.octave.org> How to fund new projects: http://www.octave.org/funding.html> Subscription information: http://www.octave.org/archive.html> 
>
>

Brendan Drew
Research Scientist
PercepTek, Inc.
12395 North Mead Way
Littleton, CO 80125
Tel: 7203441037 x 126
Fax: 7203442360

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


Wow, this is news to me, but it makes sense when I consider the
differences I've experienced with various programs I've written to work
in both ML and Octave. Some, like a special interpolator I wrote last
year that consisted of nothing but mathematical expressions and
conditional blocks, run hundreds of times faster in ML, while other
relatively loopintensive functions saw almost no performance
enhancement <insert viagra joke here> whatsoever.
So to be clear, ML basically reverts to onelineatatime interpreter
behavior when any userdefined function is inside the loop? If this is
the case, I wholeheartedly agree with you that the push to reproduce
such behavior in Octave, at the expense of time lost on more important
Octave objectives, is clearly a case of mistaken priorities. If that
much work is required to set up a loop that actually uses JIT, why not
just write a .oct/.mex file?!?
EJR
P.S. I see Brendan Drew responded with similar, if betterinformed,
comments before I could click "send". Oh well, I'll send this anyway,
and maybe get more clarification regarding my question in paragraph two.
Paul Billings wrote:
> Many people compare octave to Matlab and don't realize that Matlab has
> invested mucho $$ in the JIT (justintime or "on the fly" compiling).
> While people are quick to say, "Matlab's JIT is great, why doesn't octave
> have one?", I personally don't think the JIT buys you much at all. The
> primary flaw in Matlab's JIT is that you cannot call any user functions
> within the loop!
>
> Must structured programming is, well, structured, and has numerous calls to
> functions which call functions, etc. For a sequence of calls to builtin
> functions, I will encapsulate this into a user function so that it is
> readable in the calling code and maintainable. Whoops, I've just defeated
> Matlab's fancy JIT, but I live with it since scattered cutandpasted code
> blocks are unacceptable to me.
>
> To put it another way: I can pretend that octave has a JIT. For my code,
> the "octave JIT" is about as effective as Matlab's  meaning, it ain't. I
> am happy that the people guiding this project understand that other features
> are of greater use.
>
> Paul
>

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


If you could write such a document, the wiki or the website would be
interested in it. I know that I learned something about the JIT compiler
in the past two messages, and I would guess that many other people did,
too. Having it documented more fully would definitely be helpful.
Bill
On Mon, 20 Mar 2006, Brendan Drew wrote:
> Doing the JIT "properly" gets to be a mess, because you end up having to
> basically throw away your entire interpreter and writing a fullup compiler
> which translates Matlabish code > JVM microcode. I can understand why
> Mathworks didn't want to go this way  you end up throwing away the entire
> interpreter in favor of relying entirely on the JVM. A nasty side effect of
> this is that you end up completely breaking your previous language bindings
> (i.e. all the mex files won't work anymore) because you have to write to
> Java's language bindings (the only other option is an unspeakably nasty
> kludge). So, instead, Mathworks opted to compromise and use the JIT where it
> was easy to do without breaking things. I can't say I blame them for this
> decision.
>
> Writing fast tight loops in /any/ interpreted language is going to be really
> hard unless you are excessively smart in how you design the loop interpreting
> code. Unfortunately, you've got to either a) suck up the fact that loops
> (barring special cases) are going to be slow or b) suck up the fact fast
> loops need to be done in C/C++. The good news is that there isn't typically
> much code that needs to be done in C++ to see significant speed ups. For
> example, I did histogram code in C++ for image processing, which ended up
> cutting the run time of my code by an order of magnitude. I wrote a simple
> wrapper for libpng to do very basic image I/O and I ended up with another
> factor of 2 speed up. Very little of the original octave code was modified,
> yet I managed to speed things up nearly 20 fold.
>
> Would it be useful to produce a document explaining some of these issues
> (perhaps together with some case studies showing different strategies for
> speeding code up)?
>
> Paul Billings wrote:
>> Many people compare octave to Matlab and don't realize that Matlab has
>> invested mucho $$ in the JIT (justintime or "on the fly" compiling).
>> While people are quick to say, "Matlab's JIT is great, why doesn't octave
>> have one?", I personally don't think the JIT buys you much at all. The
>> primary flaw in Matlab's JIT is that you cannot call any user functions
>> within the loop!
>>
>> Must structured programming is, well, structured, and has numerous calls to
>> functions which call functions, etc. For a sequence of calls to builtin
>> functions, I will encapsulate this into a user function so that it is
>> readable in the calling code and maintainable. Whoops, I've just defeated
>> Matlab's fancy JIT, but I live with it since scattered cutandpasted code
>> blocks are unacceptable to me.
>>
>> To put it another way: I can pretend that octave has a JIT. For my code,
>> the "octave JIT" is about as effective as Matlab's  meaning, it ain't. I
>> am happy that the people guiding this project understand that other
>> features
>> are of greater use.
>>
>> Paul
>>
>>
>>> Original Message
>>> From: John W. Eaton [mailto: [hidden email]]
>>> Sent: Saturday, March 18, 2006 4:41 AM
>>> To: Jordi Gutierrez Hermoso
>>> Cc: [hidden email]
>>> Subject: Re: octave loop slowness (was "")
>>>
>>>
>>> On 17Mar2006, Jordi Gutierrez Hermoso wrote:
>>>
>>>  Of all the complaints I have heard about Octave, its slowness is the
>>>  one that stings the most painfully. Cuts deep. Real deep.
>>> 
>>>  So, I'm interested to know, any idea why this is happening? Why would
>>>  a simple for loop with no code to execute except running through all
>>>  the values of its iterator take orders of magnitude more in Octave
>>>  than in Matlab?
>>>
>>> I can think of a few possibilities:
>>>
>>> * because Octave's author only knows how to write a naive
>>> interpreter and is too busy with other tasks to spend a lot of
>>> time improving the interpreter (do you have a better one?)
>>>
>>> * no interpreter/compiler wizards have appeared on the scene with
>>> anything better
>>>
>>> * people who have paid actual money for Octave's development have
>>> cared more about features, correct results, and the fact that
>>> Octave is freely available than speed (which has apparently been
>>> good enough for them)
>>>
>>> * our army of programmers is damn small and underfunded
>>>
>>> Now, what can you do about it? Would you like to help, or just
>>> complain?
>>>
>>> jwe
>>>
>>>
>>>
>>> 
>>> Octave is freely available under the terms of the GNU GPL.
>>>
>>> Octave's home on the web: http://www.octave.org>>> How to fund new projects: http://www.octave.org/funding.html>>> Subscription information: http://www.octave.org/archive.html>>> 
>>>
>>
>>
>>
>> 
>> Octave is freely available under the terms of the GNU GPL.
>>
>> Octave's home on the web: http://www.octave.org>> How to fund new projects: http://www.octave.org/funding.html>> Subscription information: http://www.octave.org/archive.html>> 
>>
>>
>
>
> 
> Brendan Drew
> Research Scientist
> PercepTek, Inc.
> 12395 North Mead Way
> Littleton, CO 80125
> Tel: 7203441037 x 126
> Fax: 7203442360
>
>
>
> 
> Octave is freely available under the terms of the GNU GPL.
>
> Octave's home on the web: http://www.octave.org> How to fund new projects: http://www.octave.org/funding.html> Subscription information: http://www.octave.org/archive.html> 
>

"Some people don't like an audience when they work. Enough of them have
told me so with blunt instruments that I'm a phrenologist's dream come
true."
 Calvin, 10/26/1991

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


On 20Mar2006, Brendan Drew wrote:
 Doing the JIT "properly" gets to be a mess, because you end up having to
 basically throw away your entire interpreter and writing a fullup
 compiler which translates Matlabish code > JVM microcode.
By JVM, do you mean Java Virtual Machine? There is no requirement
that a justintime compiler generate Java bytecodes or have anything
at all to do with Java.
jwe

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


True, there is no requirement that you generate Java bytecode to be fed
to a JVM to get JIT; however, I am extremely leery of reinventing the
wheel. Especially when the wheel in question is a very very hairy piece
of software.
We didn't really deal much with JIT stuff in my compiler or architecture
classes, but I can imagine that supporting JIT capabilities puts some
pretty strong requirements on the VM / interpreter and forces your hand
in a number of important design issues (such as what your IR looks
like). First off, you're going to have to be keenly aware of the
underlying ABI conventions for whatever your implementation language is
so that you're able to link against JIT compiled code. You might have to
redo your symbol table to look more like a traditional compiler's symbol
table so that you can support the assembly phase of the JIT. This is
just off the top of my head  I'm sure that there are tons of other
issues which crop up when you implement JIT.
Java has already (largely) solved these problems, which is why most of
the JIT research that I'm aware of is all JVM based. There is a set of
GNU packages which allow a kind of limited (last I checked) JIT  GNU
Lightning and one other that I can't recall off the top of my head.
Maybe LLVM
( http://developers.slashdot.org/article.pl?sid=04/08/13/2356209) would
be of interest?
John W. Eaton wrote:
>On 20Mar2006, Brendan Drew wrote:
>
> Doing the JIT "properly" gets to be a mess, because you end up having to
> basically throw away your entire interpreter and writing a fullup
> compiler which translates Matlabish code > JVM microcode.
>
>By JVM, do you mean Java Virtual Machine? There is no requirement
>that a justintime compiler generate Java bytecodes or have anything
>at all to do with Java.
>
>jwe
>
>
>
>
>Octave is freely available under the terms of the GNU GPL.
>
>Octave's home on the web: http://www.octave.org>How to fund new projects: http://www.octave.org/funding.html>Subscription information: http://www.octave.org/archive.html>
>
>
>

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


True, there is no requirement that you generate Java bytecode to be fed
to a JVM to get JIT; however, I am extremely leery of reinventing the
wheel. Especially when the wheel in question is a very very hairy piece
of software.
"When all you have is a hammer, everything looks like a nail"
The problem with JVM is that the bytecodes that it defines are
designed for a general purpose interpreter. Octave needs bytecodes
that would perform octavish operations, such as matrix transpose,
multiplication, etc. If the bytecode execution loop crawled through
the data objects element by element, the performance would suck.
Whatever is used for Octave has to have primitives for dealing with
highlevel objects like entire matricesI don't know if JVM can be
jiggered to do that; maybe it could, by some combination of native
methods and binary opaque object data types, but I somehow doubt it.
In the end, I can't muster empathy for low loop speed problems. As
was said here before, if the program is slow because of loops, it is
probably needs rethinking.
Someone else complained that Octave forces people to do unnatural
operations instead of 'simple loops'. I think they got it precisely
backwards!!! It is the entire point of matrixbased systems like
Octave that you get to write them in a vectorized fashion; they are
only 'unnatural' because we didn't learn math through linear algebra,
because there were no systems like Octave.
My favorite example of that is the SavitzkyGolay filter code that I
needed in my work 15 years ago or so. The traditional 'Fortran' loopy
code for it takes about a page of loops:
http://www.library.cornell.edu/nr/bookcpdf/c148.pdfI set out to rewrite it in Octave, and at first it was frustrating,
but when I thought about it, it opened my eyes to a different way of
working and I loved Octave from that moment on. In vector notation,
that whole page is simply
lc = (l1)/2;
X = [lc:lc]' * ones(1,forder + 1);
p = ones(l,1) * [0:forder];
X = X .^ p;
F = pinv(X);
which actually corresponds better to the actual math definition of the
filter (eq. (14.8.6) in the book above), and it could be written in two
lines if the variables weren't broken out into separate lines for clarity.
p

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


>I think this is a realworld problem. It is probably the biggest flaw in
>the matlab language, making you write programs which use unintuitive and
>hard to understand tricks just to avoid forloops. As a real world
>example, have a look at the code for hist.m in octave. Instead of a ~N
>forloop, it uses NlogN sorting just because sort is done in C and thus
>is faster.
I don't really think that this is a flaw. The Octave (Matlab) language
is a matrix language, which is duly optimised for doing matrix
computations. This is exactly what one would expect from a matrix
language. Being fast at doing nonmatrix operations is certainly an
added benefit, not the foremost objective of the language.
Do you agree?
>I think that forloops are an essential part of any programming
>language, and avoiding them has unfortunately become the hallmark of
>good matlab programming. When conducting job interviews for positions
>for which matlab/octave is relevant, one of my questions is:
>
>how would you calculate a 10 sample running average on a 100 element vector?
I wouldn't say that using a for loop for such a small vector is wrong,
unless the operation is to be done many times.

Francesco Potortì (ricercatore) Voice: +39 050 315 3058 (op.2111)
ISTI  Area della ricerca CNR Fax: +39 050 313 8091
via G. Moruzzi 1, I56124 Pisa Email: [hidden email]
Web: http://fly.isti.cnr.it/ Key: fly.isti.cnr.it/public.key

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


On Mon, Mar 27, 2006 at 10:19:57AM +0200, Francesco Potorti` wrote:
> >how would you calculate a 10 sample running average on a 100 element vector?
>
> I wouldn't say that using a for loop for such a small vector is wrong,
> unless the operation is to be done many times.
I guess `conv' might also come in handy...
Stéfan

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


Francesco Potorti` wrote:
>> I think this is a realworld problem. It is probably the biggest flaw in
>> the matlab language, making you write programs which use unintuitive and
>> hard to understand tricks just to avoid forloops. As a real world
>> example, have a look at the code for hist.m in octave. Instead of a ~N
>> forloop, it uses NlogN sorting just because sort is done in C and thus
>> is faster.
>
> I don't really think that this is a flaw. The Octave (Matlab) language
> is a matrix language, which is duly optimised for doing matrix
> computations. This is exactly what one would expect from a matrix
> language. Being fast at doing nonmatrix operations is certainly an
> added benefit, not the foremost objective of the language.
>
> Do you agree?
I agree. I use octave because of these benifits.
>> I think that forloops are an essential part of any programming
>> language, and avoiding them has unfortunately become the hallmark of
>> good matlab programming. When conducting job interviews for positions
>> for which matlab/octave is relevant, one of my questions is:
>>
>> how would you calculate a 10 sample running average on a 100 element vector?
>
> I wouldn't say that using a for loop for such a small vector is wrong,
> unless the operation is to be done many times.
>
true, but I think someone who has some experience with matlab/octave
will understand at once that this question is all about avoiding the
forloop
Shai

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html


On 3/19/06, Shai Ayal < [hidden email]> wrote:
> how would you calculate a 10 sample running average on a 100 element vector?
for loop is slow. cumsum is faster. filter is fastest.
A JIT compiler would be great. But I'd rather have a function that
automatically converts mfile code into octfile code. Then you could
easily compile mfile code that contained for loops:
>> m2oct myfunction myfunctionoct
>> mkoctfile myfunctionoct
Plus you could tell mkoctfile to compile myfunctionoct as a
standalone application, which would make it easier to share with
friends that don't have Octave.
Which is harder to create, a JIT compiler or a function that
automatically converts mfile to octfile source code?

Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.orgHow to fund new projects: http://www.octave.org/funding.htmlSubscription information: http://www.octave.org/archive.html

