Warm-up with Menti (5 minutes)

Question of the day on Menti:

• Most confusing point in the class so far?

Logistics (5 minutes)

• Add/drop ending
• Class buddies
• Project 1 plans
• Alternate times (TR 1:25-2:40 in the Gather.town office)

Walk-through: playing with profilers (20 minutes)

Breakout groups (25 minutes)

1. What is the size of the following C struct, and why?

   typedef struct foo_t {
       char a;
       double b;
   } foo_t;
   

2. Consider an explicit time stepper on a 256^2 mesh (65536 points). Each time step takes time proportional to the mesh size (a few flops per mesh point), and every 100 steps we spend 5ms to write to disk. Roughly what fraction of the time is spent on disk writes, assumeing that we are going at about the peak flop rate?

3. How fast can you make the centroid code, in principle?

Report out (5 minutes)

Afternotes

There were two themes in the Menti poll: confusion over computer architecture (particularly caching), and confusion over tools (compilers, Unix, etc). This is consistent with what I’ve heard in past versions of the class, so it is not soo much of a surprise, but it’s worth a couple comments.

Architectural confusion

Re-emphasize something that I also said in the slides: for the purposes of this class, my goal is not to teach you a lot of computer architecture. Rather, it’s to teach you to recognize the handful of architectural features that are most relevant to scientific high-performance computing: caches and memory speeds, and things involving instruction-level parallelism.

It is fine if you get confused about the difference between conflict and capacity misses. It’s useful to distinguish between them because we might consider different tuning strategies to get around one or the other, but I am not going to quiz you on it. Similarly, I don’t know that you need to know about the details of instruction-level parallelism on modern x86-64 chips. I mostly want you to know enough to realize when your code is running slower than it ought to, and to recognize why.

The architecture material in this class is mostly in the first couple of weeks. We’ll keep using the ideas throughout, but we’ll be focusing more on organizational patterns and algorithmic ideas soon enough.

Tools and environments

I do assume students coming into this class know something about programming in a C-family language, enough to pick up C. I don’t assume you are all familiar with Unix. Fortunately, there are good resources online (with pointers from the web page and course slides), and I am happy to talk in office hours or via email/Slack/Piazza to clear up points of confusion. You can also ask your peers; we do have Unix expertise in the class, it just isn’t uniformly distributed.

I certainly don’t assume that you are familiar with GCP, nor with working in a batch queued environment (as is common in most supercomputing centers and many clusters). But we need these types of resources if we’re going to do examples on machines bigger than your personal laptops or desktops (which we are). So we’ll spend some time in the meetings to help get you familiar with these things, and you can also ask questions of me or of your peers.

Part of the reason for learning these tools is because we need them for the projects. But learning about these software tools (compilers, build systems, Unix, etc) is the thing that students most frequently tell me they valued after the course ends. Sometimes it is more specific than that, and I’m still not sure how I felt about the student comment that the most valuable thing they learned in 5220 was how to use make! It was not anonymous, and I know the student enjoyed the class, so I think this was mostly a sign of how useful they ended up finding makefiles. Anyhow, this is the sixth time I’ve taught this course at Cornell (and I also taught it at NYU and was a TA for the equivalent at Berkeley twice before that), and this appreciation for knowing about the tools seems to be a general theme in post-course feedback, even if not everyone likes it at the time they are picking it up. I suppose this makes sense, since even many of you who are never going to tune a piece of code after this course ends might want to do some work on a machine that is bigger than your laptop or desktop, or might find yourself needing to do some work in a Unix-style environment.