<div dir="ltr">    I've done some initial benchmarking of openmp performance using the<br>clang compiler from our fink llvm34-3.4.1-0e packaging which has the<br>current openmp trunk svn built against the llvm/compiler-rt/clang 3.4.1<br>
with a back port of current clang-omp from github applied. The results for<br>the heated_plate_openmp.c demo code compiled and run with the<br>heated_plate_gcc.sh shell script revealed some interesting results. The<br>demo code is run at one, two and four OMP processes. Ratioing these<br>
timings to the one OMP process timing shows the following on a 16-core <div>MacPro on darwin13…<br><br>1:1.90:3.31 for FSF gcc 4.8.3<br><br>1:1.90:3.30 for FSF gcc 4.9.0<br><br>1:1.99:3.71 for clang 3.4.1 with openmp and merged clang-omp<br>
<br>this compares to the results on a 24-core Fedora 15 linux box<br><br>1:1.99:3.92 for FSF gcc 4.6.3<br><br>1:1.99:3.93 for FSF gcc 4.8 branch svn<br><br>I've filed <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333</a> on the<br>
reduced performance of gomp on darwin compared to iomp5 on darwin and<br>gomp on linux. Their response was that darwin's use of pthread_mutex calls</div><div>rather than futex was the cause in gomp and that we should be using linux.<br>
    While the results for iomp5 are far better on darwin than those for<br>gomp on darwin, we still are lagging behind the performance of gomp using<br>futex on linux. FYI, the heated_plate_openmp.c and heated_plate_gcc.sh <div>
are attached to PR 61333.<br>            Jack</div></div></div>