Unity se prépare à remplacer le C++ par C#

Version imprimable

27/02/2019, 03h23
dourouc05

Unity se prépare à remplacer le C++ par C#

Unity est un moteur de jeu extrêmement utilisé actuellement, notamment pour ses outils d'édition complets et conviviaux. Cependant, le moteur doit suivre l'évolution des machines : depuis une dizaine d'années, les processeurs ne montent plus en fréquence, mais plutôt en nombre de cœurs. En d'autres termes, pour exploiter la nouvelle performance disponible, les jeux doivent exécuter leur code sur différents cœurs, à travers différents fils d'exécution. Pourtant, depuis le temps que la technologie est disponible, peu de jeux y arrivent vraiment. De fait, les problèmes pour l'écriture de tel code sont nombreux : il faut s'assurer que deux fils ne tentent pas d'écrire en même temps dans la même variable, par exemple. Ceci implique que l'un des deux fils doit alors attendre l'autre : si le code est légèrement mal écrit, il n'est pas impossible qu'ils s'attendent mutuellement à l'infini (une situation nommée étreinte fatale).

Pour éviter ces inconvénients, il est possible de suivre quelques séries de règles. Néanmoins, les développeurs ont peu d'outils pour s'assurer qu'elles sont suivies : un code qui ne les respecte pas continuera de compiler, pourrait fonctionner nonante-neuf fois sur cent. C'est une des raisons pour lesquelles Unity travaille sur un nouveau compilateur C#, dénommé Burst : le non-respect de ces règles provoquera une erreur de compilation.

Pour y arriver, le code doit être écrit comme une collection de tâches à effectuer. Chacune de ces tâches effectue quelques transformations sur des données, mais n'a aucun effet de bord (en suivant les préceptes de la programmation fonctionnelle) indésirable. Le programmeur doit spécifier les zones de mémoire auxquelles il peut accéder en lecture seule et celles où il souhaite lire et écrire des données : le compilateur s'assurera qu'il n'utilise rien en dehors de ces déclarations. Elles permettent de gérer une très grande partie des besoins en calcul parallèle. Ensuite, un ordonnanceur détermine la meilleure manière d'exécuter ces tâches, en temps réel, grâce à ces informations supplémentaires : il peut s'assurer qu'aucune tâche ne viendra écrire des données là où une autre tente de lire ou d'écrire, par exemple. Ce mécanisme augmente fortement la sécurité du code écrit, bon nombre de défauts sont remarqués peu après l'écriture du code ; il est aussi impossible de créer une course de données ou une étreinte fatale, les résultats sont entièrement déterministes, peu importe le nombre de fils d'exécution utilisés pour gérer les tâches ou le nombre d'interruptions d'une tâche.

Burst n'a pas que cet objectif de faciliter la programmation parallèle : il est aussi utilisé dans les parties les plus critiques (d'un point de vue performance) du code de Unity. Jusqu'à présent, ces endroits étaient écrits en C++, mais les compilateurs actuels ne sont pas entièrement satisfaisants. En effet, si un développeur souhaite qu'une boucle soit vectorisée, il n'a aucune garantie que le compilateur le fera, à cause de changements pourtant a priori sans impact (pour une addition entre deux vecteurs, par exemple, le compilateur doit prouver formellement que, dans tous les cas possibles et imaginables, les deux vecteurs ne correspondent pas aux mêmes adresses en mémoire). Et encore, il faut que tous les compilateurs utilisés pour Unity sur les différentes plateformes visées effectuent correctement cette vectorisation — sans oublier qu'une mise à jour du compilateur peut aussi être à l'origine d'une baisse de performance.

