The book is obviously a collection of previous work, and the style is quite inconsistent from section to section. Not so much that it detracts from the value of the information, but it does feel a bit rushed.

The book presents four sets of taxonomies:

• Models, which is by far the richest part. In addition to a definition of terms in the field of building models of digital systems, it also offers a detailed classification scheme for the models. The classification scheme uses five “resolution” axes along with an external/internal perspective to define what a model contains and at what level of resolution.
• Functional Verification, which is really just a collection of terms.
• Platform-Based Design, which is more of a marketing discussion in how to define and design platforms. Also mostly a definition of terms.
• Hardware-Dependent Software (HdS), which defines terms. It has some attempts to classify software along some axes, but it does not really work out too well.

The main value is really in the second chapter, where it does provide a decent basis for discussing the level of abstraction at which models are created (note that accuracy is different from abstraction: a very detailed model at a very low level of abstraction can be totally off when considered from an accuracy perspective).

However, I fear that the impact of this work has been fairly limited. No discussion on modeling that I have been participating in has really gone back to this basis and worked from there. I think a key problem here is that the material is only available as a quite expensive book from Springer, rather than as a freely downloadable document on the web. It is clear to me that spreading ideas today depends on free and easy digital access to the information… that’s why I have my own publications page up to make stuff that I have created available for reading.

The hardware-dependent software (HdS) section gave rise to several “but they forgot X” comments from my part. For example, it is missing important aspects like processor virtualization, hypervisors, and IO virtualization (which totally change the game on HdS). Also, SMP operating systems are only giving a passing reference, with the focus on uniprocessors. And why do people keep using the term “Rate-Monotonic Analysis? There are so many much more modern fixed-priority scheduling analysis theories, methods, and tools available that RMA is like talking about programming in assembler…

What a choice for summer vacation reading…  and thanks to Bart Vanhournout at CoWare for the tip about the book in a discussion trying to pin down abstraction levels.

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.

Our talk will be on how approximate you can be in simulating multicore computers, and still get useful results out from the software running on the simulator. It is something that we at Virtutech have spent a lot of time working on, and we want to bring our results to a wider community. Really exciting to present, and it is a pity that I could not be there myself.

• Several cores share the memory controller(s) — quite likely, since there is not room for more one controller per core in >2 core machines. The limitation is both because memory controllers are large and complex beasts, and because the pins needed for each memory interface makes it hard to have more than a few on a single chip. While the real estate for processors easily lets us put 4, 8, or 16 cores on a chip today.
• Modern DRAM controllers are not a strict fifo queue, but attempt to optimize memory bandwidth by prioritizing accesses that are directed to the currently open rows in the banks in the available DRAMs.
• The scheduling strategy used today (as they claim) can be easily monopolized by a thread with a high rate of memory accesses and good sequential locality. There is no attempt to provide fairness between cores or programs.

A simple stream benchmark doing a sequential read through a large array is a simple example of what they term an MPH — Memory Performance Hog. In experiments on real hardware and in simulation they show how it can kill the performance of simultaneously executing programs with somewhat more random access patterns.

So what to make of this?

First of all, this is a real attack, in the respect that this sort of thing can and do happen on current hardware with current software out in the field. How dangerous it is in practice is hard to tell, but it could be an issue for various cases where users are sharing a computer. A bit like the old “fork bomb” on Unix systems. I remember being thrown out of shared Solaris machines a few times due to these (several times unintended by beginning Unix programmers making honest mistakes).

It is more interesting in the context of embedded systems and integrated modular avionics (IMA). As I stated in a few earlier blog posts(63 and 58) I think that the best way to host multiple different applications on a multicore processor is to partition applications sparially across cores. This should be more efficient, simpler, and safer than sharing all the cores across partitions using time sharing.
However, this attack does reflect critically on that idea: if it is this simple to hog the memory and thus kill performance of other cores and applications, it might not be particularly safe to have each core run an independent set of applications of different criticalities. It does mean that in order to ensure performance isolation between applications, you will need additional hardware support of one form or the other. Could be a better DRAM scheduler (as the paper proposes), or a static allocation of a DRAM controller to each core (which is likely infeasible due to pin constraints), or DRAM controllers that do a slightly inefficient but safe allocation of a portion of their bandwidth to each core.

In the meantime, maybe the ugly temporal sharing of the entire chip is the “best” way ahead, as it at least is proof against this kind of attack based on parallel execution of partitions.

The following quotes on programming for the Clearspeed chips describes a solution that I find very attractive: use higher-level programming languages that describe an actual problem or computation to be performed, and then let a compiler/code generator take care of generating a suitable parallel implementation:

For one, it notes that a number of applications such as Matlab and Mathematica can run on the CSX600 chips without any changes to the underlying code thanks to work done by ClearSpeed and the software makers and the presence of friendly ClearSpeed libraries.

Using libraries is one solution suitable for certain classes of problems, and can cover a fair amount of the supercomputing market where the number of kernel algorithms used tend to be fairly limited. I wouldn’t try using these tools for programming a telecom switch, but that is not what the hardware is designed for either. The CSX600 chip contains 96 fully floating-point coprocessors, and there are solutions out there using massive numbers of the chips (144, according to The Register, for a total of 13824 processors). Scalability like that is pretty cool.

So it seems that by targeting a selected set of applications, Clearspeed does manage to produce a decently programmable solution. Also, one has to presume that the value to the end users of the solution is great enough that the time spent programming is worth its while.

Another example of a domain-limited solution with great power is what Acceleware is doing:  take the hardware and the software from Nvidia for using GPUs as accelerators, and code a solution applying it to a certain problem domain. This makes it very easy for the end-users to pick up, since they basically buy a package targeted to their problem, with all the hard parts already taken care of. In the case of Acceleware, the problem is electromagnetic simulations, and the customers are big companies like Nokia and Samsung. These end customers only need a month or so to incorporate the acceleration effect into their custom programs. Everybody wins, and the value of Acceleware is in letting a group of users for GPU acceleration share the cost of creating a platform to work from. Classic play in high-tech.

Finally, The Register looks at a few players working with FPGAs as their acceleration platform. This has theoretical immense performance and performance/power, but also a much steeper learning curve for programmers.  In my favorite field of embedded, I rather see FPGAs and on-chip FPGAs being used to create accelerated peripherals or simple algorithms embedded in hardware rather than as general-purpose math accelerators. The difference might not be that big in theory, but it does impact what the style and target programs for the programming tools are. And there is a big difference between floating-point math and the operations needed to decode video or do parallel table lookups.

I just got my personal copy, but my first impression of the book overall is very positive. The contents seems quite practical to a large extent, not as academic as one might have feared. Do check it out if you are into the field. It is not a collection of research paper, rather instructive chapters informed by solid research but with applications in mind.