「view this page in B3 βῆτα server」

Revisions №61037

branch: master 「№61037」
Commited by: Vikram K. Mulligan
GitHub commit link: 「e1e61459e6ead5a4」 「№4355」
Difference from previous tested commit:  code diff
Commit date: 2019-11-12 18:13:52

Merge pull request #4355 from RosettaCommons/vmullig/simplify_threadmanager_api Reduce mutex contention a bit by reducing reliance on std::shared_ptr in RosettaThreadManager classes. I was being overcautious with my ownership model, and unnecessarily using vectors of owning pointers of functions. This results in unnecessary locking of mutexes internal to `std::shared_ptr`, which can slow things down. Worse, I was _copying_ the owning pointers around, which results in new locking every time the reference count is incremented or decremented. (Even in the single-threaded build, unnecessarily passing around smart pointers is likely slowing things down a bit, since reference counts have to be incremented and decremented.) The vector object owns its contents and controls their destruction, so a vector of objects controlled by owning pointers is really unnecessary. This pull request refactors a bit so that the `RosettaThreadManager` now accepts a vector of function objects instead of a vector of owning pointers to function objects. TODO: - [x] Also switch the RosettaThreadAssignmentInfo object to be a stack-allocated object passed by reference, rather than a heap-allocated object passed by owning pointer. - [x] Check profile tests. Is there a performance benefit with packing in the single-threaded builds? (See the core_pack_pdig_current_default_sfxn performance test, which did show a slight drop in single-threaded execution when we switched to building a work vector and evaluating it). --> No big change. Maybe a small improvement. - [x] Does this improve performance scaling for multi-threaded interaction graph calculation? --> Not really. - [x] Does this rescue the scoring performance in the single-threaded build in PR #4342? --> No. Note, though, that the only slowdowns are with very fast-to-compute terms (_e.g._ chainbreak) or with an empty scorefunction. If there's any work to be done at all, the slowdown is negligible. - [x] Does this improve performance scaling for multi-threaded scoring in PR #4342? --> Not really.

...