为什么添加本地variables会使.NET代码变慢

为什么要评论这个for循环的前两行,并取消第二个42%加速的结果呢?

int count = 0; for (uint i = 0; i < 1000000000; ++i) { var isMultipleOf16 = i % 16 == 0; count += isMultipleOf16 ? 1 : 0; //count += i % 16 == 0 ? 1 : 0; } 

时序的背后是非常不同的汇编代码:循环中的13个指令和7个指令。 该平台是运行.NET 4.0 x64的Windows 7。 代码优化已启用,testing应用程序在VS2010之外运行。 [ 更新: Repro项目 ,用于validation项目设置。]

消除中间布尔值是一个基本的优化,是我1980年代龙书中最简单的一种。 在生成CIL或JITing x64机器码时,优化是如何不被应用的?

有没有“真的编译器,我想你优化这个代码,请”切换? 虽然我同情过早的优化是类似于爱的情绪,我可以看到在试图分析一个复杂的algorithm,像这样的问题分散在整个例程的挫折感。 你会通过热点工作,但没有暗示更广泛的温暖的地区,可以大大改善手工调整我们通常从编译器认为是理所当然的。 我当然希望我在这里错过了一些东西。

更新:对于x86也会出现速度差异,但取决于方法是即时编译的顺序。 请参阅为什么JIT订单会影响性能?

汇编代码 (根据要求):

  var isMultipleOf16 = i % 16 == 0; 00000037 mov eax,edx 00000039 and eax,0Fh 0000003c xor ecx,ecx 0000003e test eax,eax 00000040 sete cl count += isMultipleOf16 ? 1 : 0; 00000043 movzx eax,cl 00000046 test eax,eax 00000048 jne 0000000000000050 0000004a xor eax,eax 0000004c jmp 0000000000000055 0000004e xchg ax,ax 00000050 mov eax,1 00000055 lea r8d,[rbx+rax] 
  count += i % 16 == 0 ? 1 : 0; 00000037 mov eax,ecx 00000039 and eax,0Fh 0000003c je 0000000000000042 0000003e xor eax,eax 00000040 jmp 0000000000000047 00000042 mov eax,1 00000047 lea edx,[rbx+rax] 

问题应该是“为什么我的机器上看到这样的差异?”。 我不能再现如此巨大的速度差异,并怀疑有一些特定于您的环境的东西。 很难分辨出它可能是什么。 可以是你之前设置的一些(编译器)选项,忘记了它们。

我已经创build了一个控制台应用程序,在发行模式(x86)下重build,并在VS之外运行。 结果几乎相同,两种方法的结果都是1.77秒。 这里是确切的代码:

 static void Main(string[] args) { Stopwatch sw = new Stopwatch(); sw.Start(); int count = 0; for (uint i = 0; i < 1000000000; ++i) { // 1st method var isMultipleOf16 = i % 16 == 0; count += isMultipleOf16 ? 1 : 0; // 2nd method //count += i % 16 == 0 ? 1 : 0; } sw.Stop(); Console.WriteLine(string.Format("Ellapsed {0}, count {1}", sw.Elapsed, count)); Console.ReadKey(); } 

请任何有5分钟的人复制代码,重build,在VS之外运行,并发表评论的结果这个答案。 我想避免说“它适用于我的机器”。

编辑

为了确保我已经创build了一个64位 Winforms应用程序,结果与问题类似 – 第一个方法比第二个方法(1.05秒) (1.57秒)。 我观察到的差异是33% – 仍然很多。 似乎在.NET4 64位JIT编译器中有一个错误。

我无法与.NET编译器或其优化,甚至是执行其优化。

但在这种特定情况下,如果编译器将该布尔variables折叠到实际语句中,并且您要尝试debugging此代码,则优化后的代码将与写入的代码不匹配。 您将无法单步执行isMulitpleOf16赋值并检查它的值。

这只是优化可能被closures的一个例子。 可能有其他人。 优化可能发生在代码的加载阶段,而不是来自CLR的代码生成阶段。

现代运行时间非常复杂,特别是如果您在运行时抛出JIT和dynamic优化。 我感激代码完成了它所说的有时。

我认为这与你的其他问题有关。 当我如下更改您的代码时,多行版本将胜出。

哎呀,只在x86上。 在x64上,多线是最慢的,有条件的打败他们。

 class Program { static void Main() { ConditionalTest(); SingleLineTest(); MultiLineTest(); ConditionalTest(); SingleLineTest(); MultiLineTest(); ConditionalTest(); SingleLineTest(); MultiLineTest(); } public static void ConditionalTest() { Stopwatch stopwatch = new Stopwatch(); stopwatch.Start(); int count = 0; for (uint i = 0; i < 1000000000; ++i) { if (i % 16 == 0) ++count; } stopwatch.Stop(); Console.WriteLine("Conditional test --> Count: {0}, Time: {1}", count, stopwatch.ElapsedMilliseconds); } public static void SingleLineTest() { Stopwatch stopwatch = new Stopwatch(); stopwatch.Start(); int count = 0; for (uint i = 0; i < 1000000000; ++i) { count += i % 16 == 0 ? 1 : 0; } stopwatch.Stop(); Console.WriteLine("Single-line test --> Count: {0}, Time: {1}", count, stopwatch.ElapsedMilliseconds); } public static void MultiLineTest() { Stopwatch stopwatch = new Stopwatch(); stopwatch.Start(); int count = 0; for (uint i = 0; i < 1000000000; ++i) { var isMultipleOf16 = i % 16 == 0; count += isMultipleOf16 ? 1 : 0; } stopwatch.Stop(); Console.WriteLine("Multi-line test --> Count: {0}, Time: {1}", count, stopwatch.ElapsedMilliseconds); } } 

这是.NET Framework中的一个错误。

那么,我真的只是猜测,但我提交了一个关于Microsoft Connect的错误报告,看看他们说什么。 微软删除了这个报告之后,我在GitHub的roslyn项目上重新提交了这个报告。

更新:微软已经把这个问题转移到了coreclr项目。 从这个问题的评论看来,把它称为一个bug似乎有点强大; 这更多的是缺less优化。

我倾向于这样想:在编译器上工作的人每年只能做很多事情。 如果在那个时候他们可以实现lambda或者经典的优化,那么我会投票给lambda。 C#是一种在读取和写入代码方面效率较高的语言,而不是执行时间。

因此,团队专注于最大限度地提高读写效率的特性是合理的,而不是某个angular落案例(其中可能有数千个)的执行效率。

最初,我相信,这个想法是JITter会做所有的优化。 不幸的是,JITting需要花费大量的时间,任何先进的优化都会使其变得更糟。 所以这样做并不如人们所希望的那样好。

我发现在C#中编写真正快速的代码的一件事情是,在你提到的任何优化都会产生影响之前,你经常遇到严重的GC瓶颈。 就像分配数百万个对象一样。 C#在避免成本方面离你很远:您可以使用结构数组来代替,但是相比之下,生成的代码真的很难看。 我的观点是,关于C#和.NET的许多其他决定使得这样的特定的优化不像C ++编译器那样有价值。 哎呀,他们甚至放弃了NGEN中针对CPU的优化,为程序员(debugging器)效率提供交易性能。

说完这一切,我真的很喜欢 C#,它实际上使用了自20世纪90年代以来C ++所使用的优化。 只是不要以像async / await这样的function为代价。