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
[10_6_X] improving performance of PuppiProducer #31290
[10_6_X] improving performance of PuppiProducer #31290
Conversation
A new Pull Request was created by @missirol (Marino Missiroli) for CMSSW_10_6_X. It involves the following packages: CommonTools/PileupAlgos @perrotta, @jpata, @cmsbuild, @santocch, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here
|
backport of #31164 |
@cmsbuild please test |
The tests are being triggered in jenkins.
|
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
In https://github.com/cms-sw/cmssw/pull/31164/files#diff-1b7e1647edfc1e35ddf8671132acf8f4L2 there are also changes in |
Hi @silviodonato , I didn't backport those changes on purpose because in The only remaining change would have been to rename I added the following tentative comment to the PR description:
|
thanks @missirol ! |
+1 |
// or (2) are required for computations inside puppi-algos (see call to PuppiAlgo::add below) | ||
double pVal = -1; | ||
bool const getsDefaultWgtIfApplyCHS = iConstits[i0].id == 1 or iConstits[i0].id == 2; | ||
if (not(fApplyCHS and getsDefaultWgtIfApplyCHS) or (std::abs(iConstits[i0].eta) < fPuppiAlgo[pPupId].etaMaxExtrap() and iConstits[i0].puppi_register != 0)) { |
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 master version uses and getsDefaultWgtIfApplyCHS
in the second conditional instead of and iConstits[i0].puppi_register != 0
. Are these equivalent? If yes, a redefinition of getsDefaultWgtIfApplyCHS
may be in order.
If no, please elaborate
(in this case, the separate definition of getsDefaultWgtIfApplyCHS
seems unnecessary because it is not reused anywhere else).
also a linebreak at/after or
would be nice
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.
In practice, I think the condition id == 1 or id == 2
corresponds to register != 0
(looking at how puppi_register
is filled here), but in principle the two things can differ (or at least, I wanted to make no assumptions).
The logic behind how these changes are implemented is the following: goodVar
needs to be calculated when the final weight of the candidate is non-trivial (this is the first condition, which corresponds to the logical NOT of these two cases), or when the goodVar
of a given candidate is needed internally by PuppiAlgo::add
, here; in 10_6_X
, the latter condition translates to (.. < etaMaxExtrap) and puppi_register != 0
, while in 11_X_Y
the criterion is (.. < etaMaxExtrap) and (id == 1 or id == 2)
(see here).
So, the logic is the same here and in the original PR; the end result looks different just as a consequence of the fact that the Puppi{Container,Algo}
implementation is different in the two releases.
I added a commit to remove the temporary variable getsDefaultWgtIfApplyCHS
, which was indeed only used once, and took the opportunity to add the linebreak.
@cmsbuild please test |
The tests are being triggered in jenkins.
|
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1
|
merge |
+1 |
This pull request is fully signed and it will be integrated in one of the next CMSSW_10_6_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_11_2_X is complete. This pull request will be automatically merged. |
PR description:
This PR is an attempt to backport the changes in #31164.
This backport follows in large part the original PR, but it is not entirely trivial; this is due to the significant differences in the
PuppiProducer
's implementation in10_6_X
(wrt later releases), and the need to not introduce any numerical changes in the outputs (no-change policy).These requirements led to adding more members to the
PuppiCandidate
struct (compared to the original PR):an
int
namedpuppi_register
, due to the fact that in this release a given Puppi candidate has two IDs associated to it (named puppi "register" and puppi "id" in the source code), while in11_X
only one is used (currently calledid
);four floats (
px
,py
,pz
,e
) for the candidate's p4; this is used in thePuppiProducer
when storing the candidates kinematics (seepuppiP4s
in thePuppiProducer
; in11_X
, things are done differently and this change was not needed); recomputing(px,py,pz,e)
on-the-fly based on(pt,eta,phi,m)
would introduce small numerical changes in the outputs, and the only way I found to avoid this was to add more members to thePuppiCandidate
struct.The improvement in computational performance is approx. 45% (from ~27ms to ~15ms for one instance of the
PuppiProducer
in thePAT
step of a 2017 MC workflow); this is slighly less than the speedup in the original PR (which was closer to 60%), maybe partly due to the fact that thePuppiCandidate
struct here includes more data members.A couple of minor changes from #31164 in
PuppiContainer.h
(renaming of a data member, and removal of an unused getter) are avoided here for simplicity.No changes in the outputs are expected.
FYI: @ahinzmann @lathomas @kirschen
PR validation:
Checked that the PUPPI weights of all PF candidates are unchanged for 500 events of a 2017 MC workflow (
PAT
step), for bothpuppi
(used for jets) andpuppiNoLep
(used for MET).Standard workflows, i.e.
runTheMatrix.py -l limited -i all --ibeos
, ran successfully.if this PR is a backport please specify the original PR and why you need to backport that PR:
#31164
(with limited modifications needed to enforce the no-change policy)
This speeedup could be useful for UL re-miniAOD and analysis.