- Le runtime Mono utilisé par Unity affiche des vitesses d’exécution nettement inférieures à celles du .NET moderne, avec des cas où le même code C# présente un écart pouvant aller jusqu’à 15x
- Dans du vrai code de jeu, l’exécution Unity basée sur Mono prend 100 secondes, contre 38 secondes pour le même code sous .NET, ce qui affecte fortement l’efficacité du débogage et des tests
- Même en mode Release, Mono met 30 secondes contre 12 pour .NET, ce qui maintient un écart de performance supérieur à 2,5x même dans un environnement optimisé
- La cause vient du JIT inefficace de Mono, de ses échecs d’inlining et de copies mémoire excessives, en contraste avec les optimisations modernes du JIT CoreCLR de .NET
- Si Unity achève sa modernisation .NET basée sur CoreCLR, des gains de performance majeurs seront possibles à la fois dans les jeux et dans l’éditeur, ce qui pourrait supprimer cette taxe de performance cachée pour tous les projets Unity
Pourquoi Unity utilise Mono
- Unity utilise le framework Mono pour exécuter le code C# depuis 2006
- À l’époque, Mono était la seule implémentation .NET multiplateforme, et son caractère open source permettait à Unity de le modifier
- À partir de 2014, Microsoft a publié .NET Core en open source, puis lancé .NET Core 1.0 en 2016
- Depuis, l’écosystème .NET a progressé rapidement avec le compilateur Roslyn, un nouveau JIT et de nombreuses améliorations de performance
- En 2018, des ingénieurs d’Unity ont indiqué travailler sur un portage de CoreCLR, avec l’espoir d’un gain de performance de 2x à 10x par rapport à Mono
- Pourtant, à la fin de l’année 2025, il reste toujours impossible d’exécuter un jeu sur une base CoreCLR
L’écart de performance entre Mono et .NET
- Le code de simulation d’un projet Unity a été exécuté en dehors d’Unity sous .NET pour une comparaison directe
- Environnement Unity/Mono : 100 secondes, environnement .NET : 38 secondes (en mode Debug)
- En mode Release, l’écart demeure avec 30 secondes pour Mono contre 12 pour .NET
- .NET se montre aussi très efficace en optimisation multithread, en générant par exemple une carte 4K×4K en moins de 3 secondes
- La principale cause est la génération de code inefficace de Mono, avec un écart de vitesse de 15x même sur une boucle simple
Comparaison d’assemblage : Mono vs .NET
- Comparaison de l’assemblage x64 généré à partir du même code de test
- Le JIT de .NET déplace les invariants de boucle hors de la boucle (hoisting) et n’effectue qu’un minimum d’opérations sur registres
- Mono répète des copies mémoire avec des dizaines d’instructions
mov et souffre d’un inlining inefficace, ce qui pénalise les performances
- Temps d’exécution d’une boucle répétée sur
int.MaxValue
- .NET : 750 ms, Mono : 11 500 ms, Unity Editor (Debug) : 67 000 ms
- Mono répète à l’intérieur de la boucle des déplacements mémoire et des comparaisons inutiles
Ce que signifie l’adoption de CoreCLR
- CoreCLR apporte des fonctionnalités modernes comme un JIT récent, l’API
Span<T>, les optimisations SIMD et la prise en charge des instructions matérielles
- Ces fonctions laissent entrevoir un gain de performance supplémentaire d’au moins 2x
- Le compilateur Burst de Unity génère du code natif sur la base de LLVM, mais avec des limitations sur les fonctionnalités C#
- Le JIT moderne de CoreCLR pourrait offrir des performances proches de Burst avec moins de contraintes sur le langage
- CoreCLR prend aussi en charge l’AOT (compilation anticipée), ce qui peut améliorer la vitesse de démarrage et répondre aux besoins des plateformes limitant le JIT (comme iOS)
- Unity indique toutefois vouloir continuer à maintenir IL2CPP
Conclusion : Unity doit moderniser son .NET
- Par rapport au .NET moderne, Mono affiche des performances d’exécution 1,5x à 3x plus lentes ou davantage, ce qui constitue un coût caché pour l’ensemble des projets Unity
- Effets attendus de l’adoption de CoreCLR
- Amélioration des performances runtime, itérations de build plus rapides, GC amélioré, suppression du domain reload, part accrue du code managé
- La feuille de route de Unity 6.x inclut la modernisation .NET, mais celle-ci est prévue après 2026
- Une fois la prise en charge de CoreCLR achevée, Unity pourrait offrir une véritable révolution des performances aux développeurs comme aux joueurs
- Pour l’instant, les limites de Mono restent un goulot d’étranglement de performance pour tout l’écosystème Unity
Aucun commentaire pour le moment.