All BOINC projects allow clients to claim credit based on the formula:
claimed credit = benchmark score * cpu time
The granted credit is calculated by taking all the people whose results were valid for a particular workunit, throwing out the high and low claimed credits, and averaging the rest. Everyone with valid results receives the same number of credits --- the average of what people claimed.
So, if you are running a very fast SETI client, your cpu time will be low, and you will have a low claim. You will likely be thrown out of the calculation because you are the low claimant. But do not fear-- you will still receive the average. Nevertheless, it may be irksome that you are claiming so little. Perhaps you feel that you deserve to claim more.
The reason you are claiming so little is because the tricks that I've used in the SETI program are really not being used in the BOINC benchmark program. However, this is somewhat unfair. The benchmark programs measure standard calculations, including trig functions, exponentiation, logs, division, string copies, function references, etc.
If the SETI client speeds those functions up, then so should the benchmark. I feel that it is completely moral to use the same methods in the benchmark code that are being used in the SETI code, because the purpose of the benchmark is to see how fast you will crunch your SETI workunit. Indeed, if you used a slow sine function in the benchmark and a fast one in SETI, then that would be misleading, wouldn't it? The benchmark should serve notice to the SETI project of how fast you intend to crunch your workunit.
Up to a point. SETI has made the decision to use dhrystone and
whetstone, and we must respect the rules of those benchmarks. Whetstone
is double precision, but SETI is single precision. I would like to
replace the double precision math of the whetstone benchmark with
single precision, but I don't think that is morally acceptable, because
SETI has decided to use Whetstone, and we have to respect that.
Similarly, dhrystone is a very
well-studied benchmark and I feel that I have to respect the rules
that have been set down regarding this benchmark. In particular, it
is not allowed to combine the two files, dhrystone.C and dhrystone2.C.
This is really a shame, because the speedup is huge.
However, the Intel C-compiler is so aggressive, that its inter-procedural optimization effectively does combine the files, and there is no difference in the speed when you actually do combine the source files. The GNU C-compiler is not quite to that point. If you specifically tell it to combine the files at compile time, it will essentially do that, but I feel that is cheating. This is the moral quandry. Do what you want. I'm providing three programs.
| boinc_naparst_p4.bz2 | For Pentium 4. Not totally statically linked. If you can't run this, let me know. Linking with ICC is difficult! |
| boinc_amd64_moral.bz2 | Statically linked, for 64-bit Linux. |
| boinc_amd64_immoral.bz2 | With dhrystone files combined. Not allowed. |
To install these programs, unzip them to your boinc directory with bunzip2 boinc_naparst_p4.bz2, stop the boinc process that you have running, and then restart it with the new binary. It sometimes helps to remove the files beginning with cli* and sch*, as well as any lockfiles.
Please note that these are not the fastest programs that one could
create. If you wanted to cheat, you could do all sorts of things. You
could inline functions, use reduced precision, or even just have the
functions return whatever you think you deserve to claim! You could add
an --i-deserve flag to the binary. I'm not into that. But the
source is public, so do what you want.