DidaWiki

The SPM course exam consists in two parts:

• the implementation of a project (sse below the project text), and
• an oral exam, including a small demo/discussion relative to the project and some questions on the arguments covered by the course

The project will be available beginning of May 2013.

The steps leading to the preparation of a successful project include:

1. the analysis of the requirements. This includes figuring out the missing specifications and discussing with the teacher the suitability of the additional requirements
2. the design of alternative implementations and the evaluation of the possible performance outcome for the different solutions. This includes figuring out proper costs associated to the sequential portions of code, possibily through some kind of simple profiling activity
3. the implementation of the most promising solution investigated during the design phase, exploiting the existing tools potentialities, both in case the tools used are provided by some algorithmic skeleton programming framework, and in case the tools used are lower level concurrency and communication libraries
4. measuring the performances achieved and comparing these values with the ones predicted by using the performance models, during the design phase. In case of sensible differences, and in particular in all those cases where the shapes of the performance curves are radically different, the student must consider moving back to the design step and continuing with a different, alternative implementation
5. the collection of performance measurements on a dedicated machine, and the production of the performance plots and tables to be included in the final project report
6. the preparation of a synthetic and effective final project report
7. sending a .tar.gz (or .zip) file with all the sources of the project code (including test cases, makefiles, script files used, etc.) and the PDF of the final project report in an email with subject “SPM project 2013 submission”

A student (or a group of two students, when allowed) wishing to start working on the project should first “negotiate” the project. He/she should communicate to the professor the project chosen by sending an email (subject “SPM project choice”). The email text should give an idea of

• which project subject has been chosen and
• of the unspecified parameters of the project.

In case of “free application”, as an example, the application chosen should be introduced; in case of any application, the framework chosen for the implementation is to be specified; etc. This information may also be provided during the lesson break or question time. Upon reception of the email, the professor will insert the student name, project chosen and date of the choice in the table below, and he will send back an email confirming the choice and hosting account details to access the machine(s) to be used to test the project prototype.

These are the dates representing the deadlines for the submission of the project. After submission, I'll take about a week to mark projects, then I'll publish dates for oral exams.

Students implementing the project on multicore architectures may have a temporary, local account on a dual quad core Intel of our department (ottavinareale.di.unipi.it). Ottavinareale is not integrated with the cli.di.unipi.it facilities so you cannot use your “student” account to access it. The procedure to obtain the account (only for those that already registered the project with the professor and appear in the list of assignments in this page) requires you come in my studio (during question time or in any other time I'm in) in such a way I immediately activate you an account and you can set your own password to access it.

The accounts assigned on ottavinareale may be used without reservation any time, provided when you log in there is no “Active reservation” message in the /etc/motd (the text (file) you see right before shell prompt on the terminal. The contents of the message may be seen any time with a cat /etc/motd command from the shell prompt, or with a ssh [email protected] cat /etc/motd from any other (Unix/Linux/BSD) machine shell prompt). Code development, debugging and initial tuning may took place on the unreserved machine. The reservation mechanism is only recommended to be sure you'll take time with no other users on the machine for the final tests, those needed to generate the plots included in the final project report. Remember that I suggested you to prepare scripts to be able to run tests offline, in such a way you may also use nightime reservations.

More information on the usage of ottavinareale may be found at this web page.

This year we will use for the projects also the host andromeda.di.unipi.it which is still a dual quad core. Differently from ottavinareale, andromeda is a Nehalem class multicore, therefore each core provides two thread contexts and the overall 8 cores support 16 threads. The rules to follow to use andromeda are the very same of ottavinareale (mainly related to reservations).