Skip to content
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

Improve DD4hep workflow perf, step 3: Also reduced the number of paths (with regex) looped over for HCAL #32540

Merged
merged 18 commits into from Jan 12, 2021

Conversation

ghugo83
Copy link
Contributor

@ghugo83 ghugo83 commented Dec 18, 2020

This is based on the exact same observation as in #32505 : when SpecPar blocks have the same name, all their paths are stacked together. This results in irrelevant paths (with regex) being looped over, hence a performance penalty.

#32505 proposed a simple fix for the Tracker (just addressing the issue directly in the XMLs); this is the equivalent for HCAL.
Unnecessary HCAL paths (with regex) were looped over, for example at https://github.com/cms-sw/cmssw/blob/master/SimG4Core/Geometry/src/DD4hep_DDG4Builder.cc#L62

Summary of performance gains for FULL step 1 with DD4hep workflow (entire step with all initializations + XML parsing + CMS geo construction, up to event generation).
ZMM, Run3, on my local (obviously only the order of magnitude is relevant).

NB: The last occurrence of this issue (for Run 3) is in ZDC (zdcsens.xml and zdcProdCuts.xml). I will not address the ZDC case, as the paths there have no regex, hence the perf penalty is completely negligible, not worth the XMLs files versioning, risk of regression, etc.

NB 2: #32511 should be merged first. This branch is on top of my working branch, hence the diff with master will become relevant as soon as #32511 is merged.

@ianna @civanch @cvuosalo

…erial.xml. I presume the pixfwdblade.*Zplus had been done to distinguish from the pixfwdblade[0-9]:PixelForwardBlade. But this is not recessary, because the pixfwdblade[0-9]:PixelForwardBlade are not called in any geo scenario where data/PhaseI/trackerRecoMaterial.xml is used.
…these paths are not looped over when not needed anyway, hence this commit has no effect on workflow perf).
… has very small, but non-null, impact on perf.
…erial.xml. Very significant perf improvement. This version is compatible to work on both DDD and dd4hep cases.
…ngMaterialGroups_ForPhaseI.xml, version working for both DDD and dd4hep.
…al.xml. This has no visible impact on perf though (~85s before and after this commit), but does not harm to have a more compact file. Regex removal instead (in the previous commits) had a big impact: full DD4hep step 1 up to event generation: ~140s -> ~85s !!
…ow (~5 s gain in my local for overall step 1 XML parsing / geo construction). When SpecPar blocks jave same name, all paths are gathered unnecessarily, leading to loop over more paths (with regex) than needed).
@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-32540/20492

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @ghugo83 for master.

It involves the following packages:

Configuration/Geometry
Geometry/CMSCommonData
Geometry/HcalCommonData
Geometry/HcalSimData
Geometry/TrackerRecoData
SimTracker/TrackerMaterialAnalysis

@civanch, @Dr15Jones, @makortel, @cvuosalo, @ianna, @mdhildreth, @cmsbuild, @kpedro88 can you please review it and eventually sign? Thanks.
@fabiocos, @vargasa, @makortel, @threus, @GiacomoSguazzoni, @JanFSchulte, @rovere, @VinInn, @Martin-Grunewald, @apsallid, @ebrondol, @mtosi, @dgulhan, @slomeo this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

@@ -0,0 +1,18 @@
<?xml version="1.0"?>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Full path is wrong. It should be Geometry/HcalCommonData/data/hcalsenspmf/v1/hcalsenspmf.xml.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous path was Geometry/HcalCommonData/data/hcalsenspmf.xml

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the new directory hcalsenspmf has to be created.

@@ -0,0 +1,15 @@
<?xml version="1.0"?>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Full path needs to be Geometry/HcalSimData/data/HcalProdCuts/2021/v2/HcalProdCuts.xml. Make sure you derive v2 from the v1 file.

@@ -355,7 +355,7 @@
<Include ref='Geometry/VeryForwardData/data/CTPPS_Pixel_Sens.xml'/>
<Include ref='Geometry/VeryForwardData/data/CTPPS_2018/RP_Dist_Beam_Cent.xml'/>
<Include ref='Geometry/EcalSimData/data/ecalsens.xml'/>
<Include ref='Geometry/HcalCommonData/data/hcalsenspmf.xml'/>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here

@cmsbuild
Copy link
Contributor

cmsbuild commented Jan 8, 2021

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-b22d83/12015/summary.html
COMMIT: 8121aeb
CMSSW: CMSSW_11_3_X_2021-01-07-1100/slc7_amd64_gcc900

Comparison Summary

Summary:

  • No significant changes to the logs found
  • Reco comparison results: 3038 differences found in the comparisons
  • DQMHistoTests: Total files compared: 37
  • DQMHistoTests: Total histograms compared: 2716967
  • DQMHistoTests: Total failures: 7799
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2709146
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 36 files compared)
  • Checked 156 log files, 37 edm output root files, 37 DQM output files

