Improve inferability of `slicedim` #20154

martinholters · 2017-01-20T14:02:36Z

An attempt to fix #20141. Not perfect, but an improvement, and should do no harm.

E.g. with this PR:

julia> @code_warntype slicedim(ones(3), 1, 1)
# ...
  end::Union{Array{Float64,1},Float64}

julia> @code_warntype slicedim(ones(3), 1, 1:1)
# ...
  end::Array{Float64,1}

julia> @code_warntype slicedim(ones(3,3), 1, 1)
# ...
  end::Union{Array{Float64,1},Array{Float64,2},Float64}

julia> @code_warntype slicedim(ones(3,3), 1, 1:1)
# ...
  end::Array{Float64,2}

julia> @code_warntype slicedim(ones(3,3,3), 1, 1)
# ...
  end::Any

julia> @code_warntype slicedim(ones(3,3,3), 1, 1:1)
# ...
  end::Array{Float64,3}

julia> @code_warntype slicedim(ones(3,3,3,3,3,3), 1, 1:1)
# ...
  end::Array{Float64,6}

julia> @code_warntype slicedim(ones(3,3,3,3,3,3,3), 1, 1:1)
# ...
  end::Any

On master, they are all just ::Any.

martinholters · 2017-01-20T14:07:34Z

base/abstractarraymath.jl


+_slice_inds(new_inds::Tuple, inds::Tuple, d, i) =
+    _slice_inds((new_inds..., length(new_inds) + 1 == d ? i : first(inds)), tail(inds), d, i)
+_slice_inds(new_inds::Tuple, inds::Tuple{}, d, i) = new_inds


Could also be

setindex(x::Tuple, n, v) = _setindex((), x, n, v) _setindex(y::Tuple, x::Tuple, n, v) = _setindex((y..., length(y) + 1 == n ? v : first(x)), tail(x), n, v) _setindex(y::Tuple, x::Tuple{}, n, v) = y

and live in tuple.jl. Or do we have something like this somewhere already?

Seems like a good idea. You'd want the v to come before n in the argument order, though, for consistency with setindex!.

timholy

Maybe briefer would be ntuple(j->ifelse(j==d,i,inds[d]), Val{N}), but overall I like the idea of having an internal tuple-setindex, it makes it more readable.

I'd also point out that you may be able to get full inferrability of the output in most cases by manually allocating the output array and then using copy!. As long as the indices-tuple is homogenous, the indices-tuple of the output array differs by being of length N-1 rather than N. This is the same type as tail would produce, so you could define

drop_dth{N,I}(inds::NTuple{N,I}, d) = _drop_dth(tail(inds), (), d, inds...)
_drop_dth(ref, out, d, ind, inds...) = length(out)==d+1 ? _drop_dth(ref, out, d, inds...) : _drop_dth(ref, (out..., ind), d, inds...)
_drop_dth{M,I}(::NTuple{M,I}, out, d)::NTuple{M,I} = out  # M = N-1

drop_dth is type-unstable at intermediate stages, but the output tuple has known type. Pass out as the indices-tuple to similar, and voila, the return array is inferrable.

(Might need a fallback for non-homogeneous indices tuples, but AFAIK there are no such arrays in existence.)

timholy · 2017-01-20T19:25:46Z

base/abstractarraymath.jl

 # index A[:,:,...,i,:,:,...] where "i" is in dimension "d"

+_slice_inds(new_inds::Tuple, inds::Tuple, d, i) =
+    _slice_inds((new_inds..., length(new_inds) + 1 == d ? i : first(inds)), tail(inds), d, i)


I'd ~~consider~~evaluate ifelse here since ? will give you one branch per dimension. Might also consider @inlineing this.

timholy · 2017-01-20T19:26:56Z

base/abstractarraymath.jl


+_slice_inds(new_inds::Tuple, inds::Tuple, d, i) =
+    _slice_inds((new_inds..., length(new_inds) + 1 == d ? i : first(inds)), tail(inds), d, i)
+_slice_inds(new_inds::Tuple, inds::Tuple{}, d, i) = new_inds


Seems like a good idea. You'd want the v to come before n in the argument order, though, for consistency with setindex!.

martinholters · 2017-01-21T07:25:17Z

the indices-tuple of the output array differs by being of length N-1 rather than N

We support d>N, so the length of the output array indices tuple depends on the value of d.

timholy · 2017-01-21T10:10:39Z

Seems almost worth having a separate code path for this case, e.g., require an extra argument or something. But that's not pretty, so maybe it's better to live with the type-instability.

martinholters · 2017-01-23T08:12:58Z

Introduced setindex(x::Tuple, v, i) instead of _slice_inds and updated slicedim accordingly.

@timholy Does ntuple work for you the way you suggested? For the (f, Val{N}) case, it seems it requires a type-stable f?

timholy · 2017-01-23T10:58:04Z

Hmm, seems likely. This version looks fine to me.

martinholters · 2017-01-23T11:02:37Z

Should setindex and/or _setindex be @inline? You probably have more experience whether/when this is beneficial.

timholy · 2017-01-23T11:09:00Z

base/tuple.jl


+# returns new tuple; N.B.: becomes no-op if i is out-of-bounds
+setindex(x::Tuple, v, i::Integer) = _setindex((), x, v, i::Integer)
+_setindex(y::Tuple, r::Tuple, v, i::Integer) =


