Reading: Computer Architecture -a Quantitative Approach

I've just managed to finish what I've been intermittently reading since April: Patterson and Hennessey, Computer Architecture -a Quantitative Approach. I'd forgotten what a profound book it was -it was just something that had been sitting on a shelf at work for over a decade, and after I'd brought it home, decided to read through it all. I started it on a four day family + borrowed child break where the lack of network connectivity would force me to engage in conversation or read -I managed to get halfway through the book. Since then, patchy.

As of today -I've re-read all of the 1995 edition, and am about to read the 2007 version that I got as an eBook.

Everyone who writes programs should read Patterson and Hennessey from time to time.

• It explains the concepts and reasoning behind the decisions that have been implemented in modern microprocessors. 
• It stops you pretending a computer just "is". It's gates made out of transistors, units built from the gates. Logic -not magic. And if you don't understand logic, you're in the wrong career, as your if() statements won't work.
• Instruction pipelines, caching, read misses, write misses and the like make it clear the performance costs of various software decisions. Once you move to languages higher level than C/C++ it's harder to deal with those consequences, but even knowing about them is useful.
• The bit on queue theory is relatively easy to understand.
• The exercises in each chapter are things you can do in your head or a bit of paper, and they keep your brain busy in a way that debugging failed unit tests doesn't. 
• The section on multiprocessing, including cache-coherency and relaxed consistency models have serious consequences for applications designed for multiprocessing -and are both an adjunct and an extension to the Java memory model that most Java programmers are oblivious too, and those people who think they understand -don't. I count myself in the "don't" category since Berlin Buzzwords -more on that another day. 

One of the fascinating things is that a lot of the work on multiprocessor & multicomputer systems in the 1980s and early 90s is a precursor to datacentre design -and hence the applications that run on them. There are some big changes

• The individual nodes in a 1980s multicomputer weren't 12-16 hyperthreaded core servers with 64+GB of Non Uniform (NUMA) memory. These are shared-bus MPU machines on their own,
• Various interconnect options were tried above and beyond Ethernet with its spanning tree routing and oversubscription issues. Crossbar switches, store and forward, other ideas.
• They didn't care about failures of anything other than disks. Well they cared- but treated them as disasters, not something to keep an eye on -and not something for the OS and application to deal with.

Some of the reasoning there does help put datacentre-scale computing into its perspective as an extension of the earlier systems, from the big supercomputers to VAXcluster systems -and knowing that history helps you see things better.

A truly excellent book.

[Artwork: Sepr at the Bearpit]