This is also tied to the HT related enhancements where it has been noted that some projects are better pairs with others because of the mix of instructions.
I know at one point in the discussions we noted that a scoreboard might be an effective "learning" mechanism where BOINC would note which applications were in the mix during execution and how "well" the tasks did as measured by execution time. For example pairing PG (Integer) with SaH (FP) may be more effective in total throughput than SaH/SaH and PG/PG pairings because of the more effective use of HT ... As far as John's point about Resource Share we should all remember in the last design document RS was relegated to the very last concern of BOINC and that the current rules already allow BOINC to forgo satisfaction of RS for a number of other reasons... Personally I think this is still a long lingering effect of not considering the significant changes brought about by the growth in the "width" of most computers. The internal models are still tied to the old single processor model ... in part the lingering issue resides in the consideration of what to run on a task by task basis rather than by considering by project as indicated by debts and only after that by task, a subtle difference, but a significant one. Only after considering all projects with work on hand would we cycle back to see if and from which project should we run additional tasks. But I digress ... On Feb 12, 2010, at 7:36 AM, Raistmer wrote: >> For instance >> my quads run better with no more than 3 instances of NFS. They run better >> with only 1 instance of Lattice at a time. Other less demanding projects >> can be run on the other cores however. I should be able to limit the >> number >> of concurrent instances of any project but there's no way to do this in >> BOINC. > > It's long standing ticked in track: > http://boinc.berkeley.edu/trac/ticket/843 about project pairing ability. > " > 06/19/09 11:27:18 changed by Nicolas ΒΆ > a.. status changed from reopened to closed. > b.. resolution set to wontfix. > Do you understand the cause? > > It's not just about not running the same app twice. It's about exactly how > much CPU cache they use and having complex rules of which apps "behave nice" > with which other apps. > > If you run two AP instances, it slows down. But it also slows down if you > use AP and another app with similarly-big cache usage. And if you run two > little-RAM apps at the same time there is no slow down. It's way more > complex than you make it seem it is. > > " > > Actually I don't think it's really complex. All needed is operator knowledge > what app performs better paired with what another app. > > This knowledge can be aquired from simple experiments. > > But I tired to re-open this topic... > > > > _______________________________________________ > 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.