This is the one to inline.

martinholters · 2017-01-23T12:19:47Z

Added @_inline_meta and a test.

martinholters · 2017-01-23T14:35:06Z

Oh, there is also a slicedim specialization for BitArray that could use a similar treatment. Will take a closer look tomorrow.

martinholters · 2017-01-24T12:32:31Z

Interesting, the BitArray specialization seems to be significantly slower (orders of magnitude!) than the generic code. Hence I have just removed it. Could someone double-check whether my benchmark in this gist makes sense? (Note: I've run it against this branch, so by default there is no specialization.)

The specialized code also did not allow a "too large" dimension as long as indexing with 1, so could be made type-stable. But for consistency, probably it should either always be allowed or always disallowed.

martinholters · 2017-01-25T08:54:41Z

Travis failure on Mac looks unrelated.

martinholters · 2017-01-25T09:43:45Z

Good news:

Doing some more benchmarking I am now pretty convinced that the generic code is significantly faster than the specialized code for BitArray, so removing it seems the right thing to do, except...

Bad news:

#20233

If we want to preserve the current behavior, I could add back a specialization for BitArray{1}. (Edit: done.)

… behavior

martinholters · 2017-01-25T13:45:52Z

Added a specialization so that this PR only does what the title says and does not change any return types.

tkelman · 2017-01-25T14:00:56Z

base/bitarray.jl

-            B[l] = A[j + index_offset]
-            l += 1
-        end
+# preserve some special behavior


was this tested very carefully before?

No, it's not tested at all. And I didn't feel like adding a test now because the desired behavior might actually be redefined shortly depending on how we resolve #20233.

StefanKarpinski · 2017-01-27T14:49:58Z

Bump – this seems like a strict improvement.

martinholters · 2017-01-30T07:36:31Z

Barring any objections, I'm going to merge this tomorrow.

martinholters commented Jan 20, 2017

View reviewed changes

kshyatt added compiler:inference Type inference arrays [a, r, r, a, y, s] labels Jan 20, 2017

timholy reviewed Jan 20, 2017

View reviewed changes

timholy mentioned this pull request Jan 20, 2017

slicedim is type-unstable #20141

Closed

martinholters force-pushed the mh/slicedim branch from 0ea52db to e894075 Compare January 23, 2017 08:09

martinholters force-pushed the mh/slicedim branch from e894075 to e1423c5 Compare January 23, 2017 08:19

timholy reviewed Jan 23, 2017

View reviewed changes

martinholters added 2 commits January 23, 2017 12:17

Add setindex for tuples

d7ff02e

Improve inferability of slicedim

e36e14e

martinholters force-pushed the mh/slicedim branch from e1423c5 to e36e14e Compare January 23, 2017 12:18

martinholters changed the title ~~RFC: Improve inferability of slicedim~~ Improve inferability of slicedim Jan 23, 2017

Remove slicedim specialization for BitArray

9a95c65

martinholters mentioned this pull request Jan 25, 2017

slicedim inconsistency for BitVector vs. other AbstractVectors #20233

Closed

Add slicedim(::BitVector, ::Integer, ::Integer) to restore previous…

8f9a62e

… behavior

tkelman reviewed Jan 25, 2017

View reviewed changes

martinholters merged commit 552d5e0 into master Jan 31, 2017

martinholters deleted the mh/slicedim branch January 31, 2017 10:29

mbauman mentioned this pull request Jul 30, 2019

docstring setindex #32738

Merged

Uh oh!

Improve inferability of slicedim #20154

Improve inferability of slicedim #20154

Uh oh!

Conversation

martinholters commented Jan 20, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinholters Jan 20, 2017

Choose a reason for hiding this comment

Uh oh!

timholy Jan 20, 2017

Choose a reason for hiding this comment

Uh oh!

timholy left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timholy Jan 20, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timholy Jan 20, 2017

Choose a reason for hiding this comment

Uh oh!

martinholters commented Jan 21, 2017

Uh oh!

timholy commented Jan 21, 2017

Uh oh!

martinholters commented Jan 23, 2017

Uh oh!

timholy commented Jan 23, 2017

Uh oh!

martinholters commented Jan 23, 2017

Uh oh!

timholy Jan 23, 2017

Choose a reason for hiding this comment

Uh oh!

martinholters commented Jan 23, 2017

Uh oh!

martinholters commented Jan 23, 2017

Uh oh!

martinholters commented Jan 24, 2017

Uh oh!

martinholters commented Jan 25, 2017

Uh oh!

martinholters commented Jan 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Good news:

Bad news:

Uh oh!

martinholters commented Jan 25, 2017

Uh oh!

tkelman Jan 25, 2017

Choose a reason for hiding this comment

Uh oh!

martinholters Jan 25, 2017

Choose a reason for hiding this comment

Uh oh!

StefanKarpinski commented Jan 27, 2017

Uh oh!

martinholters commented Jan 30, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Improve inferability of `slicedim` #20154

Improve inferability of `slicedim` #20154

martinholters commented Jan 20, 2017 •

edited

Loading

timholy left a comment •

edited

Loading

timholy Jan 20, 2017 •

edited

Loading

martinholters commented Jan 25, 2017 •

edited

Loading