Discussion :

[ganon551]

Bonjour à tous,

Il y a quelques temps j'avais programmé un petit utilitaire pour calculer les nombres premiers, par le crible d'érastothène. Le but était simplement d'améliorer l'algo jusqu'au maximum, pour m'amuser. J'ai donc implémenté un timer, et comme je suis un adapte de l'overclocking j'ai commencé à l'utiliser pour bencher mon processeur.

Ce que j'aimerais savoir, c'est comment certains utilitaires (comme superPI) arrivent à savoir que le système n'est pas "stable". Par exemple en cas d'overclock trop poussé, superPI m'indique que le calcul n'est pas exact, ce qui veut dire que je dois revoir mon OC à la baisse.

Est-ce qu'il existe un moyen de "vérifier" l'intégrité d'un résultat qui serait changée si le processeur n'est pas stable ?

Je précise que l'utilitaire est codé en C++/Qt.

Merci

[Ekleog]

Supposons que ton programme code un nombre sur un long long.

Tu peux alors précalculer le résultat sur une machine que tu sais correcte (ou calculer de nombreuses fois et regarder si c'est bien stable).
Maintenant que tu as le résultat, que faire ?
La solution est simple : créer une checksum, et en vérifier la validité.

Un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
const long long valid_checksum = 10101010L; // Valeur renvoyée par le programme lorsqu'il tourne sur une machine qui fonctionne
 
long long next_prime() { /* ... */ }
 
long long checksum_incr(long long checksum, long long value) {
   // Ajoute value à la checksum. Exemple :
   return checksum ^ value;
}
 
#include <iostream>
int main() {
   long long checksum = 0L; // Valeur initiale de la checksum (valeur arbitraire ou définie par l'algorithme de checksum). DOIT ETRE UNE CONSTANTE !
   START_TIMER();
   for (int i = 0 ; i < 13374242 ; ++i) {
      long long prime = next_prime();
      checksum = checksum_incr(checksum, prime);
   }
   END_TIMER();
   std::cout << "Time : " << GET_TIMER() << std::endl;
   std::cout << (checksum == valid_checksum ? "Le calcul est valide" : "ATTENTION ! LE CALCUL EST INVALIDE !") << std::endl;
}

Toute la difficulté vient ici du choix de la checksum : une checksum trop simple risque de ne pas détecter une erreur, une checksum trop complexe risque de prendre plus de temps que le calcul principal.
Le crc32 est une méthode couramment utilisée pour le calcul de checksum face à des perturbations aléatoires (i.e. non générées par quelqu'un qui va volontairement tenter de faire échouer la checksum.)

Tu peux avoir plus de détails sur le crc32 ici, et avoir un exemple d'algorithme (à adapter) pour le calcul du crc32 ici.

Bon courage !

[ganon551]

Merci pour ta réponse.

Si je comprend ton post, il me faudrait, par exemple, créer une checksum égale dans ce cas à l'opération xor cumulative de tous les nombres premiers calculés. A la fin je fais un test pour voir si ça correspond à une valeur déjà calculée.

J'ai regardé les CRC32, au final ça correspond à peu près à ça. Du coup ça augmenterait le temps d'exécution de mon programme, mais j'essaierais d'optimiser ça le plus possible.

Je vais implémenter ça, overclocker méchamment et essayer pour voir si le checksum plante des fois.

Merci encore

[Ekleog]

Voilà, c'est ça !
(Au passage, calculer un ou deux xor par nombre premier généré, je ne pense pas que ça soit trop, vu que de toute façon la génération du prime sera très supérieure en durée -- même pour générer ne serait-ce que 5, je pense : un modulo prend plus que 2 xors, si je me souviens bien de mes classiques.)

[koala01]

Salut,

De toutes manières, en terme de bench, même si tu calcules un CRC32, tu continueras à comparer des choses comparables, vu que le calcul de la somme de controle sera toujours pris en compte...

Je veux dire que, que tu mettes en place une politique de calcul de somme de controle ou non, le temps sera toujours celui de l'ensemble du processus (qui consiste, par exemple, à retrouver les 10 000 premiers nombres premier).

Dés lors, tu peux avoir un temps de XXX avec certains réglages et de XXX/3 avec d'autres, que le calcul de la somme de controle entre en ligne de compte ou non ne changera rien : tu auras de toutes manières divisé le temps d'exécution par trois (du moins dans le seul cadre d'un bench adapté aux gains de performances sur l'OC et non dans le cadre d'un bench adapté aux gains de performances d'algorithmes )

Par contre, ce que tu peux faire, c'est faire un premier test avec le calcul de la somme de controle pour t'assurer de la stabilité du système et un deuxième sans (mais donc, avec un "chrono remis à zéro", bien sur ) pour calculer le temps effectivement.

Après plusieurs exécutions (et donc après avoir compté le nombre de résultats corrects obtenus par rapport au nombre de résultats incorrects) te permettra de déterminer un "taux de confiance" à accorder aux réglages OC que tu auras fait, et le deuxième te donnera une moyenne du gain obtenu (toujours en rapport avec tes réglages).

Grâce à ces deux informations, tu pourras assez facilement trouver le meilleur compromis entre la fiabilité / stabilité et la vitesse d'exécution (c'est à dire : trouver le réglage qui a un taux de fiabilité suffisant par rapport au gain obtenus en exécution pure )

[Lightness1024]

sachant que ca peut aussi merder pendant le calcul du CRC, auquel cas le proc est instable donc meme si le calcul est bon la detection sera juste.

par contre tu ne peux pas detecter si l'opérateur == ne va pas merder lui aussi. tu pourrais avoir un faux positif. quand le proc commence a merder, rien n'est garanti, tu pourrais aussi bien avoir un seg fault parcequ'un pointeur a muté, ou meme un écran bleu parce qu'un driver a chié...

[Ekleog]

Sauf que le CRC est fait spécifiquement pour éviter les erreurs aléatoires. Et je pense qu'on peut considérer que, en toute probabilité, un proc qui se rate ne va pas agir comme agirait un adversaire tentant de "casser" le crc. Non ?

Après, évidemment, si on veut vérifier la "validité", il faudrait enregistrer le résultat de toutes les étapes, pour minimiser la probabilité d'erreur. Mais on ne peut rien faire de mieux, de toute façon.

[Lightness1024]

Oui je me suis mal exprimé. ce que je voulais dire c'est "le test d'incohérence sera positif". par exemple, le calcul de la suite mathematique peut etre correct mais le CRC incorrect a cause d'un probleme CPU pendant le CRC.
dans ce cas, ca nous va aussi en fin de compte.