Skip to content

BigUint always use u64 as the internal machine unsigned integer #13880

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

Merged
merged 1 commit into from
May 3, 2014

Conversation

TeXitoi
Copy link
Contributor

@TeXitoi TeXitoi commented May 1, 2014

This change allow a speedup of ~1.5 on shootout-pidigits on a i32
system. MachineUint is used to abstract the internal machine
unsigned integer to simplity future architecture specialization.

#[inline]
pub fn from_uint(n: uint) -> (BigDigit, BigDigit) {
pub fn from_machineuint(n: MachineUint) -> (BigDigit, BigDigit) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a public-facing method, so this has the possibility of breaking existing code.

Could you adjust the commit message according to our guidelines?

Why did this change from uint to MachineInt? If it's always u64, could this just be from_u64?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I change the commit message to reflect that. The story is that it was not clear before if a uint is an index/len or if it is the machine representation used internally. That's why I used MachineUint to be clear.

I do not use directly u64 for future optimization. For example, I can imagine that when we have u128, MachineUint cat be u128 if the performances are better.

Finally, maybe the cleanest thing to do is to make BigDigit private because it looks like internal plumbing, not public API.

@lilyball
Copy link
Contributor

lilyball commented May 1, 2014

Why is it called MachineUint if in fact it's always u64?

@TeXitoi
Copy link
Contributor Author

TeXitoi commented May 1, 2014

@kballard as said upward, because maybe later, we will want to use u128 on some architecture.

@lilyball
Copy link
Contributor

lilyball commented May 1, 2014

@TeXitoi I'm confused because it's u64 on a 32-bit architecture, and that's clearly not the machine unsigned integer there.

@TeXitoi
Copy link
Contributor Author

TeXitoi commented May 1, 2014

@kballard for you, BignumInternalUint is better? Or DoubleBigDigit? Or something else?

@lilyball
Copy link
Contributor

lilyball commented May 1, 2014

@TeXitoi I'm not particularly familiar with the bigint implementation so I don't know what this type actually represents. But any name that doesn't suggest it's supposed to be u32 on a 32-bit architecture sounds fine to me. If it's literally twice the size of BigDigit then DoubleBigDigit sounds fine.

This change allow a speedup of ~1.5 on shootout-pidigits on a i32
system.  `DoubleBigDigit` is used to abstract the internal
unsigned integer used in computation to simplity future
architecture specialization.

`BigDigit::from_uint` and `BigDigit::to_uint` become
`BigDigit::from_doublebigdigit` and `BigDigit::to_doublebigdigit`.

[breaking-change]
@TeXitoi
Copy link
Contributor Author

TeXitoi commented May 1, 2014

@kballard just renamed MachineUint to DoubleBigDigit.

bors added a commit that referenced this pull request May 3, 2014
This change allow a speedup of ~1.5 on shootout-pidigits on a i32
system.  `MachineUint` is used to abstract the internal machine
unsigned integer to simplity future architecture specialization.
@bors bors closed this May 3, 2014
@bors bors merged commit 593f6a4 into rust-lang:master May 3, 2014
@TeXitoi TeXitoi deleted the biguint-always-use-u64 branch May 11, 2014 15:37
flip1995 added a commit to flip1995/rust that referenced this pull request Mar 20, 2025
Fixes rust-lang/rust-clippy#13744.

A simple check to check if the type is an `Option` allows to improve the
suggestion.

changelog: Improve `needless_pass_by_value` suggestion
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

Successfully merging this pull request may close these issues.

5 participants