> Repeat after me: "it depends on your problem". Some (many) codes will
> bite. Some will run like rabid foxes on meth.
Yes. My assertion is that for most interesting real-world problems, the
Cell isn't a good fit.
> It's time to dive into the parallel programming model. If you can't
> state your problem in terms of asynchronous message passing (not just
> threads), you've got a problem on your hands that will only get
> worse with time.
In the real world, I think this is mostly wrong. Remember your constraints:
programmers (especially good ones) are extremely rare and expensive. Fast
computers are not. Unless your problem is truly massive (Google-scale), you
should be optimizing for programmer productivity rather than FLOPS / $.
That means using as little parallelism as possible. In most cases, that
means no parallelism at all-- a modern CPU can handle an astonishing amount
of work, if well programmed.
If you must use parallelism, I assert (and it sounds like you agree) that a
message-based architecture is very often a better choice than a
multi-threaded one, purely because it's easier to work with.
Multi-core architectures are obviously the future. My objection is to the
specifics of the Cell architecture, which makes trade-offs around symmetry
and memory access which I (and many others) consider very sub-optimal for
most real-world applications.
You're right that current CPU architectures have serious issues with memory
latency, and that managing those issues effectively is part of what
separates good from mediocre programmers. The problem is that those issues
look to be much more severe on the Cell than on competing architectures.
There's another real-world issue with the Cell, which has to do with
lifecycle. The very strong consensus in the gaming community is that to
write a decent PS3 app, you'll need to throw away all your existing code and
start from scratch. The first generation of apps will probably be
profoundly mediocre, as developers take time to get a feel for the new
architecture. The lifetime of the architecture will be about 5 years, at
the end of which time all code written for it is almost certain to be a dead
end. That's painful but survivable if you're in the console games business.
It's a disaster if you're in the AI business (unless your timeframe for a
seed AI is < 5 years...)
This is another example of Sony optimizing for the wrong problem-- they're
maximizing theoretical FLOPS at the expense of real-world programmer
productivity.
Don't get me wrong-- I make my living writing massive distributed
applications. When you have to parallelize, you have to parallelize. But
you should do so in a very thoughtful and deliberate manner.
-mattb
-------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
