The recent devaluation has negative implications. It certainly discourages the working class as we now must produce 30% more work for the same pay.
You are doing 30% less work, also. The amount of flops were decreased because they took out redundency. So your workload is lessened, also. You do the work faster, because there is less to do.
So, the crediting system remains constant.
If I am paid an hourly wage, doing a job I would do in 30 minutes or 16 items a day (considering an 8 hour day). Someone came along and fixed something so now I could do the job in 20 minutes or 24 items a day, I am only paid for the time I do my job. I am doing the same job, but now I do more in less time, so I am paid less for that item. I do more work in a day, so at the end of the day I am still paid the same. It's simple math. Per hour is the same rate, but now you do more work in that hour, with less repetitive moves.
From Bernd: More than 90& (99% before optimization) of the run time is spent within a single loop that once had about a dozen lines of C-Code, containing only simple multiplications and additions (and the very vew divisions we coudn't avoid - I think there's actually only one of them left - hm, gives me another idea...). We have parallized/vectorized as much as we could.
Sounds like he removed a lot of unnecessary looping, eg: less flops needed to get to the same result.
I guess, then, the question is: Do you rather want an inflation of credits or an inflation of work?
I saw an earlier post which (I think sarcastically) suggested that someone could do a PhD thesis on the credits issue. My immediate thought was: It should be in the field of Economics. (If you think about it, the parallels are many.)
IMHO this actually is economics.
Quote:
So with regard to your question about inflation, I believe we should strive for "price stability" and that our "currency" should be tied to the production of science. If we can expand the economy by improving productivity, that is not inflationary. The recent devaluation has negative implications. It certainly discourages the working class as we now must produce 30% more work for the same pay.
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.
You are doing 30% less work, also. The amount of flops were decreased because they took out redundency. So your workload is lesse
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.
So far so well, 30% less work result in 30% less payment. By whatever optimizations always. Then we could have remained just as well with the old Credit system, regulated that dynamically. Less CPU time of fewer Credits.
But then there is no optimizations in the sense that the CPU uses more SSE2 or SSE3 but simply only flops savings. Then you have also in such a way written could. I speak here simply times for all others, because we assumed that, which is only faster done the SAME work by optimizations. Now the credit drop make sense in my eyes.
P.S.
Sorry for the terrible grammar, this kind of text is to strengh for my school english so google helped me.
Here's one viewpoint stated in a different way: You are a carpenter and are hired by a home builder to install nails into wood frames. You're given a hammer and told to pound nails and you will be paid a fixed amount of money each hour you pound nails. The homebuilder decides that pounding nails with a hammer is not as productive as using a pneumatic nail gun and decides to give you one. Now you're installing 4x more nails per hour by simply using a different tool (v4.24 instead of v4.02) provided by the home builder. The result is more installed nails (WUs) per hour but the pay/hour is the same as established by the project. Therefore, the credit per WU must be reduced accordingly since the throughput is higher. This is the fixed credit/hour scenario.
OTH, if I am paid according to the number of nails I install -- regardless of the tool used or who provides it -- then the faster I pump out WUs the more credit I should receive. This, afterall, is the goal. So regardless of the version of science app I should be paid credit based on the number of WUs I process -- faster machines mean more WUs/hour and more credit/hour. Each WU must be assigned a value based on units of work contained within it. Bernd refers to this unit of work as a template. Seems fair to me not having any further information.
Seems fair to me that if the project staff provides a faster science app then they have the right to reduce the credits given per WU since the science app will allow a given machine to output more WUs/hour. The User oth provides the host and, therefore, a faster host means more WU/hour and more credit/hour.
I'm sure these analogies are flawed and can be dissected; please do so.
But, the recent rule change (the devaluation) implies a subtle, yet important, difference in points of view. Are contributing to the advancement of science? Or, are we merely donating computer time?
Here's one viewpoint stated in a different way: You are a carpenter and are hired by a home builder to install nails into wood frames. You're given a hammer and told to pound nails and you will be paid a fixed amount of money each hour you pound nails. The homebuilder decides that pounding nails with a hammer is not as productive as using a pneumatic nail gun and decides to give you one. Now you're installing 4x more nails per hour by simply using a different tool (v4.24 instead of v4.02) provided by the home builder. The result is more installed nails (WUs) per hour but the pay/hour is the same as established by the project. Therefore, the credit per WU must be reduced accordingly since the throughput is higher. This is the fixed credit/hour scenario.
OTH, if I am paid according to the number of nails I install -- regardless of the tool used or who provides it -- then the faster I pump out WUs the more credit I should receive. This, afterall, is the goal. So regardless of the version of science app I should be paid credit based on the number of WUs I process -- faster machines mean more WUs/hour and more credit/hour. Each WU must be assigned a value based on units of work contained within it. Bernd refers to this unit of work as a template. Seems fair to me not having any further information.
Seems fair to me that if the project staff provides a faster science app then they have the right to reduce the credits given per WU since the science app will allow a given machine to output more WUs/hour. The User oth provides the host and, therefore, a faster host means more WU/hour and more credit/hour.
I'm sure these analogies are flawed and can be dissected; please do so.
So the question is, should we be "paid" hourly or by activity based compensation? Based on the nature of the work we do, I think that compensation based on actual production is most fair. I see no reason why my 1.25 GHz G4 should be rewarded at the same rate as a quad 2.5 GHz G5. The G5 owner has invested far more financially in their machine, and is paying more to run it in energy consumption. That person should be rewarded accordingly.
If the project supplies the tool allowing greater efficiency, they should be allowed to adjust the compensation to keep their "costs" level. If the user supplies the tool that allows greater efficiency, they should receive the greater compensation they have earned. If a more efficient open source worker is created by the users, than they should reap the benefits. However, the project should have the right to say what tools can & cannot be used to do the work. It is after all their project.
I see no reason why my 1.25 GHz G4 should be rewarded at the same rate as a quad 2.5 GHz G5. The G5 owner has invested far more financially in their machine, and is paying more to run it in energy consumption. That person should be rewarded accordingly.
I think the G5 (per one CPU) will get more work done and should get more credits total per hour. I hope it does, if it doesn't something is very wrong.
It is irrelevant how much you have spent on your equipment or how much you spend to run it (eg. electric bill, maintenance etc...). A faster more expensive to run computer will get more WU's done and be compensated fairly by the current credit standards, it will get more total credits.
Should I get less credits just because the electric company gives me a reduction in rates because I don't run my air conditioning in summer and therefore it costs me less to run a WU? Should I get more credits for suffering in the heat?
Should the owner of a mainframe computer who runs WUs and has invested $20 million in his equipment get more credit per WU?
The answer to both is: NO! You don't get more credit. We donate our computer time freely with no conditions applied. It certainly helps the science to do more WUs, so some of us will arrange to provide more expensive and capable hardware. Those who are just interested in more credits will do the same. If there is a 'contract' with a BOINC project it is that the user assumes all the expense, responsibility and problems of running the computer. If I can find a way to run my equipment more efficiently then that is a benefit to both me and the science.
RE: The recent devaluation
)
You are doing 30% less work, also. The amount of flops were decreased because they took out redundency. So your workload is lessened, also. You do the work faster, because there is less to do.
So, the crediting system remains constant.
If I am paid an hourly wage, doing a job I would do in 30 minutes or 16 items a day (considering an 8 hour day). Someone came along and fixed something so now I could do the job in 20 minutes or 24 items a day, I am only paid for the time I do my job. I am doing the same job, but now I do more in less time, so I am paid less for that item. I do more work in a day, so at the end of the day I am still paid the same. It's simple math. Per hour is the same rate, but now you do more work in that hour, with less repetitive moves.
RE: You are doing 30% less
)
No. We're doing the same work in 30% less time.
No. Where did you get that ?!?
No. It's still the same.
What ?!?
Not at all...
I'd say you're lazy then ... ;)
"Never touch a running System" or "Fix it until it's broken"
I am doing the same job, but now I do more in less time, so I am paid less for that item.
Yeah do more work get less payed i'd say... simple math ...
From Bernd:More than 90& (99%
)
From Bernd:
More than 90& (99% before optimization) of the run time is spent within a single loop that once had about a dozen lines of C-Code, containing only simple multiplications and additions (and the very vew divisions we coudn't avoid - I think there's actually only one of them left - hm, gives me another idea...). We have parallized/vectorized as much as we could.
Sounds like he removed a lot of unnecessary looping, eg: less flops needed to get to the same result.
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
So far so well, 30% less work
)
So far so well, 30% less work result in 30% less payment. By whatever optimizations always. Then we could have remained just as well with the old Credit system, regulated that dynamically. Less CPU time of fewer Credits.
But then there is no optimizations in the sense that the CPU uses more SSE2 or SSE3 but simply only flops savings. Then you have also in such a way written could. I speak here simply times for all others, because we assumed that, which is only faster done the SAME work by optimizations. Now the credit drop make sense in my eyes.
P.S.
Sorry for the terrible grammar, this kind of text is to strengh for my school english so google helped me.
Here's one viewpoint stated
)
Here's one viewpoint stated in a different way: You are a carpenter and are hired by a home builder to install nails into wood frames. You're given a hammer and told to pound nails and you will be paid a fixed amount of money each hour you pound nails. The homebuilder decides that pounding nails with a hammer is not as productive as using a pneumatic nail gun and decides to give you one. Now you're installing 4x more nails per hour by simply using a different tool (v4.24 instead of v4.02) provided by the home builder. The result is more installed nails (WUs) per hour but the pay/hour is the same as established by the project. Therefore, the credit per WU must be reduced accordingly since the throughput is higher. This is the fixed credit/hour scenario.
OTH, if I am paid according to the number of nails I install -- regardless of the tool used or who provides it -- then the faster I pump out WUs the more credit I should receive. This, afterall, is the goal. So regardless of the version of science app I should be paid credit based on the number of WUs I process -- faster machines mean more WUs/hour and more credit/hour. Each WU must be assigned a value based on units of work contained within it. Bernd refers to this unit of work as a template. Seems fair to me not having any further information.
Seems fair to me that if the project staff provides a faster science app then they have the right to reduce the credits given per WU since the science app will allow a given machine to output more WUs/hour. The User oth provides the host and, therefore, a faster host means more WU/hour and more credit/hour.
I'm sure these analogies are flawed and can be dissected; please do so.
RE: IMHO this actually is
)
No! It is just a silly game! :)
But, the recent rule change (the devaluation) implies a subtle, yet important, difference in points of view. Are contributing to the advancement of science? Or, are we merely donating computer time?
RE: Here's one viewpoint
)
So the question is, should we be "paid" hourly or by activity based compensation? Based on the nature of the work we do, I think that compensation based on actual production is most fair. I see no reason why my 1.25 GHz G4 should be rewarded at the same rate as a quad 2.5 GHz G5. The G5 owner has invested far more financially in their machine, and is paying more to run it in energy consumption. That person should be rewarded accordingly.
If the project supplies the tool allowing greater efficiency, they should be allowed to adjust the compensation to keep their "costs" level. If the user supplies the tool that allows greater efficiency, they should receive the greater compensation they have earned. If a more efficient open source worker is created by the users, than they should reap the benefits. However, the project should have the right to say what tools can & cannot be used to do the work. It is after all their project.
RE: I see no reason why my
)
I think the G5 (per one CPU) will get more work done and should get more credits total per hour. I hope it does, if it doesn't something is very wrong.
It is irrelevant how much you have spent on your equipment or how much you spend to run it (eg. electric bill, maintenance etc...). A faster more expensive to run computer will get more WU's done and be compensated fairly by the current credit standards, it will get more total credits.
Should I get less credits just because the electric company gives me a reduction in rates because I don't run my air conditioning in summer and therefore it costs me less to run a WU? Should I get more credits for suffering in the heat?
Should the owner of a mainframe computer who runs WUs and has invested $20 million in his equipment get more credit per WU?
The answer to both is: NO! You don't get more credit. We donate our computer time freely with no conditions applied. It certainly helps the science to do more WUs, so some of us will arrange to provide more expensive and capable hardware. Those who are just interested in more credits will do the same. If there is a 'contract' with a BOINC project it is that the user assumes all the expense, responsibility and problems of running the computer. If I can find a way to run my equipment more efficiently then that is a benefit to both me and the science.