Make Iterators.partition split arrays into views for faster and easier parallelism

[mbauman]

I've frequently wanted to use Iterators.partition to subdivide an iteration space into chunks amenable to parallelism, but its implementation — which defaulted to copying all elements of each partition into a new Vector — left some efficiencies to be desired. It did have one special case — wherein a partition of a Vector itself would helpfully use views. This PR makes that the default for all AbstractArrays. It goes further and adds very helpful performance specializations for some ranges and CartesianIndices essential for doing loops over partition(eachindex(...)).

This PR is divided into three commits:

• The minor change, which makes all AbstractArrays return views
• The optimization, which speeds up partitions of common ranges and CartesianIndices
• The use-case, which makes BitArray broadcasts simpler, simdier, and faster. This was the use-case that drove my optimizations, and I put together a series of benchmarks. The short version is that by using partition we can easily split the algorithm into a @simdable section, leading to up to 10x speedups for code like a .== 0:

[JeffBezanson]

Cool!!

[StefanKarpinski]

Argument for why this change is an acceptable minor change even though it is technically breaking:

• since the partitions were previously copies, mutating them was almost always pointless
• the main case that could break is if someone was hanging onto a partition and then mutating the main array or keeping the partition as an independent array from the original and mutating that

Both of these potential usages seem pretty unlikely. The main usage of this seems like it would be to just look at different partitions of the original array without doing any mutation of the original or the partition. With this change, a new potential use case becomes possible: modifying the original array by operating on partitions. Going back from views to copies would be more breaking since it would make code that used that use case stop working.

[StefanKarpinski]

Another nice coincidence: @vtjnash is doing compiler work that will make taking views usually non-allocating and therefore much more efficient in many more cases, so this could get even more efficient by the time 1.4 is actually ready.

[ararslan]

FWIW I've been using partition a lot lately and I didn't even realize it wasn't using views (nor did I do any mutation), so I'd second Stefan's comment:

Both of these potential usages seem pretty unlikely

This is great!

[StefanKarpinski]

Hasn't been officially triaged, but if anyone has any objections, please post them here. I think this seems popular enough based on the reactions to be merged without a triage debate.

[vtjnash]

OT: Are we missing an abstraction here: should we define that view(::AbstractRange, slice::AbstractRange) isa AbstractRange, or would that confuse consumes or view?

[mbauman]

That's #26872 — looks like it got stalled because it was proposed before we really had a handle on minor changes.

[mbauman]

Triage was in favor and I addressed the style review... and while I was at it I added a few more comments because I didn't understand how this worked anymore.

[Sacha0]

Very nice! :)