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

Simplify class stucture of hit generators #10016

Merged
merged 10 commits into from Jul 6, 2015

Conversation

makortel
Copy link
Contributor

@makortel makortel commented Jul 2, 2015

Current inheritance chain of the hit generators is somewhat messy, and in some parts does not serve the current usage of the classes. This PR removes unnecessary inheritances and does some further cleanup allowed by the removal.

Essentially, the inheritance from HitPairGenerator is removed from

  • HitPairGeneratorFromLayerPair
  • CombinedHitQuadrupletGeneratorForPhotonConversion
  • HitQuadrupletGeneratorFromLayerPairForPhotonConversion
  • CosmicHitPairGenerator
  • CosmicHitPairGeneratorFromLayerPair,

the inheritance from HitTripletGenerator from

  • HitTripletGeneratorFromPairAndLayers
  • CosmicHitTripletGenerator
  • CosmicHitTripletGeneratorFromLayerTriplet,

and the inheritance from MultiHitGenerator from

  • MultiHitGeneratorFromPairAndLayers.

(Most of the developments were actually done already more than a year ago, but for some reason I didn't push them for integration and they got buried under other stuff)

Tested in 750pre5, no changes expected in results.

@rovere @VinInn

…tor and CosmicHitTripletGeneratorFromLayerTriplet

These classes do not benefit from the base classes
(HitTripletGenerator, OrderedHitsGenerator). The classes are not
registered to any plugin factory, and hence can be constructed only
explicitly. The only user (SeedGeneratorForCosmics) use the type
CosmicHitTripletGenerator explicitly, so there is no need for dynamic
polymorphism from there either.
…ratorForPhotonConversion

CombinedHitQuadrupletGeneratorForPhotonConversion does not really benefit
from the base classes, and the sole user
(PhotonConversionTrajectorySeedProducerFromQuadrupletsAlgo) uses the
concrete type explicitly, so no need for dynamic polymorphism either.
In fact, now we can remove the non-implemented methods that are pure
virtual in the base class.
…mLayerPairForPhotonConversion

HitQuadrupletGeneratorFromLayerPairForPhotonConversion does not really
benefit from the base classes, and the only user
(CombinedHitQuadrupletGeneratorForPhotonConversion) uses the type
explicitly, so there is no need for dynamic polymorphism either. In
fact, now we can remove the non-implemented methods that are pure
virtual in the base class.
CosmicHitPairGenerator does not benefit from the base class, and the
users (SeedGeneratorForCRack and SeedGeneratorForCosmics) use the
concrete types, so there is no need for dynamic polymorphism either.
In fact, now we can remove some unneeded methods that are pure virtual
in the base class.
…mLayerPair

CosmicHitPairGeneratorFromLayerPair does not benefit from base
classes, and the user (CosmicHitPairGenerator) uses the type
explicitly, so there is no need for dynamic polymorphism either. In
fact, we can now remove some unnecessary methods that were pure
virtual in the base class.
…rAndLayers

MultiHitGeneratorFromPairAndLayers does not really benefit from the
base class, and the user (CombinedMultiHitGenerator) use it as the
base class type for dynamic polymorphism. Now we can also remove some
unneeded methods that are pure virtual in the base class.
…mPairAndLayers

HitTripletGeneratorFromPairAndLayers does not really benefit from the
base class, and the user (CombinedHitTripletGenerator) use it as the
base class type for dynamic polymorphism. Now we can also remove some
unneeded methods that are pure virtual in the base class.
…Pair

HitPairGeneratorFromLayerPair does not really benefit from the base
class. The users in practice use exactly this class (and not other
classes inheriting from HitPairGenerator), so they can safely be
modified to use the concrete type eliminating the need for dynamic
polymorphism. Also the HitPairGenerator::setSeedingLayers() can now be
removed as its asserting implmentation in CombinedHitPairGenerator.
@slava77
Copy link
Contributor

slava77 commented Jul 2, 2015

@cmsbuild please test
[not sure where the labels are, could be the bot didn't look at it yet, unless it's stuck]

@cmsbuild cmsbuild added this to the Next CMSSW_7_6_X milestone Jul 2, 2015
@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 2, 2015

The tests are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 2, 2015

A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_7_6_X.

Simplify class stucture of hit generators

It involves the following packages:

RecoPixelVertexing/PixelLowPtUtilities
RecoPixelVertexing/PixelTriplets
RecoTracker/ConversionSeedGenerators
RecoTracker/TkHitPairs
RecoTracker/TkSeedGenerator

@cmsbuild, @cvuosalo, @slava77 can you please review it and eventually sign? Thanks.
@ghellwig, @GiacomoSguazzoni, @rovere, @VinInn, @mschrode, @cerati, @gpetruc, @istaslis, @dgulhan this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@Degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

@VinInn
Copy link
Contributor

VinInn commented Jul 2, 2015

Lovely!

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 5, 2015

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

@makortel
Copy link
Contributor Author

makortel commented Jul 6, 2015

I have no idea how these changes could affect (the performance of) SiPixelClusterProducer, so the improvement is probably a fluctuation.

@davidlange6
Copy link
Contributor

+1

@slava77
Copy link
Contributor

slava77 commented Jul 6, 2015

On 7/6/15 1:05 AM, Matti Kortelainen wrote:

I have no idea how these changes could affect (the performance of)
|SiPixelClusterProducer|, so the improvement is probably a fluctuation.

this is quite likely from the database latency.

Carl, how did the memory look like?
That part is more interesting, considering the restructuring in the
class structure.


Reply to this email directly or view it on GitHub
#10016 (comment).

@cvuosalo
Copy link
Contributor

cvuosalo commented Jul 7, 2015

@Slava:
There were small to negligible memory changes in the comparison against baseline CMSSW_7_6_X_2015-07-02-1100 for workflow 25202.0_TTbar_13. Here they are:

Summary for 70 events
Baseline
Max VSIZ 3685.8 on evt 48 ; max RSS 3106.8 on evt 28

PR 10016
Max VSIZ 3685.85 on evt 33 ; max RSS 3099.8 on evt 28

Product size

or, B new, B delta, B delta, % deltaJ, % branch
111448 -> 111697 249 0.2 0.01 TrackingRecHitsOwned_generalTracks__RECO.
2181334 -> 2181555 221 0.0 ALL BRANCHES

@slava77
Copy link
Contributor

slava77 commented Jul 7, 2015

On 7/7/15 10:40 AM, Carl Vuosalo wrote:

@Slava https://github.com/slava:
There were small to negligible memory changes in the comparison against
baseline CMSSW_7_6_X_2015-07-02-1100 for workflow 25202.0_TTbar_13. Here
they are:

Summary for 70 events
Baseline
Max VSIZ 3685.8 on evt 48 ; max RSS 3106.8 on evt 28

PR 10016
Max VSIZ 3685.85 on evt 33 ; max RSS 3099.8 on evt 28

Thanks.
So, there may be a 7MB decrease.
As long as these downward "fluctuations" are accumulating, we are good.

Product size

or, B new, B delta, B delta, % deltaJ, % branch
111448 -> 111697 249 0.2 0.01 TrackingRecHitsOwned_generalTracks__RECO.
2181334 -> 2181555 221 0.0 ALL BRANCHES


Reply to this email directly or view it on GitHub
#10016 (comment).

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

6 participants