Postez dans ce topic vos questions, remarques, suggestions à propos de cet article.  
 
Vous pouvez le lire ICI
 
Bonne lecture

Encore un coup dans l'eau pour AMD
Dommage quand même. Il eut pu être bien ce proco, mais vu le rapport perfs / prix des C2Q ...
 

Je sens que Monsieur Chambolle va pleurer...

bourdel, qu'est-ce qu'ils foutent chez AMD  
j'aimerais bien une bonne petite guerre des prix d'ici la fin de l'année moi, histoire de toucher un C2Q 45nm apacher  

Bon article
C'est dommage de ne pas avoir les graph des jeux en reso et détail max, meme si les scores sont quasi identiques, ca aurait l'avantage de montrer qu'en utilisation réélle de jeux, le phenom n'est pas plus mauvais que les autres.

ce n'est pas qu'il est plus mauvais ou pas que les autres, c'est que c'est la carte graphique qui fait tout le travail, rien de plus

Bonjour, j'avais déjà commenter une fois une news portant sur l'apport du SSE 4 version penryn envers l'encodage divx ; j'ai retrouvé des liens concernant son utilisation.
 
http://forum.doom9.org/showthread. [...] light=sse4
http://forum.doom9.org/showthread. [...] ost1033903
http://forum.doom9.org/showthread. [...] 83&page=10
 
En gros d'après ce que j'en ai compris, divx n'a fait qu'adapter son codec à ce nouveau jeu d'instruction en utilisant du simple "full search ME" et ajouter ce même mode d'estimation de mouvement couplé à du SSE2.
Il y a un gain appréciable dans ce cas particulier, mais d'après les liens, cela n'apporterai pas grand chose (du moins pas autant que ce qui a été affirmé) par rapport aux autres algorithmes classiques (mode "qualité folle" par exemple) ni en terme de qualité ni en terme de vitesse d'encodage.
N'ayant pas de penryn sous la main, je ne peut faire des tests par moi même hélas. Il serai peut-être intéressant que matbe jette à l'occasion un oeil dessus : faire des encodages utilisant ce mode expérimentale (publicitaire ?) en SSE4 & 2, en "qualité folle", en "qualité extrème" et "meilleure qualité". Il faudrait donc observer les vitesses d'encodage et peut-être la qualité des différents extrait (overal PSNR, SSIM et de visu bien sûr). On pourrai alors confirmer éventuellement de l'utilisation pertinente de ces modes dans les benchs.
N'étant pas développeur moi-même, ni trop versé dans les algorithmes d'encodage vidéo, peut-être ai-je mal interprété certains post ; si besoin corrigez moi.
P.S. : pour les test PSNR et SSIM, n'en ayant jamais fait, je ne sais pas comment procéder, mais il doit y avoir des scripts avisynth sur le forum dont j'ai fournit les liens.
edit : typo

Bah on peux pas dire que les intel tire sur les prix (pour le moment), car aujourd'hui tu as une grosse config de joueur (pour jouer en 1680*1050), pour 1000 hors écran  

---------------
Privé de signature par un méchant modo
 
"Salut ! Je m'appelle Guybrush Threepwood, et j'aimerais devenir un pirate !"

eh ben, avec la baisse de prix d'Intel d'aujourd'hui, c'est mal barré pour le Phenom...  

encore plus, en plus les grands constructeurs ne font pas encore de pc à base de phenom (enfin pas encore eux chez nous)

---------------
Privé de signature par un méchant modo
 
"Salut ! Je m'appelle Guybrush Threepwood, et j'aimerais devenir un pirate !"

Le problème avec les benchmarks, c'est que les performances d'un processeur dépendent énormément des jeux d'instructions utilisés, ainsi que du compilateur et des options de compilation.
 
Par exemple, l'encodage FLAC avec mon Phenom 9600 BE à fréquence d'origine (2.3 GHz) est plus de deux fois plus rapide qu'avec le C2D 6600 à 2.4 GHz de cette persone (7 secondes contre 15.24 secondes), avec exactement la meme version de FLAC, en monothread. Même en overclockant son CPU à 3 GHz, il reste plus lent que mon Phenom, ce qui est évidemment anormal. Une différence notable: il a utilisé la version précompilée i686 d'Ubuntu, alors que j'ai compilé ma version moi-même en 64 bits, avec le support SSE activé (je ne sais pas si c'est le cas du package Ubuntu).
 
