I am not certain that you can calculate as you do the time of processing. I am pretty certain that the processors include some memory read-ahead mechanism. This mechanism is at work with the current code. And my reasoning is that the next few cache lines are fetched in advance when you simply read forward the memory. Hence, my thinking that 417 is the half of 908 (for very large values of 417 ) because limitation is only computation time here.

I remember Herb Sutter presenting test of algorithms that were using memory, both sequentially, and randomly, and that the results were _very_ different, and are explained by this read-ahead mechanism.

M.b. I should statistically clean results..

BTW, I can explain the figures you got from your program in June 6th comment.

908, 417, 390, 389, 390, 217, 106

The value 390 is limited by the memory accesses. As such, when you traverse your data 4 by 4, 8 by 8, or 16 by 16 (32 bits integer values) the limitation is memory.

When you traverse by 32 (217), or 64 (106), then you only use 1 cache line (64 bytes) out of 2, or out of 4. This is showed by the last 2 values, approximately divided by 2, and by 4 from the 390 limit.

For the first two ones, the limitation is not memory, but processing. It simply shows that computing `arr[i] *= 3` 16 times takes longer than accessing a 64 bytes memory line (908). Computing it 8 times divides the time by 2 (417), and is almost equal to the memory access limit.

I fully agree with your last comment.

Cache effects do not matters in ERP, CMS and many other systems. But, for exampe, in shaders you cannot avoid them. It’s better to take them into account if you create DBMS or graphics rendering engine.

But this is when reading only 1 integer value (32 bits) in a single cache line comprising 16 of them. Whenever I try to do something with the other 15 integers (which is a better approach of the real use of memory), anything as simple as summing them up makes the CPU time becoming larger than memory latency time.

Maybe memory latency and throughput have enhanced a lot recently, but in the end, it looks to me that there’s no real need to care about this.

for (int x = 1; x < 65; x <<=1)
{
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 0; i < arr.Length; i+=x) arr[i] *= 3;
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds);
}

produces output:
908
417
390
389
390
217
106

everything is not so clear, by close enough to described behavior