-
-
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
Revisit erroring behaviour of special functions #36786
Comments
Just use https://github.com/mlubin/NaNMath.jl ? |
Related / Dupe of #5234 |
I've been told to use NaNMath several times, but first of all NaNMath.jl does not solve the problem with optimizations here because it uses julia> using StaticArrays, NaNMath, BenchmarkTools
julia> let v = @SVector(rand(20)), x = 5.0
sinx = NaNMath.sin(x)
@btime $v .+ NaNMath.sin($x)
@btime $v .+ $sinx
@btime $v .+ sin($x)
end;
13.175 ns (0 allocations: 0 bytes)
0.019 ns (0 allocations: 0 bytes)
10.801 ns (0 allocations: 0 bytes) If the compiler knew that Second of all, I think if Base is going to provide these functions, it's worth having Base do them right rather than rely on external packages to patch performance problems. |
There is an 10-15% speed increase in performance between Second, if you implement
So, we have just explained why NaNMath is slightly slower. Let's examine:
You are comparing summing two arrays (ex1) vs summing two arrays and computing Please look at: So I see no performance issues |
@musm the entire point I’m highlighting here is that the functions being pure allows optimizations like hoisting out of loops. I know |
The most important optimization we are currently missing is LICM (loop invariant code motion) and I have been thinking about how we might get there and IIUC it doesn't require a change in error behavior. To explain why let's look at a function we currently fail to optimize.
This turns into:
This is valid Julia code, but I find it useful to have names for the regions of code. We want to move
Functions we can't hoist fall into buckets Ideally we want to hoist to the BB called I might have missed some finer details, but generally speaking throwing as a side-effect is fine. |
Obviously, this can't be changed until 2.0, but I think we should revisit the design of special functions such as
sqrt
,sin
, etc. to make them pure functions which cannot error. The fact thatsqrt(-1)
orsin(Inf)
produce errors make many important optimizations impossible, or harder for the compiler to perform. We can solve these things with special cases in the compiler, but that'll quickly turn into optimization whack-a-mole.The IEEE floating point specification (and computer hardware) already has a great solution for this:
NaN
. One can argue that producingNaN
for these functions is the correct thing to do according to the IEEE spec.The main problem that I forsee with returning
NaN
rather than an error is thatNaN
s are notoriously difficult to track down, but I feel that with the new compiler pass infrastructure (or even the current Cassette.jl / IRTools.jl), making better tooling for detectingNaN
production would solve this potential complaint and allow us to make more principled, general optimizations for these functions.The text was updated successfully, but these errors were encountered: