Threads vs. OpenMP in PSPP.

[John McCabe-Dansted]

I was discussing introducing threading into PSPP.  Later I though came
across OpenMP, and I am thinking that OpenMP might be a better choice
than explicit management of threads for parallelism in PSPP.
 http://www.openmp.org/drupal/mp-documents/cspec20.pdf

It seems that OpenMP would have the a number of advantages including:
 * trouble-free support on all platforms that support gcc (or icc or ...)
   - E.g.   http://www.nabble.com/Re:-windows-mingw-openmp-build---t3467009.html
 * Probably less work to convert and debug existing code, as OpenMP
is mostly #pragma style markup.
 * OpenMP programs can be compiled on architectures that don't
support threading or OpenMP, they just don't get the parallelism.
 * Easier to debug. To test whether a bug relates to thread ordering,
simply disable OpenMP.

I can think of two disadvantages of OpenMP.
* It was not supported in gcc until 4.2
* It probably isn't the best choice for putting the psppire gui into
a seperate thread so it can continue to respond while pspp is
processing.

On the other hand, older versions of gcc 4 tend to give poorer
performance, so those serious about spend should consider recompiling
with gcc 4.2 (or even icc).

Also, for psppire, we have access to the glib thread library, which is
designed to be portable. This may be a better choice for splitting the
gui thread from the work thread. I don't know if g_threads play well
with OpenMP. It may be possible to use the minimal threading API in
OpenMP to support splitting the gui thread.

An overview of the different parallelism solutions is at:
 http://www.openmp.org/drupal/node/view/11#Q5
A comparison specifically of OpenMP vs pthreads is at:
 http://www.intel.com/cd/ids/developer/asmo-na/eng/99708.htm

Anything else relevant to the issue of OpenMP vs pthreads?

--
John C. McCabe-Dansted
PhD Student
University of Western Australia