Shawn Rutledge wrote:
On 12/20/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote:
I seriously doubt that the best way to make use of all those Cell
processing units is with any kind of threading. I expect there's
probably some way to more tightly synchronize their actions, when coding
hand assembly. I'm not interested in the Cell as some kind of
architecture where you just forget about what you're doing, put stuff in
threads, and hope they perform better. That's how the XBox 360 is
designed; its threading model is coarse and conventional. I'm sure it
will be popular with developers that don't want to think much about the
architecture. I expect, however, that the Cell has capabilities that
can only be realized by writing very specifically for that
architecture. I haven't read up on the Cell enough to know what is
possible, but I will be doing so.
Yeah, makes sense.
What other kinds of constructs can you imagine in Scheme for parallel
execution, which would work better than threads?
Well I really don't think in Scheme yet, to be honest. I think in
assembly code and arrays. I'm interested in AI terrain analysis
problems for Civilization-style game maps. I would look at how to
parallelize the analysis of such a map. I'd assume that I have all 8
SPEs available to me to do so, and that my algorithm is in charge of
synchronizing them.
I would probably try to give each SPE a large, fixed quantity of work,
so that I know when the SPE will terminate its work. I call these "one
size fits all" algorithms. For instance, rather than write a bunch of
special cases for 3D matrix transforms, based on whether you've got a
3x3 matrix, or a 4x3 with a "1" coefficient in the corner, and all this
other stuff, you just code a 4x4 matrix and always use that, even for a
2x2 matrix. On a DEC Alpha in 1996, the 4x4 solution wasn't any slower
than the 2x2 solution, due to the realities of instruction pipeline
delays. I was doing the 4x4 in 16 clocks. The benefit of a "one size
fits all" algorithm is you don't waste time on conditional branching,
trying to decide what kind of case you're optimizing. Also, the code is
faster to implement and easier to maintain, because you're only doing 1
thing.
I'll also be interested in "optimizing other people's problems,"
particularly 3D graphics problems, because that's where I anticipate the
money will be. To me, this is more about looking at what you can do
with an extant codebase. I don't think, as a $$$$$ consulting service,
that I'm often going to get the chance to design a "from scratch"
architecture. Rather, someone will have written a bunch of "normal"
code for, say, a PC, a XBox, or perhaps a data server (i.e. nascent
BladeServer QS20 market). Then they'll try to port to the Cell, have
problems, and say "WTF is going on??!?" I anticipate that the solutions
to such problems are going to be ad hoc and based in engineering
pragmatism, i.e. best performance improvement for modest amount of
consulting dollars spent. In short, doing what compilers cannot
typically bring themselves to do. So part of that drill, will be
learning what the IBM compilers are actually capable of. I doubt
they're as stupid as Microsoft compilers; man, those have always been
really boring to work with. Code optimization has never been
Microsoft's profit center when working on their compiler products. I
never really got into Intel compilers. I heard they were better, but
they cost $$$, and it's not very exciting to try to optimize for x86
anyways. Not much scope for doing anything.
Today there was also this article:
http://tech.blorge.com/Structure:%20/2006/12/25/people-swapping-ps3s-for-wiis/
Some guy working at some game store wrote something on some forum
somewhere. He said, at his store, they'd get 30 Wiis in and sell 'em
out rapidly. They'd get 2 PS3s in and 1 would still be sitting on the
shelf at the end of the day. So it seems the difficulty of obtaining a
PS3 will rapidly be over with.
Cheers,
Brandon Van Every
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users