C++ vs C# pour Unreal Engine/Unity

Je pub­lie cet arti­cle suite à une ques­tion postée sur ma vidéo “Blue­prints vs C++ sous Unre­al Engine 4″.  Autant partager cela avec d’autres et con­fron­ter les argu­ments,  je n’ai pas la sci­ence infuse. On me demande quelle est la dif­férence entre C++ et C# (pronon­cez “SI SHARP” à l’anglaise). C’est bien enten­du une ques­tion posée dans la con­texte d’Un­re­al Engine, et quand on par­le de C#, c’est pour faire référence à Uni­ty. Toute­fois, il faut savoir qu’il existe un pro­jet open source de plu­g­in per­me­t­tant l’u­til­i­sa­tion de C# sous UE4, basé lui-même sur MonoUE, mais ce pro­jet n’est pas offi­ciel.  Rap­pelons ici qu’on peut utilis­er plusieurs lan­gages sous Unre­al Engine, des blue­prints au c++, en pas­sant par Python, Skoomkum­Script et Javascript (et ce n’est pas exhaus­tif).  Mais revenons à C++ vs C# !

C# vs C++ — UE/Unity

Unre­al Engine a été dévelop­pé en C++ et on peut le pro­gram­mer en Blue­prints et C++. Uni­ty a été dévelop­pé en par­tie en C++ et en par­tie en C#, et fonc­tionne avec C#.

C# est un C “man­agé”, c’est-à-dire qu’il se charge de gér­er tous les appels à la mémoire, dis­pose d’un “garbage col­lec­tor” (comme les lan­gages scrip­tés) et fonc­tionne au tra­vers de la plate­forme .NET de Microsoft (ou son équiv­a­lent Open Source Mono sur d’autres).

C++ peut être com­pilé dans une code machine directe­ment exé­cutable par un processeur, mais pas C#. C# est com­pilé dans un code inter­mé­di­aire (byte­code) qui est ensuite traduit à la volée (Just in Time) en un code exé­cutable. Il est donc moins rapi­de, mais plus portable (sur tout envi­ron­nement .NET).

Dès qu’on a besoin de vitesse on utilise le C ou le C++. Mais créer du code C++ mul­ti­plate­forme fait con­sid­érable­ment gongler la taille du code source (sans impact sur les perfs) ! Avec les processeurs actuels, on peut vrai­ment se deman­der si l’ef­fort en vaut le coup ! C’est plutôt un choix his­torique…

Mais il faut voir que dans un moteur de jeu, le code qu’on écrit n’est pas sou­vent “cri­tique”. L’im­por­tant, c’est que le reste du moteur le soit. C’est pour ça que l’u­til­i­sa­tion de scripts dans les jeux est sou­vent pos­si­ble. De fait, Uni­ty n’est pas hand­i­capé par le fait qu’il utilise le C# puisque son code moteur (il est assez opti­misé et écrit en C++ en par­tie).  Il sem­blerait que l’u­til­i­sa­tion des 2 con­join­te­ment soit source de prob­lèmes chez uni­ty et qu’ils envis­agent de tout réécrire en C# (je crains pour les per­for­mances, mais les devs sem­blent con­fi­ants).

Conclusion

Cer­tains dis­ent que C# est plus facile à appren­dre car il ressem­ble 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 par­fois déroutante. Mais tant qu’on ne met pas le nez dans le moteur, ça va (et après, on s’y habitue).

Alors per­son­nelle­ment, je n’ai pas de préférence fon­da­men­tale pour un lan­gage. Je préfère C++ car je maitrise mieux ce qu’il pro­duit, c’est-à-dire le code com­pilé (et s’il n’y avait pas la POO, je lui préfèr­erais le C d’ailleurs).

Mais je m’in­ter­roge aujour­d’hui sur la façon dont un com­pi­la­teur “Just In Time” peut accélér­er un code en prenant en compte l’ar­chi­tec­ture de la machine, avec la pos­si­bil­ité de par­al­lélis­er une par­tie du code selon le nom­bre de processeur, la présence de Cuda, de Ten­sors (cartes RTX ou dédiées IA), etc.

Je sais bien que les com­pi­la­teurs C# actuels ne le font pas (ou peu) et qu’il faudrait balis­er son code dans tous les cas pour aider à la par­al­léli­sa­tion (j’ai fait pas mal de choses autour de ça, depuis 1996 avec PVM). Donc, le poten­tiel d’un code man­agé comme C# est peut-être plus intéres­sant à terme.

2 réflexions sur « C++ vs C# pour Unreal Engine/Unity »

  1. Non, ce n’est pas la com­pi­la­tion à la volée qui fait qu’il est moins rapi­de en effet et évidem­ment on peut écrire comme un mal­pro­pre en n’im­porte quel lan­gage et faire en sorte d’avoir un code plus lent.
    Le fait d’avoir un code “retran­scrit” par con­tre est un élé­ment impor­tant, de même qu’avoir une mémoire “man­agée” (d’où le garbage col­lec­tor, etc.). Un code C/C++ est dépourvu d’un tas de mécan­ismes de ce type et s’ap­proche donc plus d’un code assem­bleur, sans fior­i­t­ure. Mais, oui, glob­ale­ment, je suis d’ac­cord, si dif­férence il y a, elle n’est pas non plus fon­da­men­tale. D’ailleurs, cela dépend sou­vent du com­pi­la­teur. Pen­dant un paquet d’an­nées, le com­pi­la­teur pro­duisant le code le plus rapi­de (util­isé par l’ar­mée US et d’autres pour le temps-réel) était un com­pi­la­teur ADA — La sécu­rité dans l’im­plé­men­ta­tion du code (qui est relatif à ADA) fai­sait que le com­pi­la­teur pou­vait “opti­miser” un tas de choses, impos­si­ble en C/C++. Donc, le com­pi­la­teur, la MV… tout ça ren­tre aus­si en ligne de compte.

  2. Ce n’est pas parce que C# est com­pilé à la volée, qu’il est moins rapi­de. A la volée, oui (encore que, cf le pro­jet “cor­ert”), mais il est com­pilé 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 facile­ment. Sachant qu’un point fon­da­men­tal quand il s’ag­it de graphique c’est surtout de gér­er le GPU et sa rela­tion avec le CPU. Et ça c’est pas dépen­dant du lan­gage mais plus de la façon dont on pro­gramme, voire du ou des frame­works qu’on utilise (Direc­tX, SDL, etc.) ou les instruc­tions SIMD (https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in-net-core/)

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.