Extra questions for PDC
CS 300, Parallel and Distributed Computing (PDC)
Not assigned in Interim 2015
From HW3 and HW4
OpenMP
[HC]
Consider the program threadsafe.C, which does
parallel operations on an array, including parallel calls to a
function func().
The output from multiple sample runs of threadsafe.C shows that
func() is not a thread-safe function, because
the value of count varies during some calls of
func, and some of the multiplications of elements in the
array arr[] are not performed correctly. Improve this
code to make the code for func() thread-safe, using
OpenMP constructs.
Report on the corrections you made and any other observations you
have on paper or in a
README file.
Notes:
After compiling threadsafe.C to produce an
executable threadsafe, invoke that executable as follows,
in order to see the initial output that indicates how
count varies:
% ./threadsafe | less
To see the next page of output from less, enter a
space; to see just one more line, press the Enter key.
The program threadsafe accepts one positive integer
command-line argument, representing the number of threads to use
(default 8).
Observe that threadsafe produces correct results if a
single thread is specified (sequential computation).
Recall that OpenMP's atomic construct can be
specified before a simple assignment using operators such as
+=, *=, <<=,
++, etc., in order to cause that assignment to be
indivisible.
Also recall that OpenMP's critical construct can
make a more general statement indivisible (e.g., a compound statement
{ ... }). Since critical uses locks to keep
more than one thread from executing its statement, it has unacceptable
performance for long program sequences. However, it can be useful for
making local copies of a global variable, as follows: Suppose that
g is a global int variable. Then
{
int copy;
#pragma omp critical
{
g *= 2;
copy = g;
}
...
}
doubles the global variable g and assigns the result
to the local variable copy without any danger of another
thread interfering (e.g., performing its own doubling operation before
this thread can assign to copy, interfering with the doubling or
assignment operations, etc.).
Threading Building Blocks
[C]
Carry out the steps of the TBB module on a
thingn computer.
Perform rudimentary performance tests of your resulting programs,
and report your observations in hw0/README .
Notes:
The module instructions call for executing an initialization
script before using TBB. For example, this initialization script
enables the compilation to find the header file
tbb/tbb.h.
The TBB module document lists the appropriate initialization script
for MTL, but the script is located in a different place on the
things. On the thingss, enter
% source /opt/tbb/tbb.sh
to execute the initialization script.
The things do not support a -ltbb-debug
option. Instead, use -ltbb when compiling a TBB program
on those computers.
From HW5
MTL vs. things
[C]
Compare the performance of two or more OpenMP or TBB programs on the
MTL with the performance of the same programs on thing1
or thing2.
Notes:
See class notes for a reminder of how to connect to the MTL with the password supplied in class.
To compile TBB on the MTL, you first need to execute the following:
source /opt/intel/Compiler/11.1/072/tbb/bin/tbbvars.sh intel64
Choose programs that differ from each other in scale, problem type, etc.
Use sievetest.sh or a modification to perform an
identical sequence of tests involving various parameters on each machine.
Record your observations and results in a file README.
For this question, submit the source code of the program you
are testing, a Makefile (or record your compilation
instructions in your README) and your test scripts (such as
sievetest.sh).