help-octave
[Top][All Lists]
Advanced

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

Re: interp1 OCT file


From: Luke M
Subject: Re: interp1 OCT file
Date: Fri, 2 Jul 2010 15:45:40 -0700 (PDT)


Jaroslav Hajek-2 wrote:
> 
> Here are several tips:
> 
> Use const declarations for read-only arrays. This eliminates the
> unnecessary aliasing check.
> 
> When writing to an array that is known to be unaliased, you may use
> the xelem method. Alternatively, use the NoAlias template wrapper for
> the array.

Thanks, those are exactly the sort of things I'm looking for.  I asked the
wrong question though: I'm more concerned with finding out better ways to do
what I've done, as opposed to just speed.  For instance, what about my
ColumnVector vs. NDArray findings?  Is that expected (see below)?  Is there
a class with less overhead that I should use for speed?  I'm not using a
whole lot of the functionality after all.

The code posted works with 3.3.51 on 64-bit Ubuntu 9.04 on AMD dual-core 2.0
GHz, though it doesn't work with 3.2.3 on 64-bit RHEL5.3 on Intel quad-core
2.66 GHz.  Octave 3.2.3 apparently can't do the implicit conversion to
ColumnVector, or at least it is not allowed.  My NDArray version, which was
only tested on RHEL5, was only slightly faster than interp1q in the 1000-
(technically 1001-) element case.

Unfortunately it has been a while since I compiled, but now that you mention
it, I believe I did so without BLAS and LAPACK on RHEL5/3.2.3.  Would that
be a source of slowdown?  In contrast I'm pretty sure my Ubuntu/3.3.51
machine does have them since I believe they are required to build it.
-- 
View this message in context: 
http://octave.1599824.n4.nabble.com/interp1-OCT-file-tp2276588p2276970.html
Sent from the Octave - General mailing list archive at Nabble.com.


reply via email to

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