[parsec-users] Fluid animate

Jim Dempsey jim at quickthreadprogramming.com
Tue Mar 9 10:08:52 EST 2010


Chrs,
 
>>When you modify some of the program versions then please make sure the
other versions are modified in a similar way
 
Will try my best, but there are some strategy differences, principally
 
Serial, Pthreads, TBB using Cell table of particles (extended to linked
table of particles when table overflows)
QuickThread using Cell with linked list of particles.
 
So particle traversal within cell is different.
 
The linked list traversial strategy could be implemented in the other
threading models, but I can leave that up to others to experiment with.
 
I am experimenting with a 2nd QuickThread variation that will have
considerations for NUMA archetecture. It is unknown at this time as to if
the overhead for the code added exceeds the memory access efficiencies
gained. I do own a 2 node 4-core NUMA system so I can perform limited
testing. Then periodically I can get access to dual socket Nehalem. Getting
time on a 4 or 8 node system is problematic. Intel has their Parallel
Universe Portal. The problem with that is transfering the data files in the
limited time window.
 
The other thing I am formulating is how to pipeline the process and
eliminate the barriers by doing so. In the in_35K runs the barriers consume
~5%. I don't have the stats on the time consumed executing the interlocked
operations for setting the locks and atomic operations. Using the border
flags this was reduced to the cells at the borders producing ~9+1+9 locks
per border cell. With the number of border cells increasing with the number
of cores. Depending on how the threads traverse the cells, the probability
of lock interference approaches 0. So maybe something can be done with
progress flags that are manipulated without locks. Still thinking about
that..
 
Jim
 
 
 

  _____  

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, March 08, 2010 8:40 PM
To: 'PARSEC Users'
Subject: Re: [parsec-users] Fluid animate



Hey Jim,

 

That looks really good. Great that you could achieve further speed
improvements with QuickThreads. How exactly did you reduce the amount of
synchronization required? Access to bigger SMP systems is the main issue I
was also fighting with when I worked on the PARSEC workloads.

 

When you modify some of the program versions then please make sure the other
versions are modified in a similar way, otherwise they become incomparable.
The idea of multiple program versions is to have the same algorithm in
different implementations so that only the parallelization model differs.
Let me know when you have a program version that you're satisfied with.

 

Great job so far! J

 

- Chris

 

 

From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of Jim
Dempsey
Sent: Saturday, March 06, 2010 8:31 PM
To: 'PARSEC Users'
Subject: [parsec-users] Fluid animate

 


Chris,

I made improvements to fluidanimate. I fixed some of the colorizing for the
visualization and I have the QuickThread version running. The in_500K really
looks neat (could have better color scheme). I am running some benchmarks
tests now. Currently compiled as 32-bit and running on Windows XP x64. The
QuickThread implementation is faster. As least on the in_35K runs. The
in_500K the difference is not as large (due to fewer locks/particle
permutation).

 

Now if I only can have access to a 16 core or more system I could realy give
it a good test.



Intel Q6600 4 Core Win XP x64 (programs compiled and run as x32)
Best of 3 runs

Fluid animate in_35K 500 iterations


              threads  run 1    run 2    run 3    best     ratio
Serial           1     46.050   45.958   46.044   45.958   1.000


Pthreads-w32     4     15.931   16.064   15.946   15.931   2.885
TBB              4     17.240   17.268   17.207   17.207   2.671
QuickThread      4     13.862   13.291   13.293   13.291   3.458

Pthreads-w32     2     26.974   27.274   27.268   26.974   1.704
TBB              2     29.051   28.929   28.950   28.929   1.589
QuickThread      2     24.478   24.501   24.949   24.478   1.878

Pthreads-w32     1     49.356   49.246   49.303   49.246   0.933
TBB              1     56.436   56.593   56.516   56.436   0.814
QuickThread      1     48.351   48.363   48.147   48.147   0.955

Fluid animate in_500K 50 iterations


              threads  run 1    run 2    run 3    best     ratio
Serial           1     67.818   67.732   67.732   67.732   1.000


Pthreads-w32     4     23.075   22.752   22.826   22.752   2.977
TBB              4     27.447   27.693   27.454   27.447   2.468
QuickThread      4     21.580   21.750   21.965   21.580   3.139
                 
Pthreads-w32     2     39.274   39.207   39.208   39.207   1.728
TBB              2     45.737   45.686   45.929   45.686   1.483
QuickThread      2     37.460   37.012   37.034   37.012   1.830
                 
Pthreads-w32     1     72.950   72.818   72.934   72.818   0.930
TBB              1     84.302   84.292   84.345   84.292   0.804
QuickThread      1     69.970   69.904   69.824   69.824   0.970 

 



Above is Serial near frame 305



Above is Pthreads-w32 near frame 305



Above is QuickThread near frame 305

All thread are similar yet different. (ignore the highlighting differences,
look at the contours)

 

Jim

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20100309/2754a292/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 32057 bytes
Desc: not available
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20100309/2754a292/attachment-0003.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 31677 bytes
Desc: not available
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20100309/2754a292/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25982 bytes
Desc: not available
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20100309/2754a292/attachment-0005.jpe>


More information about the parsec-users mailing list