Tuesday, August 2, 2011

Origins: Teaching Computer Architecture to Computer Scientists

I have taught computer architecture courses at both Caltech and CMU, at both the graduate and undergraduate level.  I’ve always found it a fascinating subject---trying to match the needs of programs with the ever-changing capabilities of hardware, while mixing in a bit about optimizing compilers and operating systems along the way.

At CMU, I used to teach a junior-level computer architecture course that was required of all CS majors.   I really liked showing how to construct a 5-stage pipeline to implement a processor that could execute MIPS code, as well as nuances of cache design, virtual memory, and data storage.  Unfortunately, the students did not share my enthusiasm.  They were much more oriented toward software, and, in their minds, this course formed a not-very-useful, dead-end branch in our curriculum.

 Every semester, students fill out evaluations of our teaching.  One outcome of these “Faculty Course Evaluations” (FCEs) is that each of us gets scored on “instructor effectiveness” on a scale between 0.0 and 5.0.  Here’s what the FCEs looked like for my teaching of computer architecture:


 

Not very impressive!  Except for one semester, I was below the overall average for the department, including a particularly bad semester in which I was a full point below.  Some of the blame could be directed at me---I’ll admit that at that point in my career I put much more of my energy into research than teaching---but a big part of the problem was that the students just plain didn’t like the material.  Of course, I could give the standard set of reasons why all CS students should learn computer architecture.  For example, students really need to understand caching, both as a general principle, and because cache behavior can dramatically affect program performance.

Over time, I tried adapting the course for a much CS-oriented audience.  I started going over code examples, showing how C code got transformed by the compiler into machine code, and how this determined how fast a program would run (it was much easier to predict execution time with those early, in-order pipelines), and how by tweaking the code it was often possible to make programs run much faster.  Still, the low FCE ratings persisted.  Somehow, there was a fundamental mismatch between the focus of the course and what students felt would really matter to them as computer scientists.

Randy Bryant


No comments:

Post a Comment