Unity prépare un nouveau compilateur en C # appelé Burst

Unity est un moteur de jeu extrêmement populaire, en particulier pour ses outils d'édition complets et faciles à utiliser.

Cependant, le moteur doit suivre l'évolution des machines: depuis dix ans, les processeurs n'augmentent pas en fréquence, mais en nombre de cœurs. En d'autres termes, Pour exploiter les nouvelles performances disponibles, les jeux doivent exécuter leur code sur différents cœurs, à travers différents fils.

Cependant, à partir du moment où la technologie est disponible, peu de jeux réussissent vraiment. En fait, les problèmes d'écriture d'un tel code sont nombreux.

Pour éviter ces inconvénients, il est possible de suivre certains ensembles de règles. C'est l'une des raisons pour lesquelles Unity travaille sur un nouveau compilateur en C #, appelé Burst avec lequel, si ces règles ne sont pas suivies, une erreur de compilation se produira.

Pour y parvenir, le code doit être écrit comme un ensemble de tâches à effectuer. Chacune de ces tâches effectue quelques transformations sur les données.

Le programmeur doit spécifier les zones mémoire auxquelles il peut accéder en lecture seule et celles dans lesquelles il souhaite lire et écrire des données- Le compilateur s'assurera que vous n'utilisez rien en dehors de ces déclarations.

Un planificateur détermine ensuite la meilleure façon d'accomplir ces tâches, en temps réel, avec ces informations supplémentaires: vous pouvez vous assurer qu'aucune tâche n'écrira de données là où quelqu'un d'autre essaie de lire ou d'écrire, par exemple.

Burst n'est pas seulement destiné à faciliter la programmation parallèle: il est également utilisé dans les parties les plus critiques (du point de vue des performances) du code Unity.

Jusqu'à présent, ceux-ci étaient écrits en C ++, mais les compilateurs actuels ne sont pas entièrement satisfaisants.

En fait, si un développeur veut qu'une boucle soit vectorisée, il n'a aucune garantie que le compilateur le fera, du fait d'une addition entre deux vecteurs, par exemple, le compilateur doit formellement prouver que, dans tous les cas possibles et imaginables, les deux vecteurs ne correspondent pas aux mêmes adresses en mémoire).

Pourquoi Burst et pas un compilateur existant?

La performance est un point critique si une boucle n'est pas vectorisée c'est un vrai problème qu'il faut résoudre rapidement.

En outre, Le binaire généré doit être sécurisé compte tenu des erreurs de dépassement de tampon et les références dangereuses doivent être découvertes dès que possible, avec des messages d'erreur réels plutôt que des comportements indéfinis (qui causent de nombreux problèmes de sécurité).

Face à ces besoins accrus, vous devez encore choisir la langue d'entrée de ce compilateur- Une variante ou un sous-ensemble de C, C ++, C # ou un nouveau langage?

Une nouvelle langue n'est pas une bonne option car dans un premier temps, vous évitez d'avoir à former des gens avec ce nouvel outil.

C # a la préférence du point de vue des utilisateurs, Puisqu'il est déjà utilisé par le moteur de jeu, il sera encodé dans la même langue que les jeux.

En outre, C # a déjà un très grand écosystème, au contraire, C ++ souffre toujours de son héritage C, avec des inclusions pas toujours évidentes à déterminer et des temps de compilation énormes, des failles que C ++ 20 corrige partiellement, malgré son obsession de la performance.

La décision a été prise de continuer avec C #, mais en supprimant un certain nombre d'éléments qui entravent les performances, tels que la bibliothèque standard, principalement le garbage collection, et les autorisations.

Burst ne fonctionne pas vraiment comme un compilateur complet car il ne prend pas une grande quantité de code en entrée, mais seulement le point d'entrée d'une boucle cruciale.

Il le compile simplement en tant que fonction, ainsi que tout ce qu'il appelle. Le niveau d'optimisation est extrêmement élevé: comme Burst se concentre sur certaines parties du code, cela peut prendre du temps.

La première itération de Burst, avec HPC # et le système de tâches est venue avec Unity 2018.1.

Le code généré est parfois plus rapide que la version précédente en C ++, parfois plus lent, mais les développeurs sont convaincus qu'ils atteindront toujours au moins le même niveau de performances que C ++.

source:  blogs.unity3d.com