Pourquoi Burst et pas un compilateur existant ? La performance est un point critique : si un boucle n'est pas vectorisée, ce n'est pas simplement dommage (ce que la plupart des compilateurs se disent), c'est un vrai problème qui doit être corrigé rapidement. De plus, le binaire généré doit être sûr : les erreurs de dépassement de tampon et de déréférencements hasardeux doivent être découvertes au plus tôt, avec de vrais messages d'erreur plutôt que des comportements indéfinis (à l'origine de nombreux problèmes de sécurité). Finalement, il doit gérer toutes les architectures sur lesquelles Unity existe : changer de langage parce qu'on développe un jeu pour console, PC ou mobile n'a pas de sens. Ce compilateur devrait effectivement être utilisé tant pour le moteur que les jeux.

Ces besoins posés, il faut encore choisir le langage d'entrée de ce compilateur : une variante ou un sous-ensemble du C, du C++, de C# ou encore un nouveau langage ? Le nouveau langage semble à bannir, pour éviter de devoir former des gens à ce nouvel outil ; C# a la préférence du point de vue des utilisateurs, puisqu'il est déjà utilisé par eux : le moteur de jeu serait alors codé dans le même langage que les jeux eux-mêmes. De plus, C# dispose déjà d'un très grand écosystème (des EDI, des compilateurs ouverts). Au contraire, C++ souffre toujours de son héritage du C, avec des inclusions pas toujours évidentes à déterminer et des temps de compilation énormes — des défauts que C++20 vient corriger en partie —, malgré son obsession sur la performance (une chose que C# n'a pas).

La décision a été prise de partir sur C#, mais en éliminant une série d'éléments qui nuisent à la performance : la bibliothèque standard, en bonne partie, la réflexion, le ramasse-miettes et les allocations (ce qui revient à interdire l'utilisation de classes, seules les structures restent autorisées), les appels virtuels. Autant dire qu'on se retrouve, à certains points de vue, aussi bien outillés qu'en C (avec les possibilités d'oubli de désallouer la mémoire qui n'est plus nécessaire) — mais ce sous-ensemble du langage n'est vraiment adapté qu'aux parties vraiment importantes d'un point de vue performance, pas à la globalité du moteur. Ce sous-ensemble est nommé High-Performance C# (ou encore HPC#).

Burst ne fonctionne pas vraiment comme un compilateur complet : il ne prend pas en entrée une énorme quantité de code, mais seulement le point d'entrée vers une boucle cruciale. Il se limite à la compiler comme une fonction, ainsi que tout ce qu'elle appelle (puisque les appels virtuels sont interdits, les fonctions appelées sont faciles à déterminer). Le niveau d'optimisation est extrêmement élevé : puisque Burst se focalise sur certaines portions de code, il peut y passer du temps. Notamment, il n'existe presque plus un seul appel de fonction en sortie : importer tout le code permet bien souvent d'éliminer une série de vérifications d'usage en début de fonction. Puisque le seul type de tableau possible est NativeArray et que ces tableaux ne permettent pas de faire des références à d'autres tableaux, deux NativeArray seront toujours distincts en mémoire : la vectorisation peut toujours se faire. Dans le futur, Burst pourra utiliser le même niveau de connaissance sur les fonctions mathématiques utilisées : le sinus d'un angle est presque égal à cet angle s'il est très petit, c'est-à-dire qu'on peut alors remplacer sin(x) par x sans grande perte de précision (ou par un développement en série de Taylor d'un plus grand ordre, si l'angle est un peu plus grand).

La première itération de Burst, avec HPC# et le système de tâches, est arrivée avec Unity 2018.1. Le code généré est parfois plus rapide que la version précédente en C++, parfois plus lente — mais les développeurs sont confiants qu'ils arriveront toujours à au moins atteindre le même niveau de performance que C++. Un élément crucial doit aussi être pris en compte : combien de temps et d'énergie a-t-il fallu pour atteindre ce niveau de performance ? Le code qui détermine les faces visibles d'un objet (culling) a été réécrit avec HPC# : alors que le code C++ était très complexe pour s'assurer qu'il soit toujours vectorisé (sans écrire d'assembleur spécifique à une plateforme), le code HPC# est quatre fois plus court… pour la même performance. Tout le reste du moteur fera la transition vers HPC#, un jour ou l'autre, tant que le bout de code concerné est critique d'un point de vue performance : le code HPC# est souvent plus facile à optimiser, le langage rend plus difficile l'écriture de code faux.

Source : On DOTS: C++ & C#.

Et vous ?

:fleche: Qu'en pensez-vous ?
27/02/2019, 14h30
Bousk

On a tous déjà entendu en réunion "J'ai corrigé un problème de course de données et une étreinte fatale" :ptdr:
C'est là que la traduction française à tout va devient ridicule imo. :no:

Pour le reste, je suis surpris et un peu dubitatif.
Déjà, il va bien falloir le créer ce nouveau compilateur, et il devra être spécifique à chaque plateforme.
Puis écrire du C#, en supprimant tellement de trucs qu'on se retrouve avec du C, au final ça revient pas à dire qu'ils utilisent ça qu'en tant que langage de script simplifié ? Le compilateur serait donc plus un parser qu'un compilateur réellement.
Réécrire l'engin avec ce nouveau langage est une tâche énorme, mais à terme ça colle avec les rumeurs/infos de leur souhait de passer le moteur open source, quand il sera complètement porté en C#.
27/02/2019, 15h41
Cassoulatine

Citation:

mais en éliminant une série d'éléments qui nuisent à la performance : la bibliothèque standard, en bonne partie, la réflexion, le ramasse-miettes et les allocations (ce qui revient à interdire l'utilisation de classes, seules les structures restent autorisées), les appels virtuels