Je ne sais pas exactement ce qui explique cette différence de performances, mais ça montre bien l'importance de la partie logicielle dans les benchs. Alors dire que les CPUs d'Intel sont plus efficaces que ceux d'AMD, c'est un peu facile, même si c'est globalement vrai. La supériorité du Phenom dans les benchs d'encodage vidéo, contrastée avec sa nette infériorité dans d'autres benchs (notamment encodage audio), le montre bien.
 
Je ne suis pas un adepte des théories de conspiration, et je doute fortement que les développeurs aient décidé d'handicaper les processeurs AMD. Peut-être s'agit-il de solutions de facilité : peut-être développent-ils principalement pour les processeurs d'Intel (les plus répandus sur le marché), tout comme ils développent principalement pour les systèmes d'exploitation de Microsoft (en quasi-monopole). En revanche, je ne peux m'empêcher de penser qu'AMD est un peu en faute, ne semblant pas faire beaucoup d'efforts pour améliorer le support logiciel de leurs produits. Ou alors, Intel a simplement fait un bien meilleur boulot de ce côté.
 
En tout cas, j'aimerais bien voir des benchmarks préparés par des spécialistes, qui profiteraient au mieux des performances de chaque processeur, d'Intel comme d'AMD. Cela dit, les benchmarks publiés par la presse informatique ont un intérêt non-négligeable : ils montrent les performances pratiques avec des logiciels tels qu'ils seraient utilisés par les consommateurs. De ce côté-là, clairement, Intel gagne haut la main.

Tu as raison, mais en gros je ne voulais souligner que le bench d'encodage en divx n'était pas forcément représentatif d'un usage commun ; d'après ce que j'ai lut (et déduis), c'est que cet encodage en "full ME" est bien moins optimisé pour la vitesse que les autres algorithmes. Je veux dire que même s'il produit une meilleure qualité d'image, son ratio qualité/vitesse doit être inférieur à un algorithme dit classique. Divx ne l'a intégré uniquement à titre "pédagogique".
J'aimerai bien voir un comparatif conroe/penryn sur divx sse4 versus divx "qualité folle" par exemple.

Salut à tous,
 
Je suis pourtant un supporter d'AMD, mais après cet article que je trouve impartial, je crois que la polémique du Quad-core d'AMD censé clouer le bec à Intel est définitivement close, même pour les fanatiques :-(
 
Petite liste des facteurs prépondérants de cette débâcle selon moi :
 
- trois niveaux de cache interne c'est trop à gérer en termes de cohérence (je sais pas pourquoi ils ont persévéré envers et contre tout dans cette voie !)
 
- pas les moyens d'un Intel en termes de technos de gravage (le partage de technos avec IBM est limité) et donc un méga train de retard en finesse de gravure et d'aptitude aux hautes fréquences
 
- un train de retard également en technos RAM utilisées
 
- AMD en tant que challenger, ne peut pas imposer l'utilisation d'un compilateur optimisé pour ses procs dans les outils de dev les plus fréquemment utilisés et encore moins convaincre de produire le code en double (optimisé Intel + optimisé AMD). Par suite, AMD est condamné à essayer de rendre les perfs de ses procs pas trop ridicules avec les compilos Intel, mais le fonctionnement de ses procs est assez éloigné ... pas simple !
 
- une architecture processeur qui, malgré son évidente supériorité théorique à mon avis, ne peut commencer à porter ses fruits que sur les machines multi-procs (et encore, à partir de quatre ... un peu comme la vieille bataille CISC vs RISC). Et le net manque de tests visibles du grand public dans de telles configurations. Perso, j'ai jamais vu un seul test comparatif Intel/AMD sur des machines au delà du bi-proc (là où le FSB tient encore la distance). Donc lorsque le responsable des achats d'une grande entreprise se trouve en négo avec le fabricant X, il peut plus facilement se référer mentalement aux résultats de tests comme celui dont on parle ici et aux millions de commentaires qu'ils génèrent sur le net et entre collègues dans les entreprises ; même si ce sont des tests qui ont un sens pour le poste de travail utilisateur et pas pour des serveurs. Cet acheteur ne va pas forcément aller chercher des tests qui sont quasi-introuvables sur le net, ou encore essayer de déchiffrer des tableaux de stats complexes sur un spec.org pour trouver ce qui se rapproche le plus de son architecture. La technique d'Intel est donc ici la même pour moi que celle de MS : verrouiller le marché end-user et s'en servir comme argument commercial pour faire plier les autres marchés (50 millions users can't be wrong !! ..... did we mention that we cut them any escape out of here ?).
 
