Assigned: Monday, Apr 25, 2016
Due: Monday, May 9, 2016 at 10:30pm Sunday night
Report Due: Friday, May 13, 2016 at 10:30pm
Collaboration: You may work individually or in groups of up to three students. You may use your classmates as a resource, but please cite them.
By this point, you should have an approved project proposal. Make sure you have read the project proposal page for details on the requirements for the project. Once you have an accepted project topic, there are three components to your project:
Your final grade on the project will be based on these three components as well as your project proposal, using the following proportions:
The following sections describe the requirements for each component. Please read them carefully!
The largest component of this project is the actual implementation. You are free to divide up the implementation work as you see fit, and you are welcome to use the language(s) of your choice, provided you stay within the vicinity of your proposed project. Every group member must play a significant role in the implementation, but you are welcome to divide up implementation tasks.
Your implementation will be evaluated using several criteria:
While the first three pieces should be easy to evaluate, it may be difficult to say whether your system works. Two weeks is a very short time for a large implementation project, so I understand that you may run into issues and your plans could change. I have tried to offer advice about which parts you could drop if you run into issues in my proposal feedback, but if you hit a major roadblock and need to change your project I am happy to help.
To show that your system works, you must provide a README file that precisely describes the basic use of your system, including both general instructions and a specific example that walks through an interaction with the system and the expected output.
Your implementation must also include all necessary source and data files and a Makefile that allows me to build your project with the make command.
You are welcome to store your code anywhere you like, although I recommend using GitHub. If you would prefer not to make your code public, I can set up a private repository for you to use.
Your report must give an overview of your system, describe the design and implementation of the system, and finally present an evaluation of your work. Details for each section are below.
Give a brief overview of your system’s design, the high level points of your implementation (e.g. ___ runs on the GPU, while the CPU handles ___ using a thread pool), and summarize your evaluation strategy and results.
Your overview should not exceed 400 words.
The design and implementation section should explain the structure of your system and, importantly, the rationale for that structure. Design decisions include details like the data structures and algorithms you used, the places where you used concurrency or decided to run code on the GPU, and any libraries you may have used for your implementation.
Try to organize this section in a top down manner: introduce the major components of your system, outline the responsibilities of each component, and then jump into the specifics of each component. You may want to repeat this process for sub-components if there are reasonable logical divisons within the major pieces of your project.
Another strategy for organizing this section would be to break it down by concerns. System concerns include updating a file index in response to a file deletion, maintaining game state over a network connection, or other general requirements that may not map to specific units of code in your system. If you can identify a handful of high-level concerns it may make more sense to discuss the overall implementation structure and then describe how each concern fits into this structure.
In describing your system, identify at least two principles from Butler Lampson’s Hints for Computer System Design that you used in building your system. In addition to identifying these hints, reflect on how they might (or might not) have helped you build a working implementation.
Your design section should be approximately two pages of text, plus figures where appropriate.
You are required to present an empirical evaluation of your system.
The details of this evaluation will depend on your project topic, but there are a few common requirements.
First, you must describe the experimental set-up;
this includes the hardware and software you are using for the evaluation, versions of any important software tools (including libraries), and the methods you use for gathering data (e.g. we measure execution time using the time command).
Then, you should measure an appropriate aspect of your system’s behavior while varying some aspect of the load on your system or its environment.
Make sure your evaluation section explains what you are trying to measure and discusses an interpretation of your results.
For a file indexing project, you may want to measure the time it takes to issue a query as a function of the total size of the files in your index. For a project that uses a GPU, you might want to explore how varying block size changes the performance of your system. Do your best to pick an evaluation dimension that fits with your project goals; if the objective is to make a particular computation faster, then measure the speed of that computation. For some projects the evaluation will be less natural. I am happy to discuss this with you.
Your evaluation section should include at least one graph with a minimum of 8 data points relating to your system (16 if you compare to another system).
Your in-class presentation should take roughly 12 minutes, not including time for questions. Your presentation should begin with a brief overview of your system. Then, discuss the high-level design of your system and at least one interesting or challenging implementation detail. You should present one of Lampson’s hints and explain how that influenced your design. Next, describe your evaluation, being sure to walk us through the objective of your evaluation and the interpretation of your results. Finally, wrap up the discussion of your system with a quick summary.
All group members must participate in the presentation, but it is up to you to decide how to divide the presentation topics.
Submit your code and report (in PDF format) via email by 10:30pm on Sunday night. You do not need to submit your presentation. If your code is hosted on GitHub, bitbucket, or some other site you can simply send me a URL; otherwise, include your source code in a .zip or .tar.gz file attachment on your email.