Voila du C# qui me parle :ptdr:
27/02/2019, 16h53
Psycrow

Hello, merci pour la news.

Par contre arrivé à "une situation nommée étreinte fatale" j'ai commencé à décrocher, à "nonante-neuf fois sur cent" mes yeux ont pleuré du sang et à "une course de données ou une étreinte fatale" j'ai zappé l'article et suis passé directement au billet original sur le blog d'Unity.

A vouloir en faire trop, cette article est devenu illisible, dommage.
27/02/2019, 17h30
Mingolito

"Nonante" c'est mieux que "quatre vingt dix", plus logique et plus court.
27/02/2019, 17h34
Zefling

Citation:

Envoyé par Bousk

Réécrire l'engin avec ce nouveau langage est une tâche énorme, mais à terme ça colle avec les rumeurs/infos de leur souhait de passer le moteur open source, quand il sera complètement porté en C#.

C'est à cause de moteurs comme godot ou Xenko qu'il le passeraient on open source ? À mon avis, ça sera pas libre pour autant. :P
27/02/2019, 18h01
melka one

on peut aussi écrire 99 c'est encore plus court.
27/02/2019, 19h34
ParseCoder

Je trouve le titre assez trompeur car C# n'a pas remplacé C++. C'est un petit sous ensemble de C#, tout petit.
27/02/2019, 23h21
Steinvikel

Citation:

Envoyé par melka one

on peut aussi écrire 99 c'est encore plus court.

C'est vrai qu'en français dès lors qu'on dépasse "treize" il devient plus léger d'utiliser des chiffres et non des mots. Mais question rédaction typographique, on fait alors quelques entorses aux coutumes, qui pousserait plutôt à tout écrire en toutes lettres. ^^'
28/02/2019, 10h06
mattdef

Citation:

Envoyé par Steinvikel

C'est vrai qu'en français dès lors qu'on dépasse "treize" il devient plus léger d'utiliser des chiffres et non des mots. Mais question rédaction typographique, on fait alors quelques entorses aux coutumes, qui pousserait plutôt à tout écrire en toutes lettres. ^^'

Au delà de 99, c'est le français qui est plutot agréable non ?

Mille cent un <> one thousand one hundred and one :D
28/02/2019, 10h16
23JFK

Si le truc fait du inline systématique, les gros jeux vont avoir des out of memory à tous les étages.
28/02/2019, 10h30
Matthieu76

C# > C++ ?

Tous ça me donne envie de réécrire mes project C++ en C#. Le C++ commence à devenir un language dépassé, non ? Quel intérêt de commencer un projet en C++ quand on a la possibilité de le faire en C# ?
28/02/2019, 11h06
Kannagi

