rust-decimal icon indicating copy to clipboard operation
rust-decimal copied to clipboard

i128/u128 based implementation

Open xilec opened this issue 6 years ago • 5 comments

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.

xilec avatar Jun 24 '18 20:06 xilec

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.

paupino avatar Jun 24 '18 23:06 paupino

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.

paupino avatar Apr 24 '19 02:04 paupino

Also this could help expand precision to 128 (or even 256) bits to completely cover theoretical limits of various cryptocurrency values.

vorot93 avatar May 06 '19 13:05 vorot93

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).

paupino avatar Jan 24 '20 02:01 paupino

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:

  1. Increase storage capacity by using unused bytes
  2. Increase storage capacity greater than 128 bits
  3. 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.

paupino avatar Mar 23 '20 01:03 paupino

@xilec I wish to refer to your i128 based implementation,thanks a lot ,Can you share a github gist link,thanks a lot ❗️

leeson1995 avatar Dec 08 '22 16:12 leeson1995

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.

A248 avatar Sep 07 '23 16:09 A248

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.

Tony-Samuels avatar Jan 20 '24 16:01 Tony-Samuels