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 construction for more types #52507

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

hycakir
Copy link
Contributor

@hycakir hycakir commented Dec 12, 2023

This pull request addresses #50940 and is a follow-up to #47546.

The changes add Julia construction of BigFloats for some inputs:

  • When the Base.BitInteger64 or Base.IEEEFloat when precision is enough to perfectly represent the input as a BigFloat
  • When the denominator of the Rational is a power of 2.
julia> @btime BigFloat(128)
  14.320 ns (2 allocations: 104 bytes)
128.0

julia> @btime Base.MPFR.BigFloat_mpfr_fallback(128)
  25.518 ns (2 allocations: 104 bytes)
128.0

julia> @btime BigFloat(128.0f0)
  17.952 ns (2 allocations: 104 bytes)
128.0

julia> @btime Base.MPFR.BigFloat_mpfr_fallback(128.0f0)
  35.667 ns (2 allocations: 104 bytes)
128.0

@hycakir
Copy link
Contributor Author

hycakir commented Jan 11, 2024

@oscardssmith Could you take a look at this?

base/mpfr.jl Outdated Show resolved Hide resolved
nsajko added a commit to nsajko/julia that referenced this pull request Jan 13, 2024
Implementation approach:

1. Convert the (numerator, denominator) pair to a (sign bit, integral
   significand, exponent) triplet using integer arithmetic. The integer
   type in question must be wide enough.

2. Convert the above triplet into an instance of the chosen FP type.
   There is special support for IEEE 754 floating-point and for
   `BigFloat`, otherwise a fallback using `ldexp` is used.

As a bonus, constructing a `BigFloat` from a `Rational` should now be
thread-safe when the rounding mode and precision are provided to the
constructor, because there is no access to the global precision or
rounding mode settings.

Updates JuliaLang#45213

Updates JuliaLang#50940

Updates JuliaLang#52507

Fixes JuliaLang#52394

Closes JuliaLang#52395

Fixes JuliaLang#52859
nsajko added a commit to nsajko/julia that referenced this pull request Jan 14, 2024
Implementation approach:

1. Convert the (numerator, denominator) pair to a (sign bit, integral
   significand, exponent) triplet using integer arithmetic. The integer
   type in question must be wide enough.

2. Convert the above triplet into an instance of the chosen FP type.
   There is special support for IEEE 754 floating-point and for
   `BigFloat`, otherwise a fallback using `ldexp` is used.

As a bonus, constructing a `BigFloat` from a `Rational` should now be
thread-safe when the rounding mode and precision are provided to the
constructor, because there is no access to the global precision or
rounding mode settings.

Updates JuliaLang#45213

Updates JuliaLang#50940

Updates JuliaLang#52507

Fixes JuliaLang#52394

Closes JuliaLang#52395

Fixes JuliaLang#52859
nsajko added a commit to nsajko/julia that referenced this pull request Jan 14, 2024
Implementation approach:

1. Convert the (numerator, denominator) pair to a (sign bit, integral
   significand, exponent) triplet using integer arithmetic. The integer
   type in question must be wide enough.

2. Convert the above triplet into an instance of the chosen FP type.
   There is special support for IEEE 754 floating-point and for
   `BigFloat`, otherwise a fallback using `ldexp` is used.

As a bonus, constructing a `BigFloat` from a `Rational` should now be
thread-safe when the rounding mode and precision are provided to the
constructor, because there is no access to the global precision or
rounding mode settings.

Updates JuliaLang#45213

Updates JuliaLang#50940

Updates JuliaLang#52507

Fixes JuliaLang#52394

Closes JuliaLang#52395

Fixes JuliaLang#52859
nsajko added a commit to nsajko/julia that referenced this pull request Jan 14, 2024
Implementation approach:

1. Convert the (numerator, denominator) pair to a (sign bit, integral
   significand, exponent) triplet using integer arithmetic. The integer
   type in question must be wide enough.

2. Convert the above triplet into an instance of the chosen FP type.
   There is special support for IEEE 754 floating-point and for
   `BigFloat`, otherwise a fallback using `ldexp` is used.

As a bonus, constructing a `BigFloat` from a `Rational` should now be
thread-safe when the rounding mode and precision are provided to the
constructor, because there is no access to the global precision or
rounding mode settings.

Updates JuliaLang#45213

Updates JuliaLang#50940

Updates JuliaLang#52507

Fixes JuliaLang#52394

Closes JuliaLang#52395

Fixes JuliaLang#52859
nsajko added a commit to nsajko/julia that referenced this pull request Jan 14, 2024
Implementation approach:

1. Convert the (numerator, denominator) pair to a (sign bit, integral
   significand, exponent) triplet using integer arithmetic. The integer
   type in question must be wide enough.

2. Convert the above triplet into an instance of the chosen FP type.
   There is special support for IEEE 754 floating-point and for
   `BigFloat`, otherwise a fallback using `ldexp` is used.

As a bonus, constructing a `BigFloat` from a `Rational` should now be
thread-safe when the rounding mode and precision are provided to the
constructor, because there is no access to the global precision or
rounding mode settings.

Updates JuliaLang#45213

Updates JuliaLang#50940

Updates JuliaLang#52507

Fixes JuliaLang#52394

Closes JuliaLang#52395

