18-742 Semester Project

Semester Projects

The project in 18-742 is an open-ended research project. We prefer that projects are done in groups of three, although groups of two may be permitted with the permission of the instructor. If you are looking for a partner, you can use 18-742 Piazza.

The project requires a proposal, a project status report, and a final report (both written and presented). See below for details.

New this year, Apple has graciously offered to judge the final projects and select a best 18-742 project. The plan is to have one or more engineers from Apple attend in person the Final Project Presentation Session, provide feedback on the projects, and select a best project. (This "judging" has no impact on your course grade: All projects will still be graded by the instructors.)

Project Ideas and Prior Project Example

On Canvas files, we have posted a list of possible project ideas and an example 18-742 project (called STAGE) from last spring.

Project Discussions with Course Staff

As noted in the syllabus, we will be offering four Fridays during which each project team meets with Phil and Mitchell to discuss progress, brainstorm, help out, etc. All meetings will be in GHC 7221.

The first of these will be February 14. Each project team should sign up for a 30 minute slot at a link to be posted on piazza.

The second of these will be March 14. Each project team should sign up for a 30 minute slot at a link to be posted on piazza.

The third of these will be March 28. Each project team should sign up for a 30 minute slot at a link to be posted on piazza.

The final of these will be April 18. Each project team should sign up for a 30 minute slot at a link to be posted on piazza.

Proposal

Due 2/19. The project proposal should be 3 pages; single spaced, one or two columns, 10 point font or larger.
Describe the project idea/application, how it relates to the course material, what work must be done (suggesting how it can be partitioned among you) and what resources you will need (including software systems you already have access to). Concentrate on convincing us that it will pertain to the course, that you will be able to complete it, and that we will be able to evaluate it. The third page should be dedicated to providing an outline of your intended final paper, identifying the specific experiments to be run and what questions they will answer.

In your proposal, provide three types of goals: 75% goals, 100% goals, and 125% goals. Think of these as the equivalent of a B grade, an A grade, and a "wow!" grade. The goals can be dependent or independent of the prior goals.

As an example, the project proposal for STAGE (from last spring) is posted to Canvas files.

Think also about providing answers to the Heilmeier Questions in your proposal, as appropriate.

Interim Project Report and Literature Survey

Due 3/19. The interim project report should contain:

Your updated introduction and motivation based upon feedback from your proposal and any changes you've made as a result of your research so far.
A re-iteration of your proposed goals, with explicit discussion about what progress you have made to date on those goals and what your timeline is for accomplishing the rest of them by the end of the semester.
A well-filled-out background and related work section citing the appropriate work from the literature.
A sketch of your evaluation section outlining your evaluation plan and listing (as simple as an itemized list if you wish) the major components you plan for your evaluation.

Feel free to include additional material in your interim report: If you wish to include, e.g., your design section or preliminary results, we will give you feedback to help ensure that your final report is great.

As an example, the project interim report for STAGE (from last spring) is posted to Canvas files.

Final Project Presentation and Report

Due 4/30 (presentation) and 5/2 (report). Final project presentations will be 1-4 pm on Wednesday 4/30 in the Panther Hollow (CIC 4105) conference room. Sign up for a time slot at a link to be posted on piazza. Each talk will be 15 minutes plus 5 minutes for questions.

We will simulate a 3 hour "conference" session. Each team will present in one of the time slots and serve as inquisitive audience members for the other slots. You are expected to attend the entire 3 hours, pay attention and ask questions at the end. The idea is to make the presentations more lively for the speakers and to simulate the Q&A of a conference presentation.

The talk should be along the lines of a conference talk for your work, e.g., with the following parts:

Introduction/motivation
Big picture overview of your system and the key ideas
Some further interesting/relevant details on your system
Experimental setup and evaluation
Conclusion (1-2 slides)

The final report will be due by 11:59 pm on Friday 5/2. It should be in the format of a research paper on your project, covering the same parts, with further details especially on related work (the literature survey from the Interim Report). As an example, the project final report for STAGE (from last spring) is posted to Canvas files.

In addition to the report, please submit a tar file of your source code to Canvas.

Project Management

You should strongly consider using Git to perform source code control for your project and using Git or Overleaf for the paper you write describing it.

We also strongly suggest writing your course project report using LaTeX. It is the de-facto tool in which most CS research papers are written. While it has a bit of start up cost, it's much easier to collaboratively write complex research papers using LaTeX than Word.

Writing Papers

An Evaluation of the Ninth SOSP Submissions - or - How (and How Not) to Write a Good Systems Paper by Roy Levin and David D. Redell
CSP project startup documents by John Wilkes
Collected resources about writing and research

PDL Machines

PDL hosts a large collection of machines that can be used for 18-742 course projects. Talk to Phil about getting accounts on PDL machines.

Project Resources

Misc Tools

Profiling

perf allows to analyze performance by monitoring a set of events (e.g., hardware/software counters, cache misses, etc.). It has a simple command line interface.
gprof is a profiling tool. It allows to display the call graph and count how many times a function (or code line) is executed, by sampling the program at fixed intervals. Potential inaccuracies and I/O operations should be taken into account.
strace is a debugging tool that allows to trace the system calls (together with the arguments) made a program. It also allows to monitor the signals that a process receives. It a simple command line interface.
ioprofiler monitors a set of I/O syscalls and reports file access information, such as name, part, access latency.

Debug

ioreplay reproduces the recorded I/O workload of a process, without the need to run it again.
valgrind allows to detect memory and thread concurrency bugs through dynamic binary instrumentation. It integrates tools like Memcheck (to detect bad memory accesses, memory leaks, etc.), Cachegrind (to simulate first and last level caches and provide info such as cache reads/writes, cache misses, etc.), Callgrind (to record the function calls in the program), Helgrind (to detect synchronization errors like deadlocks, data races, etc.). It has a simple command line interface.
dbug uses an interposition layer, to control the execution of a distributed and multi-threaded system, and an arbiter to select the execution order of concurrent function calls. It implements a systematic testing method that allows to check for deadlocks, non-reentrant function call and violations such as segmentation faults.