Si tu te pose la question :
1)Pourquoi le C++ est dépassé par rapport au C# , dans quoi au juste ?
Surtout que en terme de paradigme le C++ dépasse probablement tout les autres langages vu qu'il permet de coder de façon très différente.
2)Dans le Jeux vidéo (entre autre) on a besoin de faire du bas niveau et quel chance le C++ peut être bas niveau ,par exemple on l'utilise dans Arduino pour programmer dans l'embarquée et donc l'avantage du C++ c'est qu'il peut communiquer aisément avec le Hardware (ce n'est pas rien).
3)Ils existent moult compilateur pour le C++ , qui est de plus très efficace donc le C++ est non seulement plus performant , mais il vise plus de plateforme.
Quid des plateformes exotiques ?
Rare sont les SDK sur consoles qui offre autre chose que du C/C++ , et refaire un compilateur qui vise autant de plateforme que Unity est loin d’être aisées ...
28/02/2019, 13h54
codec_abc

Citation:

Envoyé par Kannagi

Si tu te pose la question :
1)Pourquoi le C++ est dépassé par rapport au C# , dans quoi au juste ?
Surtout que en terme de paradigme le C++ dépasse probablement tout les autres langages vu qu'il permet de coder de façon très différente.
2)Dans le Jeux vidéo (entre autre) on a besoin de faire du bas niveau et quel chance le C++ peut être bas niveau ,par exemple on l'utilise dans Arduino pour programmer dans l'embarquée et donc l'avantage du C++ c'est qu'il peut communiquer aisément avec le Hardware (ce n'est pas rien).
3)Ils existent moult compilateur pour le C++ , qui est de plus très efficace donc le C++ est non seulement plus performant , mais il vise plus de plateforme.
Quid des plateformes exotiques ?
Rare sont les SDK sur consoles qui offre autre chose que du C/C++ , et refaire un compilateur qui vise autant de plateforme que Unity est loin d’être aisées ...

Pour le point 2, je ne comprends pas ou tu veux en venir car tu parles de jeux vidéo et d'arduino dans la même phrase alors que les domaines n'ont rien à voir. Dans un domaine on est sur des machines très puissantes et dans l'autre sur des machines très lentes sans mémoire dynamique. Je ne vois pas de point commun entre les 2 domaines. De plus, tu veux dire quoi par bas niveau ? Utiliser un allocateur spécifique, utiliser des instructions SIMDs/NEON, contrôler l'alignement de structures de données ? Car une bonne partie de cela est faisable en C# pour peu que l'on se mette quelque contraintes (ce qui est le cas avec le compilateur Burst).

Pour le point 3, Ça dépend du compilateur que tu utilises. En l’occurrence Burst, le compilo que développe Unity utilise LLVM pour le back-end. Donc en soit, ce n'est pas une tache démesuré que de faire un front-end à LLVM. Plein de langages le font déjà (Rust, Swift, CUDA et plein d'autres le font). Et je pense (à vérifier) que le fait d'utiliser LLVM permet de générer du code qui fonctionne sur les principales plateformes de jeux-vidéo (consoles, PCs, mobiles).
28/02/2019, 14h56
Kannagi

Pour répondre au point 2) Oui merci , il'ya pas de point commun entre les deux d'un point de vue puissance merci ce n'était pas évident...
Sauf le coté bas niveau qui est exactement la même chose (je parle en connaissance de cause que communiquer avec le Hardware , c'est toujours pareil que ça soit sur Arduino , un PC, une console ou autre).
Je parle de contrôler du hardware , ça veut dire en gros "affiche un triangle" , "lis la manette" , "envoyer un son PCM a la carte son" etc etc
En C++ , tu peux contrôler finement le matériel (et donc exploiter le matériel assez bien) , et pour ça il faut des pointeurs nu et le mot clé volatile indispensable pour gérer les interruptions ou les I/O (le C possède aussi) .
Tu peux te reposer sur un SDK existant , mais un SDK n'est pas toujours optimiser pour certaine tache.

3)LLVM ne compile pas dans des formats propriétaire il me semble...
Nintendo n'a jamais utilisé de format standard ,quid de convertir du elf en format proprio made in Nintendo ? (C'est pas infaisable mais faudra le faire)
Il n'ya que Sony qui utilise le format ELF à ma connaissance (depuis la PS2).
28/02/2019, 15h09
23JFK

Citation:

Envoyé par Kannagi

...

