From help-request at octave dot org Fri Feb 18 14:36:20 2005
Subject: Re: C++ using Octave headers, mkoctfile
From: "Steve C. Thompson" <sct at ucsd dot edu>
To: Przemek Klosowski <przemek at jazz dot ncnr dot nist dot gov>
Cc: help at octave dot org
Date: Fri, 18 Feb 2005 12:39:03 -0800

Przemek,

Very good.  I agree with your assessment and this was my suspicion, now
it is more clear.

However, as I said on the previous post, my simulation requires a while
loop, i.e.,

go = 1;
stop = 0;
while go
 do a whole lot of randn-ing, multiplying, summing, etc. run until
  very low probability events happen, which takes days (even with
  vectorization)
 if ( a sufficiency number of these events happen )
  go = stop;
 end
end

Writing the m-file has provided a good prototype, but I think at this
point it would be worth my time transforming this while loop into C++.  I
expect gains of several times which will make it possible for me to (1)
be done sooner, or (2) (and more importantly) explore more cases/ideas.

Steve

On Feb 18 15:16PM, Przemek Klosowski wrote:
> Francesco said 
> 
>    > Perhaps, before trying to produce C++ code, you should try to learn how
>    > to use Octave's vector abilities at their best.  For example, the code
>    > you wrote can be vectorialised as:
>    > 
>    > N=30; W=exp(j*2*pi*[0:N-1]'*[1:N]/N);
>    > 
>    > and it runs faster.
> 
>    You are absolutely correct.  But this code snippet was to serve as an
>    example only.  Let me simplify the question:
> 
> Francesco's point may have been obscured by his wording--so at a risk of
> restating the obvious, I would like to observe this: on vectorized code,
> octave takes a small interpretation hit when parsing the vector statement,
> and then it dives into usually well-optimized execution loop, often simply
> passing into super-optimized basic linear algebra library routines. 
> 
> The consequence of that is that hand-written C++ code might end up
> being slower than a vectorized Octave statement---I will tip my hat to
> anyone who can sit down and write competitive matrix multiplication code
> in C++ that would outrun Atlas. I am not saying it's impossible, just unlikely;
> after all, Atlas is known to be sometimes faster than vendor libraries.
> 
> I think that for optimization, the recommended course is to vectorize the
> heck out of it, before rewriting. When rewriting, vectorization should be
> actually helpful in writing concise and fast code.
> 
> I am reminded of those two rules of optimization that I have seen somewhere:
> 
>   Rule 1:   don't
> 
>   Rule 2:   not yet
> 
> 
> 
> -------------------------------------------------------------
> Octave is freely available under the terms of the GNU GPL.
> 
> Octave's home on the web:  http://www.octave.org
> How to fund new projects:  http://www.octave.org/funding.html
> Subscription information:  http://www.octave.org/archive.html
> -------------------------------------------------------------
> 



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------