Raistmer, you're reading far more into my comment than it deserves. All I was saying is that if four cores finish quick, medium, medium, slow, and everything has to wait for "slow" to finish, then there are some idle cores for a minute or two. If they all finish medium, medium, medium, medium, BOINC can move on to the next task that little bit quicker.
With regard to the general optimisation questions: With regard to the AQUA MT app, IIRC the primary rationale was to get very large tasks turned round quickly so that the next phase of research could be planned sooner, learning from the outcome of the previous phase. Four parallel threads at 95% still gets the asnwers far sooner than a single thread at 99.999% with finely-tuned prefetchers, cache alignment, and all the other tricks of the supercomputer trade. Remember that most of these applications are designed, and to a large extent written, by scientists focussed on the outcome, not programmers focussed on the process. That's why there's an opportunity and a need for computational optimisers like yourself and Jason, who have precisely the opposite focus. If there was a way to synergise those energies, so that BOINC applications produced _both_ rapid, relevant scientific outcomes, _and_ elegant, efficient, computational code, so much the better: but for the time bieng, I'm just picking the low-hanging fruit. >> 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. > > I really have big doubts that MT AQUA will increase overall BOINC (even if > it will do it for AQUA project itself) performance on host. > Firstly, for what reason AQUA wanna use multithreaded app? > If I understood correctly what I read on their site some time ago - the > main reason - unacceptable long running times for their tasks. > If single task will be run on multicore host by MT app and will have at > least _some_ level of parralelism, it will be completed faster of course. > That is, this aim clearly will be accomplished by MT app. But there is > _nothing_ about performance. > Actually, very probably overall performance will decrease, even w/o > BOINC's too generous CPU resourse allocations for this project. > And to get true benefit (in performance sense, not in just single task > completion time sense) some benefits from better L2 cache usage required > and perfect synching and load balancing between threads of course. > > _______________________________________________ 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.
