[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: moving toward a 3.0 release

From: David Grohmann
Subject: Re: moving toward a 3.0 release
Date: Fri, 29 Sep 2006 09:39:07 -0500
User-agent: Thunderbird (Windows/20060909)

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.

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]