David Patterson (pattrsn@cs.berkeley.edu) on 2/15/08 wrote:
---------------------------
>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.

Without wanting to selective quote, it sure is true that there is a lot of room to improve upon programming languages.

The best programming language has not been invented yet. Instead the current object oriented languages are the opposite of what we want.

What happens in big projects of a lot of codelines is that templates and all kind of subclasses and all other fancy c++ type codes. Vectors, inheritance, you can list it all yourself very well; all those concepts are creating a huge code sizes. Software that just grows and grows in size.

The biggest problem in such big software is the hard fact that object oriented programming is perhaps interesting on paper, memory allocation and deallocation is a real ugly slow operation at the processor.

Also such programming languages ultimately have big problems with multithreading/multiprocessing.

Want many cores?

Fine, but you'll get effectively a core less than what we had a few years ago on a single cpu available.

So professors and researchers, wake up, please design a new generation language that can generate the same speed of code like C can and combine that with all kind of nice features such as C++ has for big projects.

JAVA and C#, though they fill a certain market need, are not only slow for speedy code, it's also having the object orientation problem of how to deal efficiently with RAM.

The challenge of the next generation software is to keep an oversight at a big product without slowing it down factor 10 to 100 (because of 'generic coding standards', or whatever).

Vincent Diepeveen,
Amsterdam,
The Netherlands

>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
>