Simplify VVIObjF object so it takes kappa only in the constructor

[tvami]

PR description:

Resolution to the issue #37529

vvidist was essentially taking 1 parameter so far as well (kappa), now there is a constructor for it that does that alone.

PR validation:

runTheMatrix.py -l 138.4

if this PR is a backport please specify the original PR and why you need to backport that PR:

N/A

Resolves #37529

[tvami]

type performance-improvements

[tvami]

test parameters:

• enable_tests = profiling

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-37533/29245

• This PR adds an extra 40KB to repository

[cmsbuild]

A new Pull Request was created by @tvami (Tamas Vami) for master.

It involves the following packages:

• RecoLocalTracker/SiPixelRecHits (reconstruction)

@jpata, @cmsbuild, @clacaputo, @slava77 can you please review it and eventually sign? Thanks.
@mtosi, @felicepantaleo, @GiacomoSguazzoni, @JanFSchulte, @rovere, @VinInn, @OzAmram, @ferencek, @dkotlins, @gpetruc, @mmusich, @threus, @tvami 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

[tvami]

Except for #37533 (comment) , I changed the PR according to the review, and tested again. It ran fine.

[tvami]

@cmsbuild , please test

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-37533/29246

• This PR adds an extra 40KB to repository

[cmsbuild]

Pull request #37533 was updated. @jpata, @clacaputo, @slava77 can you please check and sign again.

[tvami]

@smuzaffar profiling has been running for a long time now (14hours), is that expected?

[tvami]

@smuzaffar profiling has been running for a long time now (14hours), is that expected?

@smuzaffar so it's been 2 days now, can you look into this please?

[smuzaffar]

@tvami , profiling job is still running for last 16h , may be igprof is hanging somewhere. Since 5am this morning it is running

05:50:03 + igprof -pp -z -o ./igprofCPU_step3.gz -- cmsRun step3_igprof.py

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-980085/23921/summary.html
COMMIT: 4fb03c3
CMSSW: CMSSW_12_4_X_2022-04-14-1100/slc7_amd64_gcc10
Additional Tests: PROFILING
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/37533/23921/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: 0 differences found in the comparisons
• DQMHistoTests: Total files compared: 48
• DQMHistoTests: Total histograms compared: 3593039
• DQMHistoTests: Total failures: 2
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3593015
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 47 files compared)
• Checked 200 log files, 45 edm output root files, 48 DQM output files
• TriggerResults: no differences found

[mmusich]

• phase2 simulation: Total Cumulative(old->new): 937.32 -> 927.92 (-1%)
• run3 simulation: Total Cumulative(old->new): 204.76 -> 205.89 (+0.3%)
• run2 data: Total Cumulative(old->new): 853.33 -> 836.65 (-1.9%)

The reduction in the CPU usage looks sizeable if these numbers are trustable. Wondering why 2021 simulation does not get down, though.

[tvami]

run3 simulation: Total Cumulative(old->new): 204.76 -> 205.89 (+0.3%)

Indeed this is surprising to see. Maybe due to some other changes in the IBs? Should we test again?

[jpata]

I'm never sure if the cumulative numbers can be compared in the igprof bot test (the bot test runs on lxplus AFAIK, which can have other things running on the machine).

Comparing the relative time in VVIObjF might be slightly more informative:

• baseline ~2.1%, https://cmssdt.cern.ch/SDT/cgi-bin/igprof-navigator/CMSSW_12_4_X_2022-04-14-1100/slc7_amd64_gcc10/profiling/11834.21/igprofCPU_step3/125
• this PR ~1.9%, https://cmssdt.cern.ch/SDT/cgi-bin/igprof-navigator/CMSSW_12_4_X_2022-04-14-1100/slc7_amd64_gcc10/profiling/11834.21/PR-980085/23921/igprofCPU_step3/147

in phase2 it's less clear:

• baseline ~2.4%, https://cmssdt.cern.ch/SDT/cgi-bin/igprof-navigator/CMSSW_12_4_X_2022-04-14-1100/slc7_amd64_gcc10/profiling/35234.21/igprofCPU_step3/90
• this PR ~2.4%, https://cmssdt.cern.ch/SDT/cgi-bin/igprof-navigator/CMSSW_12_4_X_2022-04-14-1100/slc7_amd64_gcc10/profiling/35234.21/PR-980085/23921/igprofCPU_step3/90

So overall it looks like a small effect? In the release-to-release profiling, it might be more measurable (those are run on an unloaded benchmark machine).

[mmusich]

So overall it looks like a small effect?

This is more in line with my naive expectations, I would have expected that the bulk of the CPU is taken from evaluating all those trigonometric functions, hence was wondering if the cumulative numbers were trustable.

[tvami]

Hi @cms-sw/reconstruction-l2 shall this PR be merged? Or I should just close it given that it didn't live up to its expectation? :D

[mmusich]

Or I should just close it given that it didn't live up to its expectation? :D

why? even if small, it's better than nothing.

[jpata]

+reconstruction

• technical speed improvement, addresses Potential simplification (and speedup) of Vavilov implementation #37529
• no reco changes

[cmsbuild]

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)

[qliphy]

+1

[jpata]

type tracking

[mmusich]

type -tracking

[mmusich]

type trk