This was always true of course. Previously, it was even always the case unless a reduction prevented it.

Could be integrated into the loop. The bigger improvement here would be to avoid this function entirely initernext(). Which the code does for unbuffered iterators, but not for buffered ones.

For a next iteration, I think!

Not a change, not a catastrophe. But this always clears the buffer as if it was completely filled (even if there may only be a single item).
I guess, calculating it shouldn't be too hard, we haveNBF_STRIDES() andNBF_OUTERSTRIDES() to work with. (If either stride is 0, the core-size or the outer-size do not matter).

Let's leave that for a future enhancement

Hmmmm, maybe theif can actually just useop_single_stride_dims[iop] == idim - 1?

That would require the assumption of using reduce logic below (and potentially disabling when it is not necessary). Probably that just works, maybe even be easier to grok.

I'm still trying to grok this bit, but could one just swap the two pieces?

this might work, but not sure if it should matter right now (should make an issue probably that this all should be tweaked)...

The point is, if we use a "reduce" setup (i.e. two strides), then we can do one more dimension without buffering.

And maybe/probably it works to change this if and move it to the beginning (before the check for identical strides).
(I have to think about it myself.)

Talking with Matti today so hopefully we can push it through (with some notes in an issue). So a bit of a note to self: Changing it here is simple, I think. The difference will be thatusing_reduce needs to be discovered below by re-checking operands.
Reduce-loops are unfavorable since you need to call the inner-loop/iternext more often (but, you save on buffer filling). That trade-off may already be covered by preferring larger cores, but not sure.

This whole "finding the best" is very crude and I am sure it can be improved. Just also don't want to overcomplicate it and make it slow.

Let's leave that for a further investigation/PR. Maybe we can open a follow up issue to track more cleanup and optimizations.

Could also useITFLAG_WRITE, which may be a bit clearer, considering that we may disable the flag later.

(We don't need the flag to be set, but right now it gets set because the earlier code does input validation anyway.)

I suppose the reduce outersize is actually also always valid now. Which would be useful for advancing the iterator.
Should rename/reorganize, but would add churn elsewhere too probably.

What would it mean to "buffer beyond the outer dimension"? For some length N, I can imagine buffering some smaller M, but why ever M>N? I'm probably misreading this!

Added two examples, hopefully they help (if not for this, then hopefully to show how to think about these iterations).

The outer dimension may be iterated in chunks (not fully), so if it is say 100, and we can fit 30 of them in at a time, you reach 90. Then we just buffer 10, not 30 again, because that would increment the dimension that comes next (with a different stride).

Garbled sentence! In the larger context, doesn't it just mean that if the iterator is manually set, things have to be recalculated?

Restructured the order and wording to make it clearer hopefully.

You always have to (re-)fill buffers when manually moved (or ranged).

The point is that I decided to just finish a single core (which could be very small). For reductions, you have to do that anyway. Otherwise, it just seems a bit simpler to not worry about what happens if you iterator 1.5 core-sizes (rather than N core-sizes).

follow grammatical structure of first item:

- Reductions are possible (with or without reduce mode);- Iteration overhead is minimized. We ...

Should this be:

`(1 + n_buffers) / size`, a guess of how often we fill buffers, with`size=min(core_size * outer_dim_size, buffersize)`.

But I think this is not very clear, this does not look like a number (it has 1/bytes as dimension). I think what one really is trying to minimize is,

`(1+n_buffers) * core_size * outer_dim_size / min(buffer_size, core_size * outer_dim_size)`.

In practice, since the total size is fixed, what you write does the same thing, but maybe it is clearer to write like I have it? I.e., how about the following for the whole entry:

- Iteration overhead is minimized. For this, we use the number of times buffers  are filled, `(1 + n_buffers) * total_size / min(total_size, buffer_size)`  (where `total_size = core_size * outer_dim_size`).

OK,total_size is not actuallycore_size * outer_dim_size. Since there may be more dimensions (outer here is thefirst "outer" dimension in a sense).

(I added the "first" in a few places, maybe it helps... It would be nice to find a different name because "outer" is also a nice name for everything that isn't buffered, but for the "outer" dimension here it is just the outermost that is still iterated as a part of a buffer.
But, I can't think of one right now.)

(completely changed/expanded the formulas, though...)

Thesingle strided is a bit confusing; from the code, below, I'd call itcontiguous. Maybe change that? Otherwise, just add "(C contiguous)" here?

EDIT: or rather, I think this does not have to be contiguous at all, just consistent with the first stride. So, maybe add "(note that the stride of the first axis does not have to equal the element size; if it does, this is equivalent to the operand being C contiguous)".

Rephrased to say "first how many operand dimensions can be iterated using a single stride (all dimensions are consistent),"

Contiguouity of course doesn't matter (it only matters for that slightly awkward "contiguous" flag.)

How can this be hit? I don't see abreak in thefor loop above...

Just forgot to delete this. The first version I had broke immediately on finding a reduce op. But I wanted the info for all operands, so now it's breaking later.

I'm still trying to grok this bit, but could one just swap the two pieces?

For a next iteration, I think!

Not your problem, but, really, having macros require other variables to be defined is pretty bad form! Especially since hereaxisdata_incr could have made use ofsizeof_axisdata.

Again, only if you are making changes, maybe add:

 * Also, it uses that the operands have already been broadcast against * each other (and thus may have zero strides).

Dont' feel it fits here (also moved this comment down tobest_ndim = 0.

type? "Core starts at 0 (unless..."

A future cleanup might eliminate any internal calls to this API function and use the iter data directly.