2) to create the mathematical basis for the credit system and strong rules for its use, so anybody can check or calculate the credit for any type of workunit for the project (I don't mean any other projects and cross-platform comparability yet).
Ahh. But shrinking the context for solutions is indeed the exact rub. The conundrum is partly technical and partly human nature. Not all agree on the basis for comparison. If we all had the exact same platforms we wouldn't be having this discussion. Much. Even what is labeled as a single application comes in many versions, from the same base code but compiled to different targets - OS's and processor combo's and whatnot. As discussed, various other resources that you can't compile around like available memory, swap space, CPU to GPU bandwidth etc .... all impact upon credits per whatever metric.
Try asking for consensus on a definition of 'scientific contribution', say. Others will say it is all about the billing - because they are paying for it. If you try to toss out comparisons with other projects ( if only ! ) then there has been and will be heck to pay. We've had instances where development has inadvertently/incidentally preferred platforms/combos and that required firm corrections. I do understand the yearn for some clean mathematical beauty, as I think I suggested something like this myself about 3 years ago.
To be mercenary, from the project's point of view the scientific value of a calculation is independent of the motivation for doing it. The technical value of a signal search is the same regardless of wherever you lie on the 'I luv E@H' scale. So the trick is to keep as many motivated to contribute as possible!! :-) :-)
Quote:
If all of this will be consolidated in one single place, I guess it will solved after a small discussion and will not pollute other threads anymore.
Lovely, but that presupposes a level of coherence that I've yet to see .... isn't there a parable about a man, his son and a donkey relevant here? Having said that if you'd like to fire up a thread in this vein, I'll be glad to sticky it. :-)
There is a strange dynamic that is induced with groups by the credit concept. The source of the unbalanced credit isn't basically a lack of measures, but lack of agreement on the choice of measures. There is a tendency to mask arguments that are basically those of personal gain behind other banners, or at least a tendency in some to suspect that in others. Which is all too easy since we are lightly interacting 'strangers'. In a sense this maps politics, meaning that in the end all politics becomes local. So that people generally decide based upon their immediate milieu ( what's in it for me? ) and not some unified overall view ( what fits some overarching principle, regardless of personal effects? ) . It's not evil, it's just default human behaviour.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Having said that if you'd like to fire up a thread in this vein, I'll be glad to sticky it. :-)
Good luck on that, as speaking from experience, people will post their question about this wherever they want. They'll ignore the stickies. Some will want their own thread about it. Some will post it in the first thread they come across, damn the subject on that thread. Most will not want to read through (big or little) threads that had the same subject before.
And do not touch their thread or post, or combine it with an existing one, as then they turn into threatening beings. What gave you that right, etc.?
Einstein@home is using a server-assigned credit system that is currently bound to manual adjustment. We were trying to keep average credit in sync with SETI according to the credit comparison chart, but that has gotten increasingly difficult since e.g. the introduction of GPU computing and variety of efficiency of diffrent Apps and platforms.
David Anderson is currently working on implementing a new Credit scheme that he developed with Kevin Reed (WCG) and discussed with us (Oliver and me) last October. This is meant to automatically normalize Credit between App versions, Apps and projects. I intend to adopt this for Einstein@home as soon as it can be used.
I really hope, that WCG will never be of any (credit-)relevance. The only reason they don't get resources from me beside Christmas- and Bunny-Race are their bad Linux apps. They sometimes take twice the time compared to their Windows pedants.
Years ago I cared about credits and science, nowadays I care about efficiency and science.
I wanted to create a new set of preferences and picked "school", and I wanted to uncheck both the Global Correlations tasks, but I cannot uncheck any of the bottom three choices in there...
how do I stop my computer from getting GC tasks?
These tasks lie at the core of the project. Can we ask why you wish to exclude them?
As here credits are granted server side, I use them as an efficiency detector for my computer, they are probably intra-project consistent. I do the same with my app-of-choice in CPDN because of a similar set-up.
On my machine the most efficient crunching, i.e. the most credits per hour, is done for ABP on the CPU alone, followed by ABP on CPU+GPU and short thereafter GCE.
I don't know on what machines GCE is more efficient than ABP, I just have one, but obviously they are on some machines in line in regard of C/h, otherwise I think they would have other credits sever-side.
Atm the GW work gives more C/h on all kind of AMD CPUs from Athlon XP to Phenom II, probably a consequence of Akosh's optimizations. :)
Actually I think Akos's optimizations should be of almost identical benfit for both Intels and AMDs. I think it's rather the FFT code of the ABP2 (CPU version) that seems to be performing faster on Intel Core and rather poor on AMDs. Maybe a question of optimization, but maybe it's just the bigger caches of the Intels. FFT is a challenge to implement in a cache-friendly way.
My Athlon X2 4800 crashes every GC task it gets. It runs ABP tasks just fine. I would also like to disable them for this reason.
Any ides why it will not run GC tasks??
See my results for details on my Athlon X2 4800
RE: 2) to create the
)
Ahh. But shrinking the context for solutions is indeed the exact rub. The conundrum is partly technical and partly human nature. Not all agree on the basis for comparison. If we all had the exact same platforms we wouldn't be having this discussion. Much. Even what is labeled as a single application comes in many versions, from the same base code but compiled to different targets - OS's and processor combo's and whatnot. As discussed, various other resources that you can't compile around like available memory, swap space, CPU to GPU bandwidth etc .... all impact upon credits per whatever metric.
Try asking for consensus on a definition of 'scientific contribution', say. Others will say it is all about the billing - because they are paying for it. If you try to toss out comparisons with other projects ( if only ! ) then there has been and will be heck to pay. We've had instances where development has inadvertently/incidentally preferred platforms/combos and that required firm corrections. I do understand the yearn for some clean mathematical beauty, as I think I suggested something like this myself about 3 years ago.
To be mercenary, from the project's point of view the scientific value of a calculation is independent of the motivation for doing it. The technical value of a signal search is the same regardless of wherever you lie on the 'I luv E@H' scale. So the trick is to keep as many motivated to contribute as possible!! :-) :-)
Lovely, but that presupposes a level of coherence that I've yet to see .... isn't there a parable about a man, his son and a donkey relevant here? Having said that if you'd like to fire up a thread in this vein, I'll be glad to sticky it. :-)
There is a strange dynamic that is induced with groups by the credit concept. The source of the unbalanced credit isn't basically a lack of measures, but lack of agreement on the choice of measures. There is a tendency to mask arguments that are basically those of personal gain behind other banners, or at least a tendency in some to suspect that in others. Which is all too easy since we are lightly interacting 'strangers'. In a sense this maps politics, meaning that in the end all politics becomes local. So that people generally decide based upon their immediate milieu ( what's in it for me? ) and not some unified overall view ( what fits some overarching principle, regardless of personal effects? ) . It's not evil, it's just default human behaviour.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Having said that if
)
Good luck on that, as speaking from experience, people will post their question about this wherever they want. They'll ignore the stickies. Some will want their own thread about it. Some will post it in the first thread they come across, damn the subject on that thread. Most will not want to read through (big or little) threads that had the same subject before.
And do not touch their thread or post, or combine it with an existing one, as then they turn into threatening beings. What gave you that right, etc.?
:-)
RE: And do not touch their
)
Yep, this is a huge problem of humankind :)
Nevertheless, I'll try to make a thread tomorrow, when I will not be so busy and far from home...
Regarding
)
Regarding Credit:
Einstein@home is using a server-assigned credit system that is currently bound to manual adjustment. We were trying to keep average credit in sync with SETI according to the credit comparison chart, but that has gotten increasingly difficult since e.g. the introduction of GPU computing and variety of efficiency of diffrent Apps and platforms.
David Anderson is currently working on implementing a new Credit scheme that he developed with Kevin Reed (WCG) and discussed with us (Oliver and me) last October. This is meant to automatically normalize Credit between App versions, Apps and projects. I intend to adopt this for Einstein@home as soon as it can be used.
BM
BM
I really hope, that WCG will
)
I really hope, that WCG will never be of any (credit-)relevance. The only reason they don't get resources from me beside Christmas- and Bunny-Race are their bad Linux apps. They sometimes take twice the time compared to their Windows pedants.
Years ago I cared about credits and science, nowadays I care about efficiency and science.
Both very good reason to crunch for E@H. :)
RE: RE: I wanted to
)
As here credits are granted server side, I use them as an efficiency detector for my computer, they are probably intra-project consistent. I do the same with my app-of-choice in CPDN because of a similar set-up.
On my machine the most efficient crunching, i.e. the most credits per hour, is done for ABP on the CPU alone, followed by ABP on CPU+GPU and short thereafter GCE.
I don't know on what machines GCE is more efficient than ABP, I just have one, but obviously they are on some machines in line in regard of C/h, otherwise I think they would have other credits sever-side.
Grüße vom Sänger
Atm the GW work gives more
)
Atm the GW work gives more C/h on all kind of AMD CPUs from Athlon XP to Phenom II, probably a consequence of Akosh's optimizations. :)
RE: Atm the GW work gives
)
Actually I think Akos's optimizations should be of almost identical benfit for both Intels and AMDs. I think it's rather the FFT code of the ABP2 (CPU version) that seems to be performing faster on Intel Core and rather poor on AMDs. Maybe a question of optimization, but maybe it's just the bigger caches of the Intels. FFT is a challenge to implement in a cache-friendly way.
CU
HB
schools out! (Alice
)
schools out!
(Alice Cooper)
good hard rock
just a poet
My Athlon X2 4800 crashes
)
My Athlon X2 4800 crashes every GC task it gets. It runs ABP tasks just fine. I would also like to disable them for this reason.
Any ides why it will not run GC tasks??
See my results for details on my Athlon X2 4800