Call for Presentations

Data movement is now often the most significant constraint on speed, throughput, and power consumption for applications in a wide range of domains. Unfortunately, modern memory systems are almost always hierarchical, parallel, dynamically allocated and shared, making them hard to model and analyze. In addition, the complexity of these systems is rapidly increasing due to the advent of new technologies such as Intel Optane and high-bandwidth memory (HBM).

Conventional solutions to memory hierarchy optimization problems are often compartmentalized and heuristic-driven; in the modern era of complex memory systems these lack the rigor and robustness to be fully effective. Going forward, research on performance in the memory hierarchy must adapt, ideally creating theories of memory that aim at formal, rigorous performance and correctness models, as well as optimizations that are based on mathematics, ensure reproducible results, and have provable guarantees.

Format and Topics

PMHO is an annual specialized and topic-driven workshop to present ongoing, under review, or previously published work related to the following non-exhaustive topic list:

• Mathematical and theoretical models of memory hierarchies including CPU/GPU/accelerator caches, software caching systems, key-value stores, network caches and storage system caches
• Algorithmic and formal aspects of cache management including virtual memory
• Programming models and compiler optimization of hierarchical complex memory systems

There will be no formal peer review process or publication, and presentations will be a mix of selections from submissions and invited presentations.

The 2022 workshop will take place online during the weekend of April 2 (Exact date TBD). It is hosted by the PPoPP 2022 conference.

Submission

Submit your presentation proposal to save-g4jFdqmK9rqH@3.basecamp.com. Submissions should consist of an one-page abstract of the topic you intend to present alongside any (optional) pertinent publications or preprints.

The submission deadline is Monday March 7, 2022 AOE.

Organizers

Faculty:

• Chen Ding, University of Rochester
• Nathan Tallent, Pacific Northwest National Laboratory

Student:

• Wesley Smith, University of Rochester

Workshop Program

Call for Presentations

Data movement is now often the most significant constraint on speed, throughput, and power consumption for applications in a wide range of domains. Unfortunately, modern memory systems are almost always hierarchical, parallel, dynamically allocated and shared, making them hard to model and analyze. In addition, the complexity of these systems is rapidly increasing due to the advent of new technologies such as Intel Optane and high-bandwidth memory (HBM).

Conventional solutions to memory hierarchy optimization problems are often compartmentalized and heuristic-driven; in the modern era of complex memory systems these lack the rigor and robustness to be fully effective. Going forward, research on performance in the memory hierarchy must adapt, ideally creating theories of memory that aim at formal, rigorous performance and correctness models, as well as optimizations that are based on mathematics, ensure reproducible results, and have provable guarantees.

PMHO 2021 is a forum dedicated to the theoretical aspect of memory hierarchies as well as their programming models and optimization.

Format and Topics

PMHO 2021 will be a specialized and topic-driven workshop to present ongoing, under review, or previously published work related to the following non-exhaustive topic list:

• Mathematical and theoretical models of memory hierarchies including CPU/GPU/accelerator caches, software caching systems, key-value stores, network caches and storage system caches
• Algorithmic and formal aspects of cache management including virtual memory
• Programming models and compiler optimization of hierarchical complex memory systems

There will be no formal peer review process or publication, and presentations will be a mix of selections from submissions and invited presentations.

The workshop will take place online Sunday February 28, 2021.

Submission

Submit your presentation proposal to save-g4jFdqmK9rqH@3.basecamp.com. Submissions should consist of an one-page abstract of the topic you intend to present alongside any (optional) pertinent publications or preprints.

The submission deadline is Friday January 22, 2021 AOE.

Organizers

Faculty:

• Chen Ding, University of Rochester
• Xipeng Shen, North Carolina State University

Student:

• Wesley Smith, University of Rochester

Collaborative Programming and Software Design

Prerequisites: CSC 252 and CSC 254 are required for CSC 453 and recommended for CSC 253.  CSC 161, CSC 172 or equivalent  is required for CSC 253.
Crosslisted: TCS 453 (same requirement as CSC 253)

Modern software is complex and more than a single person can fully comprehend. This course teaches the principles and techniques of writing modular and composable code and collaborating with others in software design. The topics include advanced concepts and techniques in modern programming languages, principles of modularity, software architecture, design patterns, software development processes, and other examples of software design. A significant portion of the assignment is a group project to develop a groupware system. Students enrolled in the class are expected to already have significant programming experience in some languages. The programming languages used in lectures are mainly Ruby, Haskell and Rust.

