Status of the HLT1 sequence and a path towards 30 MHz

Transcription

1 LHCb-PUB April 2, 2018 Status of the HLT1 sequence and a path towards 30 MHz Michel De Cian 1, Agnieszka Dziurda 2, Vladimir V. Gligorov 3, Christoph Hasse 2, Wouter Hulsbergen 4, Thomas Latham 5, Sebastien Ponce 2, Renato Quagliani 3, Henry Schreiner 6, Simon Stemmle 7, Jeroen Van Tillburg 4, Mike Williams 8, Milosz Zdybal 9 LHCb-PUB /03/ Institute of Physics, Ecole Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland 2 European Organization for Nuclear Research (CERN), Geneva, Switzerland 3 LPNHE, Sorbonne Université et Université Paris Diderot, CNRS/IN2P3, Paris, France 4 Nikhef National Institute for Subatomic Physics, Amsterdam, The Netherlands 5 Department of Physics, University of Warwick, Coventry, United Kingdom 6 University of Cincinnati, Cincinnati, OH, United States 7 Physikalisches Institut, Ruprecht-Karls-Universität Heidelberg, Heidelberg, Germany 8 Massachusetts Institute of Technology, Cambridge, MA, United States 9 Henryk Niewodniczanski Institute of Nuclear Physics Polish Academy of Sciences, Kraków, Poland Abstract We present the current status of the HLT1 reconstruction sequence for the LHCb upgrade, both in terms of the number of events which can be processed per second and the achievable physics performance on a selected range of benchmark modes. We present detailed profiling of the various algorithms, describe the bottlenecks, and outline a strategy towards an HLT1 able to process the LHCb upgrade data at 30 MHz.

2

3 Introduction The LHCb detector will be upgraded during the second long shutdown of the LHC (LS2), which will take place between 2019 and The primary objective of this upgrade is to allow LHCb to take data at an instantaneous luminosity of cm 2 s 1 and to process the full 30 MHz of LHC bunch crossings ( events ) in a dedicated computing centre without any fixed latency preselection ( hardware trigger ). Events are built within a dedicated bidirectional network of around 500 servers, before being sent for processing to an Event Filter Farm (EFF). The EFF is designed to execute a fast reconstruction on the full event rate; to perform a fast preselection which reduces this event rate by a factor between 30 and 100 while efficiently keeping those events which contain interesting physical processes; and to subsequently perform a full detector reconstruction and realtime analysis on this subset of selected events. The fast reconstruction and selection stage is referred to as HLT1, while the full reconstruction and real-time analysis stage is referred to as HLT2. Between those stages the real-time alignment and calibration are performed. These objectives and the upgraded LHCb detector are described in more detail in the LHCb upgrade framework TDR [1] and Trigger TDR [2]. The evolution of the HLT1 performance is regularly followed to make sure it meets the design objectives outlined above. The latest such performance update [3] indicated that HLT1 could only process between 3.5 and 5 MHz of events, depending on assumptions, because of a worse than anticipated scaling of the price/performance of x86 architectures. Over the last two years LHCb has rewritten its underlying software framework in order to take better advantage of modern highly parallel x86 architectures and recover some of this shortfall. In this note we update the latest status of the HLT1 processing performance, both in terms of the event rate which can be processed and in terms of the expected physics performance of this processing. We document a detailed profiling of the relevant algorithms and identify the remaining bottlenecks which stand in the way of being able to process data at 30 MHz. The work presented in this note builds on both the new software framework, which is documented more fully in the Computing TDR [4], as well as on research work carried out over the last years into the optimal use of highly parallel computing architectures [5 7]. 2 Assumptions and data sets used in this note The throughput performance of HLT1 is evaluated using a dedicated benchmarking machine. The time taken to process a given number of events is calculated from the start and end times of each algorithm, as monitored by the GAUDI Timeline service. The same reconstruction sequence is executed multiple times, loading the machine with different numbers of reconstruction jobs and assigning a different number of threads to each job. In this way, the maximum achievable throughput is found. Data for the throughput tests is read from the local disk of the benchmarking machine, to reduce I/O overheads to a minimum. Algorithm profiling is done using a mixture of valgrind [8] and vtune. Data used for the thorughput tests are simulated minimum bias events with Global Event Cuts (GEC) already applied. Because there is not yet any thread-safe framework for performing selections in HLT1, physics performance is evaluated by recording the charged particle trajectories 1

