Validate and implement fallback to variant-based ThOr::Combiner<T>
The new ThOr::Combiner<T>
supports std::variant
-like inputs, meaning that it can either be instantiated with definite input types:
using ThOrCombiner__2ChargedBasics = ThOr::CombinerBest<LHCb::v2::ChargedBasics, LHCb::v2::ChargedBasics>;
or a variant type can be defined and used to instantiate the combiner:
using Particles = LHCb::variant<ChargedBasics, LHCb::Pr::zip_t<Composites>>;
using ThOrCombiner__2Particle = ThOr::CombinerBest<Particles, Particles>;
These variant types allow a list of alternative types to be given at compile time, while the choice of a specific type is made at run time. The cost is that they are rather slow to compile, come with a runtime cost (preliminary studies indicated this was a 10% effect), and that some care is required when using selection expressions that are not valid for all members of the variant type.
The best solution is probably to dispatch in the Python configuration to an explicit instantiation if one exists (example: ThOrCombiner__Composites__ChargedBasics__ChargedBasics
), and fall back to ThOrCombiner__{N}Particle
if it does not. We should also add tests that demonstrate the variant layer does not affect the results.
Some meta-optimisation of stack compile time against application throughput would also be valuable. This could go hand in hand with adding some extra monitoring to the configuration (or possibly the algorithm) to monitor which missing explicit instantiations would be most valuable to add.