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 _______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
