[parsec-users] about non OpenMP programs

Jim Dempsey jim at quickthreadprogramming.com
Thu Sep 30 11:47:31 EDT 2010

You can use OpenMP for many of the other benchmarks, however some of these
may have to be programmed using a non-traditional OpenMP technique.
Non-traditional is too harsh of a word for this type of programming, because
as you use it, it becomes more traditional.

OpenMP is traditionally thought of as

   #pragma omp parallel for

However new users overlook

   #pragma omp parallel

Take fluidanimate for example.

The Pthead technique starts a thread team of n threads (n = number of
logical processors)

A thread team can easily be started in OpenMP using

void AdvanceFrameMT(int tid)
  if(tid == 0) {
    std::swap(cells, cells2);
    std::swap(cnumPars, cnumPars2); }
  #pragma omp barrier
  #pragma omp barrier
void AdvanceFramesMT(int tid, int nFrames)
  for(int i=0; i < nFrames; ++i)

int main(int argc, char* argv[])
   #pragma omp parallel num_threads(thrednum)
     AdvancdFramesMT(omp_get_thread_num(), framenum);

I would suggest you first look at the Pthread implementation and adapte it
for using "#pragma omp parallel" team construction as opposed to using
"parallel for". Once you measure the cpu utilization, if underutilized then
experiment with moving the parallization deeper (finer grained).

I also have a QuickThread adaptation for some of the PARSEC benchmarks. For
those interested in exploring QuickThread (demo use only) just send me your
email address (use jim at quickthreadprogramming.com) and I will give you
download access to our support website. Once you get the software installed
(copy to folder and set environment variables), I can then post or email the
various PARSEC benchmarks that have been adapted to QuickThread. Eventually
I would like to submit a demo copy to the PARSEC group for inclusion into
the distribution.

As to why you might want to explore using QuickThread, the reason would be:
most of the converted programs run faster. And you might learn a thing or
two about parallel programming.

Not all of the PARSEC demos have been adapted for use with QuickThread, some
prodding by the PARSEC user base might motivate me in completing this
project. Feel free to add your own contributions too.

By the way, the QuickThread adaptation for fluidanimate is programmed with
cache level sensitivity and includes changes in the visualization code plus
several bug fixes to the original code. Some of these changes may have been
made by Chris and his PARSEC team, as I reported the bugs when I found them.

The BodyTrack version for QuickThread illustrates two features that are not
available in TBB. 

1) QuickThread has two classes of thead pools: Compute and I/O.
   Overlapping of I/O with compute is illustrated in this example.
   This feature permits you to avoid oversubscription and undersubscription
of your thread pools.

2) QuickThread has the capability of performing non-barriered (non-blocking)
   Permitting an additional degree of concurrency to be easily programmed
into the application.

Jim Dempsey

-----Original Message-----
From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of
Ramachandra CN
Sent: Thursday, September 30, 2010 9:32 AM
To: parsec-users at lists.cs.princeton.edu
Subject: [parsec-users] about non OpenMP programs

Hi all,

As I understood from the PARSEC CSWiki, only blackschole, bodytrack and
freqmine programs are OpenMP based.

As rest of programs are either pthread or ITBB based, I am assuming it
should be "possible" to make them use OpenMP.
Would that be possible or is there anything inherent in them to prevent
using OpenMP?

It would be great if anybody comment about the feasibility and availability
of OpenMP version of other tests in the suite.

Thank you
parsec-users mailing list
parsec-users at lists.cs.princeton.edu

More information about the parsec-users mailing list