Discussion :

[dem32]

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

[Bousk]

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 langag e 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.

[dem32]

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

[kaitlyn]

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.

[dem32]

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.

[kaitlyn]

Salut,

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.