Re: moving toward a 3.0 release

[David Grohmann]

Bill Denney wrote:
> John W. Eaton wrote:
> > I'll get right on that.  I think I can be done by later today.
> >
> > Seriously, you must know that this is a large project for which most
> > of us here have no knowledge of how to proceed.  If people expect
> > something like this, then I think they need to start thinking about
> > real ways to find funding for such a project, along with finding some
> > people who are actually capable of doing the work.
> >  
Let me just be clear that I wasn't trying to be disrespectful to the 
work that has been done already, nor was I trying to say that you should 
wait to release 3.0 until octave == matlab . I understand that the 
interpreter speed up would be a huge undertaking.
> John,
>
> I know that this is a huge task.  I'm guessing that anyone who reads 
> the maintainers list knows that it is a huge task.
>
> While I know that many people out here don't have money to give, there 
> are a larger number of people who do have time to give, and this is 
> one of the major things that keeps people away from Octave.  While 
> Tom's solution of throwing 128 CPUs at the problem would be great for 
> some problems, it's not possible for everyone, and even if it were, 
> having a faster interpreter would speed even the 128 CPU clusters.
>
> What I think would be most beneficial toward getting this running 
> would be the work on the manual and source for 3.0.  I agree with Tom 
> and you that speeding up the interpreter is a 3.0 issue.  What I would 
> like to see by 3.0 is better code documentation and documentation on 
> how to write both .oct files and docs on how to modify the octave 
> internals.  I think that finding people who are capable of doing the 
> work would be easier with better documented source.  I know that most 
> people (Soren excepted) writing documentation is not fun, but it keeps 
> code maintainable and usable in the future.
>
> Bill
Barring any speed improvements, documenting the .oct APIs would be the 
most useful way to allow some of us to be able to put octave to work on 
a cluster, we can just write the critical sections in C++, I attempted 
to do some .oct work and had a lot of trouble due to the lack of 
documentation, could never get the feel for whether I should be using an 
octave value or and octave value list here and what not.

Does octave use that API internally when its parsing octave syntax? If 
so has anyone taken a stab at a static octave code => C++ compiler? Not 
sure how efficient that generated code would be though.

As far as 128 CPUs goes as a solution to the problem.

I ran some loop heavy code on a Pentium 3 windows matlab, and it was 
hundreds of times faster than running the same code on a Dual processor 
hyper threaded Xeon box running linux and octave, (something that took a 
~3 minutes on the windows/matlab/P3 box, still hadn't finished after 20 
hours on the Dual processor 3ghz Xeons, I had to kill the job before 
finding out the final time it would have taken to complete) Even 128 
CPUs wouldn't have made the cut.

I don't think the entire interpreter is slow, because non looped code 
ran in about the same time as the matlab code, but when you have (lots 
of) nested looping and function calling, it gets pretty bad.

Keep up the great work :-)

---

David Grohmann
Senior Student Associate
Applied Research Lab : UT Austin : ESL - S206
Office: 512-835-3237