CISC 372: Parallel Programming
Fall 2001
Group project 1 -- addendum on deliverables 3 and 4.

Hints of Getting Good Timing Data

In order to get reliable timing data, you need to make sure that no one else is using the cluster. To do this, you should run the /usa/saunders/bin/allps command just prior to making a performance run. Also, from past experience, leaving the timings until last evenings before the assignment due date makes getting reliable timing runs very difficult to obtain due to the many other folks trying to get access to the cluster for timings.

Experimental Report

Your experimental report should consist of the following sections in this order. It is strongly recommended that you type your report using a word processor rather than handing in a hand-written report.
1.
Cover Page: Title, author, course number and semester, date.
2.
Project Summary: In one paragraph, summarize the activities of the project.
3.
Data:
  1. A chart of the raw collected timings. You may average the results of two runs. If for some number of processors you get what you consider an anomolous timing, and you get two other closer timings for that number of processors, you may average the two closer ones. However document these actions. In the spirit of science, we don't just ignore data we don't like. Explain how the timing numbers you actually use for the chart and graphs are obtained and mention other timings you rejected with your rationale for rejecting them. Note it will probably occur that you intersperse timing runs with code modification. For the report, you can ignore without comment the timings you obtained with preliminary versions of the code. Indeed, you must do this. It is crucial that all timings discussed in the report concern the final version of your code.
  2. the timings graph.
  3. Speedup graph.
  4. Efficiency graph.
(Clearly label each graph.) Remark: Each graph depicts the same information . The only difference, and one to think about, is how well the information is taken in by the human reader.
4.
Analysis of parallel life program:

Explain why you believe your program is correct. That is, explain what tests you performed to check the correctness.

Give explanations of your data. Explain what you think causes the difference between what you get and perfect linear speedup (i.e. perfect 100% parallel efficiency). Also, importantly, discuss the variation in the parallel efficiency. Does it uniformly decay as number of processes increases or not? why? What happens when the number of processes exceeds the number of processors?

5.
Conclusions: This section consists of a discussion of what you learned from the various aspects of the lab. Discuss possible reasons for inconsistencies or discrepancies in your data versus what you would have expected to happen.
6.
Appendix: Your parallel life code and sample run(s) output.

Please staple all parts of your lab together, and label each piece. Be prepared to discuss your results on the day that the assignment is due.

Criteria for Evaluation

Your first group project will be evaluated according to the following criteria:
  1. 0 pts: First deliverable (group formation).
  2. 20 pts: Second deliverable (serial code).
  3. 30 pts: Third deliverable (parallel code).
    1. 10 pts: format (consistent indentation, style. Reasonable comments)
    2. 15 pts: basic correctness
    3. 5 pts: generality: works for all p which divide n.
  4. 50 pts: Fourth deliverable (final experimental report).
    1. 2 pts: cover page.
    2. 5 pts: project summary.
    3. 8 pts: quality of chart of timings, discussion, three graphs.
    4. 10 pts: timings - parallel performance achieved.
    5. 15 pts: analysis and conclusions.
    6. 10 pts: appendix: code final form (evaluated in same way as deliverable 3). Sample run(s) output.