Помилка потенціалу .NET JIT?

Наступний код дає різний вихід при запуску випуску всередині Visual Studio та запуску випуску поза Visual Studio. Я використовую Visual Studio 2008 та націлюю на .NET 3.5. Я також спробував .NET 3.5 SP1.

Коли ви працюєте за межами Visual Studio, JIT повинен натиснути. Або (а) з 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();
        }
    }
}

Це помилка оптимізатора 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 року, ця помилка була виправлена ​​у версії 4.0.30319 джиттера. Але все ще присутній у тремтінні v2.0.50727. Мабуть, навряд чи вони виправлять це в старій версії після цього довгого часу.

Я вважаю, що це справжня помилка компіляції JIT. Я би повідомив про це Microsoft і побачив, що вони кажуть. Цікаво, що я виявив, що 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     

Це виглядає як оптимізація пішла мені погано ...

Я скопіював ваш код у новий додаток консолі.

• Налагодження налагодження
  • Правильний вихід як з налагоджувачем, так і без налагоджувача
• Переключено на випуск версії
  • Знову виправте обидва рази
• Створено нову конфігурацію x86 (я працюю на X64 Windows 2008 і використовував "Будь-який процесор")
• Налагодження налагодження
  • Отримано правильний вихід як F5, так і CTRL + F5
• Випуск збірки
  • Правильний вихід із додаванням налагоджувача
  • Немає налагоджувача - Отримано неправильний вихід

Отже, x86 JIT неправильно генерує код. Видалили мій оригінальний текст про переупорядкування циклів тощо. Кілька інших відповідей тут підтвердили, що JIT неправильно розкручує цикл, коли знаходиться на x86.

Щоб вирішити проблему, ви можете змінити декларацію IntVec на клас, і вона працює у всіх смаках.

Подумайте, що це потрібно продовжувати на MS Connect ....

-1 до Microsoft!