Improve HLT2 throughput
The throughput on mu=5 data on the EFF is about a factor 2 lower than needed to not fill the buffer quickly: https://lblogbook.cern.ch/HLT/829
This issue is to document what measures will gain how much in throughput. A throughput test on 2024 data is being set up here: lhcb-core/LHCbNightlyConf!1212 (merged)
Preliminary list:
-
Is the processing time dominated by a few (very) large events? How much would a GEC gain us in that case? -
Are the number of combinations in some lines still an issue? Is there an improvement by lowering it more here -
How much does the fast
reconstruction gain us? -
How much does switching on the optimized control flow gain? -> expect 15% from throughput tests. Included in https://gitlab.cern.ch/lhcb/Moore/-/releases/v55r8p1 -
Can we reproduce the 10% gain of !3383 (merged) in data? -> yes -
Can we use the less slow clone killing in the HybridSeeding? (3% of whole sequence) !3507 (merged) -
more cpu-efficient PV functors !2886 -
TBTC is used for fitting, solved by Rec!3659 (merged) -
ReserveIOVDD4hep is on rank 5 in the timing table! (listed under Framework in FlameBars) -
something still uses the slow TrackCloneKiller (gone) -
CheckOverlap of the NBodyParticleCombiner takes more than 3% (and seems to allocate?) Rec!3941 (merged) -
tightening ghostprob (safely according to real data studies) to 0.5 !3498 (merged) -
tightening clone removal (removes clones seen by @gciezare in semileptonic data) !3526 (merged) -
reduce extrapolations by using SDOCA (!3196 (merged)) -
do we profit a lot from tcmalloc? -> around 3% MooreOnline!442 (closed)
@mveghel @dovombru @gunther @msaur @cmarinbe @mvesteri @poluekt
Edited by Andre Gunther