Linus Torvalds (torvalds@osdl.org) on 2/15/08 wrote:
---------------------------
>David Patterson (pattrsn@cs.berkeley.edu) on 2/15/08 wrote:
>>
>>* 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.
>
>Well, you basically start off by just assuming it can
>work, and that nothing else can.
>
>That's a big assumption. It's by no means something you
>should take for granted. It's a wish that hasn't come to
>fruition so far, and quite frankly, I don't think people
>are really any closer to a solution today than they were
>two decades ago.
>
>The fact that you can find application domains where it
>does work isn't new.
>
>We've had our CM-5's, we've had our Occam programs, and
>there's no question they worked. The question is whether
>they work for general-purpose computing, and that one is
>still unanswered, I think.
>
>>* 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.
>
>No, I don't think people missed that. But you simplified
>those questions down to the point where it's not clear that
>your answers matched the question any more.
>
>For example, sure, you can claim that gcc boils down to
>a "finite state machine". In a sense pretty much
>anything boils down to that (are we Turing compete
>or not?), but that doesn't really say that the dwarf would
>be at all representing what gcc really ends up doing.
>
>And one of the projects I work on is almost purely a
>"graph traversal with hashing", so it should match your
>dwarf to a T, but the thing is, the biggest issue is how
>to minimize the size of the graph you have to traverse, not
>to traverse it as fast as possible. The problem isn't CPU
>time, it's memory and IO footprint.
>
>And I don't think that is unheard of elsewhere. The core
>algorithm could well be parallelizable, but the problem
>isn't the linear CPU speed, it's the things outside
>the CPU.
>
>>Our bet is that the best applications, the best programming
>>languages, the best libraries,... have not yet been
>>written.
>
>If we are looking at a 100+ core future, I certainly agree.
>
>>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.
>
>Here's my personal prediction, and hey, it's just that: a
>guess:
>(a) we'll continue to be largely dominated by linear
>issues in a majority of loads.
>(b) this may well mean that the future of GP computing
>ends up being about small, and low power, and being
>absolutely everywhere (== really dirty cheap).
>
>IOW, the expectation of exponential performance scaling
>may simply not be the thing that we even want. Yeah,
>we'll get it for those nice parallel loads, but rather
>than expect everything to get there, maybe we should just
>look forward to improving IT in other directions than pure
>performance.
>
>If the choice becomes one of "parallel but fast machines"
>and "really small and really cheap and really low power
>and 'fast enough' ones with just a coule of cores", maybe
>people will really pick the latter.
>
>Especially if it proves that the parallel problem really
>isn't practically solvable for a lot of things that people
>want to do.
>
>Pessimistic? It depends on what you look forward to.
>
>Linus


I dug up an interesting UCLA paper on how to utilize multiple core to speed up linear workloads:

http://www.cs.ucla.edu/~reinman/mars/papers/TPDS-07-CS.pdf

-Ilya