Point Rationale
22 Dec 2015 19:45:33 UTC
Topic 198352
(moderation:
This is probably in an FAQ somewhere, but I couldn't find the answer I was looking for.
This project is different than a lot of the others in that it gives a flat credit rate for work units. 693 for the Gamma Ray Pulsar search, 1000 for the BRP4G, 63 for BRP4, 4400 for the Parks PMPS XT...
Then I got two Gamma Ray work units back with 493 credit.
What is the rationale for these numbers, and why did two of them come back different than all the others I have seen? Just curious.
(I'm also really curious about why some processors seem to do better than others on a single thread that defy expectations based on floating point, clock speed, or cache)
Point Rationale
)
Here at Einstein, I believe the great majority of Work Units of a given type require essentially identical computational effort--hence the identical standard values for most work of a given type (this is quite unlike SETI work, at least the last time I contributed there). However there are edge cases for which it is known at dispatch time that the required work for a particular WU differs from the dominant case (less in all the cases I happen to have noticed or heard of), so the assigned value is less.
The stated goal of the project is to award credit on the different work types at equivalent pay rate--on average. As some processors and GPUs like some work better than others, this average goal does not give the result that an individual host will get credit at the same rate regardless of choice of work. So if more credit is a goal for you, it can pay (a little) to shop. I, personally, tend to restrict work to my hosts to a single flavor of GPU, CPU, or iGPU category, believing that the scheduler oddities are less troublesome that way than with a more mixed load. Also some particular mixed loads have performed poorly here on some particular hosts.
As to the architectural fit of particular processors (and particular compilers) to these particular tasks, I'm out of my depth there. But a simple floating point benchmark, does not capture that fit at all, and still less do clock speed and cache numbers.
In a distant previous life I did microprocessor design for a living, and more recently I assisted in their manufacture and testing, but your question is predominantly at the boundaries among the Einstein algorithms, the code details, code generation, and the hardware architecture. There are not many people with wide enough competence spans to give more than very superficial responses on that part of your post.
Look at the runtimes for the
)
Look at the runtimes for the workunits. The ones with 493 points took considerably less time to calculate than the ones awarding 693.
E@H awards points based on how much calculation is required. So workunits that require less calculations awards less points.
RE: 693 for the Gamma Ray
)
Jonathan hi
I have looked over some of my recent results and found 4 of 228 FGRP4 were lower than usual, but also took proportionally less processing time than usual
[pre]
CPUTime Credit
25512.48 665.50
13346.82 308.00
16425.74 393.00
24945.87 566.08
[/pre]
I seem to recall this had something to do with the task being a short one for some reason, boundary or missing data, but i can't find the post.
Do you have specific examples? I too would like to know what makes a good CPU cruncher for this project.
RE: What is the rationale
)
This question comes up from time to time. Bernd has answered it by referring to slicing the data into portions of equal computing size which then leaves some "short ends" - leftovers which have a lesser compute content and for which there is a correspondingly smaller crunch time estimate and credit award.
If you do an advanced search on all forums with an unlimited time limit for posts from userid=2 and use the search term short ends, you will find previous explanations like this one. Here is an extract from that link.
It comes from the end of a somewhat longer post which was largely about other issues just after the start of the issuing of much larger tasks in the FGRP2 run. Even though we are now on FGRP4, there is always going to be the same issue of leftover bits when cutting up the data.
Around a week ago, tasks based on the data file LATeah0138E.dat commenced being issued. The "short ends" seem to be issued first and are more prevalent when a new data file first starts to be used. I do remember seeing some of them at that time. Purely by chance, I've noticed (within the last hour) the first tasks for the next data file LATeah0139E.dat starting to be issued. So I had a look and found a host of mine that has just downloaded new FGRP4 tasks based on the new data file. It got 8 tasks - all short ends about 1/6 of normal estimate.
Cheers,
Gary.
Thanks! That was really
)
Thanks! That was really helpful. My computing time varies wildly between different computers I am using, and even on the same machine, but I still always got the same credit until recently. This makes sense.
I was also trying to figure out how the amount awarded is rationalized (why 693? Why 4400? Why is a PMPS XT worth so much more than a FGRP?) I assume this is because one is more crucial to the research the team is doing at the time or something. I work in strategy, so I was wondering if this had to do with the incentives and metrics used to drive our production here, maybe even compete with other projects to attract people with the hardware to accelerate particular projects?
Thanks for all of the replies and providing fodder for my curiosity about how the project works!
RE: I was also trying to
)
I'll repeat the answer I gave you earlier
Personally, I'd support the project if it decided to nudge us toward one type or another by credit, but I believe they instead do this when they wish by controlling relative work dispatch rates.
RE: Why is a PMPS XT worth
)
Because a PMPS XT (or as I call them BRP6) workunit requires much more calculations than a FGRP workunit.
If BRP6 workunits paying 4400 would be calculated using the CPU (like FGRP is) they would take forever to finish. Instead they are calculated on a GPU which is *much* faster than a CPU.
RE: I was also trying to
)
It's not at all to do with 'buying' participation in a particular science run by awarding disproportionate credit. It's all to do with the perception of a fair 'return' for the work completed.
As each new run starts, the Devs work out an average for the theoretical change in 'compute content' and adjust the credit award by the equivalent amount. This is not as simple as it first seems because each different 'platform' has the potential to react somewhat differently to the change. Some architectures do better than others at handling the new app. So when there are substantial changes in content, the Devs will use the initial results from the different architectures to work out a new average compute content. This may require tweaking of the credit awards in order to come up with a compromise that will be 'fairer to all'.
This project has been running for almost 11 years and for a long time there were CPU apps only. Before GPU apps were developed, the Pulsar searches were performed on CPUs and a particular credit award was established in the normal way. When GPU apps were first deployed and were found to be so much faster, GPU tasks were constructed by 'bundling' the CPU tasks. The credit award was simply scaled by the bundling factor.
You can see an example of this sort of thing in the link I posted in my previous message. If you read a bit more of that thread, you will see it was to do with bundling (by a factor of 11) FGRP2 tasks (which were even quite short running on CPUs) in preparation for a GPU app. Short running tasks put a huge strain on project servers. If a CPU task was taking an hour or two (as those ones were) you could imaging the problems dealing with GPU tasks potentially turning around every couple of minutes. The short CPU tasks were being awarded 63 credits so the new bundled tasks were awarded 693 (factor of 11). This size is still in use today and modern processors can do these tasks quite quickly (around 5 hours). The FGRP GPU app was trialed but was withdrawn until it is further developed and more efficient.
No, there has never been any suggestion that Einstein tries to leverage the credit award system to 'buy' participation. I think that if you look at any projects that do award ridiculous amounts of credit, you will find they tend to have very low participation rates. People genuinely interested in the science outcomes will not be attracted away by 'worthless' credit. They are much more likely to be attracted by the prospect of 'recognition' that comes from your host being involved in a genuine scientific discovery.
Einstein leverages this 'recognition'. Volunteers really value the certificates awarded for pulsar discoveries. If you look at how many new pulsars have been discovered, even when a lot of the data has previously been trawled by the original 'owners', you can understand why this project doesn't have to resort to subterfuge to attract volunteers. It will be very interesting to see the public reaction when advanced LIGO data is available and the first detection of gravity waves occurs, hopefully sometime in 2016 :-).
Cheers,
Gary.
That's all well and good sir,
)
That's all well and good sir, but this project awards far more credit for the same CPU time *or* GPU time than SETI and Rosetta (of which I also actively participate).
I'm not being critical of this, but I do wonder if the competitive spirit draws some here instead of some of those other projects because they perceive they are doing more. I'll admit, I check out how I am doing in comparison to others on Boincstats, but I would be doing this anyway. But the numbers do help me benchmark my machines and help me allocate resources to these projects more efficiently.
RE: That's all well and
)
According to BOINC wiki an old definition of a credit exists. I suspect this definition may pre-date SSE2, some old-timers may know more.
However we have a conundrum, as processors become more capable over time they can perform an array of calculations with a single command, and have on chip functions, both give huge speed advantage. Then the size and effect of memory caches further muddies the water.
So compile an application without SSE2 for example and it will take longer on the same processor. How much longer? - it depends on the application. Designed well - a lot i would expect.
A counter wonderment might be, do some projects optimise their algorithms to use resources better than others?
In any regard - it's all relative and as long as you have roughly consistent over time - within project - it matters little. It has no effect on scheduling.
It's not credit that attracts me, and i expect this is true for others, it's the cool science on real data, with a good chance of real discoveries, and backed by solid project infrastructure and people.