Intel : le roi des performances
Le processeur Intel le plus rapide du moment demeure le Core 2 Extreme QX9770, gravé en 45 nanomètres et composé de deux dies dual-core 3,20 GHz juxtaposés ayant chacun accès à 6 Mo de cache L2 partagé. Il s’agit donc d’un processeur quad-core équipé de 12 Mo de cache L2. La fréquence de son FSB atteint 400 MHz (1600 MHz effectifs), ce qui le rend donc plus rapide que tous les autres « Extreme ». Officiellement, ce processeur ne fonctionne que sur le chipset haut de gamme X48.
Si les performances du QX9770 ne vous suffisent pas, vous pouvez toujours opter pour la plateforme Skulltrail, une carte-mère à deux sockets pouvant accueillir deux de ces monstres. Notez toutefois que les sockets en question sont des LGA 771, destinés aux serveurs et stations de travail ; bien qu’identiques par leurs spécifications techniques, les processeurs compatibles portent donc un autre nom. Une configuration Skulltrail offre un total de huit cœurs et 24 Mo de cache L2.
Malgré le fait qu’il soit gravé en 45 nm, le fer de lance d’Intel est loin d’être économe : le QX9770 a un TDP de 136 watts et son grand frère, le QX9775 (prévu pour les cartes-mères à deux sockets), revendique 150 watts.
Du côté des modèles gravés en 65 nm, plus vieux mais toujours commercialisés, le Core 2 Duo E6600, un processeur dual-core doté de 4 Mo de cache L2 et cadencé à 2,4 GHz, est toujours dans le coup. Son équivalent quad-core, le Core 2 Quad Q6600 fonctionne exactement à la même fréquence, et tous deux s’overclockent très simplement. Depuis le lancement des processeurs 45 nm, les modèles 65 nm ont vu leur coût diminuer de manière substantielle, ce qui en fait de véritables aubaines en raison de leur rapport performances/prix plus qu’attrayant.
Les processeurs Intel plus récents sont gravés en 45 nm. Les modèles les plus populaires sont le Core 2 Duo E8400 (3 GHz) et le Core 2 Quad Q9450 (2,66 GHz), qui s’overclockent encore mieux que les modèles 65 nm.
Tous les processeurs gravés en 45 nm disposent des instructions SSE 4.1, même si les modèles actuels n’intègrent pas encore le jeu complet prévu par Intel ; celui-ci est prévu pour les puces de prochaine génération basées sur l’architecture Nehalem. Les avis concernant les effets de ces instructions sur l’accélération du traitement vidéo sont divisés : certains développeurs ont déjà annoncé leur support tandis que d’autres attendent de voir leurs avantages en termes de performances.
Il arrive par moment qu’Intel mette à jour le stepping de ses processeurs, ce qui, dans certains cas, apporte des gains de consommation considérable. Les Pentium dual-core stepping M0, par exemple, exigeaient 29 % d’énergie en moins que leurs prédécesseurs.
Enfin des tests sous Linux ! On pourrait avoir plus de détails ?
mplayer est utilisé avec quel codec: mpeg4 de ffmpeg?
il manque juste un petit test sous boinc et ça serait le top!
c'est rapide
Très complet comme test!! Bravo.
Impressionnant les tableaux récapitulatif
super job.. merci à toute l'équipe.
les comparatifs par logiciel sont rares (et donc super interessants).
1 Suggestion :
pourquoi ne pas tester le montage de video HD (264)
avec studio 12 par exemple... cela devrait mettre les
systèmes (et proc) à dure épreuve...
Encore bravo
JF
et la "perf par watt" dont les deux fondeurs nous parler elle est pas testé?
wrongillusion > Pas possible à rajouter facilement ici du fait qu'elle varie pour chaque application et que les plateformes ne sont pas entièrement identiques notamment (DDR3 VS DDR2 par exemple et mobos pas identiques). Mais nous devrions les rajouter des les prochains (et il reste les comparatifs sinon pour les valeurs des précédents processeurs).
Instinctivement, j'aurait dit que les quadcore les plus économes du marché était les petits C2Q 45nm d'Intel. Et après vérif, rien que le Q9300 consomme 45W en full. Et ça doit pas être celui qui consomme le moins.
Foudge > C'est a priori en partie basé sur ces résultats : http://www.tomshardware.com/review [...] 935-5.html . Mais effectivement le Q9300 consomme a priori moins en fait, je modifie.
Florian: toujours les mêmes résultats délirants pour le bench Linux OpenSSL. Quid?
Ils ne sont pas délirants, ils sont juste pas conformes à ce à quoi tu t'attends, mais le plus important est qu'ils soient comparables entre eux (c'est à dire qu'on puisse comparer les performances des processeurs Intel aux AMD), ce qui est le cas. Le test a été exécuté au sein d'une série (scriptée).
Ah bravo, vous utilisez une suite libre de benchmarks, et vous nous sortez des chiffres qui ne correspondent absolument pas aux résultats rapportés par les utilisateurs de la suite en question (Phoronix Test Suite). Vous avez réussi à rendre obscur un des rares benchmarks dont le code source est disponible, chapeau. Si c'est pour nous donner des chiffres trafiqués, on a PCMark pour ça, merci…
Ce que "j'attends" c'est les résultats *réels*. C'est trop demander?
Ces résultats sont réels. Teste 54 processeurs sous 43 applis et ensuite vient nous dire comment on doit faire, et pourquoi personne d'autre ne le fait.
Vraiment? Tu m'expliques pourquoi les scores sur http://global.phoronix-test-suite. [...] &u=openssl et http://global.phoronix-test-suite. [...] u=universe sont 2 à 4 fois plus grands que les votres, aussi bien pour les processeurs Intel que ceux d'AMD, et pourquoi les Intel sont toujours derrière les AMD dans ce bench, selon les résultats des utilisateurs? Tu ne me donnes même pas l'ombre d'un début d'explication! Je te donne une source relativement fiable qui contradit complètement vos résultats, et du ne daignes même pas accepter l'idée que, peut-être, vous n'êtes pas parfaits, et avez fait une erreur dans *un* bench sur les 43? Je ne compte même pas les résultats erronés de Sandra Memory Bandwidth restés en ligne pendant des mois et la bourde ou tricherie de PCMark avec le VIA Nano, dont on a déja parlé…
http://www.tomshardware.co.uk/foru [...] rk-results
Dossier impressionnant et sûrement long et compliqué à réaliser, bravo ;-)
pourquoi avoir pris une vielle carte mère AMD qui a bientôt 2 ans ?
vous êtes pro-intel ?
une 790FX+SB750 l'aurait mieux fait : vous prenez bien les dernier chipset chez intel, pourquoi pas chez AMD ?
vous ne testez pas de CPU AMD Dual Core, 1 seul aurait suffit, juste pour comparer ...
le grand tableau vert pour les CPU AMD n'est pas à jour, il manque tous les brisbanes core G2 en 65nm 65w et ceux de 45w... les 12 dernier CPU AMD dualcore en gros ....
Florian / apaige > Au vu des résultats et des comparaisons avec les sources (officielles), je serai personnellement également très intéressé pour avoir un début d'explication des grandes différences constatées (facteur ~3 à 4 environ que ce soit Intel ou AMD). D'autres lecteurs le seront sans doute également :-?
Serai-ce un problème d'optimisation à la compilation ?!? (comme expliqué dans le post en anglais sur TomsHardware.co.uk)
Merci d'avance de votre enquête ;-)
A mon sens, un plus serait également de rappeler en haut des résultat de chaque bench la version utilisée.
cyrano > En fait les benchmarks Mplayer, Kernel et PHP sont des tests de compilation. Le résultat exprime le temps de compilation des sources du noyau Linux 2.6.25, de PHP 5.2.5 et de MPlayer-1.0.rc2 via GCC (sans CFLAGS, via la commande "make -j $num_of_cpu_jobs", cette dernière variable dépendant du nombre de cores détecté).
AmaCha > Nous avons effectivement comparé les résultats de nos benchmarks avec les résultats officiels d’openSSL avec nos composants. Ils sont très proches. Ex :
).
Résultat officiel / nos résultats des charts
Intel Core 2 Duo E7200 30 / 27.57
(http://global.phoronix-test-suite.com/?k=profile&u=legg-17008-4842-31670)
Intel Core 2 Duo E6850 36 / 35.77
(http://global.phoronix-test-suite.com/?k=profile&u=root-9428-22269-13141)
Intel Core 2 Duo E6600 29 / 28.60
(http://global.phoronix-test-suite.com/?k=profile&u=smash-13799-29625-141)
En comparant ces résultats il faut faire attention car de nombreux résultats reportés l’ont été avec overclocking. Par ailleurs, de nombreux résultats officiels ont été reportés avec des composants et OS particulièrement variés ou même avec la même plateforme (ex : 53 vs 31.57, http://global.phoronix-test-suite. [...] 7207-31218 et http://global.phoronix-test-suite. [...] 6184-22637 ).
La seule explication dans ce cas provient des différences de compilation. Pour que nos résultats soient reproductibles, nous avons utilisé le même bin pour chaque bench. Nous n’avons ainsi utilisé aucune optimisation spécifique ce qui nous paraît être plus réaliste pour l’utilisateur Linux lambda qui utilise «apt-get » pour installer openSSL. Notez que cela marche aussi pour AMD (ex : 22.1 pour un Athlon 64 X2 4600+@2.4 GHz sous Ubuntu, 22.3 dans nos charts).
Alors oui, quand on compile les bin on peut effectivement optimiser l’exécution et le résultat. Mais le truc c’est que nous n’avons pas et ne pouvons pas trouver les options de compilations qui seront les plus performantes pour chacun des processeurs que nous avons testés. L’environnement de test est du coup le même pour AMD et Intel, de même que nous utilisons dans nos tests le même exécutable de Winrar, Winzip, Lame, etc (on n’est plus au temps de Pod
D’ailleurs pour info nous avons lancé la release officielle d’openSSL pour Windows ( http://www.slproweb.com/products/Win32OpenSSL.html ). Elle non plus n’est optimisée pour aucun processeur (même pas multithreading). Je pense que celle-là, personne nous aurait reproché de l’utiliser. Avec un T7300@2 GHz et en single-thread : 11.7 sur Ubuntu, 11.8 via notre bin, et 11.0 sous openSSL Vista. Ce qui prouve que même en utilisant la même plateforme on observe des variations de l’ordre de 6% au moins, dues au changement d’OS.
Vous ne voulez pas utiliser d'optimisation pour OpenSSL, mais ça ne vous empêche pas d'utiliser des applis qui profitent des instructions SSE4.1, disponibles uniquement dans les CPUs haut de gamme d'Intel. D'ailleurs, pour info, le gros des optimizations possibles est sélectionné par défaut lors de la compilation; pas besoin de chercher le meilleur combo pendant des heures.
Ensuite, vous trouvez ça normal, l'écart entre votre Phenom 9600 BE et le mien? 56 contre *173*! On passe du simple au triple! http://global.phoronix-test-suite. [...] 29218-7581
Même avec le C2Q Q6600 on passe de 57 à plus de 115. Le double.
http://global.phoronix-test-suite. [...] 0736-22029
http://global.phoronix-test-suite. [...] 19898-5608
http://global.phoronix-test-suite. [...] 3221-32481
EDIT: les résultats postés ici correspondent tous à des CPUs à fréquence d'origine, *non* overclockés.
Sans la moindre optimization, ce n'est pas le CPU dont vous faites le benchmark, ni même de l'application. De plus, puisque vous utilisez un seul et unique binaire pour tous les CPUs, vous ne devriez pas mentionner le nom de Phoronix Test Suite, puisque vous déviez complètement de son utilisation normale. Avec PTS, chaque benchmark est systématiquement compilé sur la machine testée.
Et puis surtout, ça change complètement le classement.
intéressant, mais pourquoi n'avoir finalement choisi que les moyennes/hauts de gamme ? tout le monde n'a pas/ne veut pas dépenser 150€ ou plus dans un proco, alors que pour du Lame, de la compilation de noyau, du Winzip/Winrar (bref bureautique et codage) un petit E4x00 ou un Athlon X2 DualCore (voir un chtit Opteron 1214) sont largement trouvable à moins de 100€...
bref, charts incomplet, plutôt que d'avoir multiplié les tests, ce concentrer sur quelques-uns (LameMP3, Winzip, Crisis, 3DMark CPU, et DivX) pour tous les processeurs (toutes gammes confondues, sur un banc commun AMD et un banc commun intel), vous auriez le guide ultime automne 2008...
bardiel1921 > Nous n'avons pas vraiment limités nos tests aux CPU milieu ou haut de gamme, le E7200 est disponible à moins de 100 €, et le X3 8450 à 85 € par exemple. D'autres charts viendront par la suite avec l'entrée de gamme cependant, mais qualifier les charts d'incomplets alors qu'ils intègrent 54 CPU...
cyrano > En fait les benchmarks Mplayer, Kernel et PHP sont des tests de compilation. Le résultat exprime le temps de compilation des sources du noyau Linux 2.6.25, de PHP 5.2.5 et de MPlayer-1.0.rc2 via GCC (sans CFLAGS, via la commande "make -j $num_of_cpu_jobs", cette dernière variable dépendant du nombre de cores détecté).
Compiler le noyau ou gcc doit suffire. Cela n'apporte rien de compiler 3 ou 4 soft différent. D'ailleurs, vos tests le montre : la hierarchie ne change pas trop.
Si vos données sont sur la clef usb et non sur le disque dure pour linux, les IO sont très limitant pour une compilation. Dans ce cas, un "make -j" tout court peu servir à masquer les entrées-sorties. Trouver le bon chiffre est "chaud". Plus l'accès au fichier est lent, plus il augmente pour faire du masquage de latence. Ensuite, cela dépende de la quantité de RAM (si tous les fichiers entre en RAM). L'effet d'attente des io peut être masqué en utilisant "time -u" pour le bench qui ne prendra que le temps utilisateur et non celui noyau (mais attention les temps des cpu s'additionnent).
Concernant d'autre bench, je vous recommande de regarder ce que j'avais fait ici:
http://f-cpu.seul.org/~nico/nicobenchv1.0.tar.bz2
explication : http://f-cpu.seul.org/~nico/amd64.html
Le bench que j'aurais aimé rajouter au mien est celui de povray pour faire un test de la puissance en nombre flottant. Pour l'instant, je n'avais que l'encodage ogg.
cyrano > Non toutes les fichiers sont chargés en RAM pour ces benchs. Les sources sont prises en RAM, compilées puis écrites en RAM. Le seul appel à la clef USB se fait quand le compilateur GCC est appelé. Par exemple le bench de compilation de Mplayer est fait via la commande suivante : "/usr/bin/time -f "MPlayer Build Time: %e Seconds" make -j
$NUM_CPU_JOBS 2>1& | grep Seconds"
Dans ce cas "time -u" est impossible vu que le flag "-u" n'existe pas. Mais "time -f" avec %e permet d'obtenir le temps réel pris.
Je pensais "%U" cela évite les petits désagréments lié à l'activité du PC, si il fait autre chose cela changera le résultat du tests.
Il faudrait trouver autre chose que la compilation. Dans les trucs faciles, il y a la compression audio avec oggenc, il y a la manipulation d'image avec convert (utiliser pour faire les galeries d'images numérique sur internet) etc...
Vous avez regardé mon bench ?
Pas encore non.