You each have a /home/u26/acctname directory for your project this semester. You can cd /home/u26 from compserv1 and from sbcube6.

I would like you to finish your projects and submit your final reports to me by Saturday 20 December, the end of final exams if you have no final exams. Please email your final report to ldw as a text, pdf, or doc (MS Word 97/98 or earlier) file. Make sure you include your name, your project, the submission date and report title. In your email, also tell me the exact pathname of the zip file containing all files that you wish to submit as part of your project report. Slide a printed copy of your final report under the door of my lab 1306 Computer Science, before noon on Wednesday 17 December, if it is ready then. Otherwise, reach me by email to discuss how to get a printed copy to me for grading by Saturday 20 December. If you have finals during finals week, make arrangements with me so you do not work on this project during finals week until your exams are done. I will give you time, within reason, to finish without penalty.

Please DO NOT SEND HUGE zip files by email. My disk quota is too small to accept them.

Use your directory on /home/u26 to leave ALL your data as a zip (not gzip) file containing all source files and execution records that you want me to see when grading your report. Include the final report that you email to me and submit in printed form. In your official email by Saturday, tell me the exact pathname of your project zip file. If you do not want others to see your material, leave the outer level of your /home/u26 project directory public-read and public-execute (the norm), but create an inner directory with a name such as ForLDW and make that directory public-execute only by the command chmod 711 ForLDW

Put your zip file (and any other files that you want me to see) inside that ForLDW directory. Make sure the zip file is public-read (chmod 744 FILE.z). Given your email that tells me the pathname of your zip file (e.g., /home/u26/ACCT/ForLDW/FILE.z), I can cd into /home/u26/ACCT/ForLDW and copy FILE.z but others who do not know the name FILE.z cannot access it since the directory for ForLDW is not public-readable.

1. Compile and execute your code on the sbcube6 SGI and save the output;
2. Use the perfex package to count dynamically all load and store instructions executed by the sequential code.
3. Add #pragma instructions to the C code and replace the macros calls for parallel synchronization operations by the proper #pragmas for correct parallel execution on 1, 2, 4, 6, 8, and 12 sbcube6 CPUs. Verify that you get exactly the same output as from runs of the sequential code, except for timing related values. If not, correct your lock and synchronization pragmas.
4. Use perfex to count dynamically all load and store instructions executed by the parallel code for 1, 2, 4, 6, 8, and 12 CPUs. Graph the counts and extrapolate to 32 CPUs as given in the text table and in the Splash2 overview paper included with the Splash2 C source files. The values of dynamic counts of load and store operations extrapolated to 32 CPUs should closely (say, within 10%) match the Splash2 reported counts for total reads and writes in the parallel code.
5. Correct your use of locks and other synchronizations until the parallel code actually speeds up as you go from 1 to 2 … to 8 to 12 CPUs. At first, the parallel runs may even be slower than the sequential run. The most common mistakes that slow runs, especially for larger numbers of CPUs, are uses of overly general #pragma synchronize commands and #pragma lock commands. Use of globally shared variables by multiple CPUs requires locks for correct behavior. Frequent access shared locked variables can drastically slow execution. Use private variables wherever feasible. The #pragma alock (array lock) command allows the creation and use of hundreds of fine-grained locks, as needed by some of the applications with dynamic data structures of hundreds of computation cells. Not all writes to shared variables need be lock-protected. If you can otherwise guarantee that only one processor at a time as access to a variable, then locking is not needed. An example is a variable output by one processor but read by other processors only after a phase-ending #pragma synchronize command. A variable that is only read, even by many processors, need not (should not) be locked. After eliminating excess locking, the speedup graph for your parallel code should closely match that given in the Splash2 paper. Talk to me if it does not.
6. Once you have your parallel code correctly but efficiently locked so that it gives the same output as the sequential codes for all numbers of CPUs and so that its speedup curve closely matches that in the Splash2 paper, recheck your prefex counts of total writes (stores) and total reads (loads) for each number of CPUs. Then identify the shared writes in your code and add an increment to an entry in a large temporary array used to count shared writes. Run your instrumented code for the same numbers of CPUs as before using perfex to again count all writes (stores). The difference between your write counts before adding the increment commands and after adding them is your estimate of the number of shared writes. Extrapolate your estimates to 32 CPUs. If you marked too many writes as shared, your shared write count for 32 CPUs will be high. Systematically reduce your marked writes until the extrapolated count of shared writes matches that in the paper.
7. Remove the shared write markers remaining in your code. For each substitute a delay mechanism for each marker. Have a mechanism that corresponds to execution delays of 10 nanoseconds (ns), 10 ns, 1 microsecond (m s), 10 m s,100 m s, 1 millisecond (ms), and 100 ms - all times from 10 ns to 100 ms in steps of 10X. For 10 ns, you may assume that 4 ALU instructions on sbcube6 equals 10 ns. If one of you checks this by timing - via clock() - 4,000 ALU instructions repeated 1,000,000 times in a loop and finds the count to be closer to 2 or 3, please tell me and the rest of the class by email. You may want to use inline code for both 10 and 100 ns delays. For longer delays, use a delay function call such as suggested in the Splash2SGIhints file for Hint 5. Calibrate whatever delay function you chose.
8. For each delay function value from 10 ns to 100 ms, run your sequential code and your parallel codes for at least 1, 2, 4, 6, 8, and 12 CPUs. Record the run-times carefully, until execution time per run takes more than 30 minutes or execution times have clearly become much slower than for slightly shorter delay values. Plot your run-times for each number of CPUs. If there is a sharp drop in performance - increase in execution time - between two delay function values, you do not need to make many more runs for that number of CPUs. However, consider runs for 2X, 4X, 8X, 10X and 16X the delay time before the drop in performance for a given number of CPUs to get a more detailed picture of the performance drop. If your times are noisy because of other jobs sharing sbcube6, make several runs at the same delay value and number of runs and plot the MINIMUM times.
9. Examine your results in tables and graphs and predict the execution time of your parallel code as a function of number of CPUs running concurrently and the delay time imposed before each shared write that you identified.
10. Write a carefully worded and organized report of 8 to 20 pages that gives your results, explains exactly what methods you used to validate and measure your code, and what conclusions you draw from your measurements about the behavior of your parallel code if it runs on CPUs that are more and more separated in physical distance from each other.

Include the raw data used to generate your plots in tables near the end of your report. You will be asked to handin both printed and electronic copies of your report, as well as a zip file containing your original and changed versions of the C-code and your script-produced files showing the raw data from your runs.

Finally, in your report, tell me any problems that you had doing this project that were especially annoying and unnecessary. Perhaps, I can eliminate such problems for future students. Good Luck. Larry