-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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 Float64^Float64 #42271
Faster Float64^Float64 #42271
Conversation
It'd be great to get LICM on our Julia implementations of "pure" functions like |
The other thing that would be really nice is if the compiler was smart enough to precompute |
How many people would complain if we |
We can't inline the whole thing, but we could inline |
base/special/log.jl
Outdated
return ans_hi, ans_lo | ||
end | ||
|
||
# Log implimentation that returns 2 numbers which sum to give true value with about 68 bits of precision |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Log implimentation that returns 2 numbers which sum to give true value with about 68 bits of precision | |
# Log implementation that returns 2 numbers which sum to give true value with about 68 bits of precision |
I don't really understand "which sum to give true value". Also, is SleefPirates.jl the original source of this code or was it adapted from somewhere else originally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what I mean by this is that it outputs yhi,ylo
such that log(big(x))-yh-ylo <2^-68
, but the output is not normalized (ylo !< eps(yhi)
). Basically for true double-double implementations you would typically guarantee that all the bits in yhi
are correct, but I'm not doing that because it's not necessary for pow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chriselrod where did the SLEEFPirates code come from again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SLEEF: https://github.com/shibatch/sleef
@musm 's port: https://github.com/musm/SLEEF.jl
SLEEFPirates, a fork of the port: https://github.com/JuliaSIMD/SLEEFPirates.jl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that, does this need to include some sort of license?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably?
The SLEEF.jl license mentions it's a port of SLEEF and includes a link, but has a different license and doesn't include a copy of SLEEF's.
I don't care about SLEEFPirates/its license, so probably just SLEEF.jl's is fine.
Actually, given the addition of callsite inlining, I think these functions should take the approach of not being inlined, but having all code within them inlined so that someone can do |
Co-authored-by: Kristoffer Carlsson <[email protected]>
308b9c3
to
0808d83
Compare
Merging tomorrow Sans objection. |
I am sorry -- is it intentional to remove the |
Good catch. I got sloppy with the rebase. |
@KristofferC can you run PackageEval on this? |
Sure, but I think you can do it too. @nanosoldier |
Oh, didn't realize I could. Good to know for the future. |
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
TLDR is there are a few packages that break, but only ones that do are testing with explicit floating point values, and are off by a few ULPs (and they are testing more complicated functions), so we appear to be good to merge. |
Merging on Tuesday if there aren't objections. |
This blew up compile times in MTK. cc @JeffBezanson |
@@ -947,11 +947,15 @@ end | |||
@inline function ^(x::Float64, y::Float64) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This @inline
seems potentially problematic now that this function is no longer small.
Co-authored-by: Kristoffer Carlsson <[email protected]>
Co-authored-by: Kristoffer Carlsson <[email protected]>
I've finally managed to get an accurate version of
x^y
working for Float64 inputs. I think it's still missing some NaN checks and similar, but the core hard part is now done. Massive thanks to @chriselrod for hanging out with me for the 3.5 hours it took to debug the compensated arithmetic in the extended precision log (and giving me the SLEEFPirates reference implementation). Initial benchmarks:Old:
New:
Theoretically, this should be accurate to 1 ULP, but I haven't done extensive testing yet.