-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permanently enabling method 3 #11507
Conversation
A new Pull Request was created by @igv4321 (Igor Volobouev) for CMSSW_7_6_X. Permanently enabling method 3 It involves the following packages: RecoLocalCalo/HcalRecAlgos @cmsbuild, @cvuosalo, @slava77 can you please review it and eventually sign? Thanks. |
// S.Brandt Feb19 : Add a pointer to the HLT algo | ||
std::auto_ptr<HcalDeterministicFit> hltOOTpuCorr_; | ||
|
||
// Speed up the code a little bit by not allocating a vector every time | ||
mutable std::vector<double> vectorBuffer_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the size of the saving from this buffer?
I'd much rather see no mutables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please remove this.
I don't see much benefit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The saving does not come from the "size" of the vector. It is instead about not allocating (and then deallocating) the memory from the heap for each calorimeter cell processed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there are several more allocations in the methods called internally.
So, if a fix needs to be done, better do it properly.
Your change with a mutable opens a possibility to pass information between hits.
This is not good.
Cleaning and clearing is apparently done correctly now, but this makes the code much more fragile in the future developments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is with 25ns hlt in 760pre5
https://slava77sk.web.cern.ch/slava77sk/reco/cgi-bin/igprof-navigator/CMSSW_7_6_0_pre5-orig.256729.step2-hlt.pp/797
i don't see any cpu cost reasons for this buffer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The allocations internal to "Method 2" and "Method 3" classes are, of course, irrelevant to this discussion. Bug the authors of the corresponding classes if you are so inclined.
The change with a mutable, of course, does not open any possibility to pass information between hits. The vector is cleared any time it is used.
Any code is "fragile" to some degree. I believe, the advantages outweigh the drawbacks in this particular case. The "mutable" keyword is included into the language precisely for the uses similar to this.
The cost reasons are obvious: we avoid allocating the contents of the vector on the heap for every hcal rechit.
@cmsbuild please test |
The tests are being triggered in jenkins. |
-1 |
@igv4321 The optimization made is still questionable to me and it is not time critical. Thank you. |
Do I need to make a comment for the system to see the latest push? |
Igor, yes, unfortunately cms-bot doesn't notice a commit from an "old" branch and a message is needed. Thank you very much for the factorization of the technical performance. I noticed a change in a follow up to Andrea's comment about |
@cmsbuild please test |
The tests are being triggered in jenkins. |
"setPileupCorrection_" variable is actually configured (as intended) by module parameters "dataOOTCorrectionName", "dataOOTCorrectionCategory", "mcOOTCorrectionName", and "mcOOTCorrectionCategory". Yi Chen, who put those lines in, simply did not realize this. It is harmless to set this variable to 0 at those points in the code, as "Method 1" was not intended for HF and HO to begin with. While "Method 1" is currently deprecated, I don't want to completely remove this mechanism yet -- perhaps, some other method will be developed, inheriting from AbsOOTPileupCorrection. |
@igv4321 Currently, jenkins comparisons show no differences from the change made here (as expected from the lack of the DQM/validation plots) |
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_6_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar |
<...> The (original) idea was just to have M3 vs M2 right away without manupulation of different input files and DetId matching for on-demand comparisons/tests/checks (like the ones performed for "Early 2015 Physics Commissioning" task force). |
+1 |
Permanently enabling "Method 3" in HcalSimpleRecAlgo.
Some trivial cleanup of HcalSimpleRecAlgo (e.g., removed unused default constructor, added a buffer vector of doubles so that this vector does not have to be reallocated for every digi, etc).
Require proper initialization of "Method 3" in the HcalHitReconstructor module.