Speedup ECAL (for HLT)

[VinInn]

two independent speedups.
use cached eta,phi for CaloCell
remove redundant computations in EcalUncalibRecHitWorkerMultiFit.
No regression observed.
http://innocent.home.cern.ch/innocent/regress/pu35_SpeedECAL
(for HLT, no difference in TriggerResult)

[cmsbuild]

A new Pull Request was created by @VinInn (Vincenzo Innocente) for CMSSW_8_1_X.

It involves the following packages:

Geometry/EcalMapping
RecoEcal/EgammaClusterAlgos
RecoEcal/EgammaCoreTools
RecoEgamma/EgammaHLTProducers
RecoLocalCalo/EcalRecProducers

@perrotta, @cmsbuild, @civanch, @Dr15Jones, @cvuosalo, @fwyzard, @ianna, @mdhildreth, @Martin-Grunewald, @slava77, @davidlange6 can you please review it and eventually sign? Thanks.
@ghellwig, @Sam-Harper, @argiro, @rafaellopesdesa, @lgray this is something you requested to watch as well.
@slava77, @Degano, @smuzaffar you are the release manager for this.

cms-bot commands are list here #13028

[VinInn]

@cmsbuild, please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/12344/console

[cmsbuild]

+1
Tested at: 9186b97
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-14048/12344/summary.html

The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:
d93ee85
You can see more details here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-14048/12344/git-log-recent-commits
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-14048/12344/git-merge-result

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-14048/12344/summary.html

[cvuosalo]

In CosmicClusterAlgo.cc on line 230, a variable called chi2 is defined, and operations are performed on it, but it is never used, as reported by the static analyzer. It would be good to delete it in this PR or a later one.

[Martin-Grunewald]

+1

[ianna]

+1

[cvuosalo]

An extended test of workflow 25202.0_TTbar_13 with 70 events against baseline CMSSW_8_1_X_2016-04-12-2300 shows no significant differences. CPU time decreases only marginally, and memory usage does not change significantly.

In the HLT and RECO steps there appear to be some small timing improvements. Times not including the first event:

  delta/mean delta/orJob     original                   new       module name
  ---------- ------------     --------                  ----       ------------
  -0.964020      -0.00%         1.48 ms/ev ->         0.52 ms/ev hltRechitInRegionsECAL
  -0.187550      -0.01%        32.05 ms/ev ->        26.55 ms/ev hltEcalUncalibRecHit
  -0.058299      -0.05%       118.40 ms/ev ->       111.69 ms/ev ecalMultiFitUncalibRecHit

Overall CPU time doesn't change significantly.

[fwyzard]

One should not measure the HLT timing on ttbar events, but rather on a realistic mixture of L1-accepted minimum bias events.

Still, 5.5 ms gain would be quite significant for the nominal HLT budget (~200 ms/ev). What is the total you see for the HLT on these events ?

[slava77]

@fwyzard
I think that per-module differences should be descriptive of what is happening in HLT for that specific module even in the realistic setup.
The numbers are not meant to give an absolute value change due to trigger/prescale weights.

[fwyzard]

I think that per-module differences should be descriptive of what is happening in HLT for that specific module even in the realistic setup.

Agreed. But I do not know by heart the time spent in those modules in the actual HLT, so I do not know how to scale the 5.5ms gain with respect to the total HLT budget.

[cvuosalo]

@fwyzard: I see a total of about 400 ms/ev for modules with HLT in their names for this ttbar workflow, but I don't know what part of the total HLT budget they represent. These results should be taken only as an indication that this PR may have achieved some speed up of HLT, but certainly not as any definitive timing measurement.

[cvuosalo]

+1

For #14048 9186b97

Speed-ups for ECAL HLT. There should be no change in monitored quantities.

The code changes are satisfactory, and Jenkins tests against baseline CMSSW_8_1_X_2016-04-12-2300 show no significant differences, as expected. Extended tests are discussed above, and they show some timing improvement with no other problems.

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_8_1_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @Degano, @smuzaffar

[davidlange6]

+1