Forum > GPU crunching
Modified SETI MB CUDA + opt AP package for full GPU utilization
Jason G:
Yes, Maybe I'll have to find out if the flop [Actually fpop] counting standard is modified and build new AK_v8 builds... :P
Posted in that thread:
--- Quote ---It is 'counting' more flops [Well more correctly fpops anyway] for the same processing. This would not be tolerated in a third party app. I will have to determine if this is an intentional modification to the stock op count regime, so build new AK_v8 builds to match, if it continues.
--- End quote ---
efmer (fred):
--- Quote from: Jason G on 17 Jan 2009, 08:18:23 am ---Just to throw another observation into the mix, after munching through a few WUs now. I seem to be claiming ~30% more credits than AKv8 wingmen. So far these have all been denied.
--- End quote ---
Maybe machine dependent I claim 13.83 the other non CUDA claims 16.58 so I claim a lot less....
But others are ok I claim 14.45 the other non CUDA claims 14.73.
I claim 59.82 the other 43.79
This one is interesting http://setiathome.berkeley.edu/workunit.php?wuid=394719892
It is a regular, a CUDA Raistmer and a stock CUDA. The Raistmer and Stock CUDA both claim more than a regular.
Jason G:
Yeah, If the count is borked it likely will vary by angle range in discrepancy. My concern is that it gives, for some people, a false indication of performance. [On the other hand, if it is on purpose, then it becomes the new standard, to which optimised apps must then comply]
Josef W. Segur:
--- Quote from: Jason G on 17 Jan 2009, 09:00:40 am ---Yeah, If the count is borked it likely will vary by angle range in discrepancy. My concern is that it gives, for some people, a false indication of performance. [On the other hand, if it is on purpose, then it becomes the new standard, to which optimised apps must then comply]
--- End quote ---
The undercount for triplets is recognized in a comment and is due to the CPU not knowing how many samples were above the triplet threshold in a PoT array. The overcount for gaussians is more complex, there's an overcount for the equivalent of getFixedPoT() which could easily be fixed, then difficulty in estimating how often the two data-dependent early outs are taken. A bit of statistical analysis on sufficient results should allow reasonable adjustments, though not exact. Probably the right target would be a small overclaim so variations seldom cause a lower claim than CPU and reduce the granted amount.
Joe
Radiohead:
What about ver 6.08 ?
http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=1512
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version