Fall 2020 draft schedule (see Blackboard > Course Material > 00 Schedule for updates).

Teaching Staff and office hours:  Prof. Chen Ding, Fridays 11am to 12pm in Wegmans Hall (WH) 3407 and online via Zoom.   TAs TBD.

The workload will be moderate to heavy.   Be sure to read instructions for each assignment and exam carefully, start the assignment early, know where/when to seek help, and work with peers.  (read more)

• 3 exams, roughly 30%
• attendance and participation, about 10%
• projects, approximately 45%

Assignments are typically handed out before Monday and due Friday midnight.

Preparation (before first class):

“No Silver Bullet — Essence and Accidents of Software Engineering” is a classic paper on software engineering written by Turing Award winner Fred Brooks in 1986.  Read the paper (available here) pages 3 to 5 on the “essential difficulties” of software development and skim the rest of the paper.

“A former member of the SD10 Panel on Computing in Support of Battle Management explains why he believes the ‘star wars’ effort will not achieve its stated goals.”  Read the paper (available here if accessed inside the UR network) pages 2 to 4 the section titled “Why software is unreliable.”  Which of the “essential difficulties” was Parnas discussing?

You can read this and other articles by borrowing the book “Software Fundamentals” from the textbook reserve for CSC 253/453 at the Carlson Library.  The lease is two hours.

Further material will be distributed through the Blackboard web site  for students who have registered.  Contact the instructor if you have problem accessing the site.

Textbooks (online access at learn.rochester.edu > CSC 253 > Reserves > Materials on Reserve in the Library):

