Just adding a few cents' worth of future technology...

First, you're looking at GPU computing as specialized - it's not thanks to the "standardization" of two (or three, if you count SGI) basic platforms. However, the major difference is not "can we use a WCG work unit on a parallel architecture", but "can we EFFICIENTLY use a work unit" on such a platform. Some computations don't lend themselves to parallel processing (finite element analysis, for example). Others, such as hydro/aero simulations, thrive on it.

It seems to me that a multiple docking or molecular/atomic interaction algorithm can easily be modified to fit the parallel nature of a cell processor - but you have to look at the right level in the code: at the individual docking sequence, or the individual interaction sequence - so that each cell processes an entire sequence, comprised of all of its steps, before returning to the pot for the next piece of work. Attempting to fragment at a lower level won't yield viable results; and breaking it at a higher level means lots of work units in parallel, and long processing times (which may not be so bad either, and may be easier to implement).

The question should be expanded to include all parallel platforms that use Cell processors, including the new generation IBM Linux boxes with the hybrid compute cards, or the nVidia Tesla compute cards. I think we should stop calling it GPU processing and start calling it what it is - parallel processing. The difference with yesterday's parallel procesing: it's finally affordable. Not this year, maybe, and maybe not even next depending on world economic conditions, but as soon as the small business realizes that they can model all sorts of fun things RIGHT AT THE ENGINEER'S DESK, there will be such demand that hybrid computation units will drop into the 100-400 USD range, and everyone will develop for them, so everyone will want one. You're right, Jean, it will be two years before it's mainstream. The chicken and egg rule applies: if no one supports it, why buy it? If no one buys is, why support it?

Where does that leave WCG? On the curve, or behind it? It's not up to us the contributors. The question requires knowledge of the coding side of WCG that those of us who are mere contributors don't have access to.

It would be too bad for these researchers and these projects, though, if all that computing power went somewhere else, when there are volunteers here who want to do more. Trust me, I know just how much apathy is out there, and having an enthusiastic fan base is not an asset to ignore for too long.

Cheers
Fred
Team Captain, Homebrewers

(in my 'real' job, Principal Software Systems Architect, FLSmidth Krebs)

For CUDA computing, read Paul's GTX 295 Adventure at http://www.gpugrid.net/forum_thread.php?id=675
I had not realized that BOINC 6.4.5 was the earliest version that works.

Where, by "stable", you mean "recommended by Berkeley".

Here, we have more stringent requirements for stability. Having bugfix after bugfix is not "stable". And don't forget - if the developers hadn't virtually abandoned BOINC 6.4 in favour of working on BOINC 6.6, we would have seen more bugfixes for the 6.4 line.

This is how the WCG testing process works: http://wcg.wikia.com/wiki/BOINC_beta_testing

From project developer of GPUGRID in his post http://www.gpugrid.net/forum_thread.php?id=219:

The way we assign credits takes into account these facts.
First of all we need to measure the floating point performance of the application. We have build a performance model of our applications (CELLMD and ACEMD) by counting the number of flops manually per step. For a specific WU, we are able to compute how many total floating operations are performed in average depending on the number of atoms, number of steps and so on. For CELLMD it was also possible to verify that the estimated flops were correct within few percent from the real value (multiplication, addition, subtraction, division and reciprocal square root are counted as as a single floating-point operation). In the case of GPU, we can also use interpolating texture units instead of computing some expensive expression. In this case, as the CPU does not have anything similar, we use the number of floats of the equivalent expression. It is not easy to measure the number of integer operations, so we guess the estimated MIPS to be 2 times the number of floating-point operations (really, we reckon that it would be correct to assign up to a factor 3 times, as in the example above). Therefore,

Credits = 0.5(MFLOP per WU + approx MIPS per WU)/864,000
(MFLOP is million of floating point operations)

In addition: with a GTX 295 video card you get double these points in five hours.