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.

Sign up for GitHub

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

Jump to bottom

Should n-arg fastmath addition default to using to 2-arg fastmath addition for all types #54456

Closed
Zentrik opened this issue May 13, 2024 · 1 comment · Fixed by #54513
Closed

Should n-arg fastmath addition default to using to 2-arg fastmath addition for all types #54456

Zentrik opened this issue May 13, 2024 · 1 comment · Fixed by #54513

Comments

@Zentrik
Copy link
Contributor

Zentrik commented May 13, 2024 •
edited

Currently the n-arg fastmath addition only uses fastmath for Float16, Float32 and Float64,

julia/base/fastmath.jl

Lines 171 to 172 in 931f6de

add_fast(x::T, y::T, zs::T...) where {T<:FloatTypes} =
add_fast(add_fast(x, y), zs...)

It otherwise falls back to non fastmath addition even when add_fast(x, y) is defined, like for ComplexF64 and types in SIMD.jl.

As the 2-arg fastmath add, add_fast(x, y), is defined for all types, should add_fast(x::T, y::T, zs::T...) be defined as above for all T.

The comment at the non fastmath n-arg addition definition seems to suggest that this would be expected and also should add_fast(x::T, y::T, zs::T...) switch to using afoldl?

julia/base/operators.jl

Lines 636 to 637 in 931f6de

# that defining +(a,b) is sufficient for full functionality.
($op)(a, b, c, xs...) = (@inline; afoldl($op, ($op)(($op)(a,b),c), xs...))

Presumably, if we change the behaviour for addition, we want to change it for the other operators as well.
@Zentrik
Copy link
Contributor Author

Zentrik commented May 15, 2024 •
edited

Zentrik@769e583 fixes this by defining the vararg add_fast method for all types. Let me know if I should make a pr.

@Zentrik Zentrik mentioned this issue May 17, 2024
Merged
KristofferC pushed a commit that referenced this issue May 29, 2024
@Zentrik
Fix fastmath for vararg +, *, min, max methods (#54513)
9634652 
Currently using the fastmath vararg +, *, min, max methods only actually
sets fastmath if they are specifically overloaded even when the correct
2 argument methods have been defined.
As such, `ComplexF32, ComplexF64` do not currently set fastmath when
using the vararg methods. This will also fix any other types, such as
those in SIMD.jl, which don't overload the vararg methods.

E.g. 
```julia
x = ComplexF64(1)
f(x) = @fastmath x + x + x
```
now works correctly.

I see no reason why the vararg methods shouldn't default to using the
fastmath 2 argument methods instead of the non fastmath ones, which is
the current behaviour.

I also switched the implementation to use `afoldl` as that's what the
non fastmath vararg methods use.

Fixes #54456 and eschnett/SIMD.jl#108.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix fastmath for vararg +, *, min, max methods Zentrik/julia
1 participant
@Zentrik