-
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
Fix some MkFit valgrind warnings, improve loop vectorization #43725
Conversation
…s in producer destructor
…er pools in producer destructor
cms-bot internal usage |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-43725/38426
|
A new Pull Request was created by @dan131riley (Dan Riley) for master. It involves the following packages:
@jfernan2, @mandrenguyen, @cmsbuild can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-1a095e/36874/summary.html Comparison SummarySummary:
|
+1 |
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. @rappoccio, @sextonkennedy, @antoniovilela (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
valgrind memcheck complains about uninitialised values in a few new places where we loop over NN. This PR quiets them, mostly by conditionals on N_proc and partly by initializing some MkFitter structures to 0.0f.
My working theory is that a loop over constant NN with an if on N_proc is more vectorizable than a loop over an unbounded N_proc, since the compiler can infer that N_proc <= NN, and use an N_proc mask to vectorize the loop. Therefore, this PR also switches some loop indices from N_proc to NN + a conditional on N_proc.
This PR also empties the pools of MkFitter/MkBuilder objects in the MkFit producer, to at least partially address #42700. Emptying the pool is thread-safe, so this should be safe when there are multiple instances of MkFit. tbb::concurrent_queue::clear() however is not thread safe, so calling it would require some kind of concurrency protection.
PR validation:
Validation with a standard TTBar PU55-75 showed no significant differences (validation was run multi-threaded, so small differences were not unexpected).