确定经过大量的研究（伤心！我知道），我认为已经回答了我的问题：

OK after much research (sad I know!), I think have answered my own question:

答案是也许。
显然，JIT编译做寻找模式（见的 http://blogs.msdn.com/b/clrcodegeneration/archive/2009/08/13/array-bounds-check-elimination-in-the-clr.aspx ）以决定何时以及如何阵列边界检查可以被优化，但无论是我被猜测在与否不知相同的模式。

The answer is Maybe. Apparently the JIT compilers do look for patterns (see http://blogs.msdn.com/b/clrcodegeneration/archive/2009/08/13/array-bounds-check-elimination-in-the-clr.aspx) to decide when and how array bounds checking can be optimized but whether it is the same pattern I was guessing at or not I don't know.

在这种情况下，它是一个有争议的问题，因为相对速度增加（2）是由于东西比这更多。原来，64 JIT编译器足够聪明摸出一个数组长度是否是恒定的（而且似乎也解开的循环次数多）：因此，代码只是界限在每个迭代结束和检查每个解开成为刚： -

In this case, it is a moot point because the relative speed increase of (2) was due to something more than that. Turns out that the x64 JIT compiler is clever enough to work out whether an array length is constant (and seemingly also a multiple of the number of unrolls in a loop): So the code was only bounds checking at the end of each iteration and the each unroll became just:-

        total += intArray[j]; j++;
00000081 8B 44 0B 10          mov         eax,dword ptr [rbx+rcx+10h] 
00000085 03 F0                add         esi,eax 

我通过改变应用，让数组的大小在命令行上指定的，看到不同的汇编输出证明了这一点。

I proved this by changing the app to let the array size be specified on the command line and seeing the different assembler output.

本练习中发现其他的事情： -

Other things discovered during this excercise:-

• 对于一个独立的增值业务（即不使用结果），但在无差异前缀/后缀之间的速度。


• 在当前增量操作是在一个索引使用，汇编表明，前缀表示法会更有效（因此接近，我认为它原来如此只是一个时间discrepency，并呼吁他们平等的 - 我的错误）。当作为编译的x86的差异更加明显。


• 循环展开不工作。相比于用数组边界优化标准循环，4汇总总是给的10％-20％（和64 /恒定的情况下34％）的改进。增加汇总的数量给了不同的时序与一些在索引后缀的情况下很慢得多，所以如果展开我会坚持4，只有更改后的特定情况下，大量的时间。