3)LLVM ne compile pas dans des formats propriétaire il me semble...
Nintendo n'a jamais utilisé de format standard ,quid de convertir du elf en format proprio made in Nintendo ? (C'est pas infaisable mais faudra le faire)
Il n'ya que Sony qui utilise le format ELF à ma connaissance (depuis la PS2).

Il me semble que chez Nintendo le problème vient surtout d'une couche d'encryption anti-piratage.
28/02/2019, 15h26
dancingmad

Pour préciser un peu, il y a une chose que C++ fait très bien (et c'est l'un des seuls à le faire correctement), c'est la gestion des allocations et du layout mémoire. En C++ en peut contrôler de manière très précise l'alignement mémoire, la taille des structures utilisées et surtout à quel moment une allocation/déallocation a lieu, cet c'est extrêmement critique pour un jeu vidéo dans lequel une trame fait au plus 33ms.

Dans la plupart des langages modernes type C#, la mémoire est gérées par le runtime et c'est un très gros problème pour plusieurs raisons:

1) C'est impossible de définir de manière sûre a quel endroit une struct va être alloué alors qu'on a plutôt tendance à vouloir utiliser différentes stratégies d'allocation selon le type d'objets avec des pools etc. C'est surtout par principe de localité: si on veut itérer sur 10000 objets du même type, on a envie que ces objets soient alloués côté à côté pour éviter les cache miss.

2) La philosophie globale de ces langage fait que la bibliothèque standard et la plupart des bibliothèques ne se posent pas trop de question sur les allocations puisque de toute façon tout est géré par le système. Or chaque allocation est assez coûteuse et encore une fois on ne peut pas dépasser 33ms par trame. Utiliser une expression lambda en C# déclenche des allocations (même quand on ne capture aucune variable), faire une requête LINQ déclenche des allocations, parfois même utiliser des algorithme de tri déclenche des allocations, etc. En tant que dev de jeu-vidéo on veut éviter ça absolument pour des questions de perfs.

3) Au sujet du layout mémoire, on a besoin dans le JV de contrôler exactement le contenu de certains buffers parce qu'on va les envoyer à la carte graphique par exemple, ou encore parce qu'on sait qu'on a des ressources limitées sur consoles. Oui malgré la puissance des consoles actuelles on a encore des gros problèmes de mémoire sur les gros jeux AAA parce qu'on pousse toujours la machine dans ses derniers retranchements. En C# c'est très difficile et très verbeux de contrôler la mémoire, sans compter que l'allocateur utilise des "astuces" qui rendent un enfer la vie des progs. Exemple concret: si on alloue des objets en pool en C#, il arrive qu'il y ait des "trous" - ce qui normal pour garantir l'alignement - et ces trous sont parfois utilisé par l'allocateur pour allouer des petits objets de 1 ou 2 octets. On se retrouve avec une structure qui contient une autre structure et donc toute tentative de faire un memset(0) ou toute autre operation de ce type pourrait corrompre la mémoire...

4) Mon dernier point et non le moins important, le garbage collector. Il peut se déclencher à n'importe quel moment, stoppe absolument tous les theads (même les threads critiques comme le son) et peut prendre facilement 100ms pour de grosses applications... Autrement dit 3 trames. Rien que pour cet argument, non on ne peut pas utiliser C# pour du gros jeu.

Pour en revenir au HPC et Burst, le principe est justement d'utiliser un sous-ensemble de C# qui permet d'éviter la plupart des problèmes cités avant à moindre frais: on n'utilise que des struct et pas des class pour ne pas avoir d'overhead mémoire ni provoquer des allocs intempestives, etc. On aura toujours des problèmes de garbage collector mais qui seront moins prononcés vu qu'on aura moins d'objets alloués sur le tas. Bon en plus Unity n'est pas un moteur AAA donc c'est largement suffisant pour la plupart des utilisations.
28/02/2019, 16h14
Aurelien.Regat-Barrel

Citation:

Envoyé par Matthieu76

Tous ça me donne envie de réécrire mes project C++ en C#. Le C++ commence à devenir un language dépassé, non ? Quel intérêt de commencer un projet en C++ quand on a la possibilité de le faire en C# ?

