[email protected] wrote: > A few thoughts: > > There is no guarantee that any two computation devices (general sense here) > will be equally efficient at a particular computation. The CPU and GPU in > a single box may very well have different efficiencies, and should be > treated as separate computation devices for credit comparisons.
I agree. > Goal: The credit granted for all tasks for a single WU needs to be > identical, no mater what computation devices it runs on. Sorry, disagree... What happens for the case where the CPU application is highly optimised whereas the GPU application is brazenly wasteful of the GPU resource? The GPU does more physical work and gains less credit per unit of physical processing work done. I consider a fairer scheme is that credit is granted for the resource actually used. If for example, the GPU application (wastefully) for a WU performs twice as many calculations as the equivalent CPU application, then the GPU processed WU should be awarded twice the credit of the CPU processed WU (to reflect the additional resource used/squandered). I'd modify your goal to: Goal: The credit granted for all devices for a single WU needs to be directly in proportion to the resources utilised, no mater what application code runs on it. It is then up to the project to optimise their applications to gain more science done. For better optimised WUs, you will see *less credit per WU* awarded, exactly because less resource will have been used to process them. The users still see a consistent *rate* of credit awarded for their hardware throughout. > The average credit per hour for all computers that are attached to both > project A and project B should be equal. Note that if Project A has CPU Sorry, no go on that one. What happens whereby some projects can make more effective parallel use of compute hardware than others? For example, an integer only or a logic only processing task should only be able to accumulate a fraction of the credit rate compared to that of a task utilising integer, logic, and floating point operations in parallel. Similarly so for those projects that have taken the trouble to use SIMD (higher RAC) vs those that haven't (lower RAC). That may even introduce some measured 'market forces' to encourage projects not to squander resources with poorly written code. The users get to see how well their spare resources are utilised... Regards, Martin -- -------------------- Martin Lomas m_boincdev ml1 co uk.ddSPAM.dd -------------------- _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
