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

Revert #26418, remove noinline annotation from fill! #31626

Merged
merged 1 commit into from
Jan 31, 2020

Conversation

mbauman
Copy link
Sponsor Member

@mbauman mbauman commented Apr 5, 2019

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:

# BEFORE
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)

# AFTER
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:

# AFTER
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](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
@mbauman mbauman added performance Must go faster arrays [a, r, r, a, y, s] labels Apr 5, 2019
@mbauman mbauman requested a review from KristofferC April 5, 2019 15:29
@mbauman
Copy link
Sponsor Member Author

mbauman commented Apr 5, 2019

@nanosoldier runbenchmarks(ALL, vs = ":master")

Copy link
Sponsor Member

@KristofferC KristofferC left a 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.

@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

@JeffBezanson JeffBezanson merged commit a4eaccf into master Jan 31, 2020
@JeffBezanson JeffBezanson deleted the mb/revert26418 branch January 31, 2020 19:24
@KristofferC
Copy link
Sponsor Member

I think this caused the doctests to start failing.

KristofferC pushed a commit that referenced this pull request Apr 11, 2020
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arrays [a, r, r, a, y, s] performance Must go faster
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants