Name: Linus Torvalds (torvalds@osdl.org) 2/15/08

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