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

faster BigFloat(::Float64) #47546

Merged
merged 6 commits into from
Dec 1, 2022
Merged

Conversation

oscardssmith
Copy link
Member

This technically has different behavior than the current behavior but I'm pretty sure that no one was using BigFloat with precision<53 because the current behavior is to give you all 53 bits for precision>=40 and only the leading 8 bits for precision<40. This is roughly 2x faster for precision<10000. It's a little slower for precisions >10^6 (about 20%) but IMO this doesn't really matter since for high precision things like multiplication will be way slower than construction.

This technically has different behavior than the current behavior but I'm pretty sure that no one was using `BigFloat` with precision<53 because the current behavior is to give you all 53 bits for precision>=40 and only the leading 8 bits for precision<40. This is roughly 2x faster for precision<10000. It's a little slower for precisions >10^6 (about 20%) but IMO this doesn't really matter since for high precision things like multiplication will be way slower than construction.
@oscardssmith oscardssmith added performance Must go faster maths Mathematical functions labels Nov 12, 2022
@oscardssmith
Copy link
Member Author

The tests this is failing are tests of BigFloat(::Float64) with precision=4 which I'm not sure anyone is using, but is technically breaking.

@brenhinkeller brenhinkeller added the bignums BigInt and BigFloat label Nov 26, 2022
@oscardssmith
Copy link
Member Author

This is ready to merge and is a noticeable performance improvement if we don't mind the added complexity.

base/mpfr.jl Outdated Show resolved Hide resolved
@StefanKarpinski
Copy link
Member

Yeah, why not. When has adding a little implementation complexity for the sake of speed stopped us?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bignums BigInt and BigFloat maths Mathematical functions performance Must go faster
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants