<div style="text-align: justify;"><img border="0" align="right" style="margin: 0px 0px 6px 6px;" src="http://www.presence-pc.com/images/Intel_Pentium_4_LGA775.gif" />Nous vous l’annoncions récemment, AMD avait choisi de ne pas optimiser le code source 32 bits qu’il fournissait pour réaliser des comparaisons avec ses processeurs 64bits (cf. <a href="http://www.presence-pc.com/actualite/Benchmarks-64-bits-AMD-aurait-triche--6406/" target="_top" onclick="xt_nclic('N',2,'http://www.presence-pc.com/actualite/Benchmarks-64-bits-AMD-aurait-triche--6406/')">cette actualité</a> ).<br /><br />

Aujourd’hui on apprend que, selon X86-Secret, Intel aurait également triché. En effet, après avoir constaté plusieurs bugs dans la détection de la fréquence processeur de différents logiciels spécialisés tels que CPU-Z, Crystal CPUID ou bien encore Sandra 2005, l’équipe de X86-Secret a pu démontrer qu'Intel avait modifié le fonctionnement du ReaD Time Stamp Counter (RDTSC). <br /><br />

Le RDTSC permet de déterminer la fréquence des processeurs en comptant simplement le nombre de front d’horloge, et ce quelque soit leur mode de fonctionnement du processeur. <br /><br />Il semblerait donc que depuis l’introduction du stepping F4x sur les Prescott, la fréquence renvoyée par le RDTSC n'est pas la fréquence réelle du processeur, mais la fréquence dite « commerciale » lors de l'utilisation de système d'économie d'énergie comme l'EIST.<br /><br /><span style="font-weight: bold;"><img border="0" align="left" style="margin: 0px 6px 6px;" src="http://www.presence-pc.com/images/cpuz_triche.png" />Un exemple :</span> CPUZ affiche un FSB de 215 MHz et un coefficient de 14x, alors qu'en passant par une autre méthode n'utilisant pas le RDTSC, on se rend compte que le processeur fonctionne avec un FSB à 200 MHz et un coefficient de 14x, ce qui est plus que douteux. Selon notre confrère : "<span style="font-style: italic;">les valeurs obtenues ici sont manifestement fausses</span>".<br /><br />

Alors que certains de ces processeurs sont disponibles depuis plus d'un an, Intel n'avait même pas indiqué cette modification dans ses documents officiels destinés aux développeurs.<br /><br />

Le fondeur a toutefois reconnu les faits, indiquant qu’effectivement, cette modification pouvait avoir certains effets pervers tels que des résultats incohérents dans certains benchmarks. Intel cherche égalemennt à se dédouaner en rejetant la faute sur les vendeurs de systèmes d’exploitations.<br /><br />Bref, entre mensonges et omissions, on se rend compte que les fabricants de microprocesseurs, quels qu'ils soient, sont d’une honnêteté exemplaire…<br /><br /><ul><li><a onclick="xt_nclic('S',2,'http://www.x86-secret.com/?option=newsd&nid=845')" target="_blank" href="http://www.presence-pc.com/links1.php?url=aHR0cDovL3d3dy54ODYtc2VjcmV0LmNvbS8/b3B0aW9uPW5ld3NkJm5pZD04NDU=&source=020305">Lire l'article</a></li></ul>
</div>

je connais pas ce mot

fdf (faute de frappe)

C'est qui la frappe ?

frappe cay son nègre

"Le fondeur cherche toutefois à se dédouaner en expliquant que les vendeurs de systèmes d’exploitations ne sont pas tout rose non plus."

Quel rapport ?

ils rejètent la faute sur MS

Ils font comme les posteurs sur PPC alors !!

CPUZ n'est pas un benchmark... d'ailleurs il n'y a aucun gain avec ce changement... donc aucune comparaison avec le cas de AMD de il y a quelques semaines.

A remarquer aussi que ce problème ne se vérifie pas avec CPU-Z 1.27, et que avec ScienceMark 2 ce changement rend en théorie le P4 pire qu'avant...