Course»Course 6»Spring 2016»6.816/6.836»Homepage

6.816/6.836  Multicore Programming

Spring 2016

image restricted to class participants

Instructor: Nir N Shavit

TAs: Michael Joseph Coulombe, Rati Gelashvili, Xiao Meng Zhang

Lecture:  T 2-5 P.M.  (32-144)        

Information: 

The computer industry is undergoing a paradigm shift to multicore and multiprocessor chips, a shift that will require a fundamental change in how we program. The art of multiprocessor programming, currently mastered by few, is more complex than programming uniprocessor machines, and requires an understanding of new computational principles, algorithms, and programming tools.

The key issues that distinguish multiprocessor programming from uniprocessor programming are the need to understand how to break applications into computations that can be executed in parallel, and perhaps more fundamentally, how these concurrent computations can coordinate with one another to allow this parallelism to translate into substantiative speedups.

There are few reference books addressing how to program multiprocessors. Most engineers must learn the tricks of the trade by asking help from more experienced friends and through a laborious trial and error process. This course aims to change this state of affairs, providing a comprehensive presentation of the principles and techniques available for programming multicore/multiprocessor machines.

The course will begin by covering the theoretical foundations of programming on multicore machines (we are strong believers that good practice requires understanding the theory). It will then move on to cover the real-world techniques used to program them. It will include a sequence of programming assignments of increasing difficulty, culminating with the design of a highly parallel map-reduce application, running on a state-of-the-art 80-way multicore machine.

Class Structure:
Our textbook will be "The Art of Multiprocessor Programming" by Herlihy and Shavit.
There will be 6 total assignments, covering both theory and practice (assignments 2-6 will have the practical part, the last being the final project). For 6.836 assignments will contain additional theoretical problems. The assignments will constitute 55% of the course grade.
There will be two exams, a midterm, worth 15% of the grade, and a final exam, worth 25%. If the final exam score is higher, it will also count for the midterm. The midterm will take place on Wednesday, March 16, 7-9PM, in 4-370 and the final will take place on Tuesday, May 17, from 9:00 to 12:00 Noon in the Track (W35).
The remaining 5% of the course grade will be for in-class participation.

Office Hours:
Xiao Meng Zhang M 3:30-5:30pm (32-G630), Michael Joseph Coulombe R 2-4pm (32-G630), Rati Gelashvili F 3-5pm (32-G630).

There will be recitations in the first week but no office hours. Office hours start from the second week (Feb 8th).

Recitations:
Recitation sections are on R 11-12, F 10-11 and F 11-12, in 38-166.

Resources:
We will use Piazza for class-related discussions. The class page can be found at https://piazza.com/mit/spring2016/68166836/home

Announcements

Exam Review Session

There are no recitations or office hours today. On Monday 3-5pm, there will be an exam review session in G575.

We have uploaded solutions to pset5, and will upload solutions to pset6 theory later today.

Announced on 13 May 2016  11:07  a.m. by Rati Gelashvili

Further Clar

For the final project, repeated nodes/edges are allowed on the path.

You should output nodes from each of which you can start and traverse some edges pathLen times and end up at the destination node.

Announced on 04 May 2016  7:44  a.m. by Rati Gelashvili

Final Project Clarifications

Hello Everyone,

Now that only the final project remains, here are some clarifications discussed on Piazza (and we recommend that you do check Piazza), but since all of you may not have seen it, summarized below.

To get the full (or close to full) credit on the final project, you do not need to drastically optimize performance and memory usage. The graphs on which we will run correctness tests will not be extremely large, and pathLen will also be reasonably small.

The extra credit benchmarks, however, will use a huge graph and a larger pathLen. As some of you observed, in the expander graphs like the one that the code template generates, quite soon storing outputs for all nodes becomes unmanageable. We guarantee that the graph that we will use (obviously) won't be like this, even though it will also have certain random properties. Basically, if you computed the answer for all nodes and stored this as a graph, you would be able to fit several such graphs in memory. By several, we mean 3, 4 or 5, a small constant, and more than this will result in memory exception and you won't be eligible for the extra credit.
In particular, storing pathLen or log(pathLen) graphs is out of the question.

Also, we have parameters numMappers and numReducers to make our framework general and more configurable. For the extra credit tests, these will be roughly equal (so there in no point in artificially moving the complexity between map() and reduce() methods).

Moreover, for the extra credit tests, we will set numMappers and numReducers to be the maximum parallelism allowed by the hardware. We would like you to run each Map-Reduce invocation with these parameters (and don't run multiple invocations of Map-Reduce in parallel).

There might be more discussions on Piazza, so make sure to check it out periodically.

Announced on 30 April 2016  3:04  p.m. by Rati Gelashvili

4/28 Office Hour Change

Michael's office hours this Thursday (April 28th) have been changed to 1pm - 3pm in the same place, outside 32-G630. If this change is inconvenient, email Michael to discuss alternatives.

Announced on 26 April 2016  4:27  p.m. by Michael Joseph Coulombe

Clarifications for Pset 5 Programming

Hi guys, just want to clarify three things about the programming assignment of problem set 5:

(1) In the hash table that you build, you must store all mappings of words to line numbers (not just words alone). When we test your code, we will have test cases that traverse the table and look for lists of line numbers for a given word. So be sure to design your data structure to store this information.

(Also, if you want to be nice to us -- which we'd be really grateful for -- you can implement a find method in your table that for a given word returns a list of line numbers the word appears in. This find method is called sequentially and only after all the reducers are done, so you don't need to worry about concurrent/race conditions with the method call.)

(2) The add function returns a boolean indicating whether the node has been successfully added to the list or not. For the purpose of this assignment, add() will always return True.

(3) If you decide to use ALock for your hash table lock, please modify your code for the table to take in an input param that specifies the maximum number of threads.

Announced on 12 April 2016  5:32  p.m. by Xiao Meng Zhang

View archived announcements