(PAPL) Programming and Programming Languages, 2019 version (https://papl.cs.brown.edu/2019/)
Shriram Krishnamurthi et al.
(Also see Prof. Findler’s course EECS 321 at https://www.eecs.northwestern.edu/~robby/courses/)

 (SF) Software fundamentals : collected papers by David L. Parnas Author: Parnas, David Lorge. Imprint: Boston : Addison-Wesley, 2001. On Reserve at: Carlson Library Reserve Desk 2nd Floor Call Number: QA76.754 .P365 2001

(Lipovaca) Learn You a Haskell for Great Good!
A Beginner’s Guide
No Starch Press, April 2011.

(Rust book) The Rust Programming Language A Beginner’s Guide
by Steve Klabnik and Carol Nichols
https://doc.rust-lang.org/book/

(Schach) Object-oriented Software Engineering
Author: Schach, Stephen R.
Imprint: New York : McGraw-Hill, c2008.
Available at school book store. On Reserve at: Carlson Library Reserve Desk 2nd Floor

 (Olsen) Design patterns in Ruby [electronic resource] Author: Olsen, Russ. Imprint: Upper Saddle River, NJ : Addison-Wesley, c2008. Available through Carlson Library at: Internet

Other Materials

 Ruby under a microscope [electronic resource] : an illustrated guide to Ruby internals Author: Shaughnessy, Pat. Imprint: San Francisco : No Starch Press, [2014] Available at school book store.  Also on Reserve at: Internet
 Fundamentals of software engineering Author: Ghezzi, Carlo. Imprint: Upper Saddle River, N.J. : Prentice Hall, c2003. On Reserve at: Carlson Library Reserve Desk 2nd Floor Call Number: QA76.758 .G47 2003
 Structure and Interpretation of Computer Programs Authors: Hal Abelson and Jerry Sussman and Julie Sussman Imprint: MIT Press, 1984

Policies for CSC 2/453

The workload will be heavy.   Be sure to read instructions for each assignment and exam carefully, start the assignment early, know where/when to seek help, and work with peers.

Grades will be released periodically to Blackboard, the University’s on-line course management system.

Attendance and Class Participation

Class attendance is mandatory.  Please arrive on time.  I expect to start at 3:25 sharp, and late arrivals disturb the people who are already there.    You are encouraged to ask or answer questions in class.  I may call on you just to know what you think.  As a general rule, if there’s something you don’t understand, make me stop and explain it.  Other people sitting around you probably didn’t understand it either, but don’t have the nerve to say so.  Likewise, let me know if I’m belaboring something that you already know.

For most lectures, I will assign reading before and after.   Reading is mandatory It includes all lecture slides released to Blackboard, and textbook chapters/sections listed on the first slide of each lecture.   The exams include topics covered in class and in the required reading

Late Submission Policy

A student may have a total of two extra days in all individual assignments.  They can be used as either a one-day extension for two assignments, or a two-day extension for one assignment.  Additional extensions are given to students who attend research/education conferences.  The length of extension is roughly equal to the days of the conference plus travel. A student must inform the TA about the extension before the due time.   No other late submission is permitted.

Student conduct in CSC 2/453 is governed by the College Academic Honesty Policy, the Undergraduate Laboratory Policies of the Computer Science Department, and the University’s Acceptable Use Policy for Information Technology.  I worked in the academic honesty education committee in the past.  I believe in these policies strongly, and will enforce them aggressively.

The following are details specific to CSC 2/453.

Exams in CSC 2/453 must be strictly individual work.

Collaboration on programming assignments among team members is of course expected.  Collaboration on assignments across teams is encouraged at the level of ideas.  Feel free to ask each other questions, brainstorm on algorithms, or work together at a whiteboard.  You may not claim work as your own, however, unless you transform the ideas into substance by yourself.  Among other things, this means that you must leave any brainstorming sessions with no written or electronic notes—only what you carry in your head.

If you use the work of others (e.g., you download a function from the web at the last minute so that you can get the rest of your project working), then (1) either you must have the author’s explicit permission or the material must be publicly available, and (2) you must label what you copied, clearly and prominently, when you hand it in.  You will of course get points only for the parts of your assignment that you wrote yourself.

To minimize the temptation to steal code, all students are expected to protect any directories or on-line repositories in which they do their work.

For purposes of this class, academic dishonesty is defined as

• Any attempt to pass off work on an exam or quiz that didn’t come straight out of your own head.
• Any collaboration on assignments beyond the sharing of ideas, unless the collaborating parties clearly and prominently explain exactly who did what, at turn-in time.
• Any activity that has the effect of significantly impairing the ability of another student to learn.  Examples here might include destroying the work of others, interfering with their access to resources, or deliberately providing them with misleading information.

Note that grades in CSC 2/453 are assigned on the basis of individual merit rather than relative standing, so there is no benefit—even a dishonest one—to be gained by sabotaging the work of others.

I work under the assumption that students are honest.  I will not go looking for exceptions.  If I discover one, however, I will come down on it very hard.  Over the past few years, the department has submitted violation cases to the College Board on Academic Honesty.  Many resulted in major penalties for the students involved.

A small correction to Li et. al.’s paper: in section 3.2, the length of a time window is defined as “its end time minus its start time plus one.” However, in section 3.2.1, there is a reference to “windows of length k from 0 $\leq$ k $\leq$ n,” the lower bound of which refers to windows with their end index before their start. This also leads to some mathematical inconsistencies in sections 3.2.1 and 3.2.2.

One such error is the calculation of reuse(1): by the stated definition, an interval of length k=1 has only one allocation, so the reuse should be one if the window also contains a matching free operation and 0 otherwise. Therefore, since there are a total of n windows of length 1, the average reuse of all such windows should be:

$reuse(1)$ $=\frac{\sum_{i=1}^{m}I(e_i-s_i=0)}{n}$

However, by the formulae stated in 3.2.2:

$reuse(1)$ $=\frac{\sum_{i=1}^{m}I(e_i-s_i=1)s_i - \sum_{i=1}^{m}I(e_i-s_i=1)(s_i + 1) + 2\sum_{i=1}^{m}I(e_i-s_i=1)}{n}$

$reuse(1)$ $=\frac{\sum_{i=1}^{m}I(e_i-s_i=1)}{n}$ $\neq$ $\frac{\sum_{i=1}^{m}I(e_i-s_i=0)}{n}$

In order to standardize the equations with the provided definition of window length, a few changes must be made:

In Eq. 1 and Eq. 2, every instance of $e_i - s_i \le k$ should instead read $e_i - s_i < k$

Then in Eq. 2,
$Z(k)=$ $\frac{\sum_{i=1}^{m}I(e_i - s_i < k) \cdot k}{n-k+1}$

The recursive equations should then read

$X(1) = \sum_{i=1}^{m}I(e_i - s_i = 0)s_i$

$X(k) = X(k-1) + \sum_{i=1}^{m}I(s_i\ge n-(k-1)) + \sum_{i=1}^{m}I(e_i-s_i+1=k)min(n-k, s_i)$

$Y(1) = \sum_{i=1}^{m}I(e_i - s_i = 0)e_i$

$Y(k) = Y(k-1) + \sum_{i=1}^{m}I(e_i\le k-1) + \sum_{i=1}^{m}I(e_i-s_i+1=k)max(k, e_i)$

$Z(1) = \sum_{i=1}^{m}I(e_i - s_i = 0)$

$Z(k) = Z(k-1) + \sum_{i=1}^{m}I(e_i-s_i < k) + \sum_{i=1}^{m}I(e_i-s_i+1=k) \cdot k$

(Sent to my class on the exam day)

NY Times collects and publishes New York city stories submitted by its readers at https://www.nytimes.com/column/metropolitan-diary.  The May 3 entry was Christopher Fryer who remembered “joys of city life walking every day from our apartment on the Upper West Side through Central Park, and then down Sixth Avenue to my office at 46th Street”, found “a shining Lincoln head on the penultimate step”, “paused to pick it up, being careful not to impede either the people coming up behind me or those who were heading down into the station”, and “a man on his way down the stairs spoke without breaking stride.

“Hey,” he said. “ I saw one of those at 125th Street. If you hurry you can probably get that one, too.”

Re finding pennies and other coins, I was always told that they had to be face up to be “good luck.”  I read somewhere a long time ago about a kind soul who would turn coins over when found face down so the next person to see them would have good luck, so I do that. It’s a little like being Santa Claus.

This is yet another proof of the CSC 200H theme: even good luck requires collaboration.

This slideshow requires JavaScript.

On Friday I received the Frederick D. and Susan Rice Lewis College Award for Undergraduate Teaching and Research Mentorship.  It was delightful to see everyone including many of my current and former students.  I prepared and delivered the following speech:

Thanks to Fred and Susan Lewis for creating this award and for being here, to Dean Runner, Mike, Cesar, and Chris for your generous words, to Department Chair Dr. Dwarkadas for the nomination, and Ms. Logory for organizing today’s event.

Thanks to the terrific computer science department, to our staff, especially the tireless work of Eileen Pullara.  Countless times I have asked her: can I hire another undergrad.  It is a community of support. I’m standing on the shoulder of not just the department, but also the university community and the scientific community.

Let me first state my teaching philosophy by quoting the Chinese philosopher Confucious from 2000 years ago, who he himself was a teacher. He said, and I translate: Achieve independence by making others independent. Achieve prosperity by making others prosperous.

As university faculty, we are Stewards of Knowledge.  My colleague Randal Nelson once compared education and business, he said, I quote: “The fundamental currency of a university is knowledge; while that of a corporation is capital. Both traffic information, money, and talented human beings, … but the bottom-line metric differs. ” Money, resource and capital have limits. It is often called a zero sum game. Knowledge knows no limits.

In teaching, I specialize in programming languages and systems. I show students a cartoon. This is an interview room at Ikea. The text in black instructs the nervous interviewee: “make a chair and take a seat”, the text in red is for my class “invent a language and talk.”

Interesting problems are abound: How do we describe a language when we do not yet have a language? Similar circular problems in Cesar’s research then and Mike’s research now in memory allocation. Similarly in my Confucious motto: independence and prosperity are problems that cannot be solved in isolation.

In most courses I teach, students learn by doing. Alan Perlis, the first recipient of Turing award in 1966, said “You think you know when you can learn, are more sure when you can write, even more when you can teach, but certain when you can program.” To understand a programming language, you must not just learn it but to build it.

How do we create knowledge?

We discover it through science, first by measuring. We are in the dark and remain so until we measure. The Unite State’s response to the coronavirus is hampered by a president who communicates by tweets, by politicizing the response to the crisis, and most damaging by anti-science arrogance and idiocy.

The first step it missed and still missing is testing. Without testing there is no science, and there is no knowledge.  This ignorance puts medical personnels and emergency responders and their family in danger and we begin to see disproportional fatalities in poor city neighborhoods, indigent population and people with disabilities.

This Wednesday I was most proud to see our University News photo: our medical school colleagues return from helping in NYC.  In teaching, as in medicine, we work with knowledge and skill.

Like our medical colleagues, we work together. We collaborate.

The best teacher-student relation is symbiotic. I confess when I first taught computer organization, the evaluation wasn’t good. A common criticism, believe it or not, was that the professor gave too many extensions. The next year, I set a schedule and followed it. Then the department machines had to be shut down for days due to the cooling water system repair in the building. I held the line and told my students that we don’t need extensions for lack of cooling, not in the middle of the winter, not in Rochester. I received high scores for that course.

At a research university like ours, teaching keeps a close pace with technology.
This semester I am teaching new material of machine-checked proofs.
Knowledge is not just the truth but more importantly the proof.  Proof is knowledge about knowledge — how do we know we know.

This is unprecedented material which combines the programming language and the language of logic. (1) Programming encodes reasoning, (2) reasoning verifies programming. (3) With computers, programming automates reasoning. (4) Even more exciting is the new way to collaborate — our reasoning can be combined as our programs can.  (5) Most exciting is where our students will go taking the knowledge. Three undergrads and their TA are “programming” a proof for a joint paper with my colleagues and may introduce machine-checked proofs to the database community.

We teach technology. We collaborate to develop technology. We also teach and develop technology to amplify collaborative work.

University of Rochester, its size, not too big and not too small, and its combination of research and liberal arts education, make it a best place to collaborate.

The best collaboration is to inspire and be inspired. Let me take just one minute to give two examples.

Lane Hemaspaandra created the honor course I’m teaching now and he continues to help and model for me in teaching collaborative problem solving.

Chris Tice when he was a student solved an extra credit problem after the assignment was due. So why doing extra work for no credit. He said that he didn’t have time to work on it, but he was interested so he went back once he had time. When a student is not there just for the grade, a teacher is not here just for grading. It is what Hajim said at every commencement, if you love your work, you never have to work.

To summarize, I have started with my motto of independence and prosperity and highlighted three ingredients of a happy life: to collaborate, discover, and inspire. To help you remember, the initials CDI are the first three letters of my university NetId.

I want to thank people who inspired me the most: my longest time colleagues, mentors and supporters Michael Scott and Sandhya Dwarkadas, my graduate advisors late Dr. Ken Kennedy and Philip Sweany, my mother Ruizhe Liu who’s currently battling cancer, for her unyielding courage and support, my father Shengyao, my brother Rui, my dear wife and Rochester graduate Dr. Linlin Chen and our two children Yawen and Shuwen who were both born in Rochester.

Last, let me share a few road trip photos.   In 2016, we went to conference in DC, we zoomed by at 90 miles an hour in Pennsylvania but then sit still in traffic the minute we got to Baltimore, but had fun counting the many Rs. Once arrived, undergrads had homework. The book on the table was Michael’s popular textbook, in its fourth edition. At the award banquet, we were the Rochester 9, the following year we had a smaller group and Google flew one of the undergrads out for interview, but in this photo we were the largest group and was so recognized.

This slideshow requires JavaScript.

I received an award for that exact reason — the award for being the largest group attending the conference.  Inspired, I told my students: you see — 100% of success is just showing up.

Then it was literally true for that award. Today I feel the same for this award. It is most humbling. Thank you all.

Other than the people I thanked above, I am also grateful for the many who joined the meeting and for the spontaneous comments following the event by my colleagues Michael Scott and Sandhya Dwarkadas and my former doctoral graduates Xiaoming Gu, Chengliang (Cheng) Zhang, Pengcheng Li, and Xipeng Shen.  Quoting Dr. Cheng Zhang who was attending from home in Seattle and said that through his work in Microsoft, Amazon and now Google, he collaborate in a team and he work to lift others.

It was most fun, heart warming, and well organized.  There wasn’t even problems with the network.

Collaborative Programming and Software Design

Prerequisites: CSC 252 and CSC 254 are required for CSC 453 and recommended for CSC 253.  CSC 161, CSC 172 or equivalent  is required for CSC 253.
Crosslisted: TCS 453 (same requirement as CSC 253)

Modern software is complex and more than a single person can fully comprehend. This course teaches the principles and techniques of writing modular and composable code and collaborating with others in software design. The topics include advanced concepts and techniques in modern programming languages, principles of modularity, software architecture, design patterns, software development processes, and other examples of software design. A significant portion of the assignment is a group project to develop a groupware system. Students enrolled in the class are expected to already have significant programming experience in some languages. The programming languages used in lectures are mainly Ruby, Haskell and Rust.

Fall 2019 schedule (see Blackboard and Piazza for updates).

Teaching Staff and office hours:  Prof. Chen Ding, Fridays 11am to 12pm in Wegmans Hall (WH) 3407, x51373.   Wesley Smith, Tuesdays 11am to noon WH 2215.  Michael Chavrimootoo, 10am to 11 WH 2215.

The workload will be heavy.   Be sure to read instructions for each assignment and exam carefully, start the assignment early, know where/when to seek help, and work with peers.  (read more)

• 3 exams, roughly 30%
• attendance and written homework, about 10%
• assignments and projects, approximately 60%

Assignments are typically handed out before Monday and due Friday midnight.

Preparation (before first class):

“No Silver Bullet — Essence and Accidents of Software Engineering” is a classic paper on software engineering written by Turing Award winner Fred Brooks in 1986.  Read the paper (available here) pages 3 to 5 on the “essential difficulties” of software development and skim the rest of the paper.

“A former member of the SD10 Panel on Computing in Support of Battle Management explains why he believes the ‘star wars’ effort will not achieve its stated goals.”  Read the paper (available here if accessed inside the UR network) pages 2 to 4 the section titled “Why software is unreliable.”  Which of the “essential difficulties” was Parnas discussing?

You can read this and other articles by borrowing the book “Software Fundamentals” from the textbook reserve for CSC 253/453 at the Carlson Library.  The lease is two hours.

Further material will be distributed through the Blackboard web site  for students who have registered.  Contact the instructor if you have problem accessing the site.

Textbooks (online access at learn.rochester.edu > CSC 253 > Reserves > Materials on Reserve in the Library):

 Software fundamentals : collected papers by David L. Parnas Author: Parnas, David Lorge. Imprint: Boston : Addison-Wesley, 2001. On Reserve at: Carlson Library Reserve Desk 2nd Floor Call Number: QA76.754 .P365 2001

Object-oriented Software Engineering
Author: Schach, Stephen R.
Imprint: New York : McGraw-Hill, c2008.
Available at school book store. On Reserve at: Carlson Library Reserve Desk 2nd Floor

 Design patterns in Ruby [electronic resource] Author: Olsen, Russ. Imprint: Upper Saddle River, NJ : Addison-Wesley, c2008. Available through Carlson Library at: Internet

Programming Languages: Application and Interpretation (http://cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/)
(Also see Prof. Findler’s course EECS 321 at https://www.eecs.northwestern.edu/~robby/courses/)

Learn You a Haskell for Great Good!
A Beginner’s Guide
No Starch Press, April 2011.

Programming Language Pragmatics, 4th Edition
Author: Scott, Michael L.
On Reserve at: Carlson Library Reserve Desk 2nd Floor
Call Number: CRL PersCpy

Other Materials

 Ruby under a microscope [electronic resource] : an illustrated guide to Ruby internals Author: Shaughnessy, Pat. Imprint: San Francisco : No Starch Press, [2014] Available at school book store.  Also on Reserve at: Internet
 Fundamentals of software engineering Author: Ghezzi, Carlo. Imprint: Upper Saddle River, N.J. : Prentice Hall, c2003. On Reserve at: Carlson Library Reserve Desk 2nd Floor Call Number: QA76.758 .G47 2003
 Structure and Interpretation of Computer Programs Authors: Hal Abelson and Jerry Sussman and Julie Sussman Imprint: MIT Press, 1984

Policies for CSC 2/453

The workload will be heavy.   Be sure to read instructions for each assignment and exam carefully, start the assignment early, know where/when to seek help, and work with peers.

Grades will be released periodically to Blackboard, the University’s on-line course management system.

Attendance and Class Participation

Class attendance is mandatory.  Please arrive on time.  I expect to start at 3:25 sharp, and late arrivals disturb the people who are already there.    You are encouraged to ask or answer questions in class.  I may call on you just to know what you think.  As a general rule, if there’s something you don’t understand, make me stop and explain it.  Other people sitting around you probably didn’t understand it either, but don’t have the nerve to say so.  Likewise, let me know if I’m belaboring something that you already know.

For most lectures, I will assign reading before and after.   Reading is mandatory It includes all lecture slides released to Blackboard, and textbook chapters/sections listed on the first slide of each lecture.   The exams include topics covered in class and in the required reading

Late Submission Policy

A student may have a total of two extra days in all individual assignments.  They can be used as either a one-day extension for two assignments, or a two-day extension for one assignment.  Additional extensions are given to students who attend research/education conferences.  The length of extension is roughly equal to the days of the conference plus travel. A student must inform the TA about the extension before the due time.   No other late submission is permitted.

Student conduct in CSC 2/453 is governed by the College Academic Honesty Policy, the Undergraduate Laboratory Policies of the Computer Science Department, and the University’s Acceptable Use Policy for Information Technology.  I worked in the academic honesty education committee in the past.  I believe in these policies strongly, and will enforce them aggressively.

The following are details specific to CSC 2/453.

Exams in CSC 2/453 must be strictly individual work.

Collaboration on programming assignments among team members is of course expected.  Collaboration on assignments across teams is encouraged at the level of ideas.  Feel free to ask each other questions, brainstorm on algorithms, or work together at a whiteboard.  You may not claim work as your own, however, unless you transform the ideas into substance by yourself.  Among other things, this means that you must leave any brainstorming sessions with no written or electronic notes—only what you carry in your head.

If you use the work of others (e.g., you download a function from the web at the last minute so that you can get the rest of your project working), then (1) either you must have the author’s explicit permission or the material must be publicly available, and (2) you must label what you copied, clearly and prominently, when you hand it in.  You will of course get points only for the parts of your assignment that you wrote yourself.

To minimize the temptation to steal code, all students are expected to protect any directories or on-line repositories in which they do their work.

For purposes of this class, academic dishonesty is defined as

• Any attempt to pass off work on an exam or quiz that didn’t come straight out of your own head.
• Any collaboration on assignments beyond the sharing of ideas, unless the collaborating parties clearly and prominently explain exactly who did what, at turn-in time.
• Any activity that has the effect of significantly impairing the ability of another student to learn.  Examples here might include destroying the work of others, interfering with their access to resources, or deliberately providing them with misleading information.

Note that grades in CSC 2/453 are assigned on the basis of individual merit rather than relative standing, so there is no benefit—even a dishonest one—to be gained by sabotaging the work of others.

I work under the assumption that students are honest.  I will not go looking for exceptions.  If I discover one, however, I will come down on it very hard.  Over the past few years, the department has submitted violation cases to the College Board on Academic Honesty.  Many resulted in major penalties for the students involved.

Prescriptive Software Caching Using Leases

The cost and performance of a modern system depend on its memory hierarchy. Manual management of the memory hierarchy is complex and not portable. Automatic management is sub-optimal — it reacts to program behavior but does not directly utilize program knowledge. This research seeks a middle ground with a new type of cache called Lease Cache. It enables prescriptive caching by utilizing proogram knowledge, variable cache sizes, and multi-policy caching.

Prescriptive caching takes a principled approach building on theory and optimization. It connects programming and caching directly with programming abstractions and program analysis. The research solves four problems. (1) Lease cache theory, ensuring performance no worse than LRU cache when there is no program knowledge and optimal when there is program knowledge. (2) Lease cache optimization, incuding statistical caching as well as optimization for multi-policy and multi-granularity caching. (3) Locality analysis, combining static analysis and run-time sampling to analyze program locality. (4) Lease cache system, with efficient lease management including the use of approximation to reduce the overhead.

Acknowledgement. The on-going research is supported by the National Science Foundation (Contract No. CCF-2114319, CNS-1909099). The past support came from the National Science Foundation (Contract No. CCF-1717877, CCF-1629376, CNS-1319617, CCF-1116104, CCF-0963759, CNS-0834566, CNS-0720796, CNS-0509270, CCR-0238176, CCR-0219848 and EIA-0080124), IBM CAS Faculty Fellowships, the Department of Energy (Contract No. DE-FG02-02ER25525), the National Science Foundation of China (Contract No. 61328201), two grants from Microsoft Research, a grant from Huawei, and equipment support from Intel. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the funding organizations.