@ghugo83
Copy link
Contributor Author

ghugo83 commented Jan 8, 2021

@ghugo83 If I understand correctly, the SpecPar name is is used to group SpecPars together. That is, SpecPars with the same name in different files are all grouped together.

Yes exactly

Otherwise, the SpecPar name is not used. Is that correct?

No, in the codebase apparently, the SpecPar name is sometimes used to access a specific SpecPar directly.
Using DDFilteredView::get<std::vector<std::string>>, specPar(name), etc

@ghugo83
Copy link
Contributor Author

ghugo83 commented Jan 8, 2021

What version of Geometry/TrackerRecoData/data/PhaseI/v1/trackerRecoMaterial.xml is included in this PR? There is already a "v1" in the master.
Why is SimTracker/TrackerMaterialAnalysis/data/trackingMaterialGroups_ForPhaseI.xml included in this PR, along with SimTracker/TrackerMaterialAnalysis/data/trackingMaterialGroups_ForPhaseI/v1/trackingMaterialGroups_ForPhaseI.xml?

@cvuosalo Yes that's a weird feature of cms-git, which shows the diff of the PR branch with master at the time the PR was created, instead of at the present time.
The early commits in this PR are already included in master on other topics. But they still appear in the diff with master, because master did not contain them at PR creation time.
I invite you to look at the real diff of this PR branch (ghugo83:dd4hep_perf_3) with present master: master...ghugo83:dd4hep_perf_3

As you can see, this PR does not touch trackerRecoMaterial.xml.
It also does not change any trackingMaterialGroups XML file, but it just places them in a dedicated trackingMaterialGroups_ForPhaseI repo: data/v1/ -> data/trackingMaterialGroups_ForPhaseI/v1, as you suggested in a previous comment

@cvuosalo
Copy link
Contributor

cvuosalo commented Jan 8, 2021

@ghugo83 If I understand correctly, the SpecPar name is is used to group SpecPars together. That is, SpecPars with the same name in different files are all grouped together.

Yes exactly

Otherwise, the SpecPar name is not used. Is that correct?

No, in the codebase apparently, the SpecPar name is sometimes used to access a specific SpecPar directly.
Using DDFilteredView::get<std::vector<std::string>>, specPar(name), etc

@ghugo83 It looks like in the case of the SpecPar names you changed, they are not used anywhere in the code, so it is safe to change the names.

@cvuosalo
Copy link
Contributor

cvuosalo commented Jan 8, 2021

There are a lot of comparison test differences. There are differences in GEM quantities, which would not seem to have anything to do with the PR changes. Some of the differences may just be statistical fluctuations. @ghugo83 Can you comment?

@ghugo83
Copy link
Contributor Author

ghugo83 commented Jan 11, 2021

@ghugo83 It looks like in the case of the SpecPar names you changed, they are not used anywhere in the code, so it is safe to change the names.

Yes it practice, there were few use cases of "hcal' as a SpecPar name, but only for 1 XML (out of the 4 XMLs with same SpecPar names), so I have just renamed the 3 others.

@ghugo83
Copy link
Contributor Author

ghugo83 commented Jan 11, 2021

There are a lot of comparison test differences. There are differences in GEM quantities, which would not seem to have anything to do with the PR changes. Some of the differences may just be statistical fluctuations. @ghugo83 Can you comment?

Yes with 10 events the results themselves, in a sense, are statistical fluctuations.
Though, this should point the dependencies of the PR diff to the results.

This PR should change the ECal SimHits.
It is not clear to me why GEM would be affected though: maybe because once SimHits in a certain area are modified, it can have an impact elsewhere?

@kpedro88
Copy link
Contributor

Any changes in the SIM step will impact the random number sequence, which can cause fluctuations in any detector for any subsequent events.

@ghugo83
Copy link
Contributor Author

ghugo83 commented Jan 11, 2021

Any changes in the SIM step will impact the random number sequence, which can cause fluctuations in any detector for any subsequent events.

Ok thanks for confirming this

@cvuosalo
Copy link
Contributor

I guess we can leave it to the validation process to check whether there is any real problem in the GEMs.

@cvuosalo
Copy link
Contributor

+1

@civanch
Copy link
Contributor

civanch commented Jan 11, 2021

+1

the difference is seen in DD4Hep WF, so it is the bug fix for DD4Hep.

@civanch
Copy link
Contributor

civanch commented Jan 11, 2021

urgent

@srimanob
Copy link
Contributor

+upgrade

To follow up after this PR:

@cmsbuild
Copy link
Contributor

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. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

@qliphy
Copy link
Contributor

qliphy commented Jan 12, 2021

+1

@cmsbuild cmsbuild merged commit 0797983 into cms-sw:master Jan 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants