Est-ce que .NET Framework doit être réoptimisé après la mise à niveau vers une nouvelle microarchitecture CPU?

Je crois que .NET Framework optimisera certains binaires ciblant les fonctionnalités spécifiques à la machine sur laquelle il est installé.

Après avoir changé la CPU d'un Intel Nehalem à une puce Haswell, l'optimisation doit-elle être exécutée à nouveau manuellement? Si oui, quel est le processus pour cela?

Entre les générations, il y a quelques ajouts remarquables:

  • Westmere : jeu d'instructions AES
  • Sandy Bridge : Extensions vectorielles avancées
  • Ivy Bridge : RdRand (générateur de nombres aléatoires matériels), F16C (instructions de conversion flottante à 16 bits)
  • Haswell : Haswell New Instructions (comprend Advanced Vector Extensions 2 (AVX2), rassemblement, BMI1, BMI2, prise en charge ABM et FMA3)

Donc, mon processus de réflexion, bien que naïf, était que les optimisations pouvaient en profiter dans des cas généraux. Par exemple, peut-être que les appels à la bibliothèque aléatoire pourraient utiliser le matériel-RNG sur Ivy Bridge et les modèles ultérieurs.

Réponse courte

Il n'a pas besoin, dès maintenant.

Longue réponse

Le code qui cible le .NET Framework Common Language Runtime (CLR) est connu sous le nom de code managé , et le code qui n'est pas connu comme non managé .

Lors de la compilation en code géré, le compilateur traduit votre code source en langage intermédiaire Microsoft (MSIL), qui est un ensemble d'instructions indépendant de la CPU qui peut être converti efficacement en code natif.

Avant de pouvoir exécuter le langage intermédiaire Microsoft (MSIL), il doit être compilé par rapport à l'exécution de la langue commune au code natif pour l'architecture de la machine cible. .NET Framework fournit deux façons d'effectuer cette conversion:

  • Un compilateur JIT (.NET Framework just-in-time).

  • The .NET Framework Native Image Generator (Ngen.exe) .

Source: Processus d'exécution géré

Compilation JIT

La compilation JIT prend en compte la possibilité que certains codes ne soient jamais appelés lors de l'exécution. Au lieu d'utiliser le temps et la mémoire pour convertir tout le MSIL dans un fichier PE en code natif, il convertit le MSIL au besoin pendant l'exécution et stocke le code natif résultant en mémoire afin qu'il soit accessible pour les appels ultérieurs dans le contexte de ce processus.

Source: Processus d'exécution géré

Bien qu'en théorie le compilateur JIT puisse profiter des instructions spécifiques à la CPU comme AES ou AVX, de telles optimisations n'ont pas encore été mises en œuvre. Le support AVX complet viendra probablement plus tard avec une nouvelle version du runtime .NET qui inclut RyuJIT , le compilateur JIT de prochaine génération qui est en cours de développement.

Images autochtones

[Le Native Image Generator (Ngen.exe) est un outil qui effectue une compilation [de] MS-DOS à l'avant du temps de compilation à un code natif comme le compilateur JIT. Cependant, l'opération de Ngen.exe diffère de celle du compilateur JIT de trois façons:

  • Il exécute la conversion de MSIL en code natif avant d'exécuter l'application au lieu de pendant l'exécution de l'application.

  • Il compile un ensemble entier à la fois, au lieu d'une méthode à la fois.

  • Il persiste le code généré dans le Native Image Cache en tant que fichier sur le disque.

Source: Processus d'exécution géré

Lorsque vous utilisez ngen.exe pour créer des images natives, la sortie dépend de plusieurs facteurs tels que l'identité des assemblages et la version du cadre. Jusqu'à la version 1.1 du .NET Framework, la sortie était également dépendante de la CPU:

Si vous mettez à niveau le processeur d'un ordinateur vers une nouvelle famille de processeurs, toutes les images natives stockées dans le cache d'image natif ne sont pas valides.

Source: Native Image Generator (Ngen.exe) Syntaxe héritée

À partir de la version 2.0, certaines causes d'invalidation d'image (y compris le type de CPU) ont été supprimées. De plus, un nouveau commutateur de /update à /update été ajouté pour recréer des images non valides. Citer une entrée de blog rédigée par David Notario (l'accent est mis):

Dans les versions précédentes du CLR (1.0 et 1.1), nous avons traité la compilation NGEN de la même manière que nous avons traité la compilation JIT, c'est-à-dire, étant donné que nous compilons dans la machine cible, nous devrions en profiter. Cependant, dans Whidbey [Visual Studio 2005], ce n'est pas le cas. Nous supposons un ensemble d'instructions PPro et générons un code comme s'il visait un P4. Pourquoi est-ce? Il y a eu plusieurs raisons:

  • Augmenter la prévisibilité des assemblages redistributeurs .NET (facilite notre vie de support).

  • Les OEM et les autres grands clients souhaitaient une image unique par plate-forme (pour l'entretien, la construction et la gestion des raisons).

Nous aurions pu avoir une option de ligne de commande pour générer un code spécifique à la plate-forme dans ngen , mais étant donné que ngen est principalement pour fournir un meilleur comportement de travail et que cette option supplémentaire compliquerait certains autres scénarios, nous avons décidé de ne pas y aller.

Source: Le JIT profite-t-il de ma CPU?

Dans Windows 8 et versions ultérieures, .NET Framework est capable de générer et de gérer automatiquement des images natives en fonction de l'utilisation. The Native Image Task effectuera tous les travaux en arrière-plan chaque fois que cela est nécessaire, et il n'y a pas besoin d'intervention manuelle.

Autres lectures

  • Compilation juste à temps
  • Le JIT profite-t-il de ma CPU?
  • NGEN Primer
  • Génération d'image native