Differences between revisions 18 and 19

# Submission Guidelines for the Final Project

For your final project submission, we will need the following things from you:

• An in-class final project presentation (due Dec 17/18/19).
• Please also turn in your slide deck in PDF form in your git repository. (due Dec 21)
• A final report (due Dec 21)
• The final code, with a Makefile (due Dec 21)

If you are submitting as part of a team, please make sure to indicate which team member contributed to which part. As an example, please mark the (submitted, not necessarily presented) slides by the creator's initials. Do the same for sections of your report and source files or individual functions of your code.

Please turn in all the components marked "(due Dec 21)" in a git repository (see below).

## Report

Your report should do the following:

• Precisely describe the problem you are trying to solve, including references to relevant literature. Your description should be sufficiently self-contained that we can determine whether the output of your program is correct without referring to outside literature.
• Describe the scale of the problem you are aiming at, and what the scaling limitations are.
• For example, if you are doing a linear algebra-based project, state "This project aims to be able to carry out Procedure X for matrices of size 10,000-20,000. At the high end, our project is limited by available memory on a GPU, and at the low end, parallelization overhead from our Step Y makes Approach Z more economical."

• Describe existing work/software on your topic. Also state which other codes you have used and looked at while working on your project.
• Describe your performance expectations. What do you estimate will be the most time-consuming step? Which one is hardest to parallelize? Relate this to your scaling discussion.
• In a separate section, describe performance and scaling measurements. State where performance and scaling exceed or fall short of your expectations. Explain your observations.

• Important: Please write this section in terms of rates, not absolute timings. (Compare: Computation X took 17 seconds. Computation X achieved a rate of 17 GFlops/s.) (Clarification 12/7: These don't need to be GFlops/s or GB/s, they just have to be rates that make sense for the application you're addressing. Ideally, if you're reporting that you are doing 10,000 of "Operation X" each second, then it should at least be possible to have an intuitive idea of how much computational expense is involved in "Operation X".)

Clarification 12/20: "Speed-up" values are worse than absolute timings, which are in turn worse than absolute rates. The problem with speedups is that they're inherently bogus. The worse your starting point was, the better you'll look in terms of speed-up. Please avoid using this as a metric.

• Discuss how and where you have made your code available. (see below)

Added 12/20: If you include material from outside sources (such as images or passages of text that are copied verbatim), please cite the source of the material, and clearly mark the affected parts.

## Presentation/Slides

The main goals of your presentation are the following:

1. say something interesting
2. teach the audience something they didn't already know
3. entertain
4. impress everyone with your results

That said:

• Your presentation could also cover soome of the same topics as your report, in a form that is suitable (reasonably entertaining?) for an audience consisting of your classmates. But you certainly have more wiggle room to emphasize/deemphasize or leave out some components, depending on what you deem suitable for a classroom presentation.
• If possible, it would be great if you could do a live demonstration of your code running (even if there's not much visual output to speak of).