-
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
MTD reconstruction: speed up TrackExtenderWithMTD #36793
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-36793/27938
|
A new Pull Request was created by @fabiocos (Fabio Cossutti) for master. It involves the following packages:
@clacaputo, @cmsbuild, @AdrianoDee, @srimanob, @slava77, @jpata can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-996284/21973/summary.html Comparison SummarySummary:
|
related to the memory use: IIRC, the trajectory data is fully copied down to the generalTracks. This gives an opportunity to use the framework early delete feature (hooks are in place in Configuration/StandardSequences/python/earlyDeleteSettings_cff.py). |
enable profiling |
@cmsbuild please test |
@slava77 I had given a try to |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-996284/21987/summary.html Comparison SummarySummary:
|
Looks like a fairly significant increase in memory: |
not a big surprise, the bulk of the difference is in the KF code as far as I can see, as expected It is a matter of balance, we may squeeze the overall time but at the price of having some more stuff in memory. I selected only what strictly needed by the but I expect it would make the problem worse |
please test |
please abort |
enable none |
please test |
@smuzaffar , it seems that the bot is waiting to start the profiling: bust shouldn't I have prevented it with "enable none" in #36793 (comment) ? |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-996284/22528/summary.html Comparison SummarySummary:
|
@perrotta , there is a known issue with bot that if a test was previously run for a commit then bot assumes that it will re-run again and waits for its results. I will fix this once find some time. For now I have manually set mark the profiling status |
Thank you @smuzaffar! |
+1 |
This PR might have caused an assertion failure in workflow 23234.9, see #37018. |
PR description:
This PR proposes an update of
TrackExtenderWithMTD
following the presentation at the TRK POG meeting https://indico.cern.ch/event/1108413/contributions/4662751/attachments/2373693/4054455/TRK_MTD_20220117.pdf and the following discussion.About 1/3 of the time used by this module is taken by retrieving the
Trajectory
for a given general track using theTrackTransformer
, see https://cms-reco-profiling.web.cern.ch/cms-reco-profiling/cgi-bin/igprof-navigator/releases/CMSSW_12_2_0_pre3/34834.21/step3/cpu_endjob/92 . This can be avoided by reusing theTrajectory
optionally stored in a transient form into the event by the iterative tracking, an option by default disabled.Of course this comes at some cost in memory usage, which should be balanced with the CPU gain benefit.
The activation of the flags to save the trajectories in the event if made only for the selection of modules entering into the definition of the
generalTracks
output, which at present constitutes the input of theTrackExtenderWithMTD
PR validation:
Tests have been done using the benchmark workflow 34834.21 (D76 scenario TTbar with PU, prod-like), using a home-made MinBias pile-up sample of 10k events. A simple memory and CPU profiling (single stream mode) on 100 events shows a gain in CPU:
vs previous
with similar CPU load in both tests, and an extra memory load quantified in about 5%:
vs previous
An igprof PERF_TICKS profiling on 10 events shows the expected variation in the internal module CPU use, with the modue weighting now for 2.2% of the total CPU (vs more than 3% previously):
The DQM histogram comparison shows a very moderate difference in the output of MTD tracks and vertices tests, and 4D vertices. Since the code should just replace the
Trajectory
from the original track fit with its reconstruction from theTrackTransformer
I would conclude that some possible small difference might be expected there. In any case the overall behaviour of the code looks very well consistent between the two versions, even though not strictly identical.