rust-decimal
rust-decimal copied to clipboard
i128/u128 based implementation
My small experiments shows that implementation Decimal
on top of types i128
/u128
should be simpler and more performant. In my rough reimplementation of add
method, timings of bench add_negative_pi
drops from 133 ns/iter to 41 ns/iter. As I know, i128
/u128
types supported on all rust targets.
I suppose it enough reasons to consider reimplementation or alternative implementation of Decimal
type on top of i128
/u128
.
This is definitely something I've been watching and something I'd like to implement. Of the two, I wanted to really see how u128
performed and how it could improve division performance. Blocks such as this can be removed which I think could come with some big improvements.
I'm going to keep this open as I do want to iterate on this feature.
This is still on the roadmap however due to significant restructuring will be a V2 feature instead. First stage is to stabalize towards 1.0.
Also this could help expand precision to 128 (or even 256) bits to completely cover theoretical limits of various cryptocurrency values.
I've started some experimentation of this in the evolution
branch. There is much more that needs to be done here, but am open to suggestions. I'm quite curious regarding the crypto scenario and the precision that may be needed here. What sort of precision is typically expected here? (I'm unfamiliar with the implementation of this domain).
For those that are following this issue; I'm interested if anyone has found performance improvements on their machine? In my investigations, i128
and u128
have been slower.
I also think there are perhaps three motivations here based on the comments:
- Increase storage capacity by using unused bytes
- Increase storage capacity greater than 128 bits
- Improve performance by utilizing native
u128
/i128
types
I've been focusing on number 3 with this (unsuccessfully so far on my hardware), however I suspect others may be looking for either 1 (similar to the C implementation) or perhaps number 2. I'd be interested in any input here to see what people are thinking about.
@xilec I wish to refer to your i128 based implementation,thanks a lot ,Can you share a github gist link,thanks a lot ❗️
It might be worth investigating using NonZeroU128
, to take the advantage of the null-value optimization, if there are any bits known to be non-zero.
It sounds like this has been tried and probably isn't of use right now. Given the lower performance and the other reasons being a change in scale which I think would likely happen under possible generics work in future.
Closing this for now.