Skip to content
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

i128/u128 based implementation #135

Closed
xilec opened this issue Jun 24, 2018 · 7 comments
Closed

i128/u128 based implementation #135

xilec opened this issue Jun 24, 2018 · 7 comments

Comments

@xilec
Copy link
Contributor

xilec commented Jun 24, 2018

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.

@paupino
Copy link
Owner

paupino commented Jun 24, 2018

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 paupino added this to the V1 Release milestone Jun 24, 2018
@paupino paupino modified the milestones: V1 Release, V1.1 Apr 24, 2019
@paupino
Copy link
Owner

paupino commented Apr 24, 2019

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 paupino self-assigned this Jan 21, 2020
@paupino
Copy link
Owner

paupino commented Jan 24, 2020

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
Copy link
Owner

paupino commented Mar 23, 2020

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 paupino removed their assignment May 20, 2020
@paupino paupino removed this from the V2 milestone Nov 10, 2020
@leeson1995
Copy link

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

@A248
Copy link

A248 commented Sep 7, 2023

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.

@Tony-Samuels
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants