-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General numeric type support #97
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #97 +/- ##
==========================================
- Coverage 71.52% 71.30% -0.22%
==========================================
Files 17 17
Lines 1166 1178 +12
==========================================
+ Hits 834 840 +6
- Misses 332 338 +6 ☔ View full report in Codecov by Sentry. |
For completeness, here are the benchmarks on my x86 Ryzen 7 5700G:
So, again, the significant performance loss is pp tiled (and a small loss for pp plain). |
97046e3
to
faf67cf
Compare
Allowing for different Float values, as well as more exotic types, if needed
Allowing for different Float values, as well as more exotic types, if needed.
Ensure that types are stable for EEReco, meaning that they are EEjet{T} for a specific T, not just generic EEjet
Allow instrumented-jetreco to have a type argument that makes the particle collection have that specific type, allowing for switches to different Floats N.B, Currently Float32 is slower than Float64
It is very important to pass the fully typed PseudoJet{T} around, not a generic PseudoJet
Returns the parametrised element type
Also support type switching constructor for PseudoJet
At the full constructor level the type parameter really should be known, the use case for the non-explicit parametrised version is weak, so it is removed. (This was also causing a docstring warning.)
The particle type is know in the function signature of the underlying reconstruction
We explicitly use Float64 here, because this is deliberately the simple case.
Numerical type can be passed as a parameter to the test struct This is passed down to read the events in the required precision. Add some tests for e+e- and pp in Float32
9f96393
to
79036ee
Compare
Support is added for general numerical types in this PR.
EEjet
andPseudoJet
become parametrised onT <: Real
.ClusterSequence
stays parametrised onJ <: FourMomentum
, but is it really important to pass the parametrised jet collection into the constructor otherwise performance greatly suffers! (i.e.,ClusterSequence{EEjet{Float64}}
notClusterSequence{EEjet}
. To support this theeltype
method is defined for both jet types to return the internal type used.The
instrumented-jetreco.jl
script gets a new--type
option that allows a numeric type to be passed for the reconstruction. Added a quickbenchmark.sh
script to run all three main use cases.Current performance tests shows that we are losing a bit in the$pp$ $e^+e^-$ and $pp$
N2Tiled
reconstruction, so this needs to be fixed before merging. Performance for DurhamN2Plain
are the same as the current v0.4.3 release.Testing on M2pro gives
This branch:
v0.4.3:
Closes #91
To do:
EEjet
toT <: Real
PseudoJet
toT <: Real
TiledJet
toT <: Real
instrumented_jetreco.jl
jetreco.jl
Float64
caseFloat32
reconstruction