Attending: Zhe, Brian, Guilherme
Parallel Unzipping (Zhe Zhang)
- Compared three modes:
- Existing IMT implementation of GetEntry.
- Parallel unzipping using existing .
- Discussion: how does this interact with std::thread? std::thread-based multithreading will interact poorly with TBB-based multithreading
- Brian notes that this is an existing problem, independent of this work. At least with this work, parallel unzipping does not destructively interfere IMT-mode.
- TBB-parallel-unzip always is faster (realtime, CPU time) than IMT GetEntry.
- It's not clear to Brian why TBB-parallel-unzip takes less CPU time than IMT GetEntry.
- TBB-parallel-unzip is faster than pthread-parallel-unzip at low event counts. At high event counts, appears very similar (difference in the noise?).
- Brian: Can we post the branch on GitHub so I can start reviewing?
- Next version synchronizes at the single-basket-per-task level (instead of multiple-baskets-per-task level), seems to go faster.
Update on OptimizeBasket exploration (Brian):
- Starting measuring the actual costs of more aggressively shrinking baskets. See prior presentation for algorithm.
- Using the existing code, the number of re-allocations for rewriting a CMS AOD file is 30, at a cost of 173 microseconds.
- More aggressively shrinking results in 7,194 re-allocations at a cost of 41,350 microseconds (overall, about 30 minutes for a 2.6GB file). So, cost is pretty minimal.
- Aggressive shrinking saves 25MB RSS in this case.
- In the current code, the shrinking compares the current size versus the prior size at flush of a basket. I think we can reduce the reallocations more without sacrificing our gain.
- In the case of one-basket-per-cluster mode, the aggressive shrinking savings is much larger (400MB).
Reducing lock contention on TClass (Guilerme):
- Current PR: https://github.com/root-project/root/pull/747 . Waiting on review from Philippe.
There are minutes attached to this event.
Show them.
