Hide menu

TDDD56 Multicore and GPU Programming (6 ECTS)

Autumn2 2015

Mid-Term Evaluation with Muddy Cards

The course TDDD56 has been mid-term evaluated with the muddy card method in the third week. Due to scheduling constraints, this had to be done in an optional lecture for part of the attending students only, on thursday 19 november 2015, 08:00-10:00. 26 students attended the lecture, and I received 24 cards.

In the following I summarize the most frequently raised issues and comment where appropriate.


The course contents is considered interesting and highly relevant by many participants.


The setup of the course is generally appreciated. Staff is perceived as competent and helpful.
  • Some scheduling conflicts, esp. for Norrköping-based students
    Comment: We have no influence about the mapping of courses to blocks in the block schedule. As the course is selected by students from many different programs, there will always be some conflicts here. There is no way for us to avoid time clashes between courses using the same block, as we need to utilize basically all time slots in the schedule block.
  • Significant overlap in CPU-part lectures with TDDC78 (1)
    Comment: There are 4 common lectures with TDDC78, all in the CPU part of the course. These lectures are included in both courses because both courses are about parallel programming (albeit from different perspectives and for different types of computing systems and application domains) and thus share a common technical and theoretical core, and because we want make it possible for you to take each course stand-alone or both courses in arbitrary order, for better flexibility of studies.


Positive reactions in almost all comments regarding lecturing style, structure, speed, understandability, and slide material.

Access to the lecture slides on the course web page is appreciated, especially for those who cannot attend all lectures.
Some find the lecture slides well suited for self-learning but too detailed for presentation.
Comment: This is certainly true in many cases because the slides should, as there is no appropriate textbook covering our course contents in sufficient detail, simultaneously fulfill the function of a course text, not only be in support of the speech. Maintaining two different slide sets is not practical. You might however have noticed that I tried at some places to factor out extensive text to read-only slides (with yellow background) and plan to do this more consistently in the future.

Lectures sometimes focus too much on the same subject.
Comment: OK, I will try to avoid that, but am not always aware when it seems to become too much...

There was one complaint about bad acoustics and noise coming from other seminar rooms when having lectures in a large seminar room.
Comment: I was not aware of that, and did not feel disturbed myself at any time. I generally try to speak loud, as far as my voice supports it, but whenever the signal-to-noise ratio is perceived as not large enough then please let me know immediately. -
We generally have no influence on the room assignment. Generally there is a shortage of large lecture halls at the university, especially in the first weeks of the lecturing periods, so we have to accept the larger seminar rooms, too.


Labs and lab assistance are generally very appreciated so far. Even for those who had no OS course before (like Y), the labs are considered manageable.
Lab assistants are considered helpful and special appreciation is given on a number of cards (name given).

Two cards complained about insufficient ventilation in room Konrad Zuse especially in the evening time slots.
Comment: Akademiska Hus switches off ventilation at Linköping University at 18:00. This is a general policy that we cannot affect, unfortunately.

One remarked that Lab 2 requires much more lines of codes than Lab 1.
Comment: We can fix the issue by providing a complete skeleton, but then the number of lines of code required might be even lower than for Lab 1.

There are a few complaints about malloc-free or bounded vs unbounded stack design choice issues in Lab 2. It often leads to a significant amount of work to do again.
Comment: The malloc-free performance issue is hinted in the lab instructions. Please read the lab instructions carefully, plan the implementation work and anticipate the problems before you code.

Lab instructions and lab skeletons are perceived as sometimes a bit unclear in some comments, while others explicitly appreciate them. Some suggestions were given on lab skeletons, e.g. to switch from C to C++ or removing ifdefs.
Comment: Using C++ instead of C could add additional confusion with pointer and references and wouldn't bring any significant other improvement. It is good to be comfortable with C as C++ is not always available in High-performance programming. Removing ifdef preprocessor directives would result in additional source files to edit (1 per possible variant) and hence, more complicated lab skeletons.

Some students complained about a lack of instruction on how to use Freja.
Comment: The lab instruction say how to run it, with commands inlined in the text. Also, there is a complete manual about Freja in Nicolas' web page (the page down and fixed after a student reported the page issue). Unexpected graphs are often discussed in lab demos. You are always welcome to speculate on the reason why you have such graphs and discuss it with your lab assistant.

Lab1 was perceived good but quite simple (about 10 lines of code).
Comment: Lab1 is intentionally a simple lab to get started easily.

Some very fast students are already finished with lab 1+2 and commented about unclear instructions for lab 3 (use of Drake).
Comment: We are working on this. More documentation about Drake has been broadcasted, with an almost-complete example on how to design a Drake application with code example at each step. Several of these steps are already done. Please read carefully the new document AND the lab instructions (esp. Sec. 3 of the lab instructions).

One remarked that the CPU lab web page needs a major revision.
Comment: We don't see what is wrong. Anyone is welcome to discuss the issue with Nicolas.


By and large, the course seems to run very well; there are some minor issues for improvement (see the comments above) that will be taken into consideration.

Thanks for all comments!

Christoph Kessler, examinator TDDD56

Page responsible: Christoph W Kessler
Last updated: 2015-11-24