| Date | Description |
| 14-Jan-13 | Original posting |
| 23-Jan-13 | Added language clarifying relationship of the number of threads and the chunksize to the image size |
Your assignment is to implement the Mandelbrot set computation discussed in class to use multiple cores. You'll program in pthreads, starting with a provided serial code written in C++. Using your implementation, you'll conduct experiments, on the Bang cluster, to assess scalability and to determine optimal task granularity of CYCLIC decomposition. In the spirit of friendly competition, post your performance results to the A1 Moodle forum.
The assignment includes a brief report, and the requirements for your report are described at the end of this writeup.
Instructions for setting up your environment on Bang and for submitting jobs are described HERE.
-b -2.5 -0.75 0 1
Run on 2, 4 and 8 cores, with c=1. Compare this with BLOCK decomposition (using the same -b setting), putting the observed running times in a table or plot. Explain your results and compare the trends you observed with the previous experiment (6). To understand the phenomenon that your are observing, you will need to visualize your Mandelbrot sets using the -p or -o option (-p gives an interactive feel, whereas -o is faster but requires that you preview the .png file).
You have been provided with starter code that implements the serial algorithm.
This code has been installed
on the "bang" cluster as $PUB/HW/A1, where $PUB
is defined as /share/class/public/cse160-wi13.
The README file explains the options needed to run the code.
Look over the code so you are familiar with the various modules. The code contains the serial variant which you will use to check correctness of your multithreaded code. This serial variant, in smdb.cpp, calls a low level routine that performs the Mandelbrot set iteration:
ComputeMandelbrotPoint(int x, int y, int dimX, int dimY)
To lessen the risk of error, we highly recommend that your multithreaded code invokes this same routine to perform the Mandelbrot set computation.
All of your changes will be made to just one file, which defines the entry point to a function called Mandelbrot_pthreads() that you will implement:
pmdb.cpp
To ensure that your program is correctly graded, do not rely on any changes you have made to any other provided source code files; we will substitute fresh copies when we grade your assignment. Also, don't change the signature of functions defined in pmdb.cpp, as certain provided routines make callbacks to them. It's OK to make changes to provided files besides pmdb.cpp when developing your code, but be sure and refresh them with the provided version before you collect your measurements.
To build your code, use the provided Makefile, as it sets up the appropriate flags for the compiler via an included "arch" file located in $(PUB)/Arch/arch.gnu-4.7_c++11. The Makefile produces a target called mdb. Do not change the name of this target. You may add additional source files if you wish, but don't change the names of the any of the provided files.
You may override certain settings, such as compiler optimization, by redefinining macros in your Makefile. Within the Makefile, we have provided a commented out line that, if uncommented, will redefine the optimization level. This may come in handy if you want to debug your code using gdb. But don't forget to comment this line out when collecting your timings our your code will run more slowly with optimization turned off.
To compile for debugging with gdb, specify the argument
dbg=1
Don't forget to do a make clean before rebuilding the code. Otherwise, you may get anomalous behavior.
The code has various capabilities, which are controlled via command line flags:
-i [number of maximum iterations to compute the Mandelbrot set. Default value: 200] -t [number of threads] -x [number of points to compute in the real dimension. Default value: 1024] -y [number of points to compute in the imaginary dimension Default value: 1024] -b [bounding box for the computation. Default extent: [-2.5 : 1, -1 : 1] -c [chunkSize] -o [output file name] -s Run the the provided serial algorithm instead of the parallel version -p Plot the results with gnupot, without saving to a png file -v Compare the results of the parallel version with the serial version, enabling you to verify code correctness
For example,
./mdb -i 500 -t 8 -x 512 -y 512 -b -2.0 0.8 -0.5 0.5 -c 2000 -o "output"
would compute the Mandelbrot set with 8 threads and a maximum of 500 iterations on a computational grid of size 512 x 512. The bounding box's real dimension range from -2.0 to 0.8, the imaginary dimension from -0.5 to 0.5. The -c parameter specifies that cyclic partitioning is used with a chunkSize of 2000. If (-c) is not specified, BLOCK partitioning is used. The results will be plotted and saved in the image file "output.png" which may be viewed with an image previewer.
Thus, the following invocation would run the provided serial algorithm and plot the results:
./mdb -s -p
The plotting capability, controlled via the -p flag, uses gnuplot, and may be useful in debugging. It runs on the main thread only and is not multithreaded. The plotter (splot.cpp) interfaces with gnuplot, which is free-ware.
Remote visual display can be slow if you are off campus. If a display window does not appear on your screen, then your ssh display settings are not set correctly. If you are connecting to the remote machine from a Linux platform using ssh, use the -X option:
% ssh -X yourlogin@ccom-bang-login.ucsd.edu
If you are connecting from a Windows platform, and are using a 'secure shell client' AND 'exceed' (or xwin32, or cygwin) to log into a remote machine you must ensure that 'X11 tunneling' is set. To do this, you must have installed Cygwin /X with X11.
Use the batch queues on Bang to collect timings. You may run interactively (see instructions provided in the Bang document). But you may find it more convenient to collect your measurements by running non-interactively.
Take timings with the provided timer code (it uses gettimeofday()). Take at least 3 timings for each combination of parameters, and report the minimum timing.
Do not enable plotting (-p) when you are measuring running times for your performance studies, nor output the result to a file using the -o option as doing so could affect your observations.
We will grade your assignment on bang. Be sure to do your final testing on that machine, to avoid any surprises at turnin time.
We will test your code's correctness and performance. We will test against the public input described here, plus other inputs that will not be made public. Be sure to test against various combinations of the -x -y, -t and -c command line parameters. You need not handle the case where the number of threads doesn't divide the -y parameter and similarly with the -c chunkSize option.
You can catch obvious errors using the graphical output, but use the -s option to compare results exactly. Only an exact test can be guaranteed to verify correctness; the human eye is subjective, and the visual output may not have sufficient resolution to resolve subtle errors. Verify that results are independent of the number of threads.
First try out the provided code. From within your home directory, copy over the provided assignment code, build it.
cp -p -r $PUB/HW/A1 . cd A1 make
Next, request an interactive compute node via the qlogin command. Once you've been granted your node, you'll see the following output, though your job number and assigned node number will differ:
Your job 239 ("QLOGIN") has been submitted
waiting for interactive job to be scheduled ...
Your interactive job 239 has been successfully scheduled.
Establishing builtin session to host compute-0-26.local ...
You are now running in a shell and have exclusive access, for 30 minutes, to a compute node with 8 cores.
Wait until you receive a command prompt. You will now be running in a new shell, within your $HOME directory. You may run commands on the compute node, edit and compile code, but you won't be able to submit non-interactive jobs.
As a courtesy to other users, exit the interactive session when no longer needed.
Negative results are also valid and especially valued if you can document them, with the underlying causes, or best guesses if the causes are not clear.
Take care in how you plot your data, only plotting what's necessary to get your points across, and choosing log and linear plots carefully. You must also include any plotted data in tabular form.
Cite any written works or software as appropriate in the text of the report. Citations should include any software you used that was written by someone else, or that was written by you for purposes other than this class.
Your electronic turnin must include a Makefile so that we can build and test your code. We will run your code to test it and will check correctness using the residual measurement.
Your turnin must also include three important documents:
These documents are required as the turnin process will not complete without them. Empty forms, or forms not properly filled out, will result in a 10% penalty being assessed, in addition to holding up the grading process.
Since the turnin script will try to compile your project before letting you submit your assignment, it's important that you turn in all the files you have, including a Makefile. However, when grading your assignment, we will substitute all the files that we asked you not to modify (as noted above) with the original copies of the version we provided you. This is why it is important that you do not change those files in your own turnin, as they will be lost. The turnin script will have an option to do some basic testing, and we strongly suggest you avail yourself of this option.
Don't wait until the last minute to attempt a turnin for the first time. The turnin program will ask you various questions, and it will check for the presence of certain required files, as well as your source code. It will also build the source code if you like, to catch any obvious build errors. Try out the turnin process early on so you are sure that you you are familiar with the process, and that all the required additional files are present. The turnin procedure will be available about a week before the deadline.
Your grade will depend on 3 factors: performance attained by your code, correctness and well-displayed results.
Copyright © 2013 Scott B. Baden [Mon Jan 14 08:04:57 PST 2013]