运行应用程序时.NET 3.5 JIT 不工作

发布于 2024-08-17 21:01:06 字数 1389 浏览 7 评论 0原文

以下代码在 Visual Studio 内部运行该版本和在 Visual Studio 外部运行该版本时提供不同的输出。我正在使用 Visual Studio 2008 并面向 .NET 3.5。我也尝试过.NET 3.5 SP1。

在 Visual Studio 外部运行时,JIT 应该启动。要么 (a) C# 发生了一些我忽略的微妙事情,要么 (b) JIT 实际上有错误。我怀疑 JIT 可能会出错,但我已经没有其他可能性了...

在 Visual Studio 内部运行时的输出:

    0 0,
    0 1,
    1 0,
    1 1,

在 Visual Studio 外部运行发布时的输出:

    0 2,
    0 2,
    1 2,
    1 2,

原因是什么?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Test
{
    struct IntVec
    {
        public int x;
        public int y;
    }

    interface IDoSomething
    {
        void Do(IntVec o);
    }

    class DoSomething : IDoSomething
    {
        public void Do(IntVec o)
        {
            Console.WriteLine(o.x.ToString() + " " + o.y.ToString()+",");
        }
    }

    class Program
    {
        static void Test(IDoSomething oDoesSomething)
        {
            IntVec oVec = new IntVec();
            for (oVec.x = 0; oVec.x < 2; oVec.x++)
            {
                for (oVec.y = 0; oVec.y < 2; oVec.y++)
                {
                    oDoesSomething.Do(oVec);
                }
            }
        }

        static void Main(string[] args)
        {
            Test(new DoSomething());
            Console.ReadLine();
        }
    }
}

The following code gives different output when running the release inside Visual Studio, and running the release outside Visual Studio. I'm using Visual Studio 2008 and targeting .NET 3.5. I've also tried .NET 3.5 SP1.

When running outside Visual Studio, the JIT should kick in. Either (a) there's something subtle going on with C# that I'm missing or (b) the JIT is actually in error. I'm doubtful that the JIT can go wrong, but I'm running out of other possiblities...

Output when running inside Visual Studio:

    0 0,
    0 1,
    1 0,
    1 1,

Output when running release outside of Visual Studio:

    0 2,
    0 2,
    1 2,
    1 2,

