OldChap,

The concept of points is an extremely important one to me.

First let me speak to a few comments others have made:
(1) Comparing the number of points awarded between projects is meaningless since everyone benchmarks differently, and rightly should not be a reason for switching projects.
(2) Points can be a great mechanism for transparency and feedback on the crunching process; think of it like money in the Econ 101 capitalist society. Your goal should be to maximize points made, because doing so should be maximally beneficial for the science being done.
(3) It's entirely logical to not care how many points you're making, and to just take satisfaction in the payment of an electric bill every month to an ostensibly good cause, but personally I need WCG or any distributed computing project to convince me that I'm spending my money in the most-efficient way possible, and transparent point awards is a great way to accomplish that.

How would I like to see points done?
Overall, I want points to equate to science. The more points I get, the more science I've done. Note this won't necessarily mean a cure; scientists spend their whole lives amassing knowledge of what won't work, and that's just as important of a task as the home-run (but exceedingly rare) breakthrough discoveries that scientists dream of.

However, with distributed computing, meauring science done can currently take two paths.

The first path is the intuitive one, whereby (by analogy) we have 10 million boxes to open, and if we had 10 million box openers we would be done tomorrow. In this scenario, individual-box-opening speed doesn't matter; what matters is that we open more boxes. For those of you who recognize the comparison, this is what's known as a parallelized system; another analogy would be a spreadsheet of 10 million numbers, where the work done is squaring each number. Breaking that up 10 million ways works really well, because there's no interdependence of calculations, so individual speed isn't at a premium and should factor into points awarded.

The second path is the less intuitive one, and we'll think of it more like an assembly line. For example, we need to make 2 million cars, each car requiring 5 steps, for a total again of 10 million tasks; but we can't do task 2 until task 1 has been done. We could accomplish this multiple ways; we can have everyone work on task 1, then everyone work on task 2, etc. Ford or Chevrolet would never run a factory this way, and it's unlikely that scientists would run their research this way either. They need at least some cars coming off the assembly line just like scientists need preliminary results to validate / challenge their hypotheses and predictions. For those who recognize the comparison, this type of scenario is one that is not wholly parallelized, but is partially serial; like a spreadsheet with 2 million numbers that need to be squared, then halved, then have "3" added to them, then square rooted, then doubled. There are several ways to break up these 10 million tasks, but if you care about getting preliminary results (and I presume scientists do), then there is a premium on speed, because the faster the scientists can understand statistically how a batch of work is doing, the more quickly they can react either by planning more experiments if promising or by canceling proposed experiments if not. This speed-premium knowledge can be hugely important to scientists in certain cases, and so in at-least-partially serial calculations, should be factored into points awarded.
For example, a hypothetical 8-core running at 1GHz each would not get the same point per day value as a hypothetical 2-core running at 4GHz each, because although they would be completing the same number of tasks in a day (my assumption), the 2-core is getting at least some of the results back to the scientists earlier than the 8-core would be getting any results back, and this time is valuable to scientists.

I'm not hugely knowledgable about the WCG behind-the-scenes, but it seems to me that speed should, as it does for Folding@Home (via the Quick Return Bonus), factor exponentially into the points calculations. But maybe the science for WCG doesn't work that way, in which case a speed premium would be silly and inaccurate.

Tl;dr: points should tell me how much science I'm doing because transparency is key for me continuing to donate

Actually I see the current way of awarding points on validation day as the the only logical way to run the system. Otherwise you would have ever changing point totals for each day extending out to probably 15 to 16 or more days depending on how fast the wingmen complete their tasks and how quick any repair units are completed. This would require keeping keeping and updating at least a couple of week's worth of totals, rather fixing the totals at a prescribed time each day.

If you are concerned about the ups and downs of your point totals on a daily basis then I would say you are looking at the data too granularly. You could look at the information in 7 or 10 day segments or longer which would give you more stability in the figures and negate the effect of anomalous day to day changes. As an example, you would not get a very good picture of stock market trends by looking at short time segments such as minute by minute or even hour by hour, but if you looked at 30 day, 180 day or 360 day segments you would get a better overall picture of how the market has operated.

Cheers

Credit? Like.. your name on the paper?

No, like this...

@GPUGrid Run mouse pointer over will show details (ie. rank and which paper). Click on to go paper page.

This isn't Folding@Home, where next wu is built from previous result. Meaning, if you've example got an 8-core-cpu (counting HT-cores) finishing a single SMP-wu in 1 day or 8 single-core-applications finishing 8 different wu's (7 of another type) if wants to build 100 generations means a difference between 100 days for SMP and 600 days for single-core before has an answer.

Here in WCG on the other hand, wu's is normally independent, atleast within the same batch. Additionally each wu is smaller, so it would be maybe something like 1 hour/wu if SMP and 6 hour/8 wu for single-core, meaning SMP could do 24 wu/day while single-core could do 32 wu/day. If you've example got 100 millions independent wu's and 10k computers to crunch, the single-core would use 312.5 days to finish the work while SMP would use 416.67 days to finish the work. Obviously, in this instance, single-core is better than SMP, even single-core is much slower finishing an individual wu.

HCC on GPU was an extreme example of the disadvantages of having the fastest possible turnaround-times, since running a single wu/GPU you used maybe 4 minutes/wu while running multiple wu's at once used maybe 10 minutes/8 wu's. Meaning, the "slow-running" produced 3.2 times more results/day than the "fast".


With the fairly small wu's sizes here at WCG and as long as wu's is independent within a batch, it doesn't make sence to penalize the computers returning the most results/day, even if they're using many more hours before finishing their 1st. result.

A car-analogy, you can look at FAH as driving only you as fast as possible from A to B, and for this driving a porsche at 200 km/h makes sence. In WCG on the other hand, you can look at it as moving house from A to B, including all your furnitures, clothes and so on, and for this work the porsche is completely useless. A slow-going truck averaging only 50 km/h is much better for this work.