-
-
Notifications
You must be signed in to change notification settings - Fork 25
Use registry for hermite type 13 #439
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
Conversation
This might show a greater focus on the Hermite interpolation during the benchmark run
BenchmarksWith the epoch registryWithout the epoch registrySPICEAssessmentUsing the registry, even on a large Hermite file, still doesn't significantly improve the speed of ANISE compared to SPICE. However, the registry slightly improves the performance compared to |
IAI Callgrind benchmarksSummary: the stridding barely changes the results (roughly + 0.05% of L2 cache hits), but makes the code less readable. The registry leads to very minor improvements (- 0.008% instructions, -0.006% r+w, -0.003% cycles) but really all of these changes are in the noise. I'll approve the use of the registry because it should help but won't use the stridding (make code less readable). No registry, with stridding
Registry, with stridding
Registry, no stridding
|
Fixes #37 |
Summary
This PR optimizes the ephemeris evaluation for SPICE Type 13 segments (Hermite interpolation) by implementing the documented two-stage lookup strategy. Previously, a binary search was performed on the entire set of epoch data. This change first utilizes the "epoch registry" (directory) to narrow down the search to a small block of (at most) 100 records within the main epoch data. A subsequent binary search is then performed only on this reduced-size block. This approach significantly improves performance, especially for segments with a large number of records, by enhancing CPU cache locality and reducing the search space for the most intensive part of the lookup.
Architectural Changes
No change
New Features
No change
Improvements
anise/src/naif/daf/datatypes/hermite.rs
. This significantly speeds up state vector retrieval from these segments by:Bug Fixes
No change (This is primarily a performance enhancement, not a bug fix, though the previous implementation could be considered sub-optimal).
Testing and validation
The existing test suite for SPK Type 13 evaluations in
anise/tests/ephemerides/validation/type13_hermite.rs
continues to pass with these changes, validating the correctness of the new lookup logic. These tests cover:Further validation was performed by:
No new tests were added specifically for the registry lookup mechanism itself, as its correctness is implicitly verified by the existing
evaluate
function's overall output, which now relies on this new internal logic. The existing tests ensure that the correct state vectors are returned, regardless of the internal search mechanism.Documentation
This PR does not primarily deal with documentation changes. Internal code comments in
anise/src/naif/daf/datatypes/hermite.rs
have been updated to reflect the new lookup logic.