-
-
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
Revert #26418, remove noinline annotation from fill! #31626
Conversation
This used to be necessary to avoid a strange edge case in the compiler, but it is no longer necessary -- and can now in fact cause other performance snags. Using the test case from [the original discourse post that prompted #26418](https://discourse.julialang.org/t/performance-degradation-of-fill-in-latest-julia-0-7-dev/9648): ```julia julia> @Btime fill(1.0,5,5); 49.335 ns (1 allocation: 288 bytes) julia> @Btime fill(0.0,5,5); 52.773 ns (1 allocation: 288 bytes) julia> @Btime fill(0.0,5,5); 46.724 ns (1 allocation: 288 bytes) julia> @Btime fill(1.0,5,5); 42.202 ns (1 allocation: 288 bytes) ``` Even more compelling is the case for a larger array where LLVM can exploit some sort of wider/simdier implementation for zeros when this gets inlined thanks to constant propagation: ```julia julia> A = Array{Float64}(undef, 1000, 1000); julia> @Btime fill!($A,0.0); 345.103 μs (0 allocations: 0 bytes) julia> @Btime fill!($A,1.0); 458.976 μs (0 allocations: 0 bytes) ``` Ref https://discourse.julialang.org/t/performance-of-filling-an-array/22788
@nanosoldier |
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.
If the original issue has been fixed, no need to keep the annotation.
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
I think this caused the doctests to start failing. |
This used to be necessary to avoid a strange edge case in the compiler, but it is no longer necessary -- and can now in fact cause other performance snags. Using the test case from [the original discourse post that prompted #26418](https://discourse.julialang.org/t/performance-degradation-of-fill-in-latest-julia-0-7-dev/9648): ```julia julia> @Btime fill(1.0,5,5); 49.335 ns (1 allocation: 288 bytes) julia> @Btime fill(0.0,5,5); 52.773 ns (1 allocation: 288 bytes) julia> @Btime fill(0.0,5,5); 46.724 ns (1 allocation: 288 bytes) julia> @Btime fill(1.0,5,5); 42.202 ns (1 allocation: 288 bytes) ``` Even more compelling is the case for a larger array where LLVM can exploit some sort of wider/simdier implementation for zeros when this gets inlined thanks to constant propagation: ```julia julia> A = Array{Float64}(undef, 1000, 1000); julia> @Btime fill!($A,0.0); 345.103 μs (0 allocations: 0 bytes) julia> @Btime fill!($A,1.0); 458.976 μs (0 allocations: 0 bytes) ``` Ref https://discourse.julialang.org/t/performance-of-filling-an-array/22788
This used to be necessary to avoid a strange edge case in the compiler, but it is no longer necessary -- and can now in fact cause other performance snags.
Using the test case from the original discourse post that prompted #26418:
Even more compelling is the case for a larger array where LLVM can exploit some sort of wider/simdier implementation for zeros when this gets inlined thanks to constant propagation:
Ref https://discourse.julialang.org/t/performance-of-filling-an-array/22788