This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
Re: Adding OpenMP support for some of the GSL functions
> I am doing that too, but any gain we can get is an important one, and it
> turns out that by parallelizing rkf45_apply, my simulation runs 30% faster
> on 8 cores.
That's a parallel efficiency of 0.18% ( = 1 time unit / (8 cores *
0.70 time units)). This feels like you're getting a small
memory/cache bandwidth increase for the rkf45_apply level-1-BLAS-like
operations by using multiple cores but the cores are otherwise not
being used effectively. I say this because a state vector 1e6 doubles
long will not generally fit in cache. Adding more cores increases the
amount of cache available.
> I will have a deeper look at vectorization of GSL, but in my understanding,
> vectorizing can only be done with simple operations, while algorithms like
> RKF45 involve about 10 operations per loop iterations.
The compilers are generally very good. Intel's icc 11.1 has to be
told that the last four loops you annotated are vectorizable. GCC
nails it out of the box.
On GCC 4.4.3 with something like
CFLAGS="-g -O2 -march=native -mtune=native
-ftree-vectorizer-verbose=2 -ftree-vectorize" ../gsl/configure && make
shows every one of those 6 loops vectorizing. You can check this by
configuring with those options, running make and waiting for the build
to finish, and then cd-ing into ode-initval2 and running
rm rkf45*o && make
and observing all those beautiful
LOOP VECTORIZED
messages. Better yet, with those options, 'make check' passes for me
on the 'ode-initval2' subdirectory.
Try ripping out your OpenMP pragmas in GSL, building with
vectorization against stock GSL as I suggested, and then seeing how
fast your code runs with GSL vectorized on 1 core versus GSL's
unvectorized rkf45_apply parallelized over 8 cores. I suspect it will
be comparable.
- Rhys