4 Table 1: Selection criteria applied to signal samples when defining the efficiency denominator. Particle Criterion Parent hadron p T > 2 GeV 2 < η < 5 τ > 0.2 ps Children p T > 0.2 GeV 2 < η < 5 K 0 S children decay before UT ( tracks )foundbythereconstructiontorootntuples[9], andemulatinghlt1selections offline. Because the evaluated selections consist of selecting a single track or two-track vertex, experience shows that there is almost no overhead associated with candidate combinatorics 1 and so this offline performance evaluation is not unrealistic. The reconstruction sequence performance on the benchmarking node is converted into an overall throughput by assuming that 1000 such nodes will form the 2021 EFF. This is conservative for two reasons. Firstly, the benchmarking machine is a 2015 model, so the 1000 nodes which we will be able to afford to buy in 2021 will have better performance; a factor of up to 1.5 does not seem entirely unrealistic. Secondly, LHCb currently has an EFF consisting of around 1800 nodes. While many of these will be too old for use in the upgrade, around 1000 which correspond to the benchmarking machine performance may be reusable, depending on how well the hardware holds up over the next years. Taken together these would result in an overall scaling factor of 2.5 which could be applied to the presented throughput. However, in order to leave a safety margin in the design, we set ourselves the goal of reaching 30 MHz without this factor 2.5, and therefore do not apply it when presenting numbers in the rest of this note. Throughput numbers are evaluated on a set of 14 TeV minimum bias events generated at cm 2 s 1. Only events with fewer than total hits in the UT and SciFi subdetectors are used for evaluating performance, as experience shows that events with a high occupancy cost much more in reconstruction resources than they bring in signals. Signal efficiencies are evaluated using dedicated simulated samples of a representative set of signalsofinterest. TheloosecriteriagiveninTab.1areappliedtothesignalparticleandits decay products, mostly to remove those signal decays which do not fall within the detector acceptance 2 < η < 5. The same event occupancy cut applied to minimum bias is also applied to the signal events. The use of UT and SciFi hit multiplicity for this occupancy criterion is a matter of convenience. In the final implementation the subdetectors will provide an event header containing this information, so that the occupancy criterion can be applied without requiring any decoding or clustering of subdetector raw banks and hence with a negligible CPU cost. 1 Overheads can include the cost of fitting the candidate vertices, evaluating their mass under different hypotheses for the tracks, and so on. In this case because very few tracks are preselected by the reconstruction, and because at most two tracks are combined at a time, the cost is negligible. 2

5 Physics goals and reconstruction requirements The objective of the HLT1 processing is to reduce the event rate to a level at which the full detector reconstruction can affordably be run in HLT2 while remaining as efficient as possible on the full range of signals analysed by LHCb physicists. In practice this means that HLT1 must be able to reconstruct and select at least the following signatures: 1. Tracks or two-track vertices displaced from the primary pp interaction (PV). This signature can be used to select any event containing a long-lived hadron or τ lepton, which covers the vast majority of LHCb analyses (by number, if not by importance). 2. Leptons, and particularly muons, regardless of their displacement from the PV. Displaced leptons can be selected as any other track, although the efficiency can be kept higher for the same output rate by using lepton identification criteria to allow displacement or transverse momentum criteria to be loosened. Non-displaced leptons are particularly important for spectroscopy studies, exotic searches, and electroweak physics. The reconstruction sequence evaluated in this note does not include lepton identification, because the algorithm is not presently available within the upgrade software framework. For this reason only the first, displaced, category of signatures is considered. Experience with the current detector shows that if those can be reconstructed and selected, special reconstructions and selections for prompt leptons with the same kinematic coverage can generally be added for a small fraction of the required resources. While this must still be validated in upgrade conditions, we do not expect that this omission makes the presented results significantly unrepresentative. 4 Reconstruction sequence The HLT1 reconstruction sequence evaluated in this note closely follows the displaced track reconstruction fallback scenario planned for in the Trigger TDR [10]. A schematic view of the LHCb tracking system and visualization of different type of tracks are shown in Fig. 1. As it is a tracking sequence and as lepton identification is not considered, only the VELO, UT, and SciFi subdetectors are used. The evaluated sequence consists of the following processing steps: 1. Decoding and clustering of the VELO raw data; 2. Decoding of the UT raw data, which already contains clusters; 3. Decoding of the SciFi raw data, which already contains clusters; 4. Sorting of the VELO, UT, and SciFi clusters in a way which makes them useful for the subsequent reconstruction algorithms; 5. Finding of tracks in the VELO; 6. Building of PVs from VELO tracks; 7. Selection of VELO tracks with a displacement greater than 100 µm from the PVs; 3

