Discussion :

[progfou]

Bonjour à tous !
J'ai un code (assez court) dont je connais les bornes numériques (c'est un calcul).
J'aimerais comparer différentes version du même code, mais je ne sais pas comment rendre cela représentatif !
En effet, utiliser seulement quelques cas conduira à un code prédicitif pour le compilateur, mais couvrir toute la borne sans doute aussi.
Donc, une dose d'aléatoire me parait intéressante !

Ce que j'ignore c'est si effectivement ça a une influence, combien de boucles de test sont nécessaires, comment les confronter dans des conditions optimales ?

Petite précision, le code en question prend une valeur en entrée, en renvoit une, et la valeur d'entrée est signée codée sur 16 bits.

Ma question peut avoir une réponse précise, mais je me dis qu'un topic relativement général sur ce qui fait un bon benchmark peut être intéressant .

Merci d'avance !

[khayyam90]

Bien le bonjour,

En fait, tout dépend de ce que tu veux mettre en avant : la vitesse de traitement ? l'occupation mémoire nécessaire ? la précision des calculs ? le temps de chargement du programme avant le calcul ?

[progfou]

Surtout le temps de calcul, mais si je peux avoir une estimation du goulot d'étranglement, de l'utilisation de la cache, ça m'intéresse .

[mchk0123]

Je ne comprends pas trop ce que tu veux dire par "bornes numériques" tu pourrait développer ?

Pour le côté prédictif, si tu parles de l'exécution itérative d'un même algo, et des notions de cache, décodage et pipeline des ALU et FPU du CPU, oui en théorie il peut y avoir un biais dans les estimations.

Quoiqu'il en soit un benchmark est toujours sensible au proc et au compilateur utilisé.

[Hibou57]

Bonsoir tous/toutes,

La création d'un bon jeux d'essais, qui saura contenir les éléments pouvant produire des erreurs, ainsi que ceux pouvant faire s'effondrer les performances de l'algorithme, est un art de longue haleine.

En bref, la conception d'un jeux d'essai demande autant de travail et de soin que le conception d'un algorithme.

Un bon point de départ serait de prendre des entrées ici du monde réel et de l'environnement d'utilisation réel de l'algo. C'est le minimum. Ensuite le tester sur des cas particulier. Pour cela, il faut créer une liste de cas particulier, et leur attribué chacun une série de valeur possible, puis faire toute les combinaison.

Exemple :
longeur-des-données = vide | 1 élément | trés longue
charge-du-système = forte | moyenne

Avec par exemple ces deux paramètre, tu as 3 * 2 = 6 combinaison à tester. L'exemple n'est qu'un exemple, et ne prétend pas s'appliquer à ton algo que je ne connais pas, mais c'est pour te donner une idée.... le benchmark demande un long travail de conception, et tout comme la conception d'un algo, il n'y a pas de règle générale. La conception d'un algo dépend des propriétés qu'il doit vérifié, et il en va de même d'un benchmark. Les deux demandent le même travail.

Tout comme pour ton algo, pour concevoir ton benchmark, il faudra au préalable lui donner des spécifications.

[souviron34]

assez d'accord avec Hibou, mais je rajouterais quelques points.

Pour avoir une bonne analyse statistique, un jeu de 1000 ou 10000 runs seraient bons.

• Maintenant, pratiquement, une moyenne sur 100 devrait donner de bons résultats : temps CPU utilisé, temps d'exécution total etc..
  
• Pour ce qui est des valeurs, tu peux les tirer au sort dans l'éventail de données possibles.
  
• Et pour ce qui est du profiling (ton " si je peux avoir une estimation du goulot d'étranglement") si tu es sur *n*x tu compiles avec l'option.. attends je me souviens plus.. -p ? oui c'est ça..soit -p soit -pg .. Et ensuite tu utilises le résultalt avec gprof et ça te sort les goulots d'étanglements (en fait ça te sort les pourcentages et valeurs d'utilisation de chaque routine, du temps mis dans chaque routine, etc..).
  
• Et pour l'utilisation de la cache, alors là tout dépend. L'utilisation de la mémoire tu peux suivre (si tu es sur *n*x) avec la commande top. Pour la cache disque, là je ne connais pas de programme tout fait qui permet de surveiller ça..

[Ulmo]

gprof, c'est GCC plus que *n*x. Donc si ton programme est compilable avec GCC tu peux utiliser gprof.

[mchk0123]

La création d'un bon jeux d'essais est un art de longue haleine.

Je dirais même plus, le benchmarking est tout un art. En effet, cela nécessite d'être un virtuose dans l'art de la connaissance du fonctionnement des technologies les plus récentes.

En effet, autant sur i286, il suffisait d'une boucle, un tableau Excel, un graphique et hop on avait tout suite un benchmark qui tenait la route ; autant avec des archis récentes (sans parler du 64 bits & multi-cores), s'affranchir des différents caches, pipelines, swaps, DMAs, asynchronismes, multi-threading, multi-fibers, multi-process tient vraiment de la haute voltige !

En effet, ces différentes techniques de boosting des performances deviennent une nuisance dés lors que l'on essaye de mesurer la vitesse d'exécution d'un programme, puisqu'elles biaise sensiblement les résultats.

Enfin, un petit mot sur les compilateurs eux-même, le choix de la combinaison des options pour obtenir un exécutable le plus rapide possibles est quelque chose de trés pointu, et trés délicat car chaque architecture aura sont jeu d'options le plus adapté.