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.