Choose timezone
Your profile timezone:
Powered by Indico
v3.3.3-pre
Attendees: Danilo, Oksana, Philippe, Brian, Guilherme, Jim, Zhe.
Oksana: most lz4 changes back-ported. Still problem with build system in 6.08 (double target and increase file size). And I still need to do the work for v5.34.
Oksana: I remeasured the performance of cloudflare-cms improvement to zlib. With higher number of events, I see better results. So I updated my presentation to included the new numbers. For 200, 3 to 4 times faster for writing compression setting 109 and some slight improvements to reading. See https://indico.cern.ch/event/658075/ for more details.
Brian: CMS already uses this and we were able to increase the compression level for the same CPU cost.
Oksana: I also fix the mismatch between the builtin-clang and the rest of ROOT in regard to fast-math.
Oksana: I am pondering if my fix is the right longer term fix (adding explicit a CXXFLAGS) where we may want to have an official LLVM build type.
Guilherme: I am concerned about compiling a LLVM with fast math enabled; this seems dangerous. Maybe we have should just inform ROOT/cling that ROOT was built with fast-math instead.
Guilherme: I am trying to avoid the compression/decompression in the output thread.
Philippe: It sounds like we storing the output TTree object (the meta-data) every-time we merge, so essentially every cluster.
This is way more than expected. Usually this is done every 10 clusters or so (300 on file data size). This is driven by the value
of fAutoSave.
Danilo: ras.
Brian: Being trying to get the dynamic-offset calculation finished up.
Brian: Next I will make it easier to access and test, for example extend hadd. Will eventually have Jim test on the original trigger/example report.
Brian: Two potential next steps. One is to work with Philippe on reviewing Bulk I/O. Another one is to look at newer compression-dictionary techniques (See facebook’s work, they report massive speed-up in writing and reading *and* ratio improvement). A 3rd option (time might not be right) is to look at class versioning info to be once per branch rather than once per entry. Reminder I will be at Fermilab on Wednesday.
Zhe: I replaced inner code with threadGroup, still 3 to 4% slowdown (compare to thread implementation). Looks like it is due to time spent in TTB scheduler). Maybe we can inform the scheduler that there will only two tasks.
Brian: I propose we merge as-is and address the performance later.
Philippe/Danilo: Fair enough, let’s merge after the current round of code cleanup.
Brian: This would also allow CMS to test.
Philippe: Should we write a ROOT I/O specification.
Jim: This is in the context of the many ROOT I/O implementation (java, javascript, go, alternate-C++). At least have a forum (maybe a google-group or e-group).
Brian: For the change that we are making, writing unit test are somewhat hard. So I would love to see a description of what we think the code does independently of the code. One side-effect is that it might make it clearer when we make intentional (vs unintentional) changes.
Brian: Ideally it is both human readable and useable as input/cross-check for unit-tests. However, I do not know yet how to do it. Like Philippe, I am concerned how this document/documentation stays up to date.
Philippe: Should we present this at the workshop?
Jim: Yes, i could do that.
Philippe: Next meeting on the 29th.