Further progress on "why is my mac so slow".
It turns out that the benchmark I sent roudn previously was completely
screwed by the use of
#define IMAX 1E8
This is a double not an int so each time round the loop the loop counter
was being cast to a double. Changing the code to
long IMAX = 1E8;
brings the mac into line (slightly faster).
I next tried "real world". KAPPA Fourier runs twice as fast on my linux
box as on my mac.
Further profiling of KAPPA Fourier indicated two results:
* Using memcpy or memmove is 50% faster than the equivalent
DO I = 1, NMAX
OUT(I) = IN(I)
END DO
On linux memcpy/memmove takes the same time as the normal loop.
The memcpy on OSX is hand crafter assembler but it looks like
linux glibc is straight C code.
* Almost all the time was spent extracting columns for the FFT.
This really kills the G5 since it always tries to prefetch the row.
I can't see any way of making this faster since the columns are
needed.
The recommended flags of -malign-natural and -falign-loops=16 have
miniscule effects.
Unfortunately, the biggest effect is the jumping around in a data array
and there is little I can think of to solve it.
The first issue can be "solved" though. My plan is to optimize VEC_xTOx
in PRM to call memmove. This should have no effect on systems that
implement memmove as a for loop but will have a big effect on the G5.
To that end I've done the following:
* Removed any calls to COPAR/COPAD (mainly kappa fourier it turns out)
and replaced with a call to VEC_xTOx.
* Replaced the loop in CCG1_COPA and CCG1_COPS with calls to VEC_xTOx
* I'm intending to remove copar.f and copad.f from kalibs since they
aren't used. copy2d.f is also unused.
Next up is to sort out VEC_xTOx. Followed by profiling some more to find
out which explicit loops in kappa can be replaced with a call to VEC_
Am I allowed to use "generic" code in PRM?
It seems that many loops are over 2-D image copies. I can optimize that
to a certain extent (using VEC_ or a wrapper around VEC_ if the number of
elements overloads an INTEGER). Unforuntately I can't think of an obvious
name for the function. It can't be VEC_ since it isn't vectorized
and the existing COPY2D in Kaplibs probably shouldn't stay in kaplibs
since we don't want a big kaplibs dependency for someone to do an array
copy. I was thinking of calling it ARR_xTOx and putting it in PRM
(IMG_xTOx would be confusing for a 2-D image optimization).
Something like:
ARR_xTOx( USEBAD, NDIMS, DIMS, LBND, UBND, INARR, OUTARR, IERR, NERR,
STATUS)
(with USEBAD, IERR and NERR simply there to match the prm interface for
VEC_). Then if LBND is all ones and UBND == DIMS then this is a vec_
copy, else it's a manual copy of a subarray (it's actually a VEC_
copy if the first NDIMS-1 dims match DIMS).
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
