FTF: HitDV optimisation + timers fix
1)For every spacepoint in findHitDV, we are creating a temporary 2-element vector to store one or two clusters. This can be avoided, although not very neatly since there isn't an easy way to iterate over pairs in C++ (they aren't an iterable collection). Hence some lambda functions. There might be a neater way to do this.
2)std::unordered_map<Identifier, int> umap_sp_identifier can be reserved since it's an unordered_map and takes up a contiguous area in memory. I reserve 1.3x number of spacepoints, based on tests with ttbar. The absolute maximum is 2 (2x Identifier per spacepoint).
3)The Python configuration was not adding the UTT histograms for a TrigFastTrackFinder_fullScan instance, since it was expecting jet as the name. Fix this and don't rely on a particular naming convention.
4)Move the total time to the end of findTracks. This way we count UTT processing if it's being done.
- and 2) save about 10% of the
findHitDVmethod time, from 99 ms to 91 ms on ttbar.
Merge request reports
Activity
This merge request affects 1 package:
- Trigger/TrigAlgorithms/TrigFastTrackFinder
This merge request affects 2 files:
- Trigger/TrigAlgorithms/TrigFastTrackFinder/python/TrigFastTrackFinderConfig.py
- Trigger/TrigAlgorithms/TrigFastTrackFinder/src/TrigFastTrackFinder.cxx
Adding @nagano as watcher
added 23.0 Trigger TriggerID review-pending-level-1 labels
-
Athena externals cmake make tests Full details available on this CI monitor view. Check the JIRA CI status board for known problems
-
This merge request affects 1 package:
- Trigger/TrigAlgorithms/TrigFastTrackFinder
This merge request affects 2 files:
- Trigger/TrigAlgorithms/TrigFastTrackFinder/python/TrigFastTrackFinderConfig.py
- Trigger/TrigAlgorithms/TrigFastTrackFinder/src/TrigFastTrackFinder.cxx
Adding @nagano as watcher
-
Athena externals cmake make tests Full details available on this CI monitor view. Check the JIRA CI status board for known problems
added review-approved label and removed review-pending-level-1 label
"it's an unordered_map and takes up a contiguous area in memory", depends what you mean ... but prb is a stretch?
You reserve the buckets here , so the "array " like like part.
See the diagrams
From [https://stackoverflow.com/questions/67435837/implementation-of-bucket-in-unordered-map]
So yea you get rid of the bucket re-allocation and possible re-hashing. But not sure I would call unordered_map contiguous in memory except if you use an allocator that kind of make it so for the nodes also.
Actually the fact that you allocate node of something and not something is why one needs "rebind" for custom allocators but this is another story.
So if the map is giving too many allocations for the elements and fit the fill and the use pattern i.e you do not erase. You could use ArenaSTLPoolAllocators aka put the elements also close together.
Edited by Christos Anastopoulosadded review-approved-point1 label
mentioned in commit 3161673b
mentioned in merge request !63915 (merged)
203 203 addTrackHistograms(montool, name) 204 204 if doResMon: 205 205 addResidualHistograms(montool) 206 if name=='jet': 206 uttMode = flags.Tracking.ActiveConfig.doHitDV or flags.Tracking.ActiveConfig.doDisappearingTrk mentioned in merge request !64092 (merged)
