Credits per unit dropped from 19.94 to 16.53 on Mac PPC G4, why?
Anonymous
15 Aug 2006 11:25:50 UTC
Topic 13409
(moderation:
Yep. We need to adjust the credit so that we stay on the same level of credit/hour as the other BOINC projects.
BM
Credits per unit dropped from 19.94 to 16.53 on Mac PPC G4, why?
)
Sorry - didn't throughly read the title...
I am working on it. The App for G5 PPC that's on our Power User page is meant as a first step.
However, I'm not much of a prophet, and if there's one thing I learned from recent coding, it's that it's almost impossible to predict the speedup a particular change would make on a certain CPU. One feature I'm desperately missing in the AltiVec / Velocity Engine (compared to SSE2 on x86) is double precision calculation. We'll see how far I can get with PPC.
BM
BM
RE: Well, Credits dropped a
)
This incredible improvement is already incorporated in the steps from the old S4 App to the first generation of S5R1 Apps (speedup of 2,5) and in the latest switch to the 4.17/4.24 Apps (10-30%). Looking at the current code Akos and I agreed that the theoretical speedup from using 3DNow! would be completely eaten up by the time it takes to switch between FPU and 3DNow! mode, so we probably won't make a special 3DNow! version.
BM
BM
RE: Please dont forget the
)
I won't forget it in the sense that I will make sure that the Apps run on it. However lacking the AltiVec Unit / Velocity Engine I doubt that I can speed up the code for it any further.
BM
BM
There are two completely
)
There are two completely different "things" you can give "credit" for:
1. The contribution of a machine, i.e. the time the CPU has spent on that project, the power of the CPU (which is not necessarily reflected in the power consumption of the machine), and maybe also the main memory or disk space. I see two problems on that approach, at least in the current BOINC framework: 1. To be fair, this would mean an individual credit for each machine; already averaging over a single workunit is injustice. 2. The information from the client (about run-time, benchmark etc.) can be wrong, may it be by accident or intention. We have seen a lot of this on Einstein@Home, and even more on SETI.
2. The contribution to the project's goal. If all WUs are of equal size, this is reflected in the number of WUs a certain machine has "crunched". On Einstein@Home we have workunits of different size, but the contribution to the project goal can easily be measured in the number of "Templates" a machine has analyzed. These "Templates" are uneaqually splitted up in workunits, but as we grant a constant credit per template, the workunits get different credits. The only thing that needs to be made sure is that credits remain more or less comparable between projects. Note that changing the overall credit level of a project doesn't affect the competition within this project at all (apart from the short transition time where some caches are more filled with "old work" than others etc.).
Because of the mentioned problems with the first possibility, on Einstein@Home we chose to implement the second (with the additional advantage of reduced redundancy).
BM
BM
RE: However, one of the
)
Thank you for your kind words!
We'll keep an eye on the credit, but from what I see currently, I think we got it right by now. The problem was that I couldn't say at first how much the optimized Apps would speed up the project on average - there are simply too many different machines. So we rather wanted to be too generous with credit for the first shot, and underestimated the speedup (I'm still a bit surprised...).
There's some code I'm currently working on for the Macs (Intel and PPC) that will give some speedup there, too, but due to the limited number of these machines in the project it won't make much of a difference to the (average) credit.
BM
BM
RE: RE: RE: Perhaps an
)
I guess, then, the question is: Do you rather want an inflation of credits or an inflation of work?
BM
BM
RE: RE: I guess, then,
)
IMHO this actually is economics.
There are two important differences:
1. "Credits" don't actually buy you anything, at least nothing of a more or less constant value (e.g. gold). There is no external reference to measure the value of a "credit" against.
2. The only thing "credits" are really useful for is competition, and as I still think the competition withing a project isn't affected.
I'd rather compare this to switching the national currencies to Euro in some states in Europe - they are simply made exchangeble. The numbers change, sometimes quite a lot, but they do change the same for prices and payment.
BM
BM
RE: You are doing 30% less
)
I doubt that the number of FLOPs really has changed much (in either direction) - they are just used more effectively. Note that averaging over all possible floating-point operations is like deriving an average travelling speed from all possible ways of human transportation. A division is so much slower than a multiplication that it might be worth to perform several multiplications in order to avoid it, actually increasing the number of FLOPs while still speeding up the program.
BM
BM