In this article published online last month, Microsoft's Sutter suggests three ways to break Amdahl's speed limit:

1. Revisit Gustafson's Law (covered by James Reinders here on Go Parallel -- and here's my take): Grow the problem that is parallelizable, so that a greater percentage of the program is functioning concurrently.
2. Add parallelizable features.
3. Here's a new one: Partially parallelize the sequential portion via pipelining, caching, prefetching, instruction reordering or other yet-to-be-invented approaches.

Sutter, just like our own Reinders, is eager for real-world scenarios:

But don't show me ray-traced bouncing balls or Mandelbrot graphics or the other usual embarrassingly parallel but niche (or downright useless) clichés—what we're looking for are real ideas of real software we could imagine real kids and grandmothers using that could become possible on manycore machines. Here's a quick potential example: Researchers know how to do speech recognition with near-human-quality accuracy in the lab, which is astonishingly good and would enable breakthrough user interfaces if it could be done that reliably in real time. The only trouble is that the software takes a week to run...on a single core. Can it be parallelized, and if so how many cores would we need to get a useful answer in a useful time? Bunches of smart people (and the smart money behind them) are investing hard work not only to find out the answer to that question, but also to find more questions like it.

However, I've just learned that Herb felt writer's remorse about the above paragraph. In fact, he wants me to point you to his blog where he elaborates on the "alternative real-world demos" concept:

Just to be clear, in the first sentence above I didn't mean to say that the standard demos are useless -- far from it (see below). This was intended to be a challenging call to action to not be satisfied with demos alone, but for us as an industry to imagine and develop compelling mainstream end applications that are multicore- and manycore-scalable. (To make that clearer, I'm going to ditch and rewrite the first sentence above for the Effective Concurrency book.)