The most important data in the PhD thesis is really just how much work it is to do an SMP port of an OS kernel. And how hard it is to get performance up to good levels even with several years of work. Really emphasizes the point that hard work and perseverance and just lots of calendar time is what it takes to create a good SMP OS. That’s why Solaris and AIX are still years ahead of Linux in this respect — you just need to hit the snags, fix them, retest, and hit the next snag. It takes time to polish, basically.

So, if you have any interest in multiprocessor operating systems, Simon’s work is well-worth a read. Also check out his blog at http://simonkagstrom.livejournal.com/.  And by the way, he did pass.

In a section on “other development tools”, there is the following piece on simulation:

I just had to scan the page to make it look more real, right?

Anyhow, the critical bit is at the end:

By far, the biggest disadvantage of a simulator is that it simulates only the processor.

That is simply not true. Not today. Note that this is a second edition of a book, and that when the first edition was created the market place looked different. Today, vendors like Virtutech, CoWare, Synopsys, VaST, and ARM routinely provide full-system simulators that simulate much more than just the core processor. These virtual platforms contain memory, peripherals, and often connections to the outside world or simulations of the environment in which an embedded system operates. For more on this, please read the piece I wrote for embedded.com last year, or come visit my talk at the ESC SV this year (due in two weeks).

And next we have:

So you probably won’t do too much with the simulator once the actual embedded hardware is available.

This is not generally true either. Very often, a virtual hardware platform is used to develop software for a system even after hardware appears — simply because it is more convenient, available, and capable. It really is.

But finally, here is a quote that I like, finishing off this short section in their book:

That is a very good tip: use the simulator and compare notes with reality. It is a very powerful technique, but it is even better for a full-system simulator: there you can trace the actual virtual hardware-actual software interaction and see if any of the two parties are not following the data book. On hardware, you would have no chance to see that, as you cannot usually attach a trace unit to the device bus of an integrated chip.

I guess that was all I had on this topic. Barr and Massa are a bit wrong, but I guess it is mostly because they have not seen what can be done in virtualization and simulation today. Which means we in the business have more education and marketing to do to raise awareness of what tools can do today.

The best researched chapters are those on medical technology, where there is also deep data and clear dates and names. In other chapters, this depth of detail in persons and dates is missing, and the fact checking has been downright sloppy in places. This gives a slightly uneasy feeling to my reading of the book: what can be trusted at detail level and what cannot?

Some example fact errors:

• The author talks about the Heinkel He 280 being the main German jet fighter in World War II, while anyone versed in technology history knows that that honor befalls the legendary Messerchmitt Me 262.

• There is a claim that Vikings forged swords from carbonised iron which were longer and stronger than those of continental Europe. As a Swede, I have never heard of this fact. I believe the Vikings main military strong point was there fast and shallow-running ships, along with good timing that allowed them to exploit a period of weakness of the European continent.

And I have a suspicion that there are more such minor details which are not quite right in the later chapters of the book.

So overall, a nice concept that should have focussed on a few fewer technologies with more depth.

The authors are experienced parallel software writers working at Intel, and who wrote this book for Intel as part of the multicore push.

The book covers the obvious topics for any introduction book to parallel programming:

• Application patterns for parallel programs: various ways to structure computations to extract or expose parallelism.
• Programming APIs.
• Common problems in parallel code.
• Debugging parallel code.
• Performance tuning parallel code.
• Fundamental computer architecture.

In my mind, the best part of the book is the application patterns and programming APIs section. The most interesting aspect of the book was the weight given to the programming APIs and debug tools for Windows. In comparison, most other texts that I have seen focus on the portable and generally available pthreads/Posix threads API or OpenMP. The Windows APIs are actually pretty cool and powerful. Note that the .net managed code (CLR) environment has its own set of APIs similar to but distinct from the general old Win32 API.

The authors clearly have a weak spot for OpenMP, and more time is spent on OpenMP than any other API. I remain unconvinced about its generality, but it certainly has some interesting properties. But it is far from automatic parallelization. MPI gets a very strange treatment, being tucked away in a late part of the debugging chapter. Why it was not considered a full programming API is beyond me.

A section on memory consistency is pretty well written and is one of the best expositions on how that actually works on x86 and Itanium architectures.

The worst part of the book is the strangely confused and forced section on hardware architecture. Being an Intel (trademark) book about Intel (trademark) processors and programming them, the chapter on Pentium (r) and Core (r) and Itanium (trademark) processors was probably mandatory. But to someone with prior knowledge of computer architecture it is all very confused, trying to press ILP together with SMT (HyperThreading) and multicore into some joint thread concept that just does not work as a pedagogical concept.  Also, Itanium takes up an inordinate amount of space for what is basically a moribund architecture. But I guess that Intel (trademark) cannot acknowledge that Itanium (trademark) is a titanic disaster. At least not yet.  This chapter is also full of little (r) and ™ markers and various Intel product names that really makes it harder to read.

There is a good description of Intel multithreaded programming tools, not surprisingly.

Overall, the book offers a good read, but it suffers from also being Intel PR material. I do not recommend against reading it, especially not if you are programming in an x86 desktop environment. But if you are attacking an embedded Power Architecture problem, I think there are better sources.

Note for publicity thinkers: I bought this book after reading a technical article at Embedded.com “Technical Insights”. Submitting book chapters or excerpts as technical articles there could drive readers and buyers to your books. Worked on me at least, at least this one time.