much ado about credits


i'm thinking aloud:
boinc measures m/g flops (credits) based on the Whestone benchmark
http://boinc.berkeley.edu/wiki/Computation_credit

hence after running a job say for 6 hours, u get your 'Whestone' m/g flops based on 'Whestone' time consumed/duration.

if this is true this *do not reflect* the *efficiency* of rosetta@home !

i.e. those credits are not rosetta@home m/g flops but rather 'Whestone' m/g flops.

i.e. rosetta@home could literally be using modern CPU features SSE4 / AVX / AVX2 / AVX512 & is n times more efficient than that crude 'Whestone' benchmark code, but your 'earned' credits is that lousy/poorly optimised 'Whestone' credits x the run duration. e.g. rosetta@home could literally be crunching at 200Gflops AVX2 (FMA etc) while that benchmark does a poor single slow loop & give 2 Gflops. Hence, the 'claimed/earned' credit is 2 Gflops x duration. in that case instead of say 100 credits for that run, if 'real' r@h 'credits' is measured then that is 10,000 credits for that same run? :o :p lol

this could be proven via a hack on the boinc front end code to run a highly optimized e.g. SSE4/AVX version of Whestone benchmark which could possibly give much higher m/g flops, then when rosetta@home jobs are run, the 'claimed credits' would hence be *much higher*

i.e. it is *much harder* to measure the true rosetta@home gflops (true credits) than this 'dumb' Whestone gflops ('spoofed' credits) :o :p lol

That's why your claimed credit doesn't match your granted credit. As you say, if it were just based on BOINC's benchmark then the "optimised" versions of BOINC where the benchmark can use features such as AVX, would give an unreasonably high benchmark so the claimed credit would be too high.

But Rosetta grants credit based on the average claimed credit per decoy from all jobs submitted to date. So if you're the first to report, then you might get granted too much credit, but it will quickly get diluted by the reasonable credit claims from ever other machine that submitted results before yours did.

---

while it may be true that the 'claimed' credit may be deemed 'excessively' high, the way in which boinc compute credits based on the Whestone benchmark do not give merits to the computational efficiency / prowess of the different CPUs. e.g. an Whestone benchmark say optimised using vectorised codes such as SSE4/AVX/AVX2 should generate much higher gflops on a CPU capable of SSE4/AVX/AVX2 vs when the same benchmark is run on a non SSE4/AVX/AVX2 cpu.

this would produce much higher claimed credits for the same run time between a high end CPU capable of SSE4/AVX/AVX2 vs a non capable CPU.

on the other hand, all these Whestone benchmarks which is used to compute credits may well be *distinctly* different from possible optimizations in Rosetta@home codes.

i.e. it may possibly be incorrect to say that Rosetta@home codes is 'not optimised' (it may well contain automatic compiler vectorized codes SSE4/AVX/AVX2 for instance)
but all those well meaning optimizations in Rosetta@home codes would not actually give those participants with the higher end CPUs those *much higher credits* they are seeking.

This is because boinc is measuring Whestone gflops/credits and not Rosetta@home gflops/credits.


i'd guess boinc credits would need to be revised to be more reflective of actual gflops produced in running rosetta@home jobs (i.e. a measure of rosetta@home gflops / credits rather than Whestone gflops/credits)

https://boinc.berkeley.edu/trac/wiki/CreditNew

:o :p lol

Applying benchmarks to actual work is always going to be an imperfect fit. The benchmark may exploit optimizations that the work does not, or visa-versa. The only thing one can state with certainty about the difference between two machines on running a benchmark is that work that exactly matches the benchmark can be expected to perform at the same relative rate between the two machines.

The R@h system does partially reflect hardware optimizations that the science program is able to exploit. This occurs as you complete more "decoys" per unit time. For example, system A, with very little memory and L2 cache may run the benchmark at the same rate as system B which has more of each. The two may have CPUs of the same speeds and benchmark results that reflect that raw CPU speed, but system B is going to be granted R@h credits at a faster rate as it completes more decoys per unit time for the work it processes. System B completes more work per day and is granted more credit per day for the use of a machine better suited to doing the R@h work. And this existing method of issuing credit seamlessly carries forward into other future hardware/CPU optimizations as well.

The R@h credit system does a great job of granting rewards proportional to actual work completed, and how well-suited each machine is to running that work. However, it does make R@h credit an entirely different currency than other BOINC projects.

---

Rosetta Moderator: Mod.Sense

agreed with mod sense, in a way those 'gpu' gflops/credits is granted 'too losely' compared to 'hard core' projects like r@h (and many others), i.e. the gpu projects gets those 'excessively' high gflops/credits but it is possible that those gflops/credits are 'much easier' gflops/credits that cannot be realised on 'real world' complex/complicated projects like r@h. i.e. a gpu can have several thousand cores doing *basic arithmetic* and maybe some *basic bit shuffling*, that is in no way comparable to 'real jobs' running complex scientific computing. i.e. those credits are much higher simply because they are 'cheaper credits' vs 'real credits'

in addition it is also possible that the gpu credits are well in excess what is actually delivered in various boinc project tasks. i.e. the 'measured' gflops on a high end GPU may well be 1T flops for example. but actual work tasks are actually much smaller in dimensions and say use only a tiny fraction of that gpu. but the credits claimed is that 'measured' gflops x duration which give 1 T flops/credits x duration when in fact the actual work involved is *much smaller* and hardly use any of the capacity of the gpu. that in a way could explain the large differences in 'gpu' boinc projects vs non 'gpu' projects (i.e. it is possible that those 'credits' are 'spoofed' or 'much cheaper')


i.e. those GPU cores may not even be able to do a decent Whestone computation on a single GPU core, GPU cores could be even possibly be deemed 'zero' Whestone flops if they can't do so

:o :p lol