C++ vs C# pour Unreal Engine/Unity

par | 12 Mai 2020

Je publie cet article suite à une question postée sur ma vidéo « Blueprints vs C++ sous Unreal Engine 4« .  Autant partager cela avec d’autres et confronter les arguments,  je n’ai pas la science infuse. On me demande quelle est la différence entre C++ et C# (prononcez « SI SHARP » à l’anglaise). C’est bien entendu une question posée dans la contexte d’Unreal Engine, et quand on parle de C#, c’est pour faire référence à Unity. Toutefois, il faut savoir qu’il existe un projet open source de plugin permettant l’utilisation de C# sous UE4, basé lui-même sur MonoUE, mais ce projet n’est pas officiel.  Rappelons ici qu’on peut utiliser plusieurs langages sous Unreal Engine, des blueprints au c++, en passant par Python, SkoomkumScript et Javascript (et ce n’est pas exhaustif).  Mais revenons à C++ vs C# !

C# vs C++ – UE/Unity

Unreal Engine a été développé en C++ et on peut le programmer en Blueprints et C++. Unity a été développé en partie en C++ et en partie en C#, et fonctionne avec C#.

C# est un C « managé », c’est-à-dire qu’il se charge de gérer tous les appels à la mémoire, dispose d’un « garbage collector » (comme les langages scriptés) et fonctionne au travers de la plateforme .NET de Microsoft (ou son équivalent Open Source Mono sur d’autres).

C++ peut être compilé dans une code machine directement exécutable par un processeur, mais pas C#. C# est compilé dans un code intermédiaire (bytecode) qui est ensuite traduit à la volée (Just in Time) en un code exécutable. Il est donc moins rapide, mais plus portable (sur tout environnement .NET).

Dès qu’on a besoin de vitesse on utilise le C ou le C++. Mais créer du code C++ multiplateforme fait considérablement gongler la taille du code source (sans impact sur les perfs) ! Avec les processeurs actuels, on peut vraiment se demander si l’effort en vaut le coup ! C’est plutôt un choix historique…

Mais il faut voir que dans un moteur de jeu, le code qu’on écrit n’est pas souvent « critique ». L’important, c’est que le reste du moteur le soit. C’est pour ça que l’utilisation de scripts dans les jeux est souvent possible. De fait, Unity n’est pas handicapé par le fait qu’il utilise le C# puisque son code moteur (il est assez optimisé et écrit en C++ en partie).  Il semblerait que l’utilisation des 2 conjointement soit source de problèmes chez unity et qu’ils envisagent de tout réécrire en C# (je crains pour les performances, mais les devs semblent confiants).

Conclusion

Certains disent que C# est plus facile à apprendre car il ressemble un peu à Java… Je ne sais pas, je suis dev C/C++ depuis trop longtemps. Ce que je sais, c’est que la façon dont Epic Games utilise le C++ (avec plein de macros) est parfois déroutante. Mais tant qu’on ne met pas le nez dans le moteur, ça va (et après, on s’y habitue).

Alors personnellement, je n’ai pas de préférence fondamentale pour un langage. Je préfère C++ car je maitrise mieux ce qu’il produit, c’est-à-dire le code compilé (et s’il n’y avait pas la POO, je lui préfèrerais le C d’ailleurs).

Mais je m’interroge aujourd’hui sur la façon dont un compilateur « Just In Time » peut accélérer un code en prenant en compte l’architecture de la machine, avec la possibilité de paralléliser une partie du code selon le nombre de processeur, la présence de Cuda, de Tensors (cartes RTX ou dédiées IA), etc.

Je sais bien que les compilateurs C# actuels ne le font pas (ou peu) et qu’il faudrait baliser son code dans tous les cas pour aider à la parallélisation (j’ai fait pas mal de choses autour de ça, depuis 1996 avec PVM). Donc, le potentiel d’un code managé comme C# est peut-être plus intéressant à terme.

Découvrez nos derniers numéros !

2 Commentaires

  1. Jean-René Zeitoun

    Ce n’est pas parce que C# est compilé à la volée, qu’il est moins rapide. A la volée, oui (encore que, cf le projet « corert »), mais il est compilé quand même en code natif x64/x86/ARM64. On peut écrire du C/C++ qui s’exécute moins vite que du C# très facilement. Sachant qu’un point fondamental quand il s’agit de graphique c’est surtout de gérer le GPU et sa relation avec le CPU. Et ça c’est pas dépendant du langage mais plus de la façon dont on programme, voire du ou des frameworks qu’on utilise (DirectX, SDL, etc.) ou les instructions SIMD (https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in-net-core/)

    Réponse
    • greg

      Non, ce n’est pas la compilation à la volée qui fait qu’il est moins rapide en effet et évidemment on peut écrire comme un malpropre en n’importe quel langage et faire en sorte d’avoir un code plus lent.
      Le fait d’avoir un code « retranscrit » par contre est un élément important, de même qu’avoir une mémoire « managée » (d’où le garbage collector, etc.). Un code C/C++ est dépourvu d’un tas de mécanismes de ce type et s’approche donc plus d’un code assembleur, sans fioriture. Mais, oui, globalement, je suis d’accord, si différence il y a, elle n’est pas non plus fondamentale. D’ailleurs, cela dépend souvent du compilateur. Pendant un paquet d’années, le compilateur produisant le code le plus rapide (utilisé par l’armée US et d’autres pour le temps-réel) était un compilateur ADA – La sécurité dans l’implémentation du code (qui est relatif à ADA) faisait que le compilateur pouvait « optimiser » un tas de choses, impossible en C/C++. Donc, le compilateur, la MV… tout ça rentre aussi en ligne de compte.

      Réponse

Laisser un commentaire

Ces articles pourraient aussi vous intéresser …