They're trying an app with: BOINC_OPTIONS options; boinc_options_defaults(options); options.normal_thread_priority = 1; boinc_init_options(&options);
That achieves equality, but by raising the main .exe priority to 4, matching the DLLs They also say "OpenMP does not allow changing the priority of its processes. We'll have to figure out a solution that works on Linux/Mac and Windows, and doesn't cause problems with OpenMP." - by which point, I'm well out of my depth. > Hopefully that will fix the problem; > I'd like to avoid dealing with variable # of threads. > -- David > > Richard Haselgrove wrote: > ... >> >> Originally, the AQUA devs hadn't noticed any issues: it was my experience >> of the slow-down of Jason's hybrid CUDA app that prompted the enquiry. >> But now that they're looking at it more closely, it may explain why the >> multiple application threads tend to finish at different times: the >> single thread with priority 1 will be interrupted for Windows (and >> BOINC/CUDA) housekeeping far more often than the threads with priority 4. >> This means that AQUA tasks tend to finish with three cores idle for the >> last few minutes, and the poor old 'priority 1' thread panting across the >> line a distant last. >> >> At the moment, the BOINC client scheduler can't make use of those idle >> resources: all cores are released back to BOINC 'en bloc' when the whole >> task finishes. Releasing individual cores for re-use by BOINC is probably >> a scheduler request too far, but if thread equality levels the playing >> field, efficiency overall should improve - the AQUA devs are looking into >> it. >> > > _______________________________________________ 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.
