Distance matrix moved to triangular shape.#23
Conversation
…emory footprint by 50 percent.
|
hmm, I'm pretty sure that when I last benchmarked it calculating the full square was more efficient 🤔 I'll have a closer look once I'm back from vacation |
|
Hey, we should revisit this sometime :) |
Turbo87
left a comment
Turbo87
left a comment
There was a problem hiding this comment.
I'm having a hard time doing a proper review here because this PR seems to change several different things at once.
e.g. the full- to half-matrix change should probably be split off from the olc_forward.rs implementation. similar for the typo fixes etc.
| **/*.rs.bk | ||
| Cargo.lock | ||
| .criterion | ||
| .vscode/ |
There was a problem hiding this comment.
this stuff belongs in your global gitignore file (see https://docs.github.com/en/github/using-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer) 😉
There was a problem hiding this comment.
Thanks for pointing that out :)
| if #[cfg(feature = "rayon")] { | ||
| use rayon::slice; | ||
| pub use rayon::prelude::*; | ||
|
|
There was a problem hiding this comment.
any reason for removing the whitespace here?
There was a problem hiding this comment.
I guess this happened as I was trying to add another optional rayon feature. I added it again.
2 participants
Distances in the distance matrix are only computed to preceding points. This speeds up distance calculation by ~50% and reduces memory footprint. For flights for which only one iteration is needed, benching indicates a speed up of around 15% overall. For flights with multiple iterations, I was not able to bench any kind of speed up. For longer flights with many fixes, the reduction of memory should be an improvement and could allow scoring of longer flights on smaller devices.
Moving the distance matrix to a triangular shape effectively only allows scoring in one direction. In the original implementation, the first iteration was scored 'backwards' to find potential starting points. The following iterations were then scored 'forward', starting at the selected points. This is not possible with the triangular matrix anymore.
Now, the first iteration is scored 'backwards' as well. Potential starting points and their corresponding solutions are identified. But we can not start at these points anymore. So after a start point is picked, valid end points for this start points are identified and when iterating backwards, only they are allowed by penalising other end points. The solution of this iteration is guaranteed to be as good as the solution when starting from start point in a forward manner. In the test flight, the exact number of iterations were needed. I believe that there are cases where the solution can even be better (as it is not limited to end at start point) which would result in less iteration.
In olc_forward, the same algorithms is provided with the other half of the triangular matrix, scoring everything the other way. For the average flight, this implementation seems to need more iterations, as the typical solution seems to be biased towards the start.