First of all, to change to such approach it would be good to know at least some cases where your guess about CUDA faster than CUDA 23 realised. The single case when it will be so in my understanding: the host marked as cuda23 capable but actually GPU has no enough free GPU memory to cope with new cuFFT and fall back to CPU processing. In such situation cuda plan class, truly using GPU, will surely be faster than cuda23 class that uses CPU instead. But can such situation be treated as "speed variation between plan classes that requires benchmarking" or just as "incorrect plan class determination" ? AFAIK by itself cuFFT in 2.3 much faster than prev versions so you hardly find GPU that works (works, not deny to work at all) with older CUDA runtime faster than with new one. At least for SETI MB cuFFT performance are crucial. Other app parts runs roughly at the same speed in both classes.
----- Original Message ----- From: "David Anderson" <[email protected]> To: "Richard Haselgrove" <[email protected]> Cc: "BOINC Developers Mailing List" <[email protected]>; <[email protected]> Sent: Saturday, April 10, 2010 2:22 AM Subject: Re: [boinc_dev] [boinc_alpha] Seti Beta now requires 1.4 to 2.21 CPUs for Cuda work instead of 0.04 > It's a BOINC server experiment; email problems to me. > > BTW: the new system selects among CUDA alternatives (cuda, cuda23, > cuda_fermi) > not on the basis of how fast they're expected to run, > but rather how fast they actually have run, on average, on that particular > host. > Who knows, some GPUs might be able to run either > cuda or cuda23, and run cuda faster. > > However, this scheme can get stuck in a local minimum for a host: > it might initially send some cuda23 jobs which for some reason run very > slowly. > Then it would switch to cuda, and potentially never use cuda23 again. > Any ideas about this? > > -- David > > Richard Haselgrove wrote: >>> I'll look into this. >>> Beta is running some new/experimental server software right now, >>> and it may do some odd things. >>> Please report any other stuff like this. >>> >>> -- David >> >> What's the official reporting line on this? >> >> Is it a project experiment, with feedback via messages boards? >> >> or a BOINC experiment, with feedback via this mailing list? >> >> Either way, I've just posted some bad-behaviour logs in the message board >> thread Claggy linked - I can duplicate them here if you want, but I'd >> prefer >> not to. >> >> >> _______________________________________________ >> boinc_alpha mailing list >> [email protected] >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. > > _______________________________________________ > 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. > _______________________________________________ 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.
