Explications · trois
Nous publions des comparaisons avec les logiciels d'autres personnes, la méthode doit donc être vérifiable. La voici en entier : les machines, le contenu, les réglages accordés à chaque client, et les règles qui décident si une exécution compte comme un résultat ou part à la poubelle.
Le banc d'essai
Chaque client d'une comparaison tourne sur une seule machine, face aux mêmes fournisseurs, sur le même contenu, dans la même série. Rien n'est repris d'un jour précédent.
La règle qui décide de tout
C'est la chose la plus importante de cette page. Chaque manche se termine en cherchant le plus gros fichier produit par le client, où que ce soit dans sa sortie, et en le hachant contre une copie de référence. Taille et MD5, à chaque manche, pas sur un échantillon.
Nous faisons cela parce que le rapport de succès d'un client n'est pas une preuve fiable. Nous avons mesuré un client annonçant done sur une tâche dont le dossier de sortie était vide. Nous en avons mesuré un autre annonçant Completed après avoir livré des volumes d'archive bruts qu'il n'avait jamais décompactés. Un outil de réparation très répandu se termine avec un code d'échec après une réparation réussie. Aucun de ces clients ne mentait ; les chaînes d'état veulent simplement dire des choses différentes selon les auteurs, et un benchmark qui leur fait confiance mesure du vocabulaire plutôt que du comportement.
La ligne d'arrivée est donc la même pour tous : le contenu existe, à la bonne taille, avec la bonne empreinte. Si un client s'arrête avant, il n'obtient pas de temps, et toute la colonne est signalée plutôt que discrètement omise. Un client lent qui termine fait mieux qu'un rapide qui ne termine pas, et le tableau doit le dire.
Le corollaire est qu'une non-arrivée est un résultat, pas une erreur de notre part. Quand nous en publions une, nous décrivons l'état final en termes simples, y compris tout ce qui suggère qu'elle est propre à cette tâche plutôt que générale, et nous disons ce que le client a fait au lieu de terminer.
Ordre et répétition
Le débit des fournisseurs varie d'une minute à l'autre, parfois d'un facteur deux ou trois. Deux mesures prises à des moments différents mesurent en partie la météo.
Les clients tournent donc coup sur coup et en alternance, et l'ordre s'inverse entre les répétitions, pour qu'aucun client ne soit toujours celui qui entre le premier sur une ligne chaude ou froide. Un résultat est la tendance sur l'ensemble des répétitions, pas la meilleure exécution. Quand la dispersion est large, nous publions la fourchette plutôt qu'une moyenne qui la masquerait, et si nous ignorons pourquoi les chiffres d'un client sont dispersés, nous le disons au lieu d'inventer une cause.
Les comparaisons entre séries différentes sont évitées autant que possible. Si une affirmation demande deux chiffres, nous préférons refaire courir les deux dans une même série plutôt que de soustraire le chiffre d'un jour à celui d'un autre, car l'état du banc, les conditions des fournisseurs et les versions des clients dérivent tous. Quand nous comparons deux de nos propres versions, les deux tournent dans la même série, en alternance, sur le même contenu.
Les contrôles ingrats
La plupart existent parce qu'une panne silencieuse a produit un jour un chiffre sain d'apparence, publiable et faux. Chacun tourne désormais automatiquement et arrête la série au lieu d'avertir.
Là où un client a besoin de réglages particuliers pour bien fonctionner, il les reçoit, et la série indique lesquels. Exemples : le pipelining des requêtes activé là où un client le livre désactivé, la détection de doublons désactivée quand la même tâche est téléchargée à répétition, et les utilitaires de décompactage pris dans le paquet du client plutôt qu'une copie système. Le but est que chaque client soit mesuré au mieux de ses capacités plutôt qu'à ses réglages par défaut, car les valeurs par défaut sont un débat distinct de la capacité.
Ce que nous ne ferons pas