Fixes JuliaLang#52859
nsajko added a commit to nsajko/julia that referenced this pull request Jan 15, 2024
Implementation approach:

1. Convert the (numerator, denominator) pair to a (sign bit, integral
   significand, exponent) triplet using integer arithmetic. The integer
   type in question must be wide enough.

2. Convert the above triplet into an instance of the chosen FP type.
   There is special support for IEEE 754 floating-point and for
   `BigFloat`, otherwise a fallback using `ldexp` is used.

As a bonus, constructing a `BigFloat` from a `Rational` should now be
thread-safe when the rounding mode and precision are provided to the
constructor, because there is no access to the global precision or
rounding mode settings.

Updates JuliaLang#45213

Updates JuliaLang#50940

Updates JuliaLang#52507

Fixes JuliaLang#52394

Closes JuliaLang#52395

Fixes JuliaLang#52859
nsajko added a commit to nsajko/julia that referenced this pull request Jan 15, 2024
Constructing a floating-point number from a `Rational` should now be
correctly rounded.

Implementation approach:

1. Convert the (numerator, denominator) pair to a (sign bit, integral
   significand, exponent) triplet using integer arithmetic. The integer
   type in question must be wide enough.

2. Convert the above triplet into an instance of the chosen FP type.
   There is special support for IEEE 754 floating-point and for
   `BigFloat`, otherwise a fallback using `ldexp` is used.

As a bonus, constructing a `BigFloat` from a `Rational` should now be
thread-safe when the rounding mode and precision are provided to the
constructor, because there is no access to the global precision or
rounding mode settings.

Updates JuliaLang#45213

Updates JuliaLang#50940

Updates JuliaLang#52507

Fixes JuliaLang#52394

Closes JuliaLang#52395

Fixes JuliaLang#52859
nsajko added a commit to nsajko/julia that referenced this pull request Jan 15, 2024
Constructing a floating-point number from a `Rational` should now be
correctly rounded.

Implementation approach:

1. Convert the (numerator, denominator) pair to a (sign bit, integral
   significand, exponent) triplet using integer arithmetic. The integer
   type in question must be wide enough.

2. Convert the above triplet into an instance of the chosen FP type.
   There is special support for IEEE 754 floating-point and for
   `BigFloat`, otherwise a fallback using `ldexp` is used.

As a bonus, constructing a `BigFloat` from a `Rational` should now be
thread-safe when the rounding mode and precision are provided to the
constructor, because there is no access to the global precision or
rounding mode settings.

Updates JuliaLang#45213

Updates JuliaLang#50940

Updates JuliaLang#52507

Fixes JuliaLang#52394

Closes JuliaLang#52395

Fixes JuliaLang#52859
@vtjnash
Copy link
Sponsor Member

vtjnash commented Feb 6, 2024

numbers                                          (12) |         failed at 2024-01-13T01:37:41.184
2024-01-12 20:37:41 EST	Test Failed at /cache/build/tester-amdci4-15/julialang/julia-master/julia-770900211a/share/julia/test/numbers.jl:2929
2024-01-12 20:37:41 EST	  Expression: all((m->begin
2024-01-12 20:37:41 EST	            #= /cache/build/tester-amdci4-15/julialang/julia-master/julia-770900211a/share/julia/test/numbers.jl:2929 =#
2024-01-12 20:37:41 EST	            m.file === Symbol("deprecated.jl")
2024-01-12 20:37:41 EST	        end), (collect(methods(T)))[findall((R->(#= /cache/build/tester-amdci4-15/julialang/julia-master/julia-770900211a/share/julia/test/numbers.jl:2930 =#
2024-01-12 20:37:41 EST	                    !(R <: T))), Base.return_types(T))])
2024-01-12 20:37:41 EST	

Seems like there may be an inference issue. Maybe @oscardssmith can help get this finished though, since it seems a good performance improvement?

Also, might want to sprinkle around some GC.@preserve near the unsafe load/store calls just to be careful.

@inkydragon inkydragon added the domain:bignums BigInt and BigFloat label Feb 6, 2024
@hycakir
Copy link
Contributor Author

hycakir commented Feb 28, 2024

Where would I need GC.@preserve? It seems all calls to unsafe_store makes explicit use of the relevant objects. GC should not collect these objects, no?

@nsajko nsajko added the performance Must go faster label Feb 29, 2024
nsajko added a commit to nsajko/julia that referenced this pull request May 12, 2024
Constructing a floating-point number from a `Rational` should now be
correctly rounded.

Implementation approach:

1. Convert the (numerator, denominator) pair to a (sign bit, integral
   significand, exponent) triplet using integer arithmetic. The integer
   type in question must be wide enough.

2. Convert the above triplet into an instance of the chosen FP type.
   There is special support for IEEE 754 floating-point and for
   `BigFloat`, otherwise a fallback using `ldexp` is used.

As a bonus, constructing a `BigFloat` from a `Rational` should now be
thread-safe when the rounding mode and precision are provided to the
constructor, because there is no access to the global precision or
rounding mode settings.

Updates JuliaLang#45213

Updates JuliaLang#50940

Updates JuliaLang#52507

Fixes JuliaLang#52394

Closes JuliaLang#52395

Fixes JuliaLang#52859
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:bignums BigInt and BigFloat performance Must go faster
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants