Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due
Introduction
This course will cover performance programming (memory hierarchy optimizations, SIMD, prefetching, etc.), performance analysis and modeling, shared memory parallelism, GPU programming, and message passing programming for clusters. Students who complete this course will be prepared to use and understand parallel computing concepts and software frameworks in the context of academic research or industry jobs. The programming projects will look at algorithms used in real-world applications such as machine learning, genomics, image analysis, epidemiological modeling, etc. The goal is for students to learn how to build high-performance implementations and understand the performance of computational systems, combining both algorithmic understanding and measurements.
-
CS61A,B,C, CS70, and either Math54 or EECS61A
-
Experience programming in C or C++ is also expected, or you should expect to spend some extra time getting up to speed on C++ (mainly the C subset)
-
There is significant overlap with CS267, so you should not take both courses. We encourage graduate students to take CS267 and undergraduates to take this course.
A schedule for the semester is available on the main class website. We may make adjustments to which units are covered in a given lecture or lab, but please mark your calendars now for the 4 quiz dates.
-
Lectures: Monday/Wednesday 2-3pm in 306 Soda, but also "synchronous" on Zoom and recorded.
-
Lab: 3-4pm PT Monday or Wednesday, either in person or by zoom. You will be assigned a lab based on your preference for in person / online, and recorded versions of the labs will be available after the Wednesday time for those of you with a conflict. Labs typically will have a short assignment to complete during the hour, which are also a warmup for the week's homework. These will be due Thursdays at 9pm. We know many of you have conflicts for the 3-4pm time slot; please attend the first 1/2 hour, if possible, or watch the video, and complete the lab on your own.
-
Homework: Will be roughly weekly and due on Mondays at 9pm PT.
-
Quizzes: Four quizzes will be held on Tuesdays evenings (9/14, 10/12, 11/9, 11/30). The dates are fixed, and the time is set for 6pm PT. These will be online. Let us know ASAP if you have a conflict with midterms. We do not plan to hold alternate exams.
There will be no final project and no final exam.
Our discussion forum this semester will be Piazza. For most questions about the course, Piazza is the right place to ask them. The course staff read it regularly, so you will get a quick answer. Furthermore, by posting online as opposed to emailing us directly, other students benefit by seeing the question and the answer. Don't forget to check Piazza before asking your question, just in case someone else has already posted it.
For issues specific to you (wrong scores, personal issues, etc.), please make a private Piazza post.
To talk with us, the best way is to attend office hours (posted on the home page) or if those times to not work, request appointment. Please don't be shy. We want to know if individual students are falling behind or having trouble with some material, so we can help you. And more likely than not, if you're not sure about something, then others also need more information. Our goal is to help all of you learn the material in this course.
There is no textbook for the course although we may provide you with optional reading material. This is mostly a hands-on learning based on the material in lecture and what you'll be doing in labs and on homeworks.
Because this a course about performance, which depends on the details of hardware, most assignments will be done using the Cori high performance computer system at NERSC. We will be using the Knights Landing (KNL) processors on Cori, which also has Intel Haswell nodes. The first Lab will go over how to use them, some tricks for making this easier, etc. NERSC does bring the Cori system down for maintenance, sometimes fir planned outages (e.g., there is currently one scheduled for Wednesday, September 16th and another for Wednesday, October 21) so the
This course does not have an official text editor or other tools, but if you want to develop software on your personal computer, you will need a C++ compiler and associated libraries, including OpenMP and MPI. There can be differences in the environments, so you need to make sure your code runs at NERSC on the KNL nodes with the cc compiler and libraries that is there. You will also need a secure login (ssh) and may want a few more tools to help with NERSC access. Some homework will require PDF submissions for written answers, so you will need a tool for producing that.
We'll be using the version-control system Git for keeping and tracking your work. Version-control systems allow you maintain a series of "snapshots" of your files at various points in their development. Used properly, this provides you some back-up protection, so that you can recover previous states of your work when something goes wrong. The Git documentation can be found here.
No extensions or makeup labs will be given, but we will drop the 2 lowest lab grades, including if you miss up to 2 of the labs.
You will turn in all of your assignments electronically using Git. For homeworks, each student is given 3 slip days. Each slip day is a 24-hour window of time on which you can work on your assignment and submit it without any late penalties. You start using your slip days as soon as it is past 9:00 PM PT of an assignment’s due date and time. For example, if an assignment is due Monday at 9:00 PM and you submit your assignment on Friday at 9:05 PM, you will have used a slip day. There’s no point in rushing to complete an assignment if you’re planning to use a slip day, since each slip day is worth 24 hours. If you turn in something before the 24-hour window is up for a particular slip day, you still will have used up the whole slip day. It is to your benefit to take advantage of these generous grace periods! You can check for yourself on bCourses of how many slip days you have used over the course of the semester by looking at how many assignments you have submitted late.
In case the NERSC systems are down within 72 hours of a due date, there will be an automatic extension equal to the number of hours the systems is down. (We will round up to the nearest hour, so if the system is down for 9.5 hours we will give a 10-hour extension.) Beyond slip days and NERSC outages, assignments must be turned in on time to receive any credit. There is no partial credit after the deadline.
For all submitted assignments (projects, homeworks, labs), we run any autograders at NERSC on Cori/KNL. The fact that your assignment runs at home or somewhere else is not sufficient; it must run on our setup. This only mirrors the real world: customers run software on the systems they have, not on the specially augmented systems that developers might use to create that software.
There will be four evening quizzes as noted above and no final exam. The quizzes are open book, open notes, but closed to any collaboration or discussion with classmates or others. Quizzes are to be entirely your own work. If you have a conflict with a quiz date, let us know by September 4th.
Your letter grade will be determined points on an absolute scale. In other words, there is no curve. Your grade will depend solely on how well you do, and not on how well everyone else does. The breakdown is: 50% quizzes, 40% homeworks, and 10% Labs. We are planning on roughly 14 Labs (of which 2 will be dropped) and roughly 14 homeworks (of which 1 will be dropped). We say "roughly" because we may not have one every week, in which case the remaining ones would scale appropriately so that the labs are still worth 10 points overall and the homeworks worth 40. The quizzes are equally weighted at 12.5 points each and would also be scaled in the unlikely event that one is cancelled.
Learning from and interacting with other students is an important part of the learning experience. In order to help facilitate interactions with other students in a virtual environment, we encourage working together on Lab assignments and may be placing each of you into smaller breakout groups of 3-4 students for Lab. Shared code for these short Lab assignments is acceptable.
You may also discuss the homework assignment with your study group, but in this case students are still expected to complete the assignments on their own, and identical or near-identical code will be treated as plagiarism. As a rule of thumb, you may discuss possible homework solutions with your study group partners, but you should never allow anyone to have a copy of your code in any form, or ever have anyone else’s code in your possession. Similarly, using solutions to the problems from external sources, such as the Internet is not permitted.
To help (but not entirely define) the bounds of acceptable behavior, we have have adopted three important rules for homeworks that should be familiar from CS16B projects:
-
By You Alone: All homework code that you submit (other than skeleton code we provide) should be written by you alone, except for small snippets that solve tiny subproblems (examples in the Permitted section below).
-
Do Not Possess or Share Code: Before a project deadline, you should never be in possession of solution code that you (or your partner) did not write. You will be equally culpable if you distribute such code to other students or future students. DO NOT GIVE ANYONE YOUR CODE -- EVEN IF THEY ARE DESPERATELY ASKING. DO NOT POST SOLUTIONS TO PROJECTS ONLINE (on GitHub or anywhere else)! By the way, any public posting of code derived from our skeletons is a violation of copyright as well. If you're not sure what you're doing is OK, please ask.
-
Cite Your Sources: When you receive significant assistance on a project from someone else, you should cite that assistance somewhere in your source code. We leave it to you to decide what constitutes 'significant'.
For clarity, examples of specific activities are listed below:
Permitted:
-
Discussion of approaches for solving a problem.
-
Giving away or receiving conceptual ideas towards a problem solution. Such help should be cited as comments in your code. For the sake of other's learning experience, we ask that you try not to give away anything juicy, and instead try to lead people to such solutions.
-
Discussion of specific syntax issues and bugs in your code.
-
Using small snippets of code that you find online for solving tiny problems (e.g. googling "uppercase string java" may lead you to some sample code that you copy and paste into your solution). Such usages should be cited as comments in your home code!
Permitted with Extreme Caution:
-
Looking at someone else's project code to assist with debugging. Typing or dictating code into someone else's computer is a violation of the "By You Alone" rule.
-
Looking at someone else's project code to understand a particular idea or part of a project. This is strongly discouraged due to the danger of plagiarism, but not absolutely forbidden. We are very serious about the "By You Alone" rule!
Absolutely Forbidden:
-
Possessing another student's project code in any form before a final deadline, be it electronic or on paper. This includes the situation where you're trying to help someone debug. Distributing such code is equally forbidden.
-
Possessing project solution code that you did not write yourself (from online, e.g. GitHub, staff solution code found somewhere on a server it should not have been, etc.) before a final deadline. Distributing such code is equally forbidden.
-
Posting solution code to any assignment in a public place (e.g. a public git repository, mediafire, etched into stones above the Mediterranean, etc). This applies even after the semester is over.
We have cheating-detection software, and we will routinely run this code to detect cheating..
If you admit guilt to an act of plagiarism before we catch you, you will be given zero points, and we will not refer your case to the university administration.
Speaking of giving credit for using other people's ideas and material, this document is derived from the 61B Course Overviews by Josh Hug and Paul Hilfinger. Some parts are taken verbatim, while others were adapted to the specifics of this course and my own perspectives.