[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C++ using Octave headers, mkoctfile
From: |
Steve C. Thompson |
Subject: |
Re: C++ using Octave headers, mkoctfile |
Date: |
Fri, 18 Feb 2005 12:39:03 -0800 |
User-agent: |
Mutt/1.3.28i |
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
-------------------------------------------------------------