Du old school pour plein de choses en effet.
Envoyé par
tomlev
Tu ne vois pas ? Ben eux ils voient ; s'ils ont décidé de se passer des exceptions, c'est pas par masochisme, c'est parce qu'ils ont fait des mesures, du profilage, etc, pour déterminer que ça nuisait aux perfs.
J'ai croisé pas mal d'arguments en défaveur des exceptions
- google> les développeurs n'y comprennent rien/ ne savent pas (/ne sauront jamais) écrire du code robuste => on les fuit (résultat ils considèrent les mallocs qui renvoient NULL comme des erreurs qui doivent planter les applications -- perso j'ai déjà eu à faire des allocations de tailles venant de l'extérieur (et donc non contrôlées) et toutes les allocations ne pouvaient pas aboutir (et bossant sur des softs critiques, on évite de planter chez nous))
- regoogle> on a une vieille base de code qui n'est pas exception-safe (la seule justification valide à mon gout)
- plein> mauvaises perfs
- AAA-console> la PSP-machin crashe à cause des exceptions (OK, c'est la seconde justification valide que je connaisse)
Pour les perfs, je ne suis pas convaincu. Il y a longtemps les compilos n'optimisaient pas le chemin nominal, et effectivement, ça coutait cher. Maintenant, le chemin nominal est optimisé. Résultats: un binaire plus gros et un sur-cout au lancement -- et des perfs médiocres dans les chemins non nominaux (et là, OSEF ce qui coute le plus cher dans un chemin non nominal, c'est l'utilisateur final qui va devoir régler le problème)). Seulement ... j'ai l'impression que ceux qui critiquent les exceptions ne mesurent jamais les performances du chemin nominal entre un code avec exceptions (et des catchs bien placés => en nombre restreint (merci le RAII)), et un code qui n'est pas au pays magique où les erreurs n'existent pas, c'est à dire d'un code qui a un if toutes les deux lignes. Il m'est avis que le problème est que c'est très difficile à comparer correctement. Il ne s'agit pas d'avoir des benchs de 50 lignes, mais des programmes plus pertinents avec des arbres d'appels de fonctions de jusqu'à quelques dizaines de niveaux de profondeur, avec des boucles, etc et qui remontent leurs erreurs), et écrire ces programmes en double demande du boulot pour avoir un bench fiable.
Pourquoi je suis plus que dubitatif : un if, c'est une prédiction de flot d'exécution qui peut foirer dans le pire des cas, voire pas de prédiction du tout parfois. Quand il y a un "if" entre deux call/gosub, cela fait beaucoup de prédictions qui peuvent foirer. Avec des exceptions, les tests n'ont lieu qu'aux seuls points où les erreurs peuvent être détectées. Cela fait beaucoup moins de tests. Ce qui fait qu'en nominal, cela devrait tracer bien plus vite.
On pourrait arguer qu'il ne devrait pas y avoir des cas exceptionnels dans un jeu vu qu'ils prennent la voie des optims de l'embarqué (toutes les allocations en début d'exécution), mais ... je n'y crois pas un seul instant : un câble peut-être retiré, et pouf, plus de joypad, plus de réseaux, ... Et puis d'ailleurs, ils ont implémenté leur propre système de dépilage de contexte, preuve en est qu'il y a toujours des cas exceptionnels à traiter. Cela veut-il dire qu'il ont fait le choix pays magique (pas de if), mais avec instrumentation avec leur système de surveillance de contexte ? Je serai curieux de savoir si leur code passe le
test de robustesse décrit par Raymon Chen.
Et je pense à un autre élément, "noexcept" est parfaitement utilisable pour les zones du code où l'on peut s'attendre à ce qu'aucune entrée n'ait besoin d'être vérifiée (affichages, sorties audios, ...) -- je pense rejoindre Lolilolight là.
Bref je suis plus que dubitatif.
Sur le sujet:
-
http://741mhz.com/exceptions-performance/ (une analyse des assembleurs produits, mais pas de bench associé)
-
http://www.flounder.com/exceptions.htm (autre bench, mais la propagation d'erreur n'est pas mesurée, et il ne semble pas compiler avec un -fno-exception ou équivalent)
-
http://stackoverflow.com/questions/3...es-in-c#307716 (autre analyse de l'assembleur)
-
http://nwcpp.org/october-2006.html (une analyse de 2006 qui conclue qu'un code correct a des performances équivalentes à celles d'un code avec EH)
Concernant virtual, les branch-miss, & cie. Virtual devrait couter aussi cher que des tables de pointeurs de fonctions, car en interne c'est la même chose. De plus, virtual offre de meilleures performances que des if/switch à partir d'une demi-douzaine de cas (mais des benchs sont à faire pour chaque plateforme pour connaitre le seuil exact de chacune).
Mais ... avec ces ECS qui ont le vent en poupe (et qui viennent du monde du jeu si j'ai bien compris), reste-t-il tant de virtual que cela dans les codes des jeux ? Je ne suis pas sûr qu'il en reste beaucoup avec ce pattern.
PS: il y a eu plusieurs confs par des gens d'UBI soft ou autre AAA cette dernière année, et ils utilisent le C++11 notamment pour optimiser sauvagement des accès concurrentiels. Il n'y a pas que les amateurs qui exploitent des outils récents.
7 |
0 |
) que les 
.