(no subject)

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

(no subject)

Jordi Gutiérrez Hermoso
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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness ( was "")

Shai Ayal
Jordi,

Please try to use a descriptive subject line when posting to this list.

Matlab used to be slow in loops, but now has JIT technology. This has
been discussed here many times before:

http://www.octave.org/octave-lists/archive/help-octave.2004/msg00744.html

http://www.octave.org/octave-lists/archive/help-octave.2006/msg00853.html

http://www.octave.org/octave-lists/archive/help-octave.2005/msg02597.html

and we even have this thread about trying to port JIT to octave

http://www.octave.org/octave-lists/archive/help-octave.2004/msg01524.html

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?

Shai

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?
>
> - JGH
>
>
>
> -------------------------------------------------------------
> 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
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness (was "")

John W. Eaton-6
In reply to this post by Jordi Gutiérrez Hermoso
On 17-Mar-2006, 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
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness (was "")

Søren Hauberg
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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness (was "")

Jordi Gutiérrez Hermoso
In reply to this post by John W. Eaton-6
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 17-Mar-2006, 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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness (was "")

Dmitri A. Sergatskov
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 (Just-In-Time) 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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re:

Arvid Rosén
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 real-world 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 for-loops 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 for-loops,
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
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re:

Shai Ayal
I think this is a real-world 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 for-loops. As a real world
example, have a look at the code for hist.m in octave. Instead of a ~N
for-loop, it uses NlogN sorting just because sort is done in C and thus
is faster.

I think that for-loops 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 for-loop, but of course in the
octave/matlab language it is not the "recommended" way. If I get the
for-loop answer I immediately understand that this person has no
real-life 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 real-world 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 for-loops 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 for-loops,
> 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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

RE: octave loop slowness (was "")

Paul Billings
In reply to this post by John W. Eaton-6
Many people compare octave to Matlab and don't realize that Matlab has
invested mucho $$ in the JIT (just-in-time 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 built-in
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 cut-and-pasted 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 17-Mar-2006, 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
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness (was "")

Brendan Drew
Doing the JIT "properly" gets to be a mess, because you end up having to
basically throw away your entire interpreter and writing a full-up
compiler which translates Matlab-ish 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 (just-in-time 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 built-in
> 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 cut-and-pasted 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 17-Mar-2006, 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: 720-344-1037 x 126
Fax: 720-344-2360



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

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness (was "")

Josh Rigler
In reply to this post by Paul Billings
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 loop-intensive functions saw almost no performance
enhancement <insert viagra joke here> whatsoever.

So to be clear, ML basically reverts to one-line-at-a-time interpreter
behavior when any user-defined function is inside the loop?  If this is
the case, I whole-heartedly 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 better-informed,
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 (just-in-time 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 built-in
> 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 cut-and-pasted 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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness (was "")

Bill Denney
In reply to this post by Brendan Drew
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 full-up compiler
> which translates Matlab-ish 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 (just-in-time 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 built-in
>> 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 cut-and-pasted 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 17-Mar-2006, 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: 720-344-1037 x 126
> Fax: 720-344-2360
>
>
>
> -------------------------------------------------------------
> 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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness (was "")

John W. Eaton-6
In reply to this post by Brendan Drew
On 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 full-up
| compiler which translates Matlab-ish code --> JVM microcode.

By JVM, do you mean Java Virtual Machine?  There is no requirement
that a just-in-time 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
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness (was "")

Brendan Drew
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 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 full-up
>| compiler which translates Matlab-ish code --> JVM microcode.
>
>By JVM, do you mean Java Virtual Machine?  There is no requirement
>that a just-in-time 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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: octave loop slowness (was "")

Przemek Klosowski
   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
high-level objects like entire matrices---I 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 matrix-based 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 Savitzky-Golay 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/c14-8.pdf

I 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 = (l-1)/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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re:

Francesco Potortì
In reply to this post by Shai Ayal
>I think this is a real-world 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 for-loops. As a real world
>example, have a look at the code for hist.m in octave. Instead of a ~N
>for-loop, 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 non-matrix operations is certainly an
added benefit, not the foremost objective of the language.

Do you agree?

>I think that for-loops 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, I-56124 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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re:

Stéfan van der Walt
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.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re:

Shai Ayal
In reply to this post by Francesco Potortì
Francesco Potorti` wrote:

>> I think this is a real-world 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 for-loops. As a real world
>> example, have a look at the code for hist.m in octave. Instead of a ~N
>> for-loop, 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 non-matrix 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 for-loops 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
for-loop

Shai



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

Reply | Threaded
Open this post in threaded view
|

Re:

Keith Goodman
In reply to this post by Shai Ayal
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 m-file code into oct-file code. Then you could
easily compile m-file code that contained for loops:

>> m2oct myfunction myfunctionoct
>> mkoctfile myfunctionoct

Plus you could tell mkoctfile to compile myfunctionoct as a
stand-alone 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 m-file to oct-file source code?



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