6

7 Algorithm name Input Output createutliteclusters UT raw data UT clusters PrStoreUTHit UT Clusters UT Hits for PR createftliteclusters SciFi raw data FT clusters PrStoreFTHit SciFi Clusters SciFi Hits for PR VPClustering VELO raw data VELO clusters for PR PrPixelTrackingFast VELO clusters VELO tracks PatPV3D VELO tracks PVs VELO-UT VELO tracks, UThits VELO-UT tracks PrForwardTracking Fast VELO-UT tracks and SciFi hits Forward tracks ParameterizedKalmanFit Forward tracks and their clusters Fitted Forward tracks Table 2: The algorithms used in the reconstruction sequence and their data dependencies. PR stands for pattern recognition PrStoreFTHit: prepare SciFi hits for pattern recognition. See App. B VPClustering: clustering of VELO raw data and preparation of clusters for pattern recognition. Unlike with the UT and SciFi it is assumed that the VELO will not be able to find all clusters at the FPGA level, and this algorithm therefore performs cluster finding as well as decoding and sorting. See App. C PrPixelTrackingFast: pattern recognition and simplified Kalman fit of VELO tracks using VELO clusters as input. More details about this algorithm can be found in App. D. PatPV3D: reconstruction of primary vertices using the VELO tracks. See App. E PrVELOUT: extend displaced VELO tracks (based on their IP to the reconstructed PVs) to the UT detector creating VELO-UT tracks. The IP criterion will be moved outside this algorithm as soon as a thread-safe selection framework is available. See App. F PrForwardTracking: extend VELO-UT tracks to SciFi detector creating Forward tracks. See App. G ParameterizedKalmanFit: aparametarizedkalmanfitoftheforwardtracksenabling their χ 2 to be used as a selection criterion. 5 Sequence throughput The throughput of the presented HLT1 sequence is shown in Fig. 2 for a range of jobs and threads on the benchmarking machine. The optimal performance is found at 2 jobs and 20 threads per job, and leads to a throughput of 12.4 khz for the benchmarking machine or 12.4 MHz for the assumed EFF in total. As the plot makes clear, the move to a multithreaded processing framework has gained around 20% in processing throughput. The breakdown in the resource usage by reconstruction algorithm at the peak throughput performance is shown in Fig. 3 for the whole sequence. As can be seen, around 50% 5

8

9

10 181 6 Physics performance 182 The physics performance of the sequence is evaluated based on two selection algorithms, 183 one based on finding a single displaced track with high transverse momentum, and a 184 second based on finding a two-track vertex with significant displacement and transverse 185 momentum. These algorithms take as their input Forward tracks which have been 186 processed by the parameterized Kalman fit, and which have a distance of closet approach 187 (impact parameter, or IP) of at least 100 µm from every PV in the event. We do not 188 distinguish between selecting an event because of the presence of signal particles or 189 selecting an event because of the presence of other interesting tracks in the event, for 190 example tracks produced from the other beauty or charm hadron. The combined HLT1 191 algorithm is based on a logical OR of the one- and two-track selections. 192 The one-track trigger is based on a two-dimensional hyperbolic criterion in track transverse momentum and the χ 2 of the track s IP (χ IP ). This criterion is the same as 194 used during Run 2 data taking and presented in Equation 1 of [11]. Just like in that note, 195 the criterion is adjusted for upgrade conditions by shifting the track transverse momentum 196 p T p T α where α is a tunable parameter used to balance the signal efficiency and 197 output rate. 198 The two-track trigger is based on applying a simple set of rectangular selection criteria 199 to two-track vertices. Unlike in [11] the restrictive criteria applied in the track reconstruc- 200 tion, in particular the combination of the IP and transverse momentum requirements, 201 mean that just demanding two such tracks dramatically reduces the rate. It is therefore 202 unnecessary to apply multivariate criteria in order to further control the rate, and simple rectangular selection criteria are applied on the two-track vertices instead There is currently no good estimate of what resources a hypothetical HLT2 reconstruc- 205 tion would require, and therefore no way to accurately judge what rate of events HLT1 206 can be allowed to output. We therefore choose two scenarios, with HLT1 output rates of MHz and 500 khz respectively, to give some idea of how the efficiencies would evolve for 208 looser or tighter putative HLT1 selections. Because the track preselection is so restrictive, 209 the loose scenario is based purely on relaxing the one-track criteria, as there is little room 210 to loosen the two-track. The selection criteria are presented in Tab. 3 while the signal 211 efficiencies for each rate are presented in Tab. 4. Finally, Fig. 6 shows the efficiency as a 212 function of transverse momentum and proper decay time for two representative signals. 213 The tighter reconstruction allows the efficiency for the majority of b-hadron physics 214 signals to be kept above 50% in the loose scenario, despite no stringent offline selection 215 criteria being applied to these samples. Moreover b-hadron efficiencies are relatively 216 robust against requiring the tight configuration, with most signals losing between 10 20% 217 relative efficiency. We also note that muonic b-hadron signals can be efficiently triggered 218 even without muon identification, although their efficiencies will of course get even better 219 once this powerful discriminant is available. 220 The story is rather different for charm physics and exotic or strange signals, whose 221 efficiencies are both significantly lower and significantly more reliant on being able to run 222 with a loose HLT1 configuration. It is however worth repeating that the reconstruction 2 Because high p T tracks have a better impact parameter resolution than low momentum ones, a requirement applied on the raw IP is proportionally much tighter for them. This is why one would ideally like to avoid applying IP cuts before reconstructing Forward tracks, even if it is possible to maintain much of the physics performance in this configuration. 8

