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
We theoretically have 54 bits of information in Int and 53 bits in UInt. Because it is much simpler to just wrap an existing numeric type, we currently use 8 bytes (64 bits) to store this data, even though 7 bytes (56 bits) would be sufficient. Implementing 7-byte storage would certainly complicate the code quite a bit and potentially affect performance negatively. I could imagine developing it out under a feature flag though. If we have benchmarks until then (#4), that would be very useful.
The text was updated successfully, but these errors were encountered:
This could actually save more space than one would initially expect, because it leaves one byte free for booleans or enum tags (think Option) without exceeding the required memory alignment of 8. This would therefore reduce the required memory for Vec<Option<Int>> by half for example.
But I agree that this has much potential to slow things down and should definitely be benchmarked.
(Also it needs to be considered if the alignment should still be 8 or 1 instead, since it probably needs to be copied to a register anyways)
We theoretically have 54 bits of information in
Int
and 53 bits inUInt
. Because it is much simpler to just wrap an existing numeric type, we currently use 8 bytes (64 bits) to store this data, even though 7 bytes (56 bits) would be sufficient. Implementing 7-byte storage would certainly complicate the code quite a bit and potentially affect performance negatively. I could imagine developing it out under a feature flag though. If we have benchmarks until then (#4), that would be very useful.The text was updated successfully, but these errors were encountered: