[Top][All Lists]

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

Re: execution speed in *oct files

From: Artur Jorge Azevedo Carvalho
Subject: Re: execution speed in *oct files
Date: Mon, 07 Jun 1999 17:43:30 +0100

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

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
to do a lot of matrix operation like multiplications, sums, determinants, etc
thing that  really matter cause they're the most time consumming). If i was to
c pointers instead of using octave's classes  i'd have to rewrite almost all
code of octave regarding data manipulation... one thing i'm not willing to
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
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
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
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

best regards, artur

ps: sorry for the english

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

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

any of the constructors using double pointers are proctected as far as i've
out, and the only way i see to make the array is going by each of the matrix
like this:

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

anyway any suggestion would be also welcome....

Octave is freely available under the terms of the GNU GPL.  To ensure
that development continues, see
Instructions for unsubscribing:

reply via email to

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