[parsec-users] Looking for Windows Users

Jim Dempsey jim at quickthreadprogramming.com
Mon Jan 18 15:28:37 EST 2010


Hi Chris,
 
Great to hear of your enthusiasm.
 
There are two areas that may or may not be of concern.
 
First concerned, return of modifications to PARSEC team:
 
As indicated in earlier email, I am a Windows C++ user using MS Visual
Studio (plus my QuickThread threading tool kit). This in of itself is not a
problem. What the potential problem is that I may not be able to rework the
make files such that they will properly work with the code resubmitted to
your PARSEC team (IOW the make files may be broken). This may require
someone on your end to tweak the make files. Additionally, the compiler I
use (Intel Parallel Composer (Intel C++)) does not seem to want to compile a
xxx.C file as C++ (even when I set the options to do so). I gave up trying
to fix this and simply renamed the .C files to .CPP. The project files I
create will be using the .CPP file names and thus if you rename the returned
.CPP files to .C this may break the project files. This isn't a big deal but
may require a "REN *.C *.CPP" or other means to flip the names about.
 
The second concern, changes to original PARSEC applications and libraries.
 
The original PARSEC applications were written to measure the computational
efficiency of a Region Of Interest (ROI).
My interest also extend the timing to total application run time. I have
left ROI support routines untouched but I have added timing results to
include the total application run time. So the console output includes an
additional line at the end of the report.
 
A second modification I made was, where appropriate, to add one or more
optional command line options.
 
Example: Black-Scholes as shipped contains a hard wired "#define NUM_RUNS
100" and the code uses the macro name. For blackscholes, I added "int
numRuns = NUM_RUNS;" and the code now uses numRuns. The optional command
line option can override the number of runs. Additional tuning command line
parameters may be added on an application by application basis.
 
I expect my liberties in adding functional capabilities may or may not be
acceptable to the PARSEC user community and/or they may have good comments
on argument placement and/or values to be used requiring a minor rework of
the command line parser. I think that, when viewed from the additional
functionality offered, that the changes will be accepted by the PARSEC
community.
 
Let's consider the example of Black-Scholes in greater detail and the
changes I have made.
 
As originally written, Black-Scholes, was used to measure computation
efficiency of the processor to the most extent and threading tool to a
lesser extent, with sole focus on the "hot code" as measured by a profiler.
The code includes an SIMD version as well as non-SIMD (as well as float vs
double, although read-in for double is using %f and not %lf).
 
Nothing wrong with this, excepting that users who actually use Black-Scholes
in production, are not getting the whole picture. IOW the benchmark program
is not presenting a measure of system (application) performance running a
prototypical Black-Scholes application. By adding the command line option to
input the NUM_RUNS set to 1, and by adding to the output report the total
application run time, the application can now be used to gauge (estimate)
system performance of this type of application. Essentially this includes
the I/O time and execution time of code to perform input/output conversions.
 
The following is an example of results data (read explanation below
reports):
 
Serial run
PARSEC Benchmark Suite
[HOOKS] PARSEC Hooks Version 1.2
Num of Options: 10000000
Num of Runs: 1
Size of data: 400000000
[HOOKS] Entering ROI
[HOOKS] Leaving ROI
[HOOKS] Total time spent in ROI: 1.461s
[HOOKS] Total time spent in application: 62.326s
[HOOKS] Terminating
 
4 Thread (Windows Pthreads)
PARSEC Benchmark Suite
[HOOKS] PARSEC Hooks Version 1.2
Num of Options: 10000000
Num of Runs: 1
Size of data: 400000000
[HOOKS] Entering ROI
[HOOKS] Leaving ROI
[HOOKS] Total time spent in ROI: 0.433s
[HOOKS] Total time spent in application: 63.967s
[HOOKS] Terminating
 
4 Thread QuickThread
PARSEC Benchmark Suite
[HOOKS] PARSEC Hooks Version 1.2
Num of Options: 10000000
Num of Runs: 1
Size of data: 400000000
[HOOKS] Entering ROI
[HOOKS] Leaving ROI
[HOOKS] Total time spent in ROI: 18.109s
[HOOKS] Total time spent in application: 18.129s
[HOOKS] Terminating

In the QuickThread run the ROI includes the read-in and write-out of the
input and output files and the other two runs do not. Therefore the ROI is
not comparable between QuickThread and Serial, Pthreads or TBB (not shown
above). Whereas the total application run time is comparable. (note Num of
Runs: 1)
 
Application performance can be computed by (Num of Options) / (Total Time)
 
Serial:          160,447 Options/Sec
Pthreads (4):    156,331 Options/Sec (0.974x serial)
QuickThread (4): 551,602 Options/Sec (3.438x serial)
 
To be fair with Pthreads some optimizations can be made there with respect
to parallelizing sections of code that is not in the ROI. The QuickThread
version has parallelized much of the read-in code. The QuickThread
parallel_pipeline was used for this optimization. Further revisions to the
QuickThread code will improve the parallelization even further. Some of the
other PARSEC users might want to re-work the Pthread, OpenMP and TBB
versions of the code to improve on the total application run times. After
these revisions are implemented the PARSEC benchmark will be able to measure
both raw processing power and system performance of prototypical
application.
 
I also have adapted the BodyTracking benchmark, which by the way includes
the I/O in the ROI. Summary charts follow:
 

 
I am scheduled to get time on a Dell R610 this week (2x Xeon 5570) and will
add this to the charts.
 
As time permits, I will be adapting the remaining PARSEC benchmark programs.
 
Jim Dempsey
QuickThread Programming, LLC
 

  _____  

From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of Christian
Bienia
Sent: Monday, January 18, 2010 11:21 AM
To: 'PARSEC Users'
Subject: Re: [parsec-users] Looking for Windows Users



Hi Jim,

 

Great to hear about your work. Many PARSEC workloads should already build
and run under Windows because Windows support was part of the original
development work. The PARSEC framework doesn't make this feature accessible
via build configurations but it's possible to use it manually.

 

We are generally happy to accept any code contributions that might be useful
for other PARSEC users. If you have anything more specific please let me
know and we can talk about the details.

 

Best,

Chris

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20100118/c3f59663/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 41564 bytes
Desc: not available
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20100118/c3f59663/attachment-0001.jpe>


More information about the parsec-users mailing list