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

Run G4 workers on their own dedicated threads #34899

Merged
merged 6 commits into from Aug 19, 2021

Conversation

Dr15Jones
Copy link
Contributor

PR description:

Each G4 worker now runs on its own thread. Each stream has its own thread and when the stream needs to do work it blocks the TBB thread and starts up its dedicated thread.

This should allow SimWatchers to be modified to call esConsumes.

PR validation:

Code compiles and a simple workflow runs.

@Dr15Jones
Copy link
Contributor Author

@makortel FYI

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-34899/24707

  • This PR adds an extra 28KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @Dr15Jones (Chris Jones) for master.

It involves the following packages:

  • SimG4Core/Application (simulation)

@cmsbuild, @civanch, @mdhildreth can you please review it and eventually sign? Thanks.
@makortel, @cvuosalo, @rovere, @bsunanda, @fabiocos, @slomeo this is something you requested to watch as well.
@perrotta, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

@Dr15Jones
Copy link
Contributor Author

please test

@cmsbuild
Copy link
Contributor

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-99abab/17811/summary.html
COMMIT: e058dfb
CMSSW: CMSSW_12_1_X_2021-08-16-1100/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/34899/17811/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

  • No significant changes to the logs found
  • Reco comparison results: 55303 differences found in the comparisons
  • DQMHistoTests: Total files compared: 39
  • DQMHistoTests: Total histograms compared: 3000352
  • DQMHistoTests: Total failures: 296373
  • DQMHistoTests: Total nulls: 238
  • DQMHistoTests: Total successes: 2703719
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: -11.625 KiB( 38 files compared)
  • DQMHistoSizes: changed ( 10224.0 ): -0.117 KiB SiStrip/MechanicalView
  • DQMHistoSizes: changed ( 250202.181 ): -0.410 KiB SiStrip/MechanicalView
  • DQMHistoSizes: changed ( 25202.0 ): -0.543 KiB SiStrip/MechanicalView
  • DQMHistoSizes: changed ( 312.0 ): 0.004 KiB MessageLogger/Warnings
  • DQMHistoSizes: changed ( 7.3 ): -9.066 KiB SiStrip/MechanicalView
  • DQMHistoSizes: changed ( 8.0 ): -1.493 KiB SiStrip/MechanicalView
  • Checked 165 log files, 37 edm output root files, 39 DQM output files
  • TriggerResults: found differences in 11 / 38 workflows

@civanch
Copy link
Contributor

civanch commented Aug 17, 2021

@Dr15Jones , I would expect regression for this change or we change random seed?

@Dr15Jones
Copy link
Contributor Author

@civanch

I would expect regression for this change or we change random seed?

Given the tests run single threaded, I would have expected exact comparisons. I'm making a change now where I properly propagate the random number seed to the new threads. Let's see if that avoids the differences.

@civanch
Copy link
Contributor

civanch commented Aug 17, 2021

@Dr15Jones , there is a simple method fully control random seeds. I would suggest to use it in the first place. For that, in OscarMTProducer uncomment line 217 and make line 216 and 217 edm::LogWarning.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-34899/24723

  • This PR adds an extra 28KB to repository

@cmsbuild
Copy link
Contributor

Pull request #34899 was updated. @cmsbuild, @civanch, @mdhildreth can you please check and sign again.

@Dr15Jones
Copy link
Contributor Author

please test

@cmsbuild
Copy link
Contributor

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-99abab/17829/summary.html
COMMIT: bb5bf39
CMSSW: CMSSW_12_1_X_2021-08-17-1100/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/34899/17829/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

  • No significant changes to the logs found
  • Reco comparison results: 9 differences found in the comparisons
  • DQMHistoTests: Total files compared: 39
  • DQMHistoTests: Total histograms compared: 3000352
  • DQMHistoTests: Total failures: 11
  • DQMHistoTests: Total nulls: 1
  • DQMHistoTests: Total successes: 3000318
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.004 KiB( 38 files compared)
  • DQMHistoSizes: changed ( 312.0 ): 0.004 KiB MessageLogger/Warnings
  • Checked 165 log files, 37 edm output root files, 39 DQM output files
  • TriggerResults: no differences found

@Dr15Jones
Copy link
Contributor Author

The DQM histogram differences are all from the MessageLogger and the reco differences are a known reproducibility problem caused by an uninitialized variable.
So the tests look good.

@@ -165,7 +177,13 @@ OscarMTProducer::OscarMTProducer(edm::ParameterSet const& p, const OscarMTMaster
edm::LogVerbatim("SimG4CoreApplication") << "OscarMTProducer is constructed";
}

OscarMTProducer::~OscarMTProducer() {}
OscarMTProducer::~OscarMTProducer() {
auto token = edm::ServiceRegistry::instance().presentToken();
Copy link
Contributor

Choose a reason for hiding this comment

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

@Dr15Jones , is it safe calling edm::ServiceRegistry::instance() in a destructor? May be better keeping the pointer as a class member?

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 framework guarantees that it is safe to use the Service system in module destructors.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1

If the framework guarantee the order of destruction, it is fine.

@Dr15Jones
Copy link
Contributor Author

@civanch if you intended to approve the whole pull request (and not just the one comment) you have to do the + and 1 as a top level comment.

@civanch
Copy link
Contributor

civanch commented Aug 18, 2021

+1

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

@perrotta
Copy link
Contributor

+1

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

4 participants