You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we mostly use double precision (float64) for everything in the data reduction. This affects event weights as well as coordinates.
Coordinates such as wavelength, Q, two_theta, phi, Qx, Qy, ... all default to float64. This can consume a lot of memory, and thus makes coord transform as well as all binning/grouping operations slower. We should tests if switching to float32 negatively impacts there results. Are there any operations that would be highly sensitive to the precision?
For event weights I feel there are more pitfalls with float32, since they end up getting summed and precision can easily get lost here, i.e., that may require a lot more care.
As a quick test, I converted tof to float32 right after loading. This saves about 3 seconds for 1e9 events (total reduction time 50 seconds, i.e., 5% savings). The effect may be larger if gravity is enabled, since the coord transforms get more complex.
Note: If we plan to do this, we should actually push the conversion into the loader, e.g., by providing a customization of the NXevent_data application definition to ScippNexus. This is relevant since ScippNexus performs binning into pixels which would already see performance benefits from smaller elements.
The text was updated successfully, but these errors were encountered:
Currently we mostly use double precision (float64) for everything in the data reduction. This affects event weights as well as coordinates.
wavelength
,Q
,two_theta
,phi
,Qx
,Qy
, ... all default to float64. This can consume a lot of memory, and thus makes coord transform as well as all binning/grouping operations slower. We should tests if switching to float32 negatively impacts there results. Are there any operations that would be highly sensitive to the precision?As a quick test, I converted
tof
tofloat32
right after loading. This saves about 3 seconds for 1e9 events (total reduction time 50 seconds, i.e., 5% savings). The effect may be larger if gravity is enabled, since the coord transforms get more complex.Note: If we plan to do this, we should actually push the conversion into the loader, e.g., by providing a customization of the NXevent_data application definition to ScippNexus. This is relevant since ScippNexus performs binning into pixels which would already see performance benefits from smaller elements.
The text was updated successfully, but these errors were encountered: