Re: Octave Compiler

[Przemek Klosowski]

   file and benefit from the speedup. I had a convesation with someone and 
   they said a simple "no optimization" C++ implementation of some of their 
   ..oct files gave something like a 6x speedup. 

I think the best approach is to have a flexible component system. I
think it is a false dichotomy to propose either 'full octave' or 'full
C++'. In particular, I doubt that every piece of the above-mentioned
application sped up 6 times---I would guess that they had some pieces
that were same (or slower!) in C++, and some pieces that run tight
computation loops that sped up, say, 100 times, giving an average of 6. 

In other words, I think it is better to prototype in .m files, find
out the slow spots, and speed those up. This is such a conventional
advice that I feel silly writing it down---I really don't understand
why people would prefer to prototype in C++ unless they really
disliked the .m files while loving C++ a lot.

The current .oct system is a good start: it's fairly flexible, gives
easy access to most of Octave internals, has the beginnings of a
reasonable documentation, etc. Still, as the constant discussions
show, there are usability problems with it. In the glorious end,
I wish for a flexible component system with the following attributes:

 - flexible, rich and probably extensible data exchange mechanism, to
   pass data between modules

 - language, network and platform independence--this kind-of follows from
   the previous attribute

 - introspective, self-describing environment, with some kind of directory
   of available modules/services

 - good facilities for profiling (to find the weak/slow spots) and debugging
   (NB, John, is there a way to instrument Octave to do a high-level equivalent
   of gprof? Would that be a good idea? It might simplify development work
   like fixing the concat slowness that you did recently)

As it is today, we end up doing a lot of duplicate work: the current paradigm
requires 'capturing' functionality in each system (e.g., we have to 'port'
FFTW and VTk to octave; compile GUI widgets into Matlab, etc. etc.). I want
to be able to use facilities provided by different applications to be 
easily cross-hooked between them. For instance, I would like to be able
to share an octave array with Gnumeric, for some ad-hoc editing.

In a sense, Octave's plotting (via gnuplot) is exactly the right approach:
"Don't duplicate! Freeload!". Of course, octave/gnuplot suffers from gnuplot's
one-directional approach (it will accept your X limits but won't tell you what 
its
own X limits are), and the data exchange using disk files is, ahem, limited.

Microsoft COM (and DCOM) has this to a degree, but it is a poor design
in some other respects. I hear that a number of people think that .NET
is a reasonable design (Miguel de Icaza and the MONO team)---I reserve
a judgement on that, and on how well it would work in the real world
with Linux/Mac/Windows components, but the general idea is right.

   thinking it may be possible to pre-compile the code which will run on 
   remote nodes into a form independent of octave and then execute it 
   during an Octave session. (This idea is still a little gray....in the 
   short term I'm just working on getting a bunch of machines running 
   Octave to cooperatively run arbitrary code.)

That's actually very close to what I am proposing!! don't write the whole
application in MPI, just the relevant pieces that benefit from it.

   > Today developers don't use Octave because they have to reingineer their
   > prototype sooner or later in C++. So they take C++ for the prototype as

   Yes, I know that one well, I found myself procrastinating in converting 
   my working Octave code to C/C++ code for an application a few days ago. 
   It just hurts.

Yes, it hurts. AArgh! Let's not do that :).

   > Do you know Ptolemy? Ptolemy is a simulation environment. Its kind alike
   > Simulink - but much more powerful. Its based on C++ classes connected by
   > Tcl Functions. But C++ has limitation in numerics - its just to far away
   > from the problems of engineers. So we want to use Octave as the language
   > for describing the blocks. Just like Simulink is able to use Matlab.

   Ya, I have come across this project before, it's a moutain they've done. 
   Definitely a good direction to go in, however, it may again be worth 

The usual problem with frameworks is this: one can start by
concentrating on the framework first, or the 'modules' first. In the
former case, it is hard to get people to use the framework, and it is
hard to get the design right---there's a tendency to overengineer or
get the features wrong. In the latter case, the framework tends to be
an afterthought, with, e.g., design limitations. Perhaps taking an
existing framework, like Ptolemy, or .NET, is a good approach???