C++/CLI y C#: Asombrosas diferencias en el optimizador de código (III)

Seguimos con el tema. En un comentario puesto en la segunda parte de esta entrega se comenta que conforme vaya el jitter dando vueltas sobre el mismo código, optimizará mejor el resultado. Es una de las cosas que también he leído por ahí, pero por desgracia no es cierto.

Vamos a ello.

Creemos una nueva solución con el nombre TestCS3 y piquemos el siguiente código:

using System; 
using System.Collections.Generic; 
using System.Text; 
 
namespace TestCS1 
{ 
    class Program 
    { 
        static void CallPrint() 
        { 
            //Console.WriteLine("CallPrint"); 
        } 
        static void DoWork() 
        { 
            for (int i = 0; i < 1000; i++) 
                CallPrint(); 
        } 
        static void Main(string[] args) 
        { 
            for(int i=0;i<1000;i++) 
                DoWork(); 
            Console.WriteLine("Hello World"); 
        } 
    } 
} 
 

Hemos añadido dentro de main() un bucle que hace 1000 llamadas al método DoWork(). Para comprobar si es cierto que el jitter realiza en varias llamadas mejores optimizaciones, vamos a poner un punto de interrupción condicional en el DoWork() que se dispare a las 500 pasadas. Para ello, una vez puesto en su lugar, mostramos la ventana de Breakpoints (Debug|Windows|Breakpoints ó Alt-F9), seleccionamos el punto en la lista y con el botón derecho del ratón elegimos «Hit Count». Cambiamos los valores para que se pare a las 500 veces:

Y luego ejecutamos el programa hasta que el punto de interrupción salte:

Como antes, pulsamos Alt-F8 o abrimos la ventana de desensamblado y miramos. Ejecutamos varios pasos con Step Into o F11 y llegamos, de nuevo, al punto en el que se está llamando al método vacío:

Podemos incluso observar que el código ha cambiado, pero casi a peor, ya que ahora hay más códigos de saltos y sigue ese extraño call 0x79C05A9E, que podría ser una llamada al recolector o a cualquier otro lugar. Como es una aplicación de consola no creo que sea una llamada a ningún bucle principal.

De todo esto podemos ir extrayendo varias conclusiones, ninguna excesivamente buena…

De todos modos, existe todavía una comprobación mucho más fácil, y es ir depurando paso a paso sobre el propio código fuente. En una aplicación en C++ ó C++/CLI, vemos como hay bloques de código que se saltan, mientras que en C# no se salta ni uno. 

Y todavía no he hecho ninguna medición de rendimiento más o menos seria…

Un comentario sobre “C++/CLI y C#: Asombrosas diferencias en el optimizador de código (III)”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *