• Main
• Lectures
• Seminars
• Homework
• Projects
• Tools

Projects

Project Topics

The list of project topics can be found on a separate page.

Project Work Schedule

• 9th week: Form project groups, select topics, send us an email with your chosen topic. If you want to choose your own topic, the email needs to contain an abstract and a set of minimum requirements.
• 10–11th week: Start working on the project.
• 20th December: Checkpoint! You have to show that you have already done a substantial part of the project and submit a detailed plan of further work. The code will be sent to other students for the first code review.
• 31st January 2021: Main submission! The code will be sent to other students for the final code review.
• Presentations: TBA
• Checkpoint code review deadline: 17th January
• Final code review deadline: 14th February

If the project is awarded less that the required number of points, the group may rework the project and resubmit during the exam period. Details about the resubmission deadlines will be arranged with the teachers after the presentation.

Project Repository

Every group has to create a git repository at the Faculty of Informatics’ GitLab page with the name pv264_project. The repository has to be private, and only the members of the group and the teachers should have access. The owner of the repository is up to your agreement; you have to tell us who the owner is (via email) so that we know which repositories to look at.

Project Presentation

You are expected to give a 15-minute presentation about your project at one of the last seminars (exact schedule will be announced later). The presentation should provide the audience (the teachers and the students of the course) with a brief overview of your project and highlight interesting aspects of the project (challenges during the development, interesting techniques, or any other learning outcome). The goal of the presentations is to learn from the experiences of others.

We give you the following tips for giving a good presentation:

• Keep in mind the others are not well familiar with your project.
  • It is a good idea to present the project topic at the beginning.
  • Explain it well – if people don’t understand it, they won’t understand the rest of your presentation.
  • E.g., for a parallel data structure library (PDSL), show the motivation for parallel computing, explain why we need special structures.
• Then, sketch your solution.
  • Briefly explain what parts of the topic you have covered (i.e., show the others what have you done).
  • Highlight the challenges of your project and the solutions.
  • You can also show your inspiration/sources (libraries, papers, etc.)
  • E.g., for PDSL, say which structures you have implemented. Pick one interesting principle (e.g., usage of atomic instructions) or algorithm and explain in more depth.
• Visually show the project outcomes.
  • Do you have a game? Show screenshots/video/live demo.
  • Have you performed benchmarks? Plot the results.
  • Do you have a library? Show short snippets of its usage.
  • E.g., for PDSL, show the results of the benchmarks comparing your structures, e.g., with Boost or other implementation. If you have diverged from the standard library interface, you can show a short snippet of usage.
• Wrap up the presentation with a short summary of what you have achieved.
  • Highlight learning experiences – what went well, what did not go so well. Give tips on useful tools/libraries.
  • E.g., for PDSL, you can say: we have implemented a parallel queue using three algorithms; we have benchmarked them, and it is clear that implementation 1 is the best. However, it does not outperform Boost. We think it is due to improper cache locality of our structure as our testing with a profiler shows. The profiler was a helpful tool, and we recommend trying it in your next project. Also, CRTP allowed us to get rid of much code duplication.
• Expect questions.
• We advise you to prepare 6-10 slides.
  • Presentations without slides tend to be chaotic in our experience. Slides help you keep the structure.
  • Use as little text as possible. No one is going to listen to you if they have to read pages of text.
  • No one is interested in reading your source codes during the presentation. Do not show it.
  • If you really want to show a piece of code, provide a short snippet.
  • If you want to show a UML diagram or a class hierarchy, think twice. It is usually not that interesting.
  • Images and reasonable jokes are welcome.
• Rehearse the presentation.
  • Without a rehearsal, you probably over/undershoot the time slot or omit something important.
  • As an audience member, you too would not like to hear an unprepared presentation…