WIP: split next into nextval & nextstate

[nolta]

This is a more speculative and breaking fix for #9178. It splits next into nextval and nextstate, as previously discussed in #6125.

For example,

for x in xs
    ...
end

would transform into

iter = start(xs)
while !done(xs,iter)
    x = nextval(xs,iter)
    ...
    iter = nextstate(xs,iter)
end

[eschnett]

Why not call it currval? Presumably it can be called multiple times,
without advancing the iterator.

[johnmyleswhite]

This is a cool approach. FWIW, I think using a Nullable would be a little simpler.

[nolta]

@johnmyleswhite Do you mean something like this:

function nextmaybe(a::AbstractArray, i)
    i > length(a) ? Nullable() : Nullable(a[i]), i+1
end

iter = start(xs)
while true
    maybe,iter = nextmaybe(xs,iter)
    maybe.isnull && break
    x = maybe.value
    ...
end

i.e., #8149 (comment)?

This PR basically implements C++-style iterators, while the above is more Python-like (Nullable taking the place of the StopIteration exception).

I guess i feel this PR is a little simpler:

• simpler for the user, since they don't have to understand Nullable;
• simpler for the compiler, since it doesn't have to optimize out the tuple & nullable, and because of things like regression in performance of counting loops #5469 (comment).

@eschnett Sure, nextval isn't necessarily the best name. I'm partial to iterval myself.

[timholy]

There's some evidence in #9080 that---at least on some architectures---a version of this PR might enable higher performance. It would appear to mandate putting nextstate at the end of the loop, which is currently marked "TBD" in the code.

[nolta]

Ok, i've moved nextstate to the end.

[timholy]

Cool! I'll have to test this on #9080, but I gotta run for now.

[timholy]

Sorry for the long delay. This indeed helps #9080 a bit:

# Master
julia> @time sumcart_manual(A)
elapsed time: 0.140875669 seconds (96 bytes allocated)
5.000122419731768e7

julia> @time sumcart_iter(A)
elapsed time: 0.215551555 seconds (96 bytes allocated)
5.000122419731768e7


# This branch
julia> @time sumcart_manual(A)
elapsed time: 0.142305083 seconds (96 bytes allocated)
5.0000425472199745e7

julia> @time sumcart_iter(A)
elapsed time: 0.197485609 seconds (96 bytes allocated)
5.0000425472199745e7

It doesn't eliminate the gap, but it is a 10% speed improvement, or equivalently erases 25% of the gap.

I was also hoping it would help the performance of enumerate, but unfortunately that doesn't seem to be the case. Looking at the LLVM and native code, it doesn't fully elide the tuples (even though it doesn't allocate any memory in julia).

On balance I like this change; I suppose the question is whether it is worth the breakage.

[StefanKarpinski]

For what it's worth, I'm still interested in doing this. I guess the open issues would be how to do it without breaking everything. Might be a good change for the Arraymageddon.

[Keno]

Yes, something is not quite right about iteration yet. I think the most common awkward situation is that you don't know whether you're done until you try to fetch the next value, which doesn't fit cleanly into our current iteration model.

[StefanKarpinski]

Cross reference: #8149