Ce qui compte pour mesurer la performance d'un programme pour s'orienter dans le développement c'est d'appliquer la méthode scientifique. Le but est donc de construire un énoncé falsifiable et dans le contexte de l'optimisation de ta méthode functionToMeasure on aimerait bien construire un énoncé du type "l'implémentation A est toujours plus performante que l'implémentation B" mais ce type d'énoncé n'au aucune chance de marcher.
Dans la liste des défauts de mon énoncé il y a bien-sûr le fait qu'il faut expliquer ce que veut dire "performant" ce qui n'est pas forcément facile et en plus imaginer une expérience qui mesure cette performance dont on a précisé la teneur, et le but est d'arriver à une expérience dont le résultat est reproductible, autrement on ne peut rien conclure du tout. Mais ensuite la durée d'exécution ("performance en temps") se comporte super mal! À preuve:
Le même programme lancé sur la même machine opérant sur la même donnée après un cold boot peut livrer des temps d'exécution très différents, sans problème du simple au double. Il y a des milliers de raisons possibles à cela, dont l'alignement mémoire qui a une influence directe sur la stratégie d'utilisation des caches.
Un programme plus long qu'un autre (par exemple bordé de NOPs ou qui fait des contrôles d'indice sur un tableau) peut parfois être rapide!
Les ordinateurs sont très complexes et il y a des tas de facteurs qui influent sur la vitesse d'exécution des programmes, même la taille d'une variable d'environnement non utilisée par le programme!
Ainsi, même si on réalise que les mesures individuelles n'ont aucun sens et qu'il faut toujours mesurer des distributions, on ne fait que s'avancer vers un problème très compliqué et si on veut mesurer sérieusement la vitesse d'exécution d'un programme on doit donc construire un protocole expérimental qui se débarrasse de tous les biais... et quand on le fait pour GCC on découvre que l'incidence de l'utilisation de -O3 par rapport à -O2 est indistiguable d'un bruit statistique.
Des problèmes particulièrement difficiles en pratique sont en outre la production de données dont la distribution ressemble à celles de l'application réelle, et pour les applications réseau la reproduction d'une charge ressemblant à celle de l'application réelle.
# Reproductibilité
Posté par Michaël (site web personnel) . En réponse au journal Optimisation, microbenchmark et compilation Just In Time : quand 1 + 1 ne font pas 2. Évalué à 8.
Ce qui compte pour mesurer la performance d'un programme pour s'orienter dans le développement c'est d'appliquer la méthode scientifique. Le but est donc de construire un énoncé falsifiable et dans le contexte de l'optimisation de ta méthode
functionToMeasureon aimerait bien construire un énoncé du type "l'implémentation A est toujours plus performante que l'implémentation B" mais ce type d'énoncé n'au aucune chance de marcher.Dans la liste des défauts de mon énoncé il y a bien-sûr le fait qu'il faut expliquer ce que veut dire "performant" ce qui n'est pas forcément facile et en plus imaginer une expérience qui mesure cette performance dont on a précisé la teneur, et le but est d'arriver à une expérience dont le résultat est reproductible, autrement on ne peut rien conclure du tout. Mais ensuite la durée d'exécution ("performance en temps") se comporte super mal! À preuve:
Le même programme lancé sur la même machine opérant sur la même donnée après un cold boot peut livrer des temps d'exécution très différents, sans problème du simple au double. Il y a des milliers de raisons possibles à cela, dont l'alignement mémoire qui a une influence directe sur la stratégie d'utilisation des caches.
Un programme plus long qu'un autre (par exemple bordé de NOPs ou qui fait des contrôles d'indice sur un tableau) peut parfois être rapide!
Les ordinateurs sont très complexes et il y a des tas de facteurs qui influent sur la vitesse d'exécution des programmes, même la taille d'une variable d'environnement non utilisée par le programme!
Voir par exemple Producing Wrong Data Without Doing Anything Obviously Wrong!. Un autre exemple rigolo de biais est la question la plus votée de SO.
Ainsi, même si on réalise que les mesures individuelles n'ont aucun sens et qu'il faut toujours mesurer des distributions, on ne fait que s'avancer vers un problème très compliqué et si on veut mesurer sérieusement la vitesse d'exécution d'un programme on doit donc construire un protocole expérimental qui se débarrasse de tous les biais... et quand on le fait pour GCC on découvre que l'incidence de l'utilisation de -O3 par rapport à -O2 est indistiguable d'un bruit statistique.
Des problèmes particulièrement difficiles en pratique sont en outre la production de données dont la distribution ressemble à celles de l'application réelle, et pour les applications réseau la reproduction d'une charge ressemblant à celle de l'application réelle.