Indice
SPM 2015/16 Exams
Exam dates
Term | Deadline for submitting project | Oral exams calendar |
---|---|---|
Extraordinary term | November 2nd, 2016 | Calendar |
First term 2016-17 | January 17th, 2017 | Calendar |
Second term 2016-17 | February 13rd, 2017 | Calendar |
Extraordinary term | April 6th, 2017 (deadline to submit the projects) 9.00am | |
First summer term 2016-17 | June 13th | Calendar |
Second summer term 2016-17 | July 3rd | |
Third summer term 2016-17 | July 24th | |
Autumn term 2016-17 | Sept. 12 (there will be some possibility to extend the deadline, upon motivated request) |
Machine access
Here you may find the instructions to access the machine(s) avaialable for the project.
List of assigned accounts
Final project
The final SPM project is structured in 6 different alternatives. Students should agree which one they want to choose with the Professor before actually starting to implement the project.
Alternatives
Applications
Video filtering
This is video filtering application. Video frames should be read from file/device via OpenCV calls. Some kind of filtering (up to student or suggested by professor) has to be applied to each one of the frames. Eventually a new video has to be rebuilt from streams using again OpenCV calls.
Jacobi
The application finds the solution of a system of linear equations using the Jabcobi iterative method.
Free choice application
Any application of interest for the student. TO be discussed and agreed with the professor before actually start working on it.
RTS/library
Divide & Conquer
Implement a generic D&C support, with a clean and seamless C++ interface.
Successive approximation pattern
The pattern process a stream of input tasks and a global state value. For each one of the input tasks x one or more output tasks f(x,s) may be produced onto the input stream and the state value s is updated to s'(x,s). The function updating the state is monotonic. The computation of an f(x,s) with a non updated state s does not produce any damage/side effect (but using additional computational resources).
Free choice RTS
RTS relative to a pattern of interest for the student. To be discussed and agreed with the professor before actually start working on it
Free choice (Appl and RTS: note)
Students are encourage to propose and discuss with the professor different alternatives, possibly individuated because of personal interests, subjects already tackled in other courses etc.
In order to be considered valid alternatives:
- either the alternative consist in parallelizing and existing and well known application/kernel/algorithm by means of one of the structured parallel programming frameworks discussed in the course
- or the alternative consist in implementing a new (alternative) pattern using either the low level mechanisms discussed in the initial part of the course or integrating the new pattern in one
of the existing frameworks.
Implementation possibilities
- Applications should be implemented using FastFlow. Alternative programming frameworks may be discussed with the professor. A comparison implementation using plain C++ threads will be helpful and appreciated.
- Run time supports should be implemented using C++ threads. Alternative proramming frameworks may be discussed with the professor.
OpenCV
The students using OpenCV for the Video processing application will get a different account on a machine with openCV pre-installed, in case.
Workflow
A valid project is the result of the execution of an ordered set of steps:
- the student must agree the subject with the professor, and the pairing student-project has to be published on the project assignment table (agreement should go through an email to the professor with subject “SPM project”)
- the project design has to be completed and agreed again with the professor
- the project implementation has to be completed, debugged and validated
- the project (source code, sample input files and report describing what has been actually produced) has to be submitted by one of the exam terms via email to professor email account
- the project has be demonstrated (on a text terminal) and discussed with the professor
Project code
Project code should be delivered to the professor email account as a compressed archive (.zip or .tar.gz)
Project report
The project report is a PDF document of no more than 10 pages explaining:
- what has actually been implemented in the project
- possible major design choices
- a short manual detailing how the project may be compiled and tested from the sources
- experimental results validating design and performances
More in detail:
- experiment results should show scalability, speedup and efficiency of the implementation(s) as well as the difference among the measured values and the expected ones (according to the performance models)
- the short user manual should be detailed enough to enable me to run tests with your software (what should I compile, how, which are the parameters to use to launch experiments, how can I vary parallelism degree, which input files do I need, where are they)
- the major design choices should be exposed at high level of abstraction, mentioning the patterns used, the policies adopted, if the case, particular algorithms or data types used, etc. It is not required to specify the known parts of the assignments (e.g. I don't want to see space wasted to explain GOL rules or NQ problem description)
- at the very beginning, please state clearly in a single sentence the problem solved, the programming framework(s) used, their version (if significant) and the architecture(s) used to run the experiments.
Project validity
This project is valid for all the exam terms in A.Y. 2016/2017.