-
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
mitigate high CPU cost of HBHE hit position calculation in EgammaHcalIsolation #35955
mitigate high CPU cost of HBHE hit position calculation in EgammaHcalIsolation #35955
Conversation
enable profiling |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-35955/26365
|
@cmsbuild please test |
A new Pull Request was created by @slava77 (Slava Krutelyov) for master. It involves the following packages:
@jpata, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-0b0595/20187/summary.html Comparison SummarySummary:
|
in IB igprof tests the perf counts in
This is roughly expected from the early return after the depth check (7 depths are checked). |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-35955/26386
|
@cmsbuild please test |
thank you Slava, |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-0b0595/20209/summary.html Comparison SummarySummary:
|
does this imply a backport? |
the last update now has
So, slightly more than a factor of 8 speedup. I think that further speedup is possible by refactoring the calling code. I added #35969 to track further progress with this still somewhat heavy code. |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
no, I don't think a backport is needed |
return 0.; | ||
|
||
const auto phit = caloGeometry_.getPosition(hit.detid()); | ||
const float phitEta = phit.eta(); |
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.
use cashed eta in caloGeometry_
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 clarify the member method
Geometry/CaloGeometry/interface/CaloGeometry.h has only xyz position
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.
RhoEtaPhi const& repPos() const { return m_rep; }
virtual float rhoPos() const { return m_rep.rho(); }
virtual float etaPos() const { return m_rep.eta(); }
virtual float phiPos() const { return m_rep.phi(); }
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.
eventually through CaloGeometry::getGeometry if not in the same SubDetector
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.
one could extend the CaloGeometry interface to support repPos
(copy paste code of getPosition
)
In my opinion would be more efficient to check first if the CellGeometry is the same and avoid the overhead of the code (not inlined) to search for the subDetector for each single hit....
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.
ah, so the suggestion is for an extension to the geometry interface; I thought at first that this is something that exists already.
IIRC, there is one rechit per cell in ECAL/HCAL
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.
it exits already in CaloCellGeometry that is what CaloGeometry access. please have a look to the implementation in
https://cmssdt.cern.ch/dxr/CMSSW/source/Geometry/CaloGeometry/src/CaloGeometry.cc#50
here locally one can invoke
caloGeometry_.getGeometry(hit.detid())->repPos();
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.
here https://github.com/slava77/cmssw/blob/f33bdaa8be9c4aa4a3f336dbf23501b059a8988b/RecoEgamma/EgammaIsolationAlgos/src/EgammaHcalIsolation.cc#L188
thre is a loop on the hits in HBorHE. one can verify if a hit is in the same SubDet of the previous one and avoid all the search logic in CaloGeometry and acess directly CaloCellGeometry
const float phitEta = phit.eta(); | ||
|
||
if (extIncRule_ == InclusionRule::withinConeAroundCluster or intIncRule_ == InclusionRule::withinConeAroundCluster) { | ||
auto const dR2 = deltaR2(pcluEta, pcluPhi, phitEta, phit.phi()); |
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.
use cashed phi in caloGeometry
if (!(goodHBe or goodHEe)) | ||
return 0.; | ||
|
||
const auto phit = caloGeometry_.getPosition(hit.detid()); |
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.
suggested change:
auto const & phit = caloGeometry_.getGeometry(hit.detid())->repPos();
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.
suggested change:
Thanks. Testing.
PR soon.
costs of computing HCAL isolation in egamma has increased significantly after #33666
This PR mitigates the situation by reordering the calls.
However, a better refactoring of the code should be considered in near future. Some options are
ValueMap
and use it when dR computations are needed@wrtabb @SohamBhattacharya