Precompute light propagation data at build time instead of in Space initialization. #492
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kpreid
added
kind: performance
… initialization. Instead of making a chart for the exact right size, we make the biggest one we can, then do a distance check while iterating. This avoids redundant run-time work and, in particular, should make the tests we run under Miri that happen to allocate `Space`s much faster. Size of the data is a concern; it's currently 645 KB. In the future, I plan to replace this data structure with one which combines nearly-parallel rays that traverse the same cubes, until they diverge, instead of redundantly storing and iterating over each ray's sequence of cubes. That will allow more rays for the same data and compute costs. One unused possibility for further compression is storing *only* the face/step directions instead of both the faces and the cube coordinates.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of making a chart for the exact right size, we make the biggest one we can, then do a distance check while iterating. This avoids redundant run-time work and, in particular, should make the tests we run under Miri that happen to allocate
Spaces much faster.Size of the data is a concern; it's currently 645 KB. In the future, I plan to replace this data structure with one which combines nearly-parallel rays that traverse the same cubes, until they diverge, instead of redundantly storing and iterating over each ray's sequence of cubes. That will allow more rays for the same data and compute costs.
One unused possibility for further compression is storing only the face/step directions instead of both the faces and the cube coordinates.
Part of #490