Since we spent almost 2 years of our lives working on the this report, I'd add my perspective to this discussion.
* The goal is to raise the level of abstraction to allow people the space that we'll need to be able to make the manycore bet work, rather than to be hamstrung by 15-year old legacy code written in 30-year old progamming languages.
* This report is more than a year old, and we now realize that what we were really talking about is design patterns, in the sense of the original 1997 book "A Pattern Language" by the Berkeley architecture professor Christopher Alexander (as opposed to the Gang of Four book on OO programming inspired by the Berkeley book)
* Apparently some readers skipped the part where we looked at the SPEC benchmarks, the embedded EEMBBC benchmarks, and then interviewed experts in databases, machine learning, graphics as well as high performance computing in trying to see if there was a short list of design patterns.
* Based on our 2 year investigation, we make the provactive claim that your programming lanugage, compiler, libraries, computer architecture ... better be able to handle these design patterns well, because they will be important in the upcoming decade in many apps. There are likely more design patterns that these 13, but they include, for example
- Finite State Machines
- Branch and Bound
- Graph Algorithms
which aren't in most people's lists of scientific computing problems.

Our bet is that the best applications, the best programming languages, the best libraries,... have not yet been written.

The challenge for this next generation of software to be correct, efficient, and scale with the increasing number of processors, without overburdening programmers. If we as field can succeed at this amazingly difficult challenge, the future looks good. If not, then performance increases we have relied upon for decades will come to an abrupt halt, likely dimishing the future of the IT industry.

Dave Patteron, UC Berkeley


Linus Torvalds (torvalds@osdl.org) on 2/14/08 wrote:
---------------------------
>Ugh. They seem to make essentially all of their arguments
>based on their "dwarfs" (shouldn't that be "vertically
>challenged algorithm"?).
>
>And their dwarfs in turn seem entirely selected to then
>support the end result they wanted. Can anybody say
>"circular argument" ten times fast?
>
>Apart from the obvious graphics thing, none of their loads
>seem at all relevant to "general purpose computing", they
>are all essentially about scientific computing.
>
>And we already pretty much know the solution to scientific
>computing: throw lots of cheap hardware on it (where "cheap"
>is then defined by what is mass-produced for other reasons).
>
>Designing future hardware around the needs of scientific
>computing seems ass-backwards. It's putting the cart in
>front of the horse.
>
>Linus