11 Table 3: Selection criteria for the one- and two-track selections. The m corr criterion is the p T corrected mass of the vertex, used to select vertices which are likely to originate from the decays of flavoured hadrons. Trigger Criterion One-track α = 0.55 GeV (loose) α = 1.15 GeV (tight) track χ 2 < 2.5 Two-track track χ 2 IP > 6 track χ 2 < 2.5 vertex p T > 1 GeV vertex χ 2 < 10 vertex 2 < η < 5 1 < m corr < 10 GeV Table 4: Efficiencies of the HLT1 selection for the loose and tight HLT1 configurations. The one-track and combined efficiencies are quoted for the loose (tight) configurations. The efficiency of the UT+FT occupancy requirement (GEC) is included in the subsequent efficiencies. All efficiencies are quoted in percentages. Signal GEC One-track Two-track Combined Bs 0 µ + µ (68) (69) B 0 K 0 µ + µ (51) (63) B 0 K 0 l + l (37) (48) B + D 0 (KSπ 0 + π )K (46) (54) B 0 D + D (26) (38) B 0 K π (60) (61) B 0 KSπ 0 + π (43) (48) Bs 0 φφ (35) (54) Bs 0 φγ (21) (32) B 0 D + τ (π π π + ν τ )ν τ (20) (32) B 0 D + τ (µ ν τ ν µ )ν τ (41) (52) D 0 K + K (11) 7 22 (15) D 0 K π π + π (5) 5 12 (8) D 0 KSπ 0 + π (6) 5 15 (9) Σ pµ + µ 89 9 (4) 1 10 (5) K 0 S µ + µ (2) 1 22 (3) τ µ + µ µ (10) (15) sequence presented here implements the displaced track reconstruction backup scenario planned for in the trigger TDR [10] and corresponds to a looser version of the Run 1 LHCb reconstruction. While the requirement of high p T tracks which have 100 µm of IP is inefficient for charm and light-quark signals compared to the Run 2 sequence, the 9

12 efficiency efficiency τ [ps] p [MeV] T Figure 6: Combined HLT1 efficiency as a function of (left) hadron decay time and (right) hadron transverse momentum. The efficiency is shown for (blue) B 0 s φφ and (red) D 0 K 0 Sπ + π. Open and closed circles correspond to the tight and loose HLT selections, respectively removal of the hardware trigger criteria means that the upgrade sequence is still more efficient as a whole. We would of course like to do even better and remove or at least loosen this IP threshold and lower the tracking p T threshold. In this respect it is actually encouraging that the sequence is currently bottlenecked by data preparation and the VELO reconstruction, since improvements to these would allow the IP and p T thresholds to be relaxed even without improvements to the VELO-UT or Forward reconstruction. Of course improvements to the VELO-UT and Forward reconstruction would also be important, particularly in creating room to integrate the muon reconstruction and identification into the sequence. 7 Conclusion and outlook Wehavepresentedthephysicsperformanceandthroughputofthebestcurrentlyachievable HLT1 reconstruction sequence for the LHCb upgrade, which can process 12.4 MHz of events while maintaining signal efficiencies of around 40-75% for beauty and 10-20% for charm hadron decays for HLT1 output rates between 0.5 and 1 MHz. We have demonstrated that the throughput of this reconstruction sequence is equally limited by the data preparation and pattern recognition components of the sequence, and we have presented a detailed profiling of the relevant algorithms and highlighted areas where improvements can be expected. We have also drawn attention to where improvements will require changing what information is stored or passed between reconstruction algorithms, which should be taken into consideration when designing a new event model for the LHCb upgrade. Finally we note that although not yet at 30 MHz, the presented sequence represents a significant step forward from that evaluated in the last biannual performance review [3], with a roughly threefold improvement in throughput. This throughput comes at a cost of physics performance for prompt, charm and light-quark physics, and further work is required to both achieve a 30 MHz throughput and to be able to remove or loosen the displacement and transverse momentum criteria inside the reconstruction. We hope that this note will serve as a useful documentation to guide this effort. 10

