Re: execution speed in *oct files

[Artur Jorge Azevedo Carvalho]

> 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

Hi all,

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 beiing a usefull 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've found very interesting the fact that, as we all that use octave have
surely notice
from the beginning, things aren't quite fast as c pointer or matlab or
whatever, so in
terms of performance we can't call octave as the best example of optimized
code.

If we start doing the .oct files like Andy Adler suggests, we all lose the
potencialities that octave has to offer. Imagine as a little example that i
have
to do a lot of matrix operation like multiplications, sums, determinants, etc
(the
thing that  really matter cause they're the most time consumming). If i was to
use
c pointers instead of using octave's classes  i'd have to rewrite almost all
the
code of octave regarding data manipulation... one thing i'm not willing to
do...
As far as i see it, one way to do this would have to pass throught jwe, cause
optimization would have do come from the inner classes.
Most operations on matrixes are made using function calls, using the elem(x,y)

insted of using the direct reference *(p*x +y), data is proctected from the
outside
so there is no way of accessing it directly, etc. One could create a fast
class that
inherits  from MArray2 and call it FMatrix but then again you would have to
redefine
everything again and, as far as i know, there is no garantee from jwe that
things would
work out on diferent, and next to come, versions.

I understand perfectly the position of jwe, cause in terms of code maintenance
it's
much easier to do it like it is done and, after all c++ should be this way,
but it is a fact
that perfomance is an issue that we can't let it pass by so
unconscientiously...

best regards, artur

ps: sorry for the english

ps2: and if you think that the best solution is indeed the one refered by Andy
Adler
has anybody any suggestion on doing the reverse transformation? from pointer
to
matrix data type? Because I might want to *change* the matrix, not just read
it.

DEFUN_DLD (testex, args,,"")
{
Matrix x = args(0).matrix_value();
 const double *px = x.data();
 return octave_value_list(???what???);
}

octave_value(Matrix(MArray2<double>(px,c,r)))
any of the constructors using double pointers are proctected as far as i've
found
out, and the only way i see to make the array is going by each of the matrix
elements,
like this:

Matrix z(x.rows(),x.columns());
for (int i=0;i<x.rows();++i)
    for (int j=0;j<x.columns();++j)
        z(i,j)=static_cast<double>(px++);

anyway any suggestion would be also welcome....



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