Execution

_reduce_chunks(f, op, n, backend)

f(range) over a partition of 1:n, combined left to right with op.

Distinct from map_chunks because the serial path has nothing to collect: it hands f the whole range and returns that value directly, where going through map_chunks would build a one-element Vector to index once and discard. The compiler usually erases that vector, so its cost shows up only where it cannot — a reduction is otherwise allocation-free, and this keeps it so unconditionally.

chunk_ranges(n, k) -> Vector{UnitRange{Int}}

Partition 1:n into at most k contiguous ranges of near-equal length. Contiguity matters: each chunk then touches one span of every array the loop indexes, rather than striding across all of them.

map_chunks(f, n, backend) -> Vector

Apply f(range) over a partition of 1:n and collect one result per chunk, for a bulk operation that reduces rather than writes. The caller combines them, so f needs no lock and the combining order is the caller's to fix — which is what keeps a threaded reduction bit-identical to a serial one when the operation is associative but not commutative.

run_chunks(f, n, backend)

Apply f(range) over a partition of 1:n, under the execution policy backend names.

f must be safe to run on disjoint index ranges concurrently — every write it makes has to be determined by the index, never accumulated across chunks. nothing means serial and hands f the whole range in one call, so the serial path adds no partitioning at all.

run_indices(f, n, backend)

Apply f(i) for each i in 1:n, under the execution policy backend names. f must write only what i determines, with no accumulation across indices — the same contract as run_chunks, stated per index because that is what a device launch can express.

This is the form a kernel maps onto: with KernelAbstractions loaded and a device backend, f becomes the body of a launch over 1:n rather than a host loop.