401 votes

.NET JIT potentiel d'erreur?

Le code suivant donne les différentes sortie lors de l'exécution de la libération à l'intérieur de Visual Studio, et l'exécution de la libération à l'extérieur de Visual Studio. Je suis à l'aide de Visual Studio 2008 et le ciblage .NET 3.5. J'ai aussi essayé .NET 3.5 SP1.

Lors de l'exécution à l'extérieur de Visual Studio, l'équipe doit coup de pied dans. Soit (un) il y a quelque chose de subtile passe avec C# que je suis absent ou (b) le JIT est en fait dans l'erreur. Je doute que l'équipe peut aller mal, mais je suis à cours d'autres horizons...

De sortie lors de l'exécution dans Visual Studio:

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

De sortie lors de l'exécution de la libération en dehors de Visual Studio:

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

Quelle est la raison?

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();
        }
    }
}

210voto

Hans Passant Points 475940

C'est un JIT, l'optimiseur de bug. Il est de dérouler la boucle interne, mais pas la mise à jour de l'oVec.y valeur correctement:

      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 

Le bug disparaît lorsque vous laissez oVec.y incrément de 4, c'est trop d'appels à dérouler.

Une solution de contournement consiste à ceci:

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

Mise à JOUR: le re-vérifié en août 2012, ce bug a été corrigé dans la version 4.0.30319 de la gigue. Mais il est toujours présent dans la v2.0.50727 de la gigue. Il semble peu probable qu'ils vont résoudre ce problème dans l'ancienne version après cette longue.

82voto

Nick Guerrera Points 1981

Je crois que c'est dans un véritable compilation JIT bug. Je voudrais signaler à Microsoft et voir ce qu'ils disent. Fait intéressant, j'ai trouvé que le JIT x64 n'ont pas le même problème.

Voici ma lecture du JIT x86.

// 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     

Cela ressemble à une optimisation gone bad pour moi...

23voto

Andras Zoltan Points 24996

J'ai copié ton code dans une nouvelle Application de Console.

  • Debug
    • Sortie correcte avec les deux débogueur et pas de débogueur
  • Passé à la Libération de Construire
    • Encore une fois, de corriger sortie deux fois
  • Créé un nouveau x86 configuration (je suis sur l'exécution de Windows X64 2008 et a été l'utilisation de 'CPU')
  • Debug
    • A obtenu de bons résultats à la fois sur F5 et CTRL+F5
  • Communiqué De Construire
    • Sortie correcte avec le Débogueur
    • Pas de débogueur Eu la mauvaise sortie

C'est donc le JIT x86 incorrecte de générer le code. Avez supprimé mon texte original sur la réorganisation des boucles etc. Quelques autres réponses ici ont confirmé que le JIT est dénouement de la boucle de manière incorrecte lorsque sur x86.

Pour résoudre le problème, vous pouvez modifier la déclaration de IntVec à une classe et ça marche à tous les saveurs.

Pense que cela doit aller sur connexion MS....

-1 pour Microsoft!

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X