1.3.1 : La question du réalisme



A ce stade, nous allons nous heurter à un des dilemmes les plus fondamentaux du benchmarking, à savoir le compromis entre réalisme et efficacité du développement:

  • D'un côté, nous souhaitons mesurer nos performances logicielles dans une configuration aussi proche que possible de celle où l'application sera exécutée en production, puisque ce sont ces performances-là qui comptent.
  • D'un autre côté, le test de performances "en conditions réelles" présente de nombreux problèmes dans une optique de développement logiciel efficace:
    • Le test réaliste n'est pratiquable que lorsque le développement de l'application est presque terminé, alors que souvent on souhaite avoir des retours aussi tôt que possible dans le processus de développement pour ne pas s'engager durablement dans de mauvaises pistes.
    • Les conditions réelles peuvent être impossibles à répliquer tant que l'application n'est pas véritablement en production (ex: serveur connecté à de très nombreux clients) ou proche de la production (ex: matériel expérimental qui doit être momentanément cesser de prendre des données pour tester une nouvelle version du logiciel, centre HPC où les heures de test sont comptées).
    • L'environnement de production peut être difficile à analyser (ex: système fortement restreint où l'installation d'outils d'analyse sophistiqués est politiquement difficile, virtualisation, OS embarqué exotique, architecture matérielle qui change à chaque exécution comme sur la grille WLCG....).
    • Les tailles de problème utilisées en production peuvent être incompatibles avec des itérations de développement logiciel efficaces (ex: temps d'exécution de plusieurs heures, ou même juste de quelques minutes qui deviendront des heures si on instrumente l'exécution avec un outil comme callgrind).
    • Certaines approches intéressantes d'analyse de performances sont inapplicables à grande échelle (ex: pour des mesures de temps précises il faut mesurer des temps d'exécution inférieurs à un quantum d'ordonnanceur OS, pour utiliser des outils d'analyse statique comme MAQAO le code doit être suffisamment simple).
    • Et enfin, pour revenir au sujet qui nous occupe, les conditions d'exécution en production peuvent être très loin de l'optimum en termes de reproductibilité (système de fichier distribué, machines partagées, réseau plus ou moins saturé...), ce qui obligera à avoir recours à des approches de mesure statistiques très chronophages qui sont autant de temps perdu pour l'optimisation à proprement parler.


Dans ce chapitre, nous allons partir du principe que la reproductiblité des mesures prime sur toute autre considération. Mais il est évident qu'en réalité, certains des points discutés ci-après nous écartent trop du scénario réaliste de production, et risquent de nous faire optimiser une configuration d'exécution non pertinente. Toute simplification du programme ayant pour but d'optimiser la reproductibilité d'exécution doit être idéalement comparée à une exécution plus réaliste pour s'assurer que les caractéristiques générales de l'exécution restent la même, réduction de la fluctuation des performances exceptée.

Cet avertissement étant donné, voyons maintenant quelques pistes pour des exécutions de benchmarks plus reproductibles...