pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Threads vs. OpenMP in PSPP.


From: John Darrington
Subject: Re: Threads vs. OpenMP in PSPP.
Date: Tue, 3 Apr 2007 07:35:44 +0800
User-agent: Mutt/1.5.9i

On Mon, Apr 02, 2007 at 08:53:21AM -0700, Ben Pfaff wrote:
     "John McCabe-Dansted" <address@hidden> writes:
     
     > 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.
     
     I don't think I saw the discussion of adding threading to PSPP.
     Was it on pspp-dev?

I think John's refering to a discussion I had with him in-person in
the UWA tea room some weeks ago.
     
     What is the purpose of adding threading?  I can think of two
     possibilities: to separate the UI from data processing to improve
     the interactive experience, or to break data processing into
     multiple threads to increase data processing throughput.

Indeed, this is a very pertinent question.  For the latter purpose,
(what I call "parallelism") tools like OpenMP might be useful.  For
the former purpose (what I call "concurrency") I think that
conventional multithreading APIs are more suitable.

  I can think of two disadvantages of OpenMP.
   * It was not supported in gcc until 4.2

I looked at OpenMP a few years ago.  I'm sure this was before gcc 4.0
was out.  As I recall, OpenMP (at least back then) is merely a
preprocessing layer which converts it's own pseudo code into Pthread
calls.  Perhaps in gcc 4.2 it's inherently supported somehow?

Regardless of whether OpenMP or something else is used, any use of
underlying libraries have to be thread safe ... and  our libpspp and data
libraries are currently not.  They could be made safe with a few
synchronisations --- but the API you use for synchronisation has to be
available on all platforms...

  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.

The GThread stuff in GLib is just a wrapper around whatever threading
library is supported on the platform concerned.  In the case of
GNU/Linux, this is PThreads.

As I understand it, OpenMP is also merely a wrapper around a lower
level thread library. If it happens to be the same as the library used
by GLib, then there should be no fundamental problem.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.


Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]