Coûts du polymorphisme

Bonjour,

Je fait une application c++ avec du polymorphisme.
Je suis sur une ancienne version de visual studio 2012 (j'ai un veux ordinateur).
J'ai plusieurs millier d'objets qui utilisent des fonctions virtuelles plusieurs fois par secondes (petit moteur de jeux perso).

J'ai trouver cette article qui expérimente 5 techniques pour le polymorphisme (compatible MSVC, gcc et Clang).
- Fonction virtuelle mise en cache
- Accès directe à la fonction mise en cache
- Fonction virtuelle pas mise en cache
- Accès directe à la fonction pas mise en cache
- Accès directe à la fonction virtuelle pas mise en cache

J'ai 2 questions:
1) Les compilateurs d'aujourd'hui peuvent t'ils optimiser le polymorphisme par eux même, l'article qui date de 2019 est t'il encore d'actualité aujourd'hui?
2) J'aimerais savoir ce que les utilisateurs expérimentés en c++ pense de cette article?

Merci

Quand j'ai débuté ma carrière y'a 10-15 ans, la règle était que virtual était cher et de l'éviter au maximum.
Maintenant tu ouvres UE, tu peux voir que quasi tout est virtual et le focus se porte plutôt sur la mémoire, le cache et les cache miss.
Le langage a sans doute évolué, et surtout les outils.
Je pense que ça reste une bonne pratique de ne pas mettre absolument tout en virtual, mais il ne faut pas non plus tenter de l'éviter coûte que coûte à moins d'avoir un profiler qui indique que oui il y aurait un gain. Mais d'après le graph de ton lien, le gain le plus important semble rester le cache de toutes façons, donc autant mettre ses efforts sur ça directement.

Merci Bousk pour tes conseils :)
Oui pour les optimisations tous semble tourner autour du cache et lire la mémoire Ram le moins possible (avoir un code cache friendly).

Salut,

Instinctivement je dirais qu'en dehors de la boucle de jeu (game loop) le coût est nul et non avenu, ce qui réduit la problématique à une question d'organisation en fait.

De souvenir, pour aller plus loin dans la performance, on peut compléter (ou en alternative) avec de la programmation orientée données où l'on fera utilement la différence entre données froides et données chaudes pour justement aller encore plus loin dans les perfs.

Enfin ne perdons pas de vue que lorsque les performances (intrinsèques) augmentent, les exigences matérielles baissent, et c'est là tout l'intérêt de la chose, améliorer l'expérience utilisateur et toucher le plus de monde possible.

Bonjour kaitlyn.

Oui la boucle de jeu (game loop), c'est là que je veux le plus optimiser.

Pour les données froides (statique) et données chaudes (dynamique) j'essaye de placer mes const au bon endroit.

Pour mes optimisations:
- Utiliser le parallélisme CPU (enkiTS)
- Utiliser le parallélisme GPU (Compute Shader)
- Utiliser les fonctions intrinsics.
- Structure de donnée et algorithmes.
- Code cache friendly pour limiter le plus possible la lecture dans la mémoire RAM.

Mais, oui le plus important c'est le gameplay du jeu et l'expérience utilisateur.
Le jeu peut être bien optimisé et être nulle comme le jeu peut être mal optimiser et être un succès.

Salut,

Citation:

---

Envoyé par dem32

Pour les données froides (statique) et données chaudes (dynamique) j'essaye de placer mes const au bon endroit.

---

Non, données froides/chaudes dans le contexte de la programmation orientée données.
En gros tu divises physiquement ta structure de données en deux, les données chaudes étant les données que tu utilises fréquemment et que tu auras donc tout intérêt à faire en sorte que ça reste en cache cpu (L2). Ça sera difficilement le cas si tu l'encombres de données non vitales.

Merci pour ces infos kaitlyn! :)

Il faut mettre les valeurs utiliser des objets dans un même tableau pour que le tout soit le plus possible dans la mémoire cache!

J'ai aussi découvert que bientôt la nouvelle technologie va nous donnée la mémoire résistive qui va remplacer la mémoire RAM.
Cette mémoire va être intégré direstement dans le processeur ce qui va permettre d'avoir plusieurs Tera de mémoire cache!
Avec ça on va pouvoir enfin programmer normalement sans faire du code cache friendly!
La vidéo youtube de cette technologie: https://www.youtube.com/watch?v=7MJy...iM</a></u></b>

A noter qu'Unity développe depuis quelques années une stack data oriented : ECS / DOTS
Et les résultats, en terme de perf, sont bluffants.
D'après ce que j'ai compris, les gains sont dus à la façon dont sont stockées les données. Plutôt que d'avoir des objets alloués de façon random, on a des tableaux avec des éléments bien contigus en mémoire.
Ce qui permet des optimisations de parcours (cache, pages processeurs, etc.) et un multithreading plus efficace.
Ce n'est donc finalement pas tant une question de virtualité/polymorphisme (vtable), que d'organisation de la mémoire.

Salut,

Oui, dans Unity depuis qu'ils appliquent la programmation orientée données.
Et Unity c'est aussi du CSharp, mais ce n'est pas important, et je ne connais pas trop ce langage.

Par contre en C++, le concept va très loin, au point où l'on se retrouve (si l'on y adhère complètement, conf mon premier message) à faire du C++ façon C, c'est-à-dire pas d'exceptions, pas de STL, pas de Class (notamment à cause du pointeur qui traîne), etc, etc, c'est vraiment extrême.
À cet effet, on peut utilement se référer aux présentations vidéos et billets de blog de Mike Acton, qui justement travaillait sur Unity jusqu'il y a peu (pendant au moins 5 ans si je me souviens bien, et il a quitté la boîte il y a un ou 2 mois, je ne sais plus).
Il y a aussi la pépite de Meyers, une vidéo où il parle de l'invalidation du cache à cause du faux partage.

Mike Acton - Data-Oriented Design and C++ [CppCon 2014 - 1:27:45] :
https://www.youtube.com/watch?v=rX0ItVEVjHc
Scott Meyers - Cpu Caches and Why You Care [code::dive conference 2014 - 1:16:57] :
https://www.youtube.com/watch?v=WDIkqP4JbkE

Pour ceux qui connaissent le concept passez directement à la deuxième vidéo.

Edit:

Désolée pour les fautes. Message écrit sur téléphone avec un clavier virtuel prédictif qui débloque. Faire sans c'est trop fastidieux. Je corrigerai plus tard.

Merci beaucoup,
je vais regarder ça la programmation orientée données! :)