La news est assez trompeuse. Il serait plus juste de dire qu'ils ont créé leur propre langage dont la syntaxe correspond à un sous ensemble de C# et qui est très spécialisé pour leur besoin très précis (ils ne s'agit pas recoder tout Unity avec ce langage). Sur leur blog ils donnent le liens vers quelqu'un qui a fait des tests assez poussés de perf C# "normal" vs C++, et je pense que ça résume pourquoi on utilise C++ malgré sa complexité:

Citation:

So the summary of C# performance so far:

- Basic .NET Core performance is roughly 2x slower than C++ performance, on both Windows & Mac.
- For simple types like “vector” or “color”, you really want to use struct to avoid allocation & garbage collection overhead. Otherwise your code will run 30 (!) times slower on a 16-thread PC, and 3 times slower on a 8-thread Mac. I don’t know why such a performance discrepancy.
- Mono .NET implementation is about 3x slower than .NET Core implementation, at least on Mac, which makes it ~6x slower than C++. I suspect the Mono JIT is much “weaker” than RyuJIT and does way less inlining etc.; you might want to “manually inline” your heavily used functions.
28/02/2019, 16h52
Juniper62

wtf

il faudrait une traduction du belge vers le français... les nonante et les francisations à outrance, c'est bien de chez eux ça ... pourquoi parler de 'ramasse miettes' alors qu'on parle tous de 'garbage collector'? etc...
et bien, si tout ce que raconte l'article est réel, ça devient beaucoup moins sexy de coder sous Unity ... :s berk
28/02/2019, 17h27
Matthieu76

Citation:

Envoyé par Aurelien.Regat-Barrel

Sur leur blog ils donnent le liens vers quelqu'un qui a fait des tests assez poussés de perf C# "normal" vs C++, et je pense que ça résume pourquoi on utilise C++ malgré sa complexité

Moi j'avais regarder ça : https://www.codeproject.com/Articles...-Csharp-vs-NET

Je sais bien de théoriquement C++ et plus rapide que C# mais je pense que s'il on optimise pas son code à la ligne près on ne verra pas la différence. Et je dirais même que c'est plus facile de faire un code lent en C++ qu'en C#.
Tu oublies juste de passer un vector par référence et paf ton code est plus lent que si tu l'avais fait en C#.

Et puis mon dans mon code C++ je ne fais aucun malloc, je ne fais que des news, j'utilise toujours les destructors par défaut, je n'utilise plus que des vectors car les tableaux trop compliqué quand tu dois copier des objets en contenant, etc...

Je suis sur que plus de 90% des programmes fait en C++ serait plus rapide en C# car les développeurs font beaucoup d'erreurs qui ralentisse le code.
28/02/2019, 19h23
Steinvikel

La plupart des optimisations en langage "compilé" sont faites par le compilateur, pas par le codeur... et la qualité de l'optimisation dépend de : les paramétrage du compilateur, ses limites, et la verbosité du codeur. --> écrire simplement "auto i = 3;" et écrire "static const int i = 3;" n'entraine pas du tout la même profondeur d'optimisation suivant le contexte.