- une architecture processeur orientée serveur, donc pas étonnant qu'elle soit en retrait dans des utilisations poste de travail : erreur marketing et/ou stratégie produit de la part d'AMD
 
- enfin (c'est juste un sentiment ici), je pense qu'il y a quelque part un gros défaut de jeunesse dans la conception de ces quad-core et qu'AMD le sait mais soit n'a pas encore réussi à mettre précisément le doigt dessus, soit est en train de paniquer au vu de tout ce qu'il faudrait modifier pour corriger ! Parce que se retrouver autant à la ramasse face à la concurrence avec une architecture qui a demandé autant de boulot ; voire sur certains tests, à la traîne par rapport à ses propres procs de génération précédente à fréquence égale ...... désolé, j'y crois pas !
 
Voilà, c'est tout, l'avenir nous enseignera.
 
Eric

Merci pour toutes ces réactions fort à propos

Sauf que compiler pour AMD ou Intel c'est le meme code, personne n'optimise pour une marque de CPU

Quand un soft utilise SSE4.1 mais pas SSE4a, il est optimisé pour Intel. Pareil pour SSSE3.

Ben non il est pas optimise pour Intel, il est optimise pour une version du SSE
Apres c'est aux constructeurs d'ajouter le jeu d'instruction
Quand y avait que les Pentiums qui avaient du SSE, c'est pas "optimise Intel", c'etait optimise SSE et AMD a rajoute le support apres
Et comparer le "4.1" au "4a", c'est un peu bete, y a 10x + d'instructions dans le 4.1

Sinon, Stéphane, est-ce que ce mode SSE4 du divx apporte réellement quelque chose pour qu'il soit inclut dans un bench (full ME SSE4 versus qualité folle) ? Les procs ne devraient-ils pas être comparés sur simple "qualité folle" ? (n'ayant pas de penryn sous la main, j'aimerai être éclairé).

De mémoire il apporte 30% de perf, la qualité de l'encodage est lié à l'algo du programme, pas au jeu d'instructions...

J'entend bien, c'est évident.

Si tu pouvais développer, mais je comprends que c'est peut-être du chipotage.
++

il est plus rapides de 30 pour cent stou

---------------
Privé de signature par un méchant modo
 
"Salut ! Je m'appelle Guybrush Threepwood, et j'aimerais devenir un pirate !"

30 % me parait un peu démesuré pour un algorithme "exhaustif" (mode utilisant le sse4) par rapport à un algorithme plus subtil de l'estimation de mouvement qui fait moins de calcul.

En meme temps comparer des algorithmes ca n'a plus grand rapport avec le jeu d'instruction utilise

http://www.matbe.com/articles/lire [...] /page9.php
Virtualdub 1.7.6 – Compression AVI vers DiVX
Regarde la différence entre le E6850 3ghz SSE2 vs E8300 3ghz SSE4 => grosso modo 30%

J'ai fait un petit test sur un Q6600 à 3 Ghz ; le passage du mode qualité folle au mode expérimentale (SSE2) fait augmenter le temps d'encodage de ~15% pour une qualité métrique quasi égale au centième près (bref invisible a l'oeil normal même s'il faut toujours relativiser ces méthodes de comparaison). N'étant pas chez moi je posterai mes chiffres ce soir.
C'était juste pour dire que faire un bench utilisant ce mode expérimentale n'apporte rien, voire même est pénalisant pour les processeurs non SSE4 compliant. Dans une démarche scientifique il est vrai qu'il faut réaliser des tests où un seul paramètre varie (alors qu'ici les cpu [B]et[/B] les modes d'encodage diffèrent déja!), mais dans ces benchs où on utilise un protocole ne mettant pas tous les cpu sur un pied d'égalité (I.E. en conditions optimales), ils renvois à des résultats "biaisés" mettant en valeur la soi-disante avancée que procure le SSE4 (c'est Divx et Intel qui doivent en être content) alors qu'il n'en est rien ou n'est pas encore démontré.
J'avoue que c'est du chipotage et que cela ne changera pas l'ordre de classement des processeurs hein, le penryn sera toujours plus performant que les kentsfield, ne serai-ce que dut aux optimisations mineures qu'ils ont eu.
P.S. : par curiosité j'ai également testé le xvid sur le même extrait et il se révèle plus rapide et de meilleure qualité .
 
édith Cresson :  
                           1pass 2pass tps total      taille     SSIM average PSNR
divx expSSE2       135      118 253           34450    0,95797 41,517985
divx qualité folle 112         103   215         34452  0,95781 41,5104825

en même temps, est ce que la seule diff entre ces deux cpu est le sse?

y a la qté de cache aussi... 4 mo Vs 6 Mo...

A cache égal, la diff est plutôt de 20-25 % avec DiVX et SSE4

(tests en cours pour le prochain article)

Bien vu j'avais pas fait gaffe

Le Q9300 est abordable je me demande si c'est pénalisant genre sur toshop, en encodage, voire sur supreme commander (même si je sais qu'il n'est pas benchable) d'avoir "seulement" 2x3mo de cache.
Si jamais tu savais tester la différence entre les 2x4Mo de cache du Q6600, les 2x3mo sur le Q9300 et les 2x6Mo du Q9400 à fréquence égale, ça serait assez fabuleux.

c'est fait, ce sera publié lundi
 
Sauf que j'ai comparé Q6600 et Q9300 à 2.33 GHz dans un tableau séparé car là y a pas que le cache qui joue mais aussi SSE4 et les améliorations de Penryn.
 
Sinon j'ai comparé QX9650 ramené à 2.33 au Q9300 à 2.33 GHz aussi. Le Q9400 a pas 2x6 Mo mais 2x3...

http://prix.matbe.com/prix/fiche-technique/160961/
Je me suis trompé de modèle (retour de soirée toussa)
Vivement lundi

Le q9450 est dans le test aussi et il l'était déjà dans les tests du Phenom

Je viens d'éditer en retard (en période d'examens les priorités différent). Sur un extrait de boulevard de la mort de 5855 images, en script avisynth seulement le chargement des plugins,crop et resize adéquat (crop(0,72,0,-72),lanczosresize(704,288)).
La différence totale peut sembler dérisoire, mais quand on essaye d'améliorer la qualité visuelle d'une vidéo ou sa compressibilité, on peut effectuer beaucoup de test de compressibilité/de rendu qui fassent que certaines "non amélioration" (I.E. SSE4) sont plus  pénalisantes qu'autre chose. Bref, les CPU non SSE4 compliant, bien qu'étant inférieur en terme de productivité, le sont moins que ce que les tests actuels veulent bien le démontrer. Bref à quand un test Penryn mode SSE4 versus autres CPU mode qualité folle (chez divx) ? Faut croire que personne ne veut essayer.

Rien ne t'empeche de faire le test toi meme

Honnetement je veux bien évidemment, pas de pot, je ne vais pas m'acheter un nouveau CPU rien que pour bencher alors que j'ai un q6600 neuf sous la main (et ça ne m'amuse pas plus que ça de chercher à le refourguer et perdre des roros au passage @_@). Ceci dit si tu me le paye et l'envoi, je veux bien m'en occuper (et de ton côté sa donne quoi ?).

De mon cote je lis meme pas les tests matbe

Et par rapport au sujet ?

Quelqu'un sait-il s'il existe une comparaison de ce type (récents processeurs Intel vs AMD) sur des benchmarks Java ?
 
Parce que franchement, les applis de bureautique ou les jeux, cela ne me sert à rien pour faire un choix concret quand je décide d'acheter une machine.

un test de perfs sous java, c'est plus le code et la JVM qui vont les influencer que les CPU en eux-même  

Si les applis bureautique ou jeu servent pas a faire un choix, c'est pas avec les 3 malheureux trucs java par an qui tournent sur une machine de particulier que ca va avancer a grand chose

déconne pas le configurateur BMW est en java et j'le fais tourner au moins une fois / mois