Intersection of CartesianIndices

[rapus95]

Hey,
I recently stumbled across the fact, that intersection of CartesianIndices can be quite slow and scales with the size of the ranges that are used. As such I found out that there is no specialized version for the intersection of multiple CartesianIndices. Does this have any reason? If not, if you want and if you tell me where that line

Base.intersect(a::CartesianIndices, b::CartesianIndices) = CartesianIndices(intersect.(a.indices, b.indices))

would go and what the proper naming conventions here are, I could do a pull request.
EDIT: How to handle intersect(IdentityUnitRange, IdentityUnitRange) and mixed intersect?

https://github.com/JuliaLang/julia/blob/master/base/multidimensional.jl#L385
And while looking into this file, why do you not use a short-circuiting && in this line?

[mbauman]

Sure, that seems like a reasonable specialization to have. I'd put it in the IteratorsMD module inside base/multidimensional.jl. Putting it somewhere around that in function seems like a good place.

It looks like we already handle IdentityUnitRanges appropriately — this seems like the right thing to do:

julia> intersect(Base.OneTo(4), Base.OneTo(5))
Base.OneTo(4)

julia> intersect(Base.OneTo(4), 1:5)
1:4

As far as why in isn't using short-circuiting, there are cases where avoiding the branch introduced by && can be beneficial. In some cases LLVM will automatically convert && to & by itself when it thinks it's advantageous, but it has to be able to prove that the second expression doesn't have a side-effect. It's most evident inside SIMD-able loops, where failing to perform this optimization breaks SIMDification and leads to a huge (2-8x) performance loss.

[mdav2]

What needs to be done to get this merged? The implementation of intersect above cut down my runtime by orders of magnitude, so it seems like a good idea!

[timholy]

Submit a pull request with some tests.