exemple en vidéo de 27:00 à 28:30 :D
CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
https://youtu.be/zBkNBP00wJE?t=1596
Dans ce cas précis, tu as oublié un "const" et paff, au lieu de 4 lignes assembleur en mémoire (il fait tourner l'ensemble du programme sur le cache du processeur) tu rajoutes plus de 350 lignes !!.

Je ne suis pas sûr que les erreurs courantes en C# et en C++ soient plus coûteuse chez l'un que chez l'autre, en revanche, il y a peut-être généralement plus de rigueur chez les C++ de par la pluralité paradigmatique (j'étais inspiré, dsl), à l'image du Pascal ou un pet de mouche empêche la compilation.
Bref, je pense que les problèmes de perf sont plus lié à des facteurs convergeant, comme les habitudes communautaires, les nécessités absolues, les facilités, les spécialisations... plutôt que le langage en lui même.
28/02/2019, 22h35
Invité

Citation:

Envoyé par Mingolito

"Nonante" c'est mieux que "quatre vingt dix", plus logique et plus court.

C'est surtout que ça n'a rien à voir avec la news. Si vous voulez disserter là dessus, pourquoi ne pas créer un topic dans la section taverne ?
28/02/2019, 22h57
Aurelien.Regat-Barrel

Citation:

Envoyé par Matthieu76

Moi j'avais regarder ça : https://www.codeproject.com/Articles...-Csharp-vs-NET

On dit parfois que C++ ne donne pas de la performance, il donne accès à la performance. Les techniques d'optimisations sont les mêmes au delà du langage car c'est le hardware sous jacent qui dicte ça, et c'est une expertise à part entière. La différence en C++ c'est qu'il est plus "hardware sympathic" et en ne te faisant pas payer pour ce que tu n'utilises pas. Au hasard le garbage collector qui met régulièrement en micro-pause ton programme et déclenche des recopies complète de tes data en mémoire.

Pour ce qui est des micro benchmark, ile ne veulent pas dire grand chose car la performance dans und vraie application se trouve aussi (voire surtout) dans la data, et plus exactement dans l'empreinte et l'agencement mémoire de ton programme. Dès que tu satures la taille de tes caches (quelques Mo), les performances s'écroulent (du genre 10 à 50 fois plus lent). Et si tes data ne sont pas ordonnées de manière continue, c'est la même sanction. Et donc un langage qui t'imposent d'allouer à tout va sur le heap en rajoutant en plus un overhead pour le type System.Object de base obligatoire c'est catastrophique pour les perfs passé un certaine taille.

Une intro de qualité par un exellent speaker (vers la 22eme min):
https://channel9.msdn.com/Events/Build/2014/2-661

Concernant les erreurs de programmation qui dégradent les perf, la règle d'or en optimisation c'est de commencer par profiler ton code, ainsi tu découvres vite les erreurs de ce type. Mais aussi de nos jours on a des outils d'analyse statique de code (gratuits) qui peuvent détecter certaines copies inutiles. CLion par exemple te signale dans ton code ce genre de cas et t'invite à faire un move ou un const ref.

Enfin, la tendance moderne est de prendre en input un string_view ou un span quand tu ne fait que consulter la data, de cette manière il n'y a aucun risque en terme de perfs en plus d'avoir une meilleur sémantique vis à vis du code.

Ces exemples résument mes propos initiaux : oui en C++ il est facile (comme dans d'autres langages) d'écrire du code avec de mauvaises performances. Mais une fois localisé, on a beaucoup d'options assez simples pour régler efficacement le problème.
01/03/2019, 12h24
Matthieu76

Merci, tout cas est hyper intéressant mais en réalité je suis sur des 99% de la lenteur de mon code vient de la conception des algo et de l'architecture du code. Avoir du code avec des objets contenant des vectors d'objet contenant des vectors d'objet contenant des vectors de float et faire des calculs en boucle sur ces float ça doit être au moins 100 fois plus lent que si j'avais juste un tableau 3D de float. Après si j'avais juste des structs et des tableaux de float j'aurais un code plus rapide mais complètement imbitable avec des erreurs de calcul et d'index partout, un enfer à debugger !

PS : Ne pas oublier les options de compilation, le jour ou j'ai découvert ça j'ai rendu mon code 4 fois plus rapides !

Citation:

Envoyé par Matthieu76

Avoir du code avec des objets contenant des vectors d'objet contenant des vectors d'objet contenant des vectors de float et faire des calculs en boucle sur ces float ça doit être au moins 100 fois plus lent que si j'avais juste un tableau 3D de float. Après si j'avais juste des structs et des tableaux de float j'aurais un code plus rapide mais complètement imbitable avec des erreurs de calcul et d'index partout, un enfer à debugger !

Tu n'es pas obligé de créer un vecteur de vecteur de vecteur pour avoir une syntaxe commode. Tu peux aussi encapsuler ton tableau 3D dans une classe dont tu choisis la syntaxe.

Exemple simple de template de classe pour gérer un tableau 3D dont on ne connaît les dimensions qu'au runtime :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#include <cassert>
#include <vector>
 
template<class T>
class DynamicArray3D {
private:
	size_t m_sizeX;
	size_t m_sizeY;
	size_t m_sizeZ;
	std::vector<T> m_elements;
public:
	DynamicArray3D(size_t sizeX, size_t sizeY, size_t sizeZ) :
		m_sizeX{sizeX},
		m_sizeY{sizeY},
		m_sizeZ{sizeZ},
		m_elements(sizeX*sizeY*sizeZ)
	{}
	T& operator()(size_t x, size_t y, size_t z) {
		assert(x < m_sizeX);
		assert(y < m_sizeY);
		assert(z < m_sizeZ);
		return m_elements[x + y*m_sizeX + z*m_sizeX*m_sizeY];
	}
	T const& operator()(size_t x, size_t y, size_t z) const {
		assert(x < m_sizeX);
		assert(y < m_sizeY);
		assert(z < m_sizeZ);
		return m_elements[x + y*m_sizeX + z*m_sizeX*m_sizeY];
	}
	size_t getSizeX() const { return m_sizeX; }
	size_t getSizeY() const { return m_sizeY; }
	size_t getSizeZ() const { return m_sizeZ; }
};

Exemple d'utilisation :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
#include <iostream>
 
DynamicArray3D<double> createMyDynamicArray3D(size_t sizeX, size_t sizeY, size_t sizeZ)
{
	DynamicArray3D<double> dynArr{sizeX, sizeY, sizeZ};
	for(size_t z = 0; z < sizeZ; ++z)
		for(size_t y = 0; y < sizeY; ++y)
			for(size_t x = 0; x < sizeX; ++x)
				dynArr(x, y, z) = 100*z + 10*y + x;
	return dynArr;
}
 
void print(DynamicArray3D<double> const& dynArr)
{
	const size_t sizeX = dynArr.getSizeX();
	const size_t sizeY = dynArr.getSizeY();
	const size_t sizeZ = dynArr.getSizeZ();
	for(size_t z = 0; z < sizeZ; ++z) {
		for(size_t y = 0; y < sizeY; ++y) {
			for(size_t x = 0; x < sizeX; ++x) {
				std::cout << dynArr(x, y, z);
				if(x+1 < sizeX)
					std::cout << ", ";
			}
			if(y+1 < sizeY)
				std::cout << '\n';
		}
		if(z+1 < sizeZ)
			std::cout << "\n\n";
	}
}
 
int main()
{
	constexpr size_t sizeX = 5;
	constexpr size_t sizeY = 3;
	constexpr size_t sizeZ = 2;
	const DynamicArray3D<double> dynArr = createMyDynamicArray3D(sizeX, sizeY, sizeZ);
	print(dynArr);
	return 0;
}

04/03/2019, 19h16
Matthieu76

Citation:

Envoyé par Pyramidev

Tu n'es pas obligé de créer un vecteur de vecteur de vecteur pour avoir une syntaxe commode. Tu peux aussi encapsuler ton tableau 3D dans une classe dont tu choisis la syntaxe.

Cela est-il vraiment plus rapide qu'un vector<vector<vector<float>>> ?
N'il a-t'il pas un moyen d'utiliser des pointers intelligent qui point un tableaux 3D à la place ? Ça serait plus rapide non ?

Et puis en vrai j'ai pas vraiment ça, je travaille sur des réseaux de neurones, j'ai donc une classe NeuralNetwork qui contient un vector<Layer> qui contient un vector<Neuron> qui contient un vector<int>. Enfin pour avoir un code lisible et compréhensible je suis un peu obligé de sacrifier l'optimisation. Et plus bon c'est bien gentil tout cas mais le meilleur moyen d’optimiser mon code reste quand même le multi-threading tant que mon code ne tournera pas sur les 8 cœurs de mon processeur ça ne sert à rien d'optimiser le reste enfin pas à ce niveau d'optimisation. J'avais essayer de faire tourner mon code sur ma carte graphics en recodant tout en CUDA mais j'avais obtenu un code totalement illisible et quasiment impossible à maintenir donc j'ai abandonné.
(J'arrivais pas à copier des structures sur ma carte graphique du coup je passais tout par pointeur par conséquent j'avais des méthodes avec une 10e de paramètres d'entrés.) En puis bon vu que je passe mon temps à retoucher mes algo je préfère un code maintenable qu'un code optimisé au poil de ***.