Hello E. Frijters,

I would like to think that, indeed, "there are a lot of geeks that would love to participate..." (in writing GPU code). Given what has been said here in WCG (and probably elsewhere) about the perceived difficulty of GPU programming, the hoped-for participation of prospective GPU coders is unlikely, in my opinion, to take place in "production environments" like what we have here in WCG and other DC grids. While it is true that these grids do research, the tools they use to bear on the projects that is being researched are not at all research stuff. These tools and resources are, and needs to be, of production class. Put another way, GPU coding needs to be a proven, working tool/resource before any talk of using it in DC grid is even discussed.

The computing/software industry need to work on GPU programming and show results before (any) DC grid considers using it. That seems obvious but what may not be obvious is: if we can use DC itself as a tool and come up with a DC project to help the industry evolve GPU programming. :-)

Look for the graphics chip manufacturers to push some effort there. It is their chips that will get a shot at alternative uses of their ever-increasingly powerful GPU. And look for the CPU producers to try block that effort for it'll be bye-bye to the CPU when a GPU can do it all!

Hello Dmitrio

So the next question would be: what architecture would do a better job for the most number of users and/or applications.

Intel, with Larabee, bets the x86 architecture and the attendant coding there. How much of an extension could the x86 architecture take without straining from the demands of graphics processing it wasn't originally built to address AND still handle current tasks? At the other side, the GPU camp's problem is evolving GPU coding to handle the relatively easy CPU tasks alongside the graphics tasks it already handles. In other words, the battle is extension vs. evolution. My money goes to the evolution camp. Bye-bye CPU!