help-octave
[Top][All Lists]
Advanced

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

Re: iterations are s l o w


From: Ted Harding
Subject: Re: iterations are s l o w
Date: Fri, 14 Jul 1995 13:01:49 +0200 (BST)

( Re Message From: Francesco Potorti` )
Exactly the same happens in Matlab, for instance. Without knowing the full
internal details, the essential reason is that your first code (for n=12)
makes several passes (on j), for each value of i, through the interpreter
(which is relatively slow), passing single elements from the arrays each
time, while your second code makes one pass, passing the arrays in full
that one time. The compiled-in array arithmetic routines are very fast
indeed, so almost all the time is spent in the interpreter.  Hence your
time factor. There is also the overhead of extracting the individual
elements from each array each time, and assigning the individual results.

Programming with whole arrays rather than element-by-element should always
be adopted when possible in Matlab or octave - it is what they were
designed for. You should no more think of doing your calculation
element-by-element than you should think of computing a matrix product
element-by-element.

It is worth making every effort (which may sometimes require considerable
ingenuity) to maximize the "array-wise" computation.  Some of my
calculations, which take a minute or two done array-wise, would take
several days if done element-wise.

Ted.                                    (address@hidden)
----------------------------------------------------------------------------
> I got a tenfold or some increase on a simple instructions loop by
> modifying it to use matrix ranges.  While I expected a speed increase,
> I have the feeling that the increase is too big, and something is
> wrong in the for iteration.
> 
> In the following, FBM is a 2^n+1 long column vector.  The second code
> does the same thing more or less 10 times quicker on an alpha (I can
> time it exactly if it is important) when n is 12.  With greater n, the
> difference is greater yet (this is obvious, but it is too much, in my
> opinion). 
> 
> Is there a reason or is it a sort of "performance bug"?
> 
> ##for i = 1:n
> ##  d = 2^(n-i);
> ##  scale = scale * 2^-H;
> ##  for j = d+1:2*d:N-d+1
> ##    FBM(j) = 0.5 * (FBM(j-d) + FBM(j+d)) + FBM(j)*scale;
> ##  endfor
> ##endfor
> 
>   for i = 1:n
>     d = 2^(n-i);
>     scale = scale * 2^-H;
>     range = [d+1:2*d:N-d+1];
>     FBM(range) = 0.5 * (FBM(range-d) + FBM(range+d)) + FBM(range)*scale;
>   endfor
> 
> --
>        Francesco Potorti`     | address@hidden (Internet)
>        researcher at          | 39369::pot (DECnet)
>        CNUCE-CNR, Pisa, Italy | +39-50-593203 (voice) 904052 (fax)
> 




reply via email to

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