multicore - ¿Funciona realmente ProfileOptimization?

jit .net-4.5

Question

Una de las nuevas mejoras de rendimiento para .NET 4.5 es la introducción del ''MultiCode JIT''.

Vea here para más detalles.

He intentado esto, pero parece no tener efecto en mi aplicación.

La razón por la que estoy interesado es que mi aplicación (IronScheme) tarda mucho tiempo en iniciarse si no es NGEN''d, lo que implica que una cantidad justa de JIT''ng está involucrada en el inicio. (1.4 seg contra 0.1 seg cuando NGEN''d).

He seguido las instrucciones sobre cómo habilitar esto y puedo ver que se crea un ''pequeño'' (4-12KB). Pero en el inicio posterior, parece que no tiene ningún efecto en mejorar el tiempo de inicio. Todavía es 1.4 seg.

¿Alguien realmente ha visto (o hecho) este trabajo en la práctica?

Además, ¿existen limitaciones respecto de qué código se "rastreará"? Por ejemplo: contextos de carga de ensamblajes, ensamblajes transitorios, etc. Pido esto porque el archivo creado nunca parece crecer, pero de hecho estoy generando una buena cantidad de código (en un ensamblaje transitorio).

Un error que encontré fue que SetProfileRoot no parece entender un / como separador de ruta, asegúrese de usar /.

Answer 1

¿Llamar Activator.CreateInstance durante el inicio parece matar MCJ?

O, más bien, eso desencadenó una Resolución de asamblea, que parece detener completamente a MCJ. Y nunca trabajar después de eso. Tal vez los documentos de MSDN deberían mencionar esto.

Answer 2

La regla de oro que usamos en Microsoft es que el JIT Multicore lo lleva a la mitad del camino hacia el rendimiento de inicio de NGEN. Por lo tanto, si su aplicación se inicia en 0.1 segundos con NGEN y 1.4 segundos sin NGEN, esperaríamos que el inicio del multinúcleo JIT demorara aproximadamente 0.75 segundos.

Dicho esto, tuvimos que establecer algunas limitaciones para garantizar que el orden de ejecución del programa sea el mismo con y sin MCJ. En ocasiones, MCJ pausará el subproceso en segundo plano a la espera de que los módulos se carguen con el subproceso en primer plano y abortará la compilación en segundo plano si hay un evento de resolución de ensamblado o resolución de módulo.

Si desea averiguar qué está sucediendo en su caso, tenemos la instrumentación ETW (Event Tracing For Windows) de la función MCJ y pronto lanzaremos una versión de PerfView que podrá recopilar estos eventos si realiza un seguimiento. de su aplicación de inicio.

Actualización: PerfView se ha actualizado para poder mostrar información JIT de fondo. Aquí están los pasos para diagnosticar con la última versión (1.2.2.0):

1. Recopile una traza usando PerfView del inicio de su aplicación, ya sea usando Collect-> Run o Collect-> Collect en el menú principal de PerfView.
2. Suponiendo que haya usado Collect-> Run, ponga el nombre de su archivo .exe en el cuadro de texto Comando, elija un nombre de archivo (es decir, IronScheme.etl), seleccione Background JIT en Opciones avanzadas y haga clic en Ejecutar comando.
3. Cierre su aplicación y haga doble clic en el archivo IronScheme.etl que se genera.
4. Haga doble clic en la vista de estadísticas JIT en la lista debajo de IronScheme.etl, debería ver algo como esto en la vista que aparece:

This process uses Background JIT compilation (System.Runtime.ProfileOptimize) 
    Methods Background JITTed : 2,951 
    Percent # Methods Background JITTed : 52.9% 
    MSec Background JITTing : 3,901 
    Percent Time JITTing is Background : 50.9% 
    Background JIT Thread : 11308 

Puede hacer clic en "Ver los diagnósticos de Jit de fondo sin procesar" para ver todos los eventos de MCJ en excel. Una pregunta que olvidé preguntar: ¿está ejecutando esto en una máquina multinúcleo o en una máquina virtual multinúcleo? Es un error común probar MCJ en una máquina virtual que solo tiene un único procesador lógico.