|Deletions are marked like this.||Additions are marked like this.|
|Line 11:||Line 11:|
|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 creators initials. Do the same for sections of your report and source files or individual functions of your code.||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.|
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).
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)
Include instructions on how to download, build and run a simple example of your code. Specify what hardware environment your code requires. If applicable, include data files so that we are able to try your code. If we won't be able to run your code on either the NYU systems or generic Linux machines with Nvidia GPUs, please provide a link to a YouTube video where you demonstrate your code. See this Wikipedia page for help with capturing your screen during the demonstration.
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.
The main goals of your presentation are the following:
- say something interesting
- teach the audience something they didn't already know
- impress everyone with your results
- 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).
Code release/Git repository
I would like to encourage you to provide the code resulting from your project in open-source form. One convenient way to do that would be to create an account on GitHub and upload your code there. If you do so, please add a README so that others have a way of getting started with your work. There is extra credit to be had if you decide to go down this route. Also be sure to specify a license in your README. When in doubt, the MIT license is a reasonable, liberal default choice.
If you feel like you must keep your code private, please use the following naming convention for your final project repository on forge:
hpc12-fp-<NETIDS in alphabetical order, separated by dashes>
So if you and your teammates have NetIDs abc123 and xyz456, then your repository should be named