Après AMD, c'est Intel qui triche !

Infos-du-Net.comAprè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 :

_QUOTEC



The current PRM does not include a complete description for the latest Intel(r) Pentium(r) 4 Processor TSC operation. Intel is currently working on a clarification of the Programmers Reference Manual (PRM) in relation to, but not inclusive of, the following points.

For Intel(r) Pentium(r) 4 Processors with CPUID (Family, Model, Stepping) greater than 0xF30 the designed implementation of the TSC is for the counter to operate at a constant rate. This was implemented due to a request from Operating System Software vendor(s). That rate may be set by the maximum core-clock to bus-clock ratio of the processor or may be set by the frequency at which the processor is booted. The specific processor configuration will determine the exact behavior.

This constant TSC behavior ensures that the duration of each clock tick is uniform and supports the use of the TSC as a high resolution wall clock timer even while the processor core may change frequency. The use of the TSC as a wall clock timer has effectively been prioritized over other uses of the TSC. This is the architectural behavior for the TSC moving forward.

To count processor core clocks or to calculate the average processor frequency Intel recommends using the PMON counters Monitoring data from the event counters over the period of time for which the average frequency is required. See PRM Volume 3 Chapter 15 Debugging and Performance Measuring, Section 15.10.9 and Appendix A Performance Monitoring Events for details on the Global_Power_Events, event.




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

Posez une question dans la catégorie News du forum
Cette page n'accepte plus de commentaires
9 commentaires
    Votre commentaire
  • jun
    C'est quoi une midification ?^^
    0
  • phantom lord
    Euh cest pas plutot Intel Inside le logo
    0
  • aurelie@IDN
    lol j'avais même pas remarqué ^^
    0