Après AMD qui avait biaisé les benchmarks en faveur de ses processeurs Athlon 64 face aux Athlon XP, c'est au tour d'Intel de s'amuser à bricoler des informations.
Nos processeurs sont dotés d'une instruction, introduite par Intel à l'époque du Pentium, premier du nom, qui permet de connaitre la fréquence actuelle du core du processeur. Cette fonction est très vite devenue un standard de facto, et est toujours à l'heure actuelle très utilisée dans de nombreux logiciels, pour connaitre la fréquence du processeur à un instant T.

Là où le problème se pose, c'est qu'Intel a modifié, avec le lancement d'une nouvelle révision des 'Prescott', le comportement de cette fonction. Le processeur Prescott, qui a la réputation d'être relativement calorifique, est dans cette nouvelle révision équipé d'une technologie, l'EIST, qui lui permet d'adapter sa fréquence à la charge de travail qu'il effectue, et ainsi de réduire de manière non négligeable sa consommation, et par conséquent la dissipation thermique qu'il en résulte. Cette technologie est à mettre en parallèle avec le Cool'N'Quiet d'AMD, qui a exactement le même rôle.

Donc, un processeur Prescott qui entre en mode d'économie d'énergie va voir sa fréquence réduire. Or, et c'est là le coeur du problème, la fonction qui est censée retourner la fréquence du core, retourne la fréquence du processeur. Attention à la nuance : par fréquence du core, j'entends la fréquence à laquelle tourne le core du processeur à l'instant t, et par fréquence du processeur, j'entends la fréquence pour laquelle il a été vendu.
Un exemple : un Prescott 3Ghz. En mode EIST, il tourne à 2.8Ghz. La fonction devrait donc renvoyer 2.8Ghz. Or, elle renvoit 3Ghz. Biaisant ainsi nombre de programmes qui se basent dessus, comme par exemple CPUz.

De plus, la documentation d'Intel n'a pas changé ! Ce comportement erratique, qui est donc un bug, ne peut pas ne pas avoir été remarqué. Le but d'Intel semble donc d'être que de cacher quelque chose.
Le site X86-Secret.com a donc émis plusieurs hypothèses, parmis lesquelles :

* Une volonté marketing : On se souvient qu'il y a peu encore, le fer de lance d'Intel c'était la fréquence. D'un point de vue marketing, il est donc gênant qu'un processeur vendu comme à 3Ghz fonctionne la majorité du temps à 2.8Ghz.

* Limiter l'overclocking : selon X86-Secret, Intel possède tout les éléments à l'intérieur même du processeur pour détecter un pourcentage de modification de l'horloge. Il est envisageable donc qu'ils bloquent les overclocking qui dépassent un certain seuil.

* Préparer le terrain pour le DualCore : c'est la prochaine évolution majeure, présentée comme les services marketing comme une bombe de puissance (ce qui est en très grande partie faux, mais ça n'est pas le sujet du jour). En effet, dans ces processeurs les deux cores pourront avoir des fréquences différentes. Ainsi, la fonction originelle d'Intel ne saurait quelle fréquence renvoyer, celle du premier ou du deuxième core, et renverrait donc la fréquence du processeur. On peut toute fois d'interroger quant à l'utilité d'implémenter cette modification, majeure, sur des processeurs mono-core.

Le problème majeur, étant l'absence de documentation de cette modification, même si Intel admet la midification, dans une réponse adressée à X86-Secret :

Dans cette réponse, Intel fait état de la dernière hypothèse, à savoir la préparation du DualCore. Intel rejette cependant la faute sur Microsoft (littéralement, les vendeurs d'OS, l'ellipse étant magistrale).
La question du pourquoi de l'implémentation de cette modification, si elle est effectivement destinée aux processeurs dualcore, n'est quant à elle pas résolue. Pourquoi implémenter ceci dans un processeur vendu pour être monocore ?
Et pourquoi, si on l'implémente, ne pas mettre à jour la documentation ?

Source : X86-Secret.com

Voir les posts : Par défaut Tous Les bonnes notes Les notes insuffisantes