ECE 1747H Parallel Programming Project
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
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.
- September 23: Talk to professor about your project in office hours or by appointment
- October 7 and 14: 1-2 page proposal due in class, 3-4 minute proposal presentation
- December 9: In class presentations of projects (15 minutes each)
- December 20, 11:59 PM: Final project reports due (no extensions)
Your proposal should be submitted in PDF format to the professor by
email (firstname.lastname@example.org). Your proposal should cover the
- 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
- A timetable.
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.
Your final report should be submitted in PDF format to the
professor by email (email@example.com). 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
- 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
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.
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
- 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