Dans ce cas, a était (indirectement) un paramètre (0.0 par défaut). Du coup, il était tout à fait crédible que a soit exactement 0, et ça avait du sens de gérer cette situation. Je préfère largement ça à un paramétrage redondant (style un switch booléen, et une variable numérique qui n'a de sens que si le switch est activé).
J'aurais eu plus de doutes pour une variable différente de 0, style 1.0. En théorie, si on est carré sur les types, j'imagine que c'est possible d'avoir un test exact, parce que la représentation binaire ne devrait pas changer (si le fichier de paramètres contient MAVAR=1.0, qu'on lit ça avec >> pour mettre dans un type à virgule flottante, qu'on ne transtype pas et qu'on finit par tester == 1.0, j'ai l'intuition que ça devrait marcher). Mais avec 0.0 ça doit forcément marcher, sauf s'il y a une gestion vraiment déconnante des types à virgule flottante.
Le pire dans cette histoire, c'est que même si le test ne fonctionnait pas comme prévu (si a était le résultat d'un calcul numérique, style a = 3.0 - sqrt(9.0)), l'algo restait tout à fait fonctionnel (il aurait multiplié par 1e-32 et aurait obtenu quelque chose du même ordre de grandeur). Il n'y avait donc aucune raison de partir en vrille.
si les cas où l'optimisation se déclenche était trop rare par rapport au reste, ça resterait une optimisation discutable.
J'imagine qu'en théorie la prédiction de branches permet justement de faire en sorte que ça marche. Mais j'ai eu l'impression (ce n'est qu'une impression, je n'ai pas analysé plus que ça) que dans tous les cas les deux branches étaient calculées (peut-être parce que le nombre de cycles nécessaire était inférieur à un critère que je ne connais pas), et que la version avec if() nécessitait de revenir en arrière alors que le coût du calcul était de toutes manières déja passé.
J'ai aussi à mon actif quelques cas de mémoïsation ratés, parce que ça coûtait plus cher d'aller chercher un résultat dans une table que de calculer une fonction non-triviale. C'est probablement des cas très classiques pour des gens dont le métier est d'optimiser des algorithmes (typiquement, des algos en O(1) en pratique plus lents que des O(2) à cause d'un coût initial), mais quand on n'est confrontés que sporadiquement à des problèmes d'optimisation, c'est toujours destabilisant.
[^] # Re: Paradigme
Posté par arnaudus . En réponse au lien « Clean code » : performances lamentables. Évalué à 3.
Dans ce cas, a était (indirectement) un paramètre (0.0 par défaut). Du coup, il était tout à fait crédible que a soit exactement 0, et ça avait du sens de gérer cette situation. Je préfère largement ça à un paramétrage redondant (style un switch booléen, et une variable numérique qui n'a de sens que si le switch est activé).
J'aurais eu plus de doutes pour une variable différente de 0, style 1.0. En théorie, si on est carré sur les types, j'imagine que c'est possible d'avoir un test exact, parce que la représentation binaire ne devrait pas changer (si le fichier de paramètres contient MAVAR=1.0, qu'on lit ça avec >> pour mettre dans un type à virgule flottante, qu'on ne transtype pas et qu'on finit par tester == 1.0, j'ai l'intuition que ça devrait marcher). Mais avec 0.0 ça doit forcément marcher, sauf s'il y a une gestion vraiment déconnante des types à virgule flottante.
Le pire dans cette histoire, c'est que même si le test ne fonctionnait pas comme prévu (si a était le résultat d'un calcul numérique, style a = 3.0 - sqrt(9.0)), l'algo restait tout à fait fonctionnel (il aurait multiplié par 1e-32 et aurait obtenu quelque chose du même ordre de grandeur). Il n'y avait donc aucune raison de partir en vrille.
J'imagine qu'en théorie la prédiction de branches permet justement de faire en sorte que ça marche. Mais j'ai eu l'impression (ce n'est qu'une impression, je n'ai pas analysé plus que ça) que dans tous les cas les deux branches étaient calculées (peut-être parce que le nombre de cycles nécessaire était inférieur à un critère que je ne connais pas), et que la version avec if() nécessitait de revenir en arrière alors que le coût du calcul était de toutes manières déja passé.
J'ai aussi à mon actif quelques cas de mémoïsation ratés, parce que ça coûtait plus cher d'aller chercher un résultat dans une table que de calculer une fonction non-triviale. C'est probablement des cas très classiques pour des gens dont le métier est d'optimiser des algorithmes (typiquement, des algos en O(1) en pratique plus lents que des O(2) à cause d'un coût initial), mais quand on n'est confrontés que sporadiquement à des problèmes d'optimisation, c'est toujours destabilisant.