VDC (a research firm covering developers of embedded systems) recently unveiled a “teaser” press release commenting on developer attitudes towards multicore architectures. The teaser said “…embedded developers still do not yet consider multiprocessing and multi-core architecture support a highly critical factor influencing their selection of embedded operating systems for current projects.”

Well… isn’t that confusing? Is multicore a flop? Did Intel, Cavium, ARM, TI, and Freescale all place the wrong bet?

My opinion is, no, multicore isn’t a flop. This survey is, however, a symptom of a few inconvenient truths.

Most applications likely can’t exploit multicore without significant re-engineering.

Recent discussions with several customers helps to confirm some of this thinking. I’ve heard all sorts of misconceptions about multicore and what developers need to do to exploit it. There is some real wishful thinking going on in some minds about how throwing 8 processors at a single threaded application will make the whole job GOFAST! right now.

We had a discussion in the office a while ago that was sparked by this informal ESC poll about multicore adoption:

Only 51 percent of respondents said they have applications running on multicore CPUs or will migrate to multicore processors in the next 3-5 years. A whopping 49 percent said they neither use multicore chips nor plan to in the next five years.

[Note that this was just a casual survey by Freescale and Virtutech. Likely they just walked around the show floor and asked folks what they thought. VDC runs a good shop and employs strong survey methodologies with secondary sources.]

The discussion got started with this quote from Donald Knuth that was shared in a recent article:

I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the Itanium approach that was supposed to be so terrific until it turned out that the wished-for compilers were basically impossible to write.

Let me put it this way: During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX.

I know that important applications for parallelism exist… rendering graphics, breaking codes, scanning images, simulating physical and biological processes, etc. But all these applications require dedicated code and special-purpose techniques, which will need to be changed substantially every few years.

The office debate that followed was interesting. It boiled down to:

• There well could be many uses for multicore processors that don’t have anything direct to do with the implementation of multicore aware algorithms. Pinning a critical algorithm to a dedicated processor is one example. More efficiently implementing virtualization for its many use cases is another. All of these are in effect using multicore inefficiently from an algorithm standpoint but delivering benefit nevertheless.
• Multicore transition is a marathon, not a sprint.
• Many of the edge cases Knuth highlights as suitable for multicore are actually typical in the world of embedded devices.

Heterogeneous multicore processors are hotrods… but application developers need huge motivation or lots of help to use them.

I first heard wiffs of this in discussions with a company that makes consumer products based on a popular ARM+DSP architecture. While we certainly are aware of companies that will employ DSP developers to exploit this heterogeneous multicore chip this particular company didn’t want to be in that business. They would rather have the DSP code pre-cooked and provided to them by the vendor or ISV partners.

You’ve seen this in graphics processors for years. Most everyone has a heterogeneous multicore computer on their desk now. The graphics processors have a slew of processors that can be used, in some cases, for running algorithms other than graphics processing. Specialty companies even exist to help you exploit these capabilities.

Exploiting the GPU is still, however, a niche activity for engineers.

Intel’s upcoming Larabee graphics processors will be an interesting test. Larabee is described as a multicore x86 based GPU. Will introducing a familiar instruction set remove a barrier to running non-graphics algorithms?

This is a broad market survey.

VDC typically surveys a wide swath of developers who are building all sorts of applications. If you segmented the market and isolated developers who are likely to have applications that would benefit from multicore you’d likely have a different view.

Wrap up

I don’t share’s Knuth’s opinion that multicore could end up being Itanium like in any way. There is a demonstrated track record of successful multicore applications in the embedded software domain.

I do wonder if in the broad embedded systems market if multicore adoption will lag or the multicore architecture will be used inefficiently to serve other important use cases facing designers.

ShareThis

This entry was posted on Thursday, August 7th, 2008 at 8:53 am and is filed under multicore.