As much as I like stats sites like Boincstats, they kind of raise expectations that cross-project parity is a natural thing. Nobody would add 100 $ + 200 € + 300 Yen to add up to 600 something, cobblestones are added, averaged, compared cross-project all the time.
Look at Einstein@Home: The performance of the stock Linux app on a (say) Core2Duo has very roughly doubled since the start of the S5R3 run, in several steps of 10% to 20 % performance increases. Should the credit/unit have been reduced with every new app? But some CPUs get more out of the new apps than other ones, so some users might then see reduced RAC for their hosts even if they continue to crunch along like before. I think if productivity increases because of better apps, the users should see their RAC increase. After all, trying out new apps and seeing progress is all part of the fun here, isn't it?
OTOH, whether you like it or not, users are attracted by high credits/CPU hr ratios, so a certain "fairness" between the projects has to be observed.
It's a difficult matter. In my view, it's ok to adjust the credits to a reasonable level (say) once "run" or once per year.
Don't get me wrong, I'm not asking for anyone to do anything. The question was raised, and I'm showing what I'm seeing. Trust me I know the complication, reasons, excuses, credit inflation spirals, optimization arguments and such.
I'd like someone to tell me what resource share I can set for my top six projects so that I can end up with each at 600K at roughly the same time. Aside from manually fetching work, endless adjustments to resource share etc. My goal is to equalize credit for the top 6 on pie chart to the same credit at 600K.
Using resource share used to be pretty close(back before optimized boinc clients when seti, predictor, LHC and einstein started), but is no longer anywhere near close.
Don't get me wrong, I'm not asking for anyone to do anything. The question was raised, and I'm showing what I'm seeing. Trust me I know the complication, reasons, excuses, credit inflation spirals, optimization arguments and such.
I know you're a staunch advocate of cross-project parity, despite your statements that it is futile... :-P
I'd ask you to consider that despite that Boinc Combined Stats page that claimed that Einstein and SETI were within 3% of each other for a very long time, the truth of the matter for my AMD system for all of S5R2 was that Einstein work was yielding 30-50% less than SETI. This was because of the AMD penalty that the compiler caused.
My point is that stat routinely showed Einstein as like 1.03-1.05 times SETI, but the reality for me was quite different...
I am running a few tasks over at SETI right now to see what the current comparison comes out to be. I have a feeling Einstein will be about 1.25x SETI, which if we keep to David Anderson's wishes, is only very slightly over the "allowed variance"... This comes after continuing S5R3 at about 10-20% disadvantage over SETI, again despite claims to the contrary by the chart that David loves to reference...
I am running a few tasks over at SETI right now to see what the current comparison comes out to be. I have a feeling Einstein will be about 1.25x SETI
Well, I've been out of the SETI game for quite some time, so I don't know if what I got was a low yield or not (I think it is), but anyway:
SETI: 72.26 Claimed Credit @ 9251 seconds, or 28.12 cr/hr.
Einstein: 236.53 credit @ 20041 seconds, or 42.49 cr/hr.
Advantage: Einstein (1.51 x SETI)
Like I said, I think that particular AR at SETI was one of the lower yielding ARs, as I remember several claims up in the 32-38 cr/hr range back when I was more active...
Anyway, if you follow the logic that runtimes here at Einstein were at least double for me before all the improvements that have been included into the Windows app lately, we do the comparison as:
236.53 @ 40100 seconds = 21.23 cr/hr, which means, if I'm correct about that SETI task being a low-yield task, before the changes here, SETI was at least about 1.33 x Einstein, when viewed from my perspective, despite the fact that the illustrious chart at BOINC Combined Statistics always had Einstein within 3-5% of SETI.
IOW, that chart doesn't tell the truth all the time... That's the main point I'm trying to get across...
I am running a few tasks over at SETI right now to see what the current comparison comes out to be. I have a feeling Einstein will be about 1.25x SETI
Well, I've been out of the SETI game for quite some time, so I don't know if what I got was a low yield or not (I think it is), but anyway:
SETI: 72.26 Claimed Credit @ 9251 seconds, or 28.12 cr/hr.
Einstein: 236.53 credit @ 20041 seconds, or 42.49 cr/hr.
Advantage: Einstein (1.51 x SETI)
Like I said, I think that particular AR at SETI was one of the lower yielding ARs, as I remember several claims up in the 32-38 cr/hr range back when I was more active...
Anyway, if you follow the logic that runtimes here at Einstein were at least double for me before all the improvements that have been included into the Windows app lately, we do the comparison as:
236.53 @ 40100 seconds = 21.23 cr/hr, which means, if I'm correct about that SETI task being a low-yield task, before the changes here, SETI was at least about 1.33 x Einstein, when viewed from my perspective, despite the fact that the illustrious chart at BOINC Combined Statistics always had Einstein within 3-5% of SETI.
IOW, that chart doesn't tell the truth all the time... That's the main point I'm trying to get across...
I think you did actually get it right there with your ", when viewed from my perspective,".
If you do have a look at the Project granted credit comparison it is now showing Einstein v Seti at 1.146.
So when Ver 4.36 comes out of Beta and into mainstream I assume there will be a reduction in credits.
One other observation cr/hr here can vary +/- 10% depending on wether unit is in dip or at peak compared to average. You really do need to make full analysis before publishing results.
IOW, that chart doesn't tell the truth all the time... That's the main point I'm trying to get across...
I think you did actually get it right there with your ", when viewed from my perspective,".
C'mon Andy... Why can't you just follow the logic instead of being mystified by the numbers? Also, my perspective is the one that matters to me, and I'm not seeing how relating it to other people's experience makes my factual observations invalid...
Quote:
If you do have a look at the Project granted credit comparison it is now showing Einstein v Seti at 1.146.
So when Ver 4.36 comes out of Beta and into mainstream I assume there will be a reduction in credits.
...and it is my assertion that a recalibration of the cr/hr when SSE is enabled (assuming they get the wrapper working properly) to SETI's stock app is deflationary and makes it to where the cr/hr advantage tips back to migrating back over to SETI and using the anonymous platform apps.
IOW, if they recalibrate x87 to the stock app, then that might be close, but since the bulk of the hosts here will be able to use SSE, in order to keep David happy, the work that Bernd and Akos (and others) put in will end up being disproportionately devalued.
Meanwhile, back at the ranch, the optimized app over at SETI then returns to a substantial performance advantage.
You can argue all you want about how "most users don't use the optimized apps", but for those of us that do, the supposed "parity" is utter hogwash the way that it has been done in the past. If you want real parity, then both the x87 code and the SSE code need to yield relatively close cr/hr values when compared to their respective SETI counterparts!!!! Calibrating to one of the two is just not going to be sufficient in regards to ALL potential users.
Quote:
One other observation cr/hr here can vary +/- 10% depending on wether unit is in dip or at peak compared to average. You really do need to make full analysis before publishing results.
Finally, don't you think I know that?!?!?! Do you really think I was clueless when giving Mike advice on Ready Reckoner changes to make it user friendlier? Do you really think I didn't check for an average value out of my current result list? Did you not notice that I nearly always have relatively wide margin of error padding?
Yes, I'm quite tired of being inferred to be a clueless boob...
IOW, that chart doesn't tell the truth all the time... That's the main point I'm trying to get across...
I think you did actually get it right there with your ", when viewed from my perspective,".
C'mon Andy... Why can't you just follow the logic instead of being mystified by the numbers? Also, my perspective is the one that matters to me, and I'm not seeing how relating it to other people's experience makes my factual observations invalid...
Quote:
If you do have a look at the Project granted credit comparison it is now showing Einstein v Seti at 1.146.
So when Ver 4.36 comes out of Beta and into mainstream I assume there will be a reduction in credits.
...and it is my assertion that a recalibration of the cr/hr when SSE is enabled (assuming they get the wrapper working properly) to SETI's stock app is deflationary and makes it to where the cr/hr advantage tips back to migrating back over to SETI and using the anonymous platform apps.
IOW, if they recalibrate x87 to the stock app, then that might be close, but since the bulk of the hosts here will be able to use SSE, in order to keep David happy, the work that Bernd and Akos (and others) put in will end up being disproportionately devalued.
Meanwhile, back at the ranch, the optimized app over at SETI then returns to a substantial performance advantage.
You can argue all you want about how "most users don't use the optimized apps", but for those of us that do, the supposed "parity" is utter hogwash...
Quote:
One other observation cr/hr here can vary +/- 10% depending on wether unit is in dip or at peak compared to average. You really do need to make full analysis before publishing results.
Finally, don't you think I know that?!?!?! Do you really think I was clueless when giving Mike advice on Ready Reckoner changes to make it user friendlier? Do you really think I didn't check for an average value out of my current result list? Did you not notice that I nearly always have relatively wide margin of error padding?
Yes, I'm quite tired of being inferred to be a clueless boob...
[/rant]
Fine if that is what you think but by the same token, because of all the optimisations that have been made available from the volunteer programmers then the cr/hr at Seti should be about 10 times what it is now. And you would probably ranting on wanting Einstein or any other project to raise their level to be equal to Seti's.
Andy
At approx the same AR times for Seti v5.xx have decreased from 50ksec to 15ksec on the same computer at Seti Beta using default applications. And using the optimised app on Seti has now reduced that to 9.2ksec.
Fine if that is what you think but by the same token, because of all the optimisations that have been made available from the volunteer programmers then the cr/hr at Seti should be about 10 times what it is now. And you would probably ranting on wanting Einstein or any other project to raise their level to be equal to Seti's.
Andy,
Please state true or false on your perceived equality given the following scenarios:
What I think amounts to "parity" is when both A and D are true, not when only A is true or only D is true...and it certainly is not B or C, even though B has "the same numeric value" twice...
Fine if that is what you think but by the same token, because of all the optimisations that have been made available from the volunteer programmers then the cr/hr at Seti should be about 10 times what it is now. And you would probably ranting on wanting Einstein or any other project to raise their level to be equal to Seti's.
Andy,
Please state true or false on your perceived equality given the following scenarios:
What I think amounts to "parity" is when both A and D are true, not when only A is true or only D is true...and it certainly is not B or C, even though B has "the same numeric value" twice...
A is the only true answer. B & C definitely not true, D has to be complete unknown. But if either app in D were to be made stock app then it must be substituted into A.
True cross project parity can only come about when all projects apps are fully optimised and produce the same average cr/hr on all computer systems.
That means that some computer system may see better on some projects than others whilst a different computer system may see the opposite. (That was certainly true for Seti, pre-enhanced v Einstein S5R1 with regard to Intel (large L2) v AMD & Intel celeries.)
D has to be complete unknown. But if either app in D were to be made stock app then it must be substituted into A.
See, that's where this wrapper thing that Bernd is working on would allow them to bundle both codepaths / apps in a single version. If it works out, x87 optimizations, which would equate to stock SETI, would be called if the processor support wasn't there for the SSE version, which would equate to the anonymous platform apps (optimzed SETI).
Since it is all bundled in one, if the credit target for the SSE side is set for the x87 (stock) SETI app, then you are not comparing apples to apples...
(or penguins to penguins...see your PM...and sorry for the length)
Hi! As much as I like
)
Hi!
As much as I like stats sites like Boincstats, they kind of raise expectations that cross-project parity is a natural thing. Nobody would add 100 $ + 200 € + 300 Yen to add up to 600 something, cobblestones are added, averaged, compared cross-project all the time.
Look at Einstein@Home: The performance of the stock Linux app on a (say) Core2Duo has very roughly doubled since the start of the S5R3 run, in several steps of 10% to 20 % performance increases. Should the credit/unit have been reduced with every new app? But some CPUs get more out of the new apps than other ones, so some users might then see reduced RAC for their hosts even if they continue to crunch along like before. I think if productivity increases because of better apps, the users should see their RAC increase. After all, trying out new apps and seeing progress is all part of the fun here, isn't it?
OTOH, whether you like it or not, users are attracted by high credits/CPU hr ratios, so a certain "fairness" between the projects has to be observed.
It's a difficult matter. In my view, it's ok to adjust the credits to a reasonable level (say) once "run" or once per year.
CU
Bikeman
Don't get me wrong, I'm not
)
Don't get me wrong, I'm not asking for anyone to do anything. The question was raised, and I'm showing what I'm seeing. Trust me I know the complication, reasons, excuses, credit inflation spirals, optimization arguments and such.
I'd like someone to tell me what resource share I can set for my top six projects so that I can end up with each at 600K at roughly the same time. Aside from manually fetching work, endless adjustments to resource share etc. My goal is to equalize credit for the top 6 on pie chart to the same credit at 600K.
Using resource share used to be pretty close(back before optimized boinc clients when seti, predictor, LHC and einstein started), but is no longer anywhere near close.
RE: Don't get me wrong, I'm
)
I know you're a staunch advocate of cross-project parity, despite your statements that it is futile... :-P
I'd ask you to consider that despite that Boinc Combined Stats page that claimed that Einstein and SETI were within 3% of each other for a very long time, the truth of the matter for my AMD system for all of S5R2 was that Einstein work was yielding 30-50% less than SETI. This was because of the AMD penalty that the compiler caused.
My point is that stat routinely showed Einstein as like 1.03-1.05 times SETI, but the reality for me was quite different...
I am running a few tasks over at SETI right now to see what the current comparison comes out to be. I have a feeling Einstein will be about 1.25x SETI, which if we keep to David Anderson's wishes, is only very slightly over the "allowed variance"... This comes after continuing S5R3 at about 10-20% disadvantage over SETI, again despite claims to the contrary by the chart that David loves to reference...
RE: I am running a few
)
Well, I've been out of the SETI game for quite some time, so I don't know if what I got was a low yield or not (I think it is), but anyway:
SETI: 72.26 Claimed Credit @ 9251 seconds, or 28.12 cr/hr.
Einstein: 236.53 credit @ 20041 seconds, or 42.49 cr/hr.
Advantage: Einstein (1.51 x SETI)
Like I said, I think that particular AR at SETI was one of the lower yielding ARs, as I remember several claims up in the 32-38 cr/hr range back when I was more active...
Anyway, if you follow the logic that runtimes here at Einstein were at least double for me before all the improvements that have been included into the Windows app lately, we do the comparison as:
236.53 @ 40100 seconds = 21.23 cr/hr, which means, if I'm correct about that SETI task being a low-yield task, before the changes here, SETI was at least about 1.33 x Einstein, when viewed from my perspective, despite the fact that the illustrious chart at BOINC Combined Statistics always had Einstein within 3-5% of SETI.
IOW, that chart doesn't tell the truth all the time... That's the main point I'm trying to get across...
RE: RE: I am running a
)
I think you did actually get it right there with your ", when viewed from my perspective,".
If you do have a look at the Project granted credit comparison it is now showing Einstein v Seti at 1.146.
So when Ver 4.36 comes out of Beta and into mainstream I assume there will be a reduction in credits.
One other observation cr/hr here can vary +/- 10% depending on wether unit is in dip or at peak compared to average. You really do need to make full analysis before publishing results.
Andy
RE: RE: IOW, that chart
)
C'mon Andy... Why can't you just follow the logic instead of being mystified by the numbers? Also, my perspective is the one that matters to me, and I'm not seeing how relating it to other people's experience makes my factual observations invalid...
...and it is my assertion that a recalibration of the cr/hr when SSE is enabled (assuming they get the wrapper working properly) to SETI's stock app is deflationary and makes it to where the cr/hr advantage tips back to migrating back over to SETI and using the anonymous platform apps.
IOW, if they recalibrate x87 to the stock app, then that might be close, but since the bulk of the hosts here will be able to use SSE, in order to keep David happy, the work that Bernd and Akos (and others) put in will end up being disproportionately devalued.
Meanwhile, back at the ranch, the optimized app over at SETI then returns to a substantial performance advantage.
You can argue all you want about how "most users don't use the optimized apps", but for those of us that do, the supposed "parity" is utter hogwash the way that it has been done in the past. If you want real parity, then both the x87 code and the SSE code need to yield relatively close cr/hr values when compared to their respective SETI counterparts!!!! Calibrating to one of the two is just not going to be sufficient in regards to ALL potential users.
Finally, don't you think I know that?!?!?! Do you really think I was clueless when giving Mike advice on Ready Reckoner changes to make it user friendlier? Do you really think I didn't check for an average value out of my current result list? Did you not notice that I nearly always have relatively wide margin of error padding?
Yes, I'm quite tired of being inferred to be a clueless boob...
[/rant]
RE: RE: RE: IOW, that
)
Fine if that is what you think but by the same token, because of all the optimisations that have been made available from the volunteer programmers then the cr/hr at Seti should be about 10 times what it is now. And you would probably ranting on wanting Einstein or any other project to raise their level to be equal to Seti's.
Andy
At approx the same AR times for Seti v5.xx have decreased from 50ksec to 15ksec on the same computer at Seti Beta using default applications. And using the optimised app on Seti has now reduced that to 9.2ksec.
RE: Fine if that is what
)
Andy,
Please state true or false on your perceived equality given the following scenarios:
A: SETI stock app granting 20 cr/hr, Einstein stock app granting 20 cr/hr.
B: SETI stock app granting 20 cr/hr, Einstein optimized app (SSE) granting 20 cr/hr.
C: SETI anonymous platform app granting 30 cr/hr, Einstein optimized app (SSE) granting 20 cr/hr.
D: SETI anonymous platform app granting 30 cr/hr, Einstein optimized app (SSE) granting 30 cr/hr.
I'll go ahead and give you a secret:
What I think amounts to "parity" is when both A and D are true, not when only A is true or only D is true...and it certainly is not B or C, even though B has "the same numeric value" twice...
RE: RE: Fine if that is
)
A is the only true answer. B & C definitely not true, D has to be complete unknown. But if either app in D were to be made stock app then it must be substituted into A.
True cross project parity can only come about when all projects apps are fully optimised and produce the same average cr/hr on all computer systems.
That means that some computer system may see better on some projects than others whilst a different computer system may see the opposite. (That was certainly true for Seti, pre-enhanced v Einstein S5R1 with regard to Intel (large L2) v AMD & Intel celeries.)
Andy
RE: D has to be complete
)
See, that's where this wrapper thing that Bernd is working on would allow them to bundle both codepaths / apps in a single version. If it works out, x87 optimizations, which would equate to stock SETI, would be called if the processor support wasn't there for the SSE version, which would equate to the anonymous platform apps (optimzed SETI).
Since it is all bundled in one, if the credit target for the SSE side is set for the x87 (stock) SETI app, then you are not comparing apples to apples...
(or penguins to penguins...see your PM...and sorry for the length)