What is the reason?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Test
{
    struct IntVec
    {
        public int x;
        public int y;
    }

    interface IDoSomething
    {
        void Do(IntVec o);
    }

    class DoSomething : IDoSomething
    {
        public void Do(IntVec o)
        {
            Console.WriteLine(o.x.ToString() + " " + o.y.ToString()+",");
        }
    }

    class Program
    {
        static void Test(IDoSomething oDoesSomething)
        {
            IntVec oVec = new IntVec();
            for (oVec.x = 0; oVec.x < 2; oVec.x++)
            {
                for (oVec.y = 0; oVec.y < 2; oVec.y++)
                {
                    oDoesSomething.Do(oVec);
                }
            }
        }

        static void Main(string[] args)
        {
            Test(new DoSomething());
            Console.ReadLine();
        }
    }
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

我不在是我 2024-08-24 21:01:06

这是一个 JIT 优化器错误。它正在展开内部循环,但没有正确更新 oVec.y 值:

      for (oVec.x = 0; oVec.x < 2; oVec.x++) {
0000000a  xor         esi,esi                         ; oVec.x = 0
        for (oVec.y = 0; oVec.y < 2; oVec.y++) {
0000000c  mov         edi,2                           ; oVec.y = 2, WRONG!
          oDoesSomething.Do(oVec);
00000011  push        edi  
00000012  push        esi  
00000013  mov         ecx,ebx 
00000015  call        dword ptr ds:[00170210h]        ; first unrolled call
0000001b  push        edi                             ; WRONG! does not increment oVec.y
0000001c  push        esi  
0000001d  mov         ecx,ebx 
0000001f  call        dword ptr ds:[00170210h]        ; second unrolled call
      for (oVec.x = 0; oVec.x < 2; oVec.x++) {
00000025  inc         esi  
00000026  cmp         esi,2 
00000029  jl          0000000C 

当您让 oVec.y 递增到 4 时,该错误就会消失,因为需要展开的调用太多。

一种解决方法是这样的:

  for (int x = 0; x < 2; x++) {
    for (int y = 0; y < 2; y++) {
      oDoesSomething.Do(new IntVec(x, y));
    }
  }

更新:2012年8月重新检查,这个bug在4.0.30319抖动版本中修复。但在v2.0.50727中仍然存在抖动。经过这么长时间,他们似乎不太可能在旧版本中解决这个问题。

It is a JIT optimizer bug. It is unrolling the inner loop but not updating the oVec.y value properly:

      for (oVec.x = 0; oVec.x < 2; oVec.x++) {
0000000a  xor         esi,esi                         ; oVec.x = 0
        for (oVec.y = 0; oVec.y < 2; oVec.y++) {
0000000c  mov         edi,2                           ; oVec.y = 2, WRONG!
          oDoesSomething.Do(oVec);
00000011  push        edi  
00000012  push        esi  
00000013  mov         ecx,ebx 
00000015  call        dword ptr ds:[00170210h]        ; first unrolled call
0000001b  push        edi                             ; WRONG! does not increment oVec.y
0000001c  push        esi  
0000001d  mov         ecx,ebx 
0000001f  call        dword ptr ds:[00170210h]        ; second unrolled call
      for (oVec.x = 0; oVec.x < 2; oVec.x++) {
00000025  inc         esi  
00000026  cmp         esi,2 
00000029  jl          0000000C 

The bug disappears when you let oVec.y increment to 4, that's too many calls to unroll.

One workaround is this:

  for (int x = 0; x < 2; x++) {
    for (int y = 0; y < 2; y++) {
      oDoesSomething.Do(new IntVec(x, y));
    }
  }

UPDATE: re-checked in August 2012, this bug was fixed in the version 4.0.30319 jitter. But is still present in the v2.0.50727 jitter. It seems unlikely they'll fix this in the old version after this long.

初心未许 2024-08-24 21:01:06

我相信这是一个真正的 JIT 编译错误。我会将其报告给微软,看看他们怎么说。有趣的是,我发现x64 JIT没有同样的问题。

这是我对 x86 JIT 的阅读。

// save context
00000000  push        ebp  
00000001  mov         ebp,esp 
00000003  push        edi  
00000004  push        esi  
00000005  push        ebx  

// put oDoesSomething pointer in ebx
00000006  mov         ebx,ecx 

// zero out edi, this will store oVec.y
00000008  xor         edi,edi 

// zero out esi, this will store oVec.x
0000000a  xor         esi,esi 

// NOTE: the inner loop is unrolled here.
// set oVec.y to 2
0000000c  mov         edi,2 

// call oDoesSomething.Do(oVec) -- y is always 2!?!
00000011  push        edi  
00000012  push        esi  
00000013  mov         ecx,ebx 
00000015  call        dword ptr ds:[002F0010h] 

// call oDoesSomething.Do(oVec) -- y is always 2?!?!
0000001b  push        edi  
0000001c  push        esi  
0000001d  mov         ecx,ebx 
0000001f  call        dword ptr ds:[002F0010h] 

// increment oVec.x
00000025  inc         esi  

// loop back to 0000000C if oVec.x < 2
00000026  cmp         esi,2 
00000029  jl          0000000C 

// restore context and return
0000002b  pop         ebx  
0000002c  pop         esi  
0000002d  pop         edi  
0000002e  pop         ebp  
0000002f  ret     

这对我来说似乎是一个糟糕的优化......

I believe this is in a genuine JIT compilation bug. I would report it to Microsoft and see what they say. Interestingly, I found that the x64 JIT does not have the same problem.

Here is my reading of the x86 JIT.

// save context
00000000  push        ebp  
00000001  mov         ebp,esp 
00000003  push        edi  
00000004  push        esi  
00000005  push        ebx  

// put oDoesSomething pointer in ebx
00000006  mov         ebx,ecx 

// zero out edi, this will store oVec.y
00000008  xor         edi,edi 

// zero out esi, this will store oVec.x
0000000a  xor         esi,esi 

// NOTE: the inner loop is unrolled here.
// set oVec.y to 2
0000000c  mov         edi,2 

// call oDoesSomething.Do(oVec) -- y is always 2!?!
00000011  push        edi  
00000012  push        esi  
00000013  mov         ecx,ebx 
00000015  call        dword ptr ds:[002F0010h] 

// call oDoesSomething.Do(oVec) -- y is always 2?!?!
0000001b  push        edi  
0000001c  push        esi  
0000001d  mov         ecx,ebx 
0000001f  call        dword ptr ds:[002F0010h] 

// increment oVec.x
00000025  inc         esi  

// loop back to 0000000C if oVec.x < 2
00000026  cmp         esi,2 
00000029  jl          0000000C 

// restore context and return
0000002b  pop         ebx  
0000002c  pop         esi  
0000002d  pop         edi  
0000002e  pop         ebp  
0000002f  ret     

This looks like an optimization gone bad to me...

酸甜透明夹心 2024-08-24 21:01:06

我将您的代码复制到新的控制台应用程序中。

  • 调试构建
    • 使用调试器和不使用调试器时的正确输出
  • 切换到发布版本
    • 再次,两次正确输出
  • 创建了一个新的 x86 配置(我正在运行 X64 Windows 2008 并使用“任何 CPU”)
  • 调试构建
    • F5 和 CTRL+F5 均获得正确输出
  • F5 和 CTRL+F5 Release Build
    • 附加调试器后的正确输出
    • 没有调试器 - 得到不正确的输出

所以这是 x86 JIT 错误地生成了代码。已删除我关于循环重新排序等的原始文本。此处的一些其他答案已确认 JIT 在 x86 上错误地展开循环。

要解决这个问题,您可以将 IntVec 的声明更改为一个类,它适用于所有风格。

认为这需要在 MS Connect 上继续...-

1 给 Microsoft!

I copied your code into a new Console App.

  • Debug Build
    • Correct output with both debugger and no debugger
  • Switched to Release Build
    • Again, correct output both times
  • Created a new x86 configuration (I'm on running X64 Windows 2008 and was using 'Any CPU')
  • Debug Build
    • Got the correct output both F5 and CTRL+F5
  • Release Build
    • Correct output with Debugger attached
    • No debugger - Got the incorrect output

So it is the x86 JIT incorrectly generating the code. Have deleted my original text about reordering of loops etc. A few other answers on here have confirmed that the JIT is unwinding the loop incorrectly when on x86.

To fix the problem you can change the declaration of IntVec to a class and it works in all flavours.

Think this needs to go on MS Connect....

-1 to Microsoft!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文