CPU `__thread_run` could loop over CartesianIndices?

I noticed in Stencils.jl that when I'm using a fast stencil (e.g. 3x3 window summing over a Matrix{Bool}) that the indexing in __thread_run takes longer than actually reading and summing the stencil!

It seems to be because the conversion from linear back to cartesian indices is pretty slow. I'm getting 4ns for N=2, 7ns for N=3 and 11ns for N=4 on my laptop. So there is also a penalty to adding dimensions.

Could we switch the loop to iterating over CartesianIndices directly?

I guess it will make dividing up the array a little messier, and might be slower for really large workloads where an even split of tasks is more important than 7ns per operation. It could have a keyword to choose behaviours.

Start at the __thread_run entry point and inspect how it converts linear indices and divides work among tasks. Benchmark the fast 3x3 stencil case, then compare CartesianIndices iteration and workload partitioning, including large workloads. Done means the indexing overhead is reduced without changing stencil results or creating unacceptable task-splitting regressions.