13 Acknowledgements Vladimir V. Gligorov and Renato Quagliani acknowledge funding from the European ResearchCouncil(ERC)undertheEuropeanUnion shorizon2020researchandinnovation programme under grant agreement No RECEPT. Thomas Latham is supported by the Science and Technology Facilities Council (STFC), United Kingdom. Mike Williams is supported by U.S. NSF grant PHY We express our gratitude to our colleagues in the LHCb computing and online teams, both for their work on the new software framework which has enabled this work and for their pedagogical guidance in the optimal use of parallel computing architectures. We would also like to thank Ben Couturier and Maciej Pawel Szymanski for their work on an automated infrastructure for benchmarking the throughput and physics performance of our software. References [1] LHCb collaboration, Framework TDR for the LHCb Upgrade: Technical Design Report, CERN-LHCC LHCb-TDR-012. [2] LHCb collaboration, LHCb Trigger and Online Technical Design Report, CERN- LHCC LHCb-TDR-016. [3] R. Aaij et al., Upgrade trigger: Biannual performance update, Tech. Rep. LHCb- PUB CERN-LHCb-PUB , CERN, Geneva, Feb, [4] C. Bozzi, Upgrade Software and Computing, Tech. Rep. CERN-LHCC LHCB-TDR-017, CERN, Geneva, Mar, [5] D. H. Prez Cmpora, LHCb Kalman Filter cross architecture studies, J. Phys. Conf. Ser. 898 (2017), no [6] F. Lemaitre, B. Couturier, and L. Lacassagne, Small simd matrices for cern high throughput computing, in Proceedings of the th Workshop on Programming Models for SIMD/Vector Processing, WPMVP 18, (New York, NY, USA), pp. 1:1 1:8, ACM, doi: / [7] M. Hadji, Measuring code performance, Tech. Rep [8] N. Nethercote and J. Seward, Valgrind: A framework for heavyweight dynamic binary instrumentation, in Proceedings of ACM SIGPLAN 2007 Conference on Programming Language Design and Implementation (PLDI 2007), [9] R. Brun and F. Rademakers, ROOT: An object oriented data analysis framework, Nucl. Instrum. Meth. A389 (1997) 81. [10] LHCb collaboration, LHCb trigger system: Technical Design Report, CERN-LHCC LHCb-TDR-010. [11] C. Fitzpatrick et al., Upgrade trigger: Bandwidth strategy proposal, Tech. Rep. LHCb-PUB CERN-LHCb-PUB , CERN, Geneva, Feb,

14 A createutliteclusters and PrStoreUTHit The algorithm profile of the UT clustering and hit storing is detailed in Fig. 11 and 12. Compared to the biannual performance review [3] the following changes in the algorithm logic have been implemented: Drop of string manipulation in createutliteclusters and checking of errors in clusters read-out. The UT detector description is based on the Run 1 and Run 2 ST/IT/OT detector description. The UT cluster sorting is quite expensive as well as the interaction with the detector geometry description to convert the binary format to a measurement for pattern recogntion. The same arguments made for the FT apply here as well, we can gain in time simplifying the amount of information stored to the minimum needed by the pattern recognition and track fit. B createftclusters and PrStoreFTHit The algorithm profile of the FT clustering and hit storing is detailed in Fig. 9 and 10. Compared to the biannual performance review [3] the following changes in the algorithm logic have been implemented: The FT detector produces partially sorted clusters, which allows some of the sorting steps to be skipped. Caching of expensive geometry description access to convert binary format of raw data to actual geometrical position. Use of float instead of double for geometry information. The inlining of several functions make the callgrind profile output hard to understand, however further speed-up may require a rewrite of the class used to store FT data to make it lighter and store only the information absolutely needed by the HLT1 pattern recognition. C VPClustering The algorithm profile of the VP clustering is shown in Fig. 7. A large part of it is spent in reading raw banks and performing clustering and the remaining part (around 30%) in sorting the clusters. D PrPixelTrackingFast The algorithm profile of the VELO tracking is shown in Fig. 8. The logic of this algorithmhasundergonesignificantchangessincetheimplementationusedforthebiannual performance review [3], the most significant of which are: 12

