-
Notifications
You must be signed in to change notification settings - Fork 463
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
RFC: Array.usize #4654
Comments
Surely this step is optimized out by LLVM anyway? |
Of course, no actual division is done but it's not quite optimized out. The issue is that the |
Add efficient usize functions for Array, ByteArray, FloatArray. Closes leanprover#4654
Add efficient `usize` functions for `Array`, `ByteArray`, `FloatArray`. This is part 1 of 2 since there is a need to update stage0 between the two parts. (See discussion below.) Closes #4654
Proposal
I propose to add
Array.usize
to get theUSize
size of an array, without going throughNat
.Currently, to get the
USize
of an array, one needs to useArray.size
and thenNat.toUSize
. The latter takes the return value ofArray.size
and calculates the remainder moduloUSize.size
. This is not optimal since arrays are stored in memory and therefore cannot exceedUSize.size
. This proposal would bypass the remainder step and return the correct array size as anUSize
scalar (which is trivial to access in the current array implementation).Other array operations have optimizations that bypass this trivial size check for the sake of nearly matching C-language performance. Some of my code at
UnicodeBasic
and elsewhere could benefit a lot from this nearly trivial improvement to the array API.The drawback is that this adds one more unsafe implementation. So this request needs some careful consideration.
Impact
Add 👍 to issues you consider important. If others benefit from the changes in this proposal being added, please ask them to add 👍 to it.
The text was updated successfully, but these errors were encountered: