Compiler (GCC) support to parallelism

04/07/2008

Testing parallel std-algorithms

std::random_shuffle does not work for OMP_NUM_THREADS=1 bug submitted. see report

gcc 4.3.1 include parallel version of many std algorithms. I tested some of them with this trivial program (stdsort.cpp)

  std::vector<int> v(1000000,1);
  std::partial_sum(v.begin(),v.end(),v.begin());
   std::random_shuffle(v.begin(),v.end());
   std::sort(v.begin(),v.end());
   std::random_shuffle(v.begin(),v.end());
   std::stable_sort(v.begin(),v.end());

where each call is actually enclosed in a "high precision real-time clock".

Once discovered that random_shuffle seems to be buggy for one thread results make a bit more sense....

a simple "HPC" multi-thread program: prime numbers

The training organized by OpenLab proposed the simple exercise of compiling the list of the first N prime numbers using a brute force approach.

The original version (ompPrimes.cpp) uses OpenMP and compile just fine with gcc 4.3.1. I also developed two alternative solutions: the first (psxPrimes.cpp) uses standard posix threads (actually boost::thread), the second (stdPrimes.cpp) uses parallel gcc.

The results listed below has been obtained on a 2x4core machine Intel Xeon E5410 2.33GHz

03/07/2008

multicore tests

can be found in /afs/cern.ch/user/i/innocent/public/multicore

compiling with gcc 4.3.1

gcc 4.3.1 has support for omp and parallel-stl

I use this simple script to set up my development environment

setenv Boost135 /afs/cern.ch/sw/lcg/external/Boost/1.35.0_python2.5/slc4_amd64_gcc43/include/boost-1_35/
setenv LD_LIBRARY_PATH /afs/cern.ch/sw/lcg/contrib/gcc/4.3.1/slc4_amd64_gcc34/lib64/:/afs/cern.ch/sw/lcg/contrib/mpfr/2.3.1/slc4_amd64_gcc34/lib/:${Boost135}/../../lib/:${LD_LIBRARY_PATH} 
alias c43 /afs/cern.ch/sw/lcg/contrib/gcc/4.3.1/slc4_amd64_gcc34/bin/c++ -O2 -D_GLIBCXX_PARALLEL -fopenmp  -pthread -I${Boost135} -L${Boost135}/../../lib/ -lboost_thread-gcc43-mt
unsetenv OMP_NUM_THREADS

setenv OMP_NUM_THREADS 1 can be used to switch to a sequential processing in a single thread

-- VincenzoInnocente - 02-Mar-2011