Faster view creation

[mbauman]

This is a series of performance patches that I wrote a while ago, but never had a chance to fully vet their performance impact. At a minimum, this fixes #19257. We really need better benchmarks for subarray creation in nanosoldier; I don't think SubArray creation is really tested there.

The fourth commit is the most micro- of micro-optimizations, and it might be a little too cute… but I think there's good reason to do it beyond the micro-optimization. See the commit message for more details.

[mbauman]

May as well see what the soldier reports in any case: @nanosoldier runbenchmarks("ALL", vs = ":master")

[nanosoldier]

Your benchmark job has completed, but no benchmarks were actually executed. Perhaps your tag predicate contains mispelled tags? cc @jrevels

[jrevels]

(ALL is a keyword for run all benchmarks, "ALL" means run all benchmarks tagged "ALL")
@nanosoldier runbenchmarks(ALL, vs = ":master")

[nanosoldier]

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

[timholy]

Nice! I like the direction, good catch. What kind of speedups are you seeing?

Aside from the test failures, might want to look into the lu regression. The rest I bet are spurious.

[kmsquire]

tabs -> spaces

[mbauman]

I didn't push this sooner since I had a hard time constructing benchmarks that actually demonstrated that this was an improvement. The inlining changes were purely based upon simplifications to @code_typed/llvm, but I had a hard time measuring an impact there.

The reason I pushed it when I did was because I didn't want others to duplicate this work as they investigated #19257. That result seems to have been somewhat spurious, but we need more benchmarks here in any case. I'm not sure when I'll have time to test this further.

[StefanKarpinski]

So what's your call, @mbauman, merge or not? If you don't think it's a regression, I'd be in favor.

[mbauman]

Lemme drop the last commit here and propose it separately since it's breaking.

[mbauman]

I'd like to merge this for 0.6, but it'd be good to wait until JuliaCI/BaseBenchmarks.jl#54 makes it onto Nanosoldier for a final perf check.

[tkelman]

bit overly long lines here, wrap?

[mbauman]

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

[jrevels]

Had to kick nanosoldier, retriggering:

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

[nanosoldier]

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

[mbauman]

Hm, I cannot reproduce any of the largest regressions… in fact "sumeach_view","linspace(1.0,2.0,10000)" is nearly 2x faster with this branch on my computer (instead of 2x slower). It is pretty old, though, and doesn't have the same fancy SIMD registers that nanosoldier has. But there are many more performance gains — including a few constant-folds, which is pretty cool.

Since I can't reproduce the perf issues, I think this is as good as I can make it.

[KristofferC]

As another data point, on my laptop I'm getting a ~3x slowdown for the benchmark in the comment above. The LLVM codes are here: https://gist.github.com/KristofferC/1cf9e09d97289b521f494c9c68958043.

Edit: Removed some confusion...

[mbauman]

Thanks for checking Kristoffer. I'm seeing the same LLVM IR as you, but 75us on this branch compared to 130us on master. I have an old i5; OpenBLAS reports compiling for Nehalem, LLVM reports westmere.

…

On Jan 3, 2017, at 6:09 PM, Kristoffer Carlsson ***@***.***> wrote: As another data point, on my laptop I'm getting a ~3x slowdown. The LLVM codes are here: https://gist.github.com/KristofferC/1cf9e09d97289b521f494c9c68958043 and what seems suspicious is this call: %22 = call i64 @jlsys_convert_52679(%jl_value_t* inttoptr (i64 139759635777136 to %jl_value_t*), double %21) in the loop. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[KristofferC]

I get 115us on PR and ~45us on master. On 0.5 it is around 115us as well. This PR improves much more than it regresses though so while it is sometimes good to be greedy, perhaps this can just be merged?

[StefanKarpinski]

The failure is the current ongoing 32-bit Linux problem. I'm with @KristofferC on this.

[JeffBezanson]

Sounds good to me too.

[KristofferC]

@yuyichao postulated that the slowdown is due to LLVM generating bad native code on newer architectures causing a partial register stall when converting an integer to double. I confirmed this by recompiling the sysimg for x86-64 which made the relevant benchmark almost 3x faster. (The same problem appears for the pi_sum benchmark at

julia/test/perf/micro/perf.jl

Line 84 in 30bf89f

function pisum()

which is 2x slower when compiling for native architecture).

[vchuravy]

In that light I would say we should merge this and tackle the code generation issue later.

[timholy]

I wonder if this has regressed?

master:

julia> A = rand(1000,1000,1);

julia> @benchmark view(A, :, :, 1) seconds=1
BenchmarkTools.Trial: 
  memory estimate:  880 bytes
  allocs estimate:  40
  --------------
  minimum time:     14.049 μs (0.00% GC)
  median time:      14.456 μs (0.00% GC)
  mean time:        14.703 μs (0.00% GC)
  maximum time:     64.914 μs (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     1
  time tolerance:   5.00%
  memory tolerance: 1.00%

julia-0.5:

julia> A = rand(1000,1000,1);

julia> @benchmark view(A, :, :, 1) seconds=1
BenchmarkTools.Trial: 
  memory estimate:  48 bytes
  allocs estimate:  1
  --------------
  minimum time:     27.119 ns (0.00% GC)
  median time:      28.238 ns (0.00% GC)
  mean time:        35.656 ns (6.56% GC)
  maximum time:     1.478 μs (95.10% GC)
  --------------
  samples:          10000
  evals/sample:     995
  time tolerance:   5.00%
  memory tolerance: 1.00%

(I'd fix this myself except I'm up to my neck in another project right now.)

[KristofferC]

I get:

julia> A = rand(1000,1000,1);

julia> @btime view($A, :, :, 1)
 10.903 ns (1 allocation: 64 bytes)

[KristofferC]

Looks like the missed interpolation of $A was the problem

[timholy]

You are so right. Newbie error 😄. With it, they're the same speed on 0.5 and 0.6.