-
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
Clean Propagator and TrajectoryState interface, avoid memory churn #3534
Conversation
A new Pull Request was created by @VinInn (Vincenzo Innocente) for CMSSW_7_1_X. Clean Propagator and TrajectoryState interface, avoid memory churn It involves the following packages: Alignment/KalmanAlignmentAlgorithm @civanch, @diguida, @lveldere, @mdhildreth, @cmsbuild, @anton-a, @thspeer, @rcastello, @giamman, @slava77, @Degano, @nclopezo can you please review it and eventually sign? Thanks. |
destParameters.position(), | ||
destParameters.momentum(), s); | ||
auto const & jacobian = analyticalJacobian.jacobian(); | ||
return std::pair<TrajectoryStateOnSurface,double>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here, in "standard workflows" no memory churn occur, we may try to use default allocator.
1 similar comment
|
||
void deallocate(pointer p, size_type n) | ||
{ | ||
Cache & c = cache(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can you guarantee that the object is deleted on the same thread as it was allocated? The framework does not give the guarantee that one event will only be processed by one thread.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is not and does not matter.
if deleted and not found in the cache its space will not be reused.
a thread will never find an object in the cache that was NOT allocated by it.
-1 --- Registered EDM Plugin: TrackingToolsTrajectoryStateCapabilities >> Leaving Package TrackingTools/TrajectoryState >> Package TrackingTools/TrajectoryState built @@@@ Running edmWriteConfigs for TrackingToolsGsfTrackingPlugins /afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc6_amd64_gcc481/cms/cmssw/CMSSW_7_1_X_2014-04-27-0200/lib/slc6_amd64_gcc481/libTrackingToolsTrackFitters.so: undefined reference to `TrajectoryStateOnSurface::TrajectoryStateOnSurface(LocalTrajectoryParameters const&, LocalTrajectoryError const&, Surface const&, MagneticField const_, SurfaceSideDefinition::SurfaceSide, double)' collect2: error: ld returned 1 exit status >> Deleted: tmp/slc6_amd64_gcc481/src/TrackingTools/GsfTracking/test/GsfMaterialEffectsUpdator_t/GsfMaterialEffectsUpdator_t gmake: *_\* [tmp/slc6_amd64_gcc481/src/TrackingTools/GsfTracking/test/GsfMaterialEffectsUpdator_t/GsfMaterialEffectsUpdator_t] Error 1 gmake: **\* Waiting for unfinished jobs.... Leaving library rule at src/RecoPixelVertexing/PixelTrackFitting/plugins --- Registered EDM Plugin: TrackingToolsGsfTrackingPlugins you can see the results of the tests here: |
sure an why the libs and not been rebuilt? |
+1 for #3534 2ebdc26 Here's one example (similar is in the ele gun, and pretty tiny in the dijet) for muon gun 1 TeV (wf 22.0) |
+1 |
ping |
+1 |
FastSim touched by adaptation to new API. Bypassing signature. Complain if not OK. |
Tracking speedup -- Clean Propagator and TrajectoryState interface, avoid memory churn
This Pull Request encompasses few related improvements
in particular avoids accidental conversion between "double" and "SurfaceSide" and various override issues.
number 3 has now a less striking effect due to the large speed-up of jemalloc itself
no regression expected
no regression observed
latest tests on top of SMatrix improvements that act also in the very same portion of code (construction of TrajectoryState in the AnalyticPropagator "called" from CkfTrajectoryBuilder)