Re: execution speed in *oct files

[A. Scottedward Hodel]

>From: [user name deleted; many others echo similar sentiments]
>> I've tried to focus on correctness rather than speed, so there may
>> also be some things in the Octave libraries that are written in ways
>> that make certain optimizations or inlining is not possible.  If so,
>> and you have ideas about how to fix the source, please submit a patch.
>>
>> Thanks,
>>
>> jwe
>
>I've found that this may be a topic worth of discussion, so if you all don't
>mind i'd like to share my thoughts on this...
>
>I'd like to start on pointing that octave, i should say the core of octave,
>has reached a rather stable point, i think, in terms of basic structures 
>which octave is based on, and no question about it, it has proved as being 
> a useful tool for all of us.
>
>Now, of course the PROJECTS file is rather long, and things such as sparse
>matrices, multidimensional arrays, etc are always important improvements. 
>But isn't speed also important? Isn't this the reason of being of .oct 
>files? So, in the users perspective what is at this point more important? 
>Wouldn't be important to make Octave faster before
>turning it more and more dependant on its actual structure?

I am very pleased and grateful for the work that has been done on Octave to
date; it's amazingly portable and versatile, especially considering the
number of people/man-hours involved in its development.  The current 
development environment is somewhat different from a couple of years ago.

* Octave is a fairly stable program, and the 80/20 rule on feature development
  seems to be taking effect

* Octave features required by the initial developers are pretty much in
  place, and so some of the motivation for amazingly fast development is
  gone, replaced by motivation to use the package to solve problems, 
  developing new features as needed.

Continued rapid development is merely a question of manpower and funding.
John has been great about FAST turnaround for fixes that required his 
attention.  [I, on the other hand, took over a month to take care of a 
relatively simple problem in expm reported on the octave-maintainers list.]  
A lot of this development has been done in people's "spare time" or as part 
of other projects (e.g., my work with MSFC over the last 9 years).  

There is desire (in me as well)  to optimize the libraries for speed 
(and, of course, correctness), but the work's gotta come from some place.
While many of us on the list would be glad to do the work on Octave
to make it globally available, we can't work for free.  (My dept. head
measures me in terms of publications and dollars, not necessarily in that
order.)  

Last March there was a flurry of mail on the idea of financial
support for John so that he could continue to work on Octave, culminating
in establishment of a funding vehicle at U. Wisc. so that wish
lists could become reality.  Until that vehicle gets effectively used,
Octave will progress only as fast as its current development community
directly needs it to do so.  [And so the control systems toolbox is
now basically holding still while I use it to solve "real" problems.]

My experience with John is that if someone will do the work to 
implement and test a more efficient/more accurate way to do something, 
he's been pretty  good about incorporation into the main Octave releases.  

"And that's about all I got to say about that."
    --- Forrest Gump

A S Hodel Assoc. Prof. Dept Elect Eng, Auburn Univ,AL  36849-5201
On leave at NASA Marshall Space Flight Center (256) 544-1426
Address until 15 Mar 2000:Mail Code TD-55, MSFC, Alabama, 35812
http://www.eng.auburn.edu/~scotte



---------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.  To ensure
that development continues, see www.che.wisc.edu/octave/giftform.html
Instructions for unsubscribing: www.che.wisc.edu/octave/archive.html
---------------------------------------------------------------------