15 Hits are sorted by φ (not x as before) using a numerical approximation with accuracy of 0.6 degrees. Split the search of tracks in forward direction and backward direction in two different steps. Introduction and usage of speed-flags to improve the logic of the algorithm: 1. Introduction of missed consecutive modules in track extrapolation and missed modules on track to early break the track extrapolation 2. Introduction of early 3 hit track candidate kill by checking enough hits in φ-search windows. 3. Introduction of a hard flagging strategy: avoid usage of already used hits for tracks in all track extrapolation steps. Early flag of hits also in 3 hit track candidate passing the χ 2 cut. 4. Splitting the hit extrapolation in same side module and opposite side module, to deal with detector acceptance before doing any computation. E PatPV3D The algorithm profile of the PV finding is detailed in Fig. 13. Compared to the biannual performance review [3] the following changes in the algorithm logic have been implemented: the seeding procedure has been changed from full three dimensional (PVSeed3DTool) to the fast simplified version (PVSeedTool). The fast seeding procedure is based on finding the clusters of tracks along the beam line (z coordinate), A gain by a factor 2 in the speed execution has been found. The fitting procedure has been changed from LSAdaptPV3DFitter to AdaptivePV3DFitter. The math has been corrected taking into account the covariance matrix of measured tracks parameters in the χ 2 calculation, which minimizes the fake PV reconstruction. In addition, the new algorithm gained about 25% of the speed execution. Both PVSeedTool and AdaptivePV3DFitter algorithms parameters have been reoptimized to speed up convergence of the PV reconstruction without loose of the performance, resulting with a gain about 10%. The studies shown the overall speed up of Primary Vertex reconstruction by a factor of 3, with 1% lose of efficiency and similar PV resolution. F PrVELOUTFast The algorithm profile of the VELO-UT tracking is detailed in Fig. 14. Compared to the biannual performance review [3] the following changes in the algorithm logic have been implemented: 13

16 Caching of lookup tables once per event instead of accessing them for every track via the tool. Improved logic of the algorithm, reduced usage of memory allocations by avoiding the use of std::vector. Fast computations by precalculating numbers outside loops. An IP cut is applied at 100 µm and a tight p T threshold set at 800 MeV. Previously no IP cut was applied, and the p T threshold was 300 MeV. Those 2 cuts strongly reduce the amount of VELO tracks to process and the combinatoric to deal with in the UT. The speed of the VELO-UT tracking can be improved considerably in the future by using a small output class to pass the information to the forward tracking instead of relying on the LHCb::Track class. Furthermore, some parts could profit from using SIMD. G PrForwardTrackingFast The algorithm profile of the forward tracking is detailed in Fig. 15. Compared to the biannual performance review [3] the following changes in the algorithm logic have been implemented: A tight p T threshold cut is applied at 1.0 GeV. It was 400 MeV. This cuts strongly reduces the size of the search windows for input VELO-UT tracks, speeding up the track finding. By balancing the efficiency of the VELO-UT tracking and the forward tracking, one can make use of the momentum estimate from the VELO-UT track, without losing too much in long track efficiency. Furthermore, many algorithmic structures in the forwrad tracking can be simplified, which, together with other simplifications due to the high p T threshold, will lead to a significant speed-up. 14

17 383 H Callgrind profiles for particular algorithms Figure 7: Callgrind profile (cycle extimation) of the VPClustering algorithm. Figure 8: Callgrind profile (cycle extimation) of PrPixelTrackingFast algorithm. 15

18 Figure 9: Callgrind profile (cycle extimation) of the PrStoreFT algorithm. Figure 10: Callgrind profile (cycle extimation) of the createftliteclusters algorithm. 16

19 Figure 11: Callgrind profile (cycle extimation) of PrStoreUT algorithm. Figure 12: Callgrind profile (cycle extimation) of createutliteclusters algorithm. 17

20 Figure 13: Callgrind profile (cycle extimation) of PatPV3D algorithm. Figure 14: Callgrind profile (cycle extimation) of the VELO-UT track finding. 18

21 Figure 15: Callgrind profile (cycle extimation) of Forward tracking. 19