ECE 1747H Parallel Programming Project 

Fall 2021

Overview

The goal of the project is to do a miniature version of a research project. You will first pick a topic, and argue in a proposal that this is a topic worth exploring, and that you are capable and prepared to do so. You will design and implement a solution to the problem you have chosen, and measure the performance of your solution. You will finally present the results of your project in a final report and in a classroom presentation.

Please keep in mind that this is a research project, and not a programming project. Although the implementation of your solution is an essential component, it is only one aspect of the project, next to other equally important components, such as the evaluation and the presentation of your results. Typical research topics include parallelization and analysis of a sequential code or improvement or adaptation of a pre-existing parallel code.

Projects should be done individually or in small groups (ideally of two students, but three students are also acceptable). All reports and presentations should be done in a group basis. The most interesting projects usually result from groups.

Deadlines

• September 14 - October 21: Talk to professor about your project in office hours or by appointment
• Oct 21: 1-2 page proposal due in class, 3-4 minute proposal presentation
• TBA: In class presentations of projects (15 minutes each)
• December 20, 11:59 PM: Final project reports due (no extensions)

Proposal

Your proposal should be submitted in PDF format to the professor by email (amza@eecg.toronto.edu). Your proposal should cover the following topics:

• Statement of the problem (not the program).
• Description of the program to be used, and what parallel versions exist, if any.
• Statement of what you are going to do.
• The method that you are going to use to evaluate the results. Be specific: state what experiments you plan to do, what measurements you want to take, etc.
• Statement of expected results, and some preliminary justification of why you think the results will come out the way you state. Again, try to be specific.
• If there are papers describing the algorithm and/or the program, a brief bibliography.
• A timetable.

Presentations

Your presentations of both your proposal and project should be well-prepared. You should be ready to handle questions from the professor and your classmates. Time limits will be strictly enforced. Please use PowerPoint to produce your slides. A projector will be provided. 

Please refer to Professor Mark Hill's advice on oral presentations when preparing your talks.

Final Report

Your final report should be submitted in PDF format to the professor by email (amza@eecg.toronto.edu). Your final report will typically contain the following content:

• Abstract: summarize your contribution in 100 words or less. An informed reader should be able to stop at the abstract and know roughly what you are doing.
• Introduction: Background on the current state-of-the-art, why your topic is important, and what is the motivation for your work
• Proposed Solution: detailed description, but not code!
• Experimental Methodology: tests, input sets, environment, etc.
• Experimental Results: Quantitative data and analysis!
• Related work: Relate your work to research by others. Any time you mention some other work, compare or contrast it to your own.
• Conclusions: Highlight the important points of your analysis and contribution. Also give prospects for future research on this or related topics.

The most important parts of establishing your contribution are an appropriately detailed description of the solution and a thorough analysis of the quantitative data. The abstract is incredibly important for setting the overall tone for the reader.

If you have never written a technical document before, you should seriously consider reading one of the standard references on the subject. One of the best reference texts is The Elements of Style by Strunk and White.

Pitfalls

Common pitfalls include the following:

• Starting too late. You should start well in advance of the deadlines.
• Neglecting the proposal. This is your chance to get useful feedback.
• Waiting to write until all results are in. Writing up results often gives you insights on what further measurements should be taken.
• Too little detail. This is a technical document, not a sales pitch.
• Too much detail. This is a report, not a code review.
• Lack of analysis. Quantitative data are nearly useless without analysis. Explain not only your numbers, but also the reasons why your numbers turned out the way they did.
• Vacuous statements. Give details, starting from the abstract (say "We saw 2.5X speedup on 4 processors", not "Performance optimizations were achieved")
• Topics arising from thin air. Don't bring up a topic without giving an informed reader the necessary background information.
• Topics vanishing into thin air. Don't introduce a topic unless you intend to back it up.

Back to ECE 1747H