Home
>>    




Extra questions for PDC

CS 300, Parallel and Distributed Computing (PDC)

Homework 100   Due

    Not assigned in Interim 2015

    From HW3 and HW4

  1. OpenMP

    1. [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.).

  2. Threading Building Blocks

    1. [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.

  3. From HW5

  4. MTL vs. things

    1. [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).