refactor!: compile-time DetectorMeasurementInfo for SSS

[LuisFelipeCoelho]

This is my first attempt to implement compile-time DetectorMeasurementInfo for SSS, as alternative to PR #1985 and following the same approach by @CarloVarni #2013

[CarloVarni]

it looks good to me. Do you have an estimate of the timing gain due to this?

[codecov]

Codecov Report

Merging #2108 (6063a55) into main (c535c5d) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #2108      +/-   ##
==========================================
- Coverage   49.53%   49.52%   -0.01%     
==========================================
  Files         453      453              
  Lines       25692    25695       +3     
  Branches    11819    11813       -6     
==========================================
  Hits        12726    12726              
- Misses       4583     4586       +3     
  Partials     8383     8383              

Files Changed	Coverage Δ
Core/include/Acts/Seeding/SeedFinder.hpp	0.00% <ø> (ø)
Core/include/Acts/Seeding/SeedFinder.ipp	0.00% <0.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[paulgessinger]

Is this actually faster due to the template parameter? If this is consistent for the entire SP loop, the branch prediction should make a runtime if equally fast, I would think.

Also: is it possible to decouple the config changes from the other changes, somehow?

EDIT: Oh, I see this partially contains #2067.

[CarloVarni]

Indeed @paulgessinger the config changes are also in another PR. Not sure if we want them here or there. Concerning why we want to remove one of the config parameters see the discussion here: #2067 (comment)

Concerning the timing: we indeed expect the code to be faster with these compile-time if statements. This has already been demostrated with #2013 and by Luis' studies. He observed that having two separate functions for SSS and PPP makes us reache ~the same timing performances of Athena. The compile-time ifs are a way to avoid code duplications while achieving that

[paulgessinger]

Thanks @CarloVarni.

I see, it's surprising to me, but ok. I really would think if the if variable doesn't change, it should effectively be skipped.
Anyway, the whole struct is templated already, so probably ok to template this function too.

[LuisFelipeCoelho]

In the case of this PR I still need to test it the performance gain comes from the changes from #2067 or actually because of the if statements

[github-actions]

📊: Physics performance monitoring for 6063a55

Full contents

physmon summary

• ✅ CKF truth_smeared
• ✅ IVF truth_smeared
• ✅ AMVF truth_smeared
• ✅ Track Summary CKF truth_smeared
• ✅ Seeding truth_estimated
• ✅ CKF truth_estimated
• ✅ IVF truth_estimated
• ✅ AMVF truth_estimated
• ✅ Track Summary CKF truth_estimated
• ✅ Seeding seeded
• ✅ CKF seeded
• ✅ IVF seeded
• ✅ AMVF seeded
• ✅ AMVF (+grid seeder) seeded
• ✅ Track Summary CKF seeded
• ✅ Seeding orthogonal
• ✅ CKF orthogonal
• ✅ IVF orthogonal
• ✅ AMVF orthogonal
• ✅ Track Summary CKF orthogonal
• ✅ Ambisolver seeded
• ✅ Ambisolver orthogonal
• ✅ Seeding ttbar
• ✅ CKF ttbar
• ✅ Ambisolver
• ✅ AMVF ttbar
• ✅ AMVF (+grid seeder) ttbar
• ✅ Truth tracking (GSF)
• ✅ Truth tracking
• ✅ Particles inital fatras
• ✅ Particles final fatras
• ✅ Particles inital geant4
• ✅ Particles final geant4

[LuisFelipeCoelho]

from my comparison in Athena, just changing the if statements it improves around 2-3%

[paulgessinger]

Could you do me a favor @LuisFelipeCoelho and recheck the timing where you keep everything as is in this PR but change the enum parameter to a runtime argument, rather than a template parameter?

Otherwise: should we get this in for v28?

[paulgessinger]

What's the plan for this @LuisFelipeCoelho ?

[CarloVarni]

Hi @LuisFelipeCoelho there are merge conflicts. Can you resolve them?

[acts-project-service]

🔴 Athena integration test results

Build job with this PR failed!

Please investigate the build job for the pipeline!