Reprise du message précédent :

Ah ça ! sur un même PC (ou Mac) suivant le carte son, la version des pilotes et le DAW utilisé ça varie. Si on ajoute le CPU et la Ram comme variable ça peut vite devenir compliqué.
 

Peut-on trouver des renseignements sur le web à propos de cette méthode ?
 
Pour revenir au dossier, les performances de ce nouveau FX à propos des DAW devraient être dans la même ligné que la majorité des autres applications à savoir à la hausse au point de concurrencer l'offre Intel? Enfin il reste le problème du refroidissement qui vous l'imaginer dans mon cas doit être le plus silencieux possible.
 
Petit hors-sujet : en parcourant des forums anglophones audio, j'ai vu plusieurs personnes qui parlaient d'utiliser des cartes graphiques en guise de DSP pour les traitements temps réel. Pour le moment aucun constructeurs n'a évoqué cette solution car ils développent pour la plupart leur cartes DSP propriétaires (ex: accel core pour Pro Tools HD) et qu'ils ont tout intérêt à garder ce modèle économique. Toutefois avec cette idée qui jais sur les forums et je me demande si c'est farfelue ou au contraire viable.
 
 
 
 
 
 

Pour une utilisation gamer, je pense qu'il vaut mieux grapiller 100€ sur le CPU et le mettre sur le GPU s'il faut un compromis sur le prix...
Non ?

Tu oublie la question du deplacement des atomes, ca demande de l'energie aussi.

rastapopey > bien sûr que pour jouer il faut une carte graphique de jeu
& la meilleure sera le mieux, même par rapport au CPU qui n'est pas un composant de jeu (mais il y contribue, c'est tout)

hum, OK, mais je parlai (et toi aussi, du moins je croyais) de Rendement :
[Wiki]  
En électronique, le rendement exprime le rapport entre la puissance consommée et la puissance fournie par un circuit.  
En physique, le rendement désigne le rapport entre l'efficacité énergétique réelle d'une machine thermique et son efficacité théorique maximale.  
[/Wiki]
Et il me semble qu'un PC est loin d'être une machine thermique  

En fait c'est plus automatisé qu'automatique, je n'ai pas plus d'info à donner c'est une appli tierce dev par eux qui permet de gagner du temps dans ce genre de test.

Sinon, je pense que oui, mais cela dépend des plugins, peut-être que vous utilisez des plugins qui tournent vraiment mieux sur Intel (ou le contraire!), impossible de savoir sans test Dommage que des sites spécialisés ne traitent pas cela en profondeur.

Pour l'utilisation du GPU en guise de DSP je ne vois rien qui s'y opposerait au niveau de la puissance de traitement, par contre je ne sais pas du tout si la latence serait au niveau nécessaire.

Ça part en cacahuètes les com'. On en vient à parler chauffage sur le test du 8350, trop fort. Méga troll le retour!

HS
 
Si tu prends la planète terre (la boule) le rendement est aussi zéro?
Ben oui la seule chose qui sort/entre de la planète c'est le rayonnement électromagnétique (chaleur entre autre justement,...).
Et pourtant on ne peut pas dire que la terre soit inertes , il y a pas mal de vie que crouille dessus .
 
Autre exemple ta voiture, le moteur à un rendement de 10-40% en fonction de l'usage, oui, mais si la aussi tu regardes à un niveau plus haut, de l'extérieur, ben toute l'énergie consommée par la voiture terminera inévitablement en chaleur.  
1. Directement au niveau du moteur (le rendement mentionné).
2. Et l’énergie servant à faire avancer la voiture finira aussi en chaleur. Ben oui elle finira par s'arrêter la voiture à un moment -> frottement de l'air, déformation des pneus, frottement des freins.
 
Bref tu te trompes de référentiel si on peut dire. Si tu regardes le PC, comme la planète terre, donc de l'extérieur en l'occurrence ta tour, le seul truc qui rentre dans le PC c'est électricité 230V, et éventuellement des signaux data électrique mais qui sont totalement négligeables en terme de puissance (LAN, Wifi p.ex).
En sortie t'as quoi? La aussi des signaux électriques de très faible puissance (sortie video, audio), un flux d'air en mouvement bof, totalement négligeable la aussi.  
Ben il est passé où tout le courant 230V? Ben en chaleur.
 
/HS
 
 
Sinon pas trop mal ce CPU surtout pour ce prix. Mais la conso semble vraiment démesurée.

Ne pas suivre toussa

+1

Machine thermique ou non, si une énergie rentre dans le système, elle en sort d'une façon ou d'une autre... L'énergie consommer par ton processeur sera à 100% à dissiper par le ventirad...
On parle de rendement dans le cas de l'alim, ton alimentation ne consomme pas a proprement parler 300W (c'est la config complète) à la prise, il y a 300W qui rentre dans le système, une partie est directement éjecté sous forme de chaleur en fonction du rendement de l'alim (80% => 60W de dégagement thermique) le reste des 240W sera utilisé (on oublie le rendement des étages d'alimentations) par le proc, le DD, la CG, etc... Toute cette puissance consommer sera ensuite dissipé par un rad ou par simple dissipation thermique du composant (le peu d'énergie consommé par la ram ne requière généralement pas de rad pour ce dissiper correctement)

Le même raisonnement est applicable à une voiture, le moteur à un rendement, il chauffe donc beaucoup car 1 litre d'essence représente a peu pret 10kWh, or le rendement est inférieur à 40%, il y a donc déjà plus de 6kWh de chaleur qui sont a dissiper par le radiateur (pour chaque litre d'essence consommer) afin de redroidire le moteur. Les 4kWh qui reste vont se dissiper en chauffant les pneus (par exemple) a cause du frotement entre les pneus et la route, parmis ces 4kWh une partie de l'énergie est indispensable pour maintenant la voiture à une vitesse constante en venant fournir une force égale au frotement des pneus (même raisonnement avec les frotements avec l'air, une voiture va réchauffer très légèrement l'air ambiant en roulant...)

[/hs]

 
Petit HS : réparties entre le radiateur, les parois du moteur, l'échappement, les gaz d'échappement. Et si on considère le rendement aux roues on peut ajouter toute la transmission.

Merci bien pour toutes informations Marc.
Encore une fois, vous faites un excellent boulot, on ne trouve nul part ailleurs des tests aussi complet et aussi objectif.

En même temps, c'est bien de sortir un tel processeur, on va bientôt rentrer en hiver...

Merci pour cette article complet !

EUH il y en a certains qui sont dur quand même , c'est un bon processeur proposé a un juste prix en fonction de ce qu'il est capable de faire face a la concurrence , et si il consomme un peu ben tans pis , cela dit , on attendra steamroller pour certain avec le famous ipc increase , la on pourra vraiment la noté cette architecture .
(Une parenthèse le cycle de renouvellement de gamme est plus rapide qu'avant , donc on constate moin les up de performance , en fait l'archi a la base de bulldozer aurait pris un peu plus de 4 ans puisque cè'est l'excavator qui terminera sont cycle de developpement)  
Au jour d'aujourd'hui ce processeur est a ca place en gamme et en prix.

Je salue la qualité rédactionnel et technique, ainsi que la pertinence de tes tests l'ami. J'ai jamais vu meilleur, chapeaux!

sans vouloir troller arreter d'esperer le retour d'AMD a chaque nouveau cpu lol Meme si moi aussi dans le fond je l'espere pour assaisnir le marche et relancer veritablement l'innovation.

c'est ce qui s'appelle dire tout et son contraire  
 
plus sérieusement , faut reconnaitre que les progrès sont notables , le soucis , c'est qu'ils partent de loin  
rattraper un tel retard ne pourras pas se faire sur une seule génération, mais ça reste un début

+1  
et je dirais même plus, un très bon début, car la finesse de gravure est toujours la même

Merci pour votre test
C'est plutôt potable pour upgrader mon phenom II x 6 1045 T sans changer de plateforme..
et ça semble tout à fait correct pour completer une hd 7850/70 comme indiqué sur le graphique amd que l'on peut trouver en ligne    engadget.com/photos/amd-fx-vishera-slide-deck/...
Apres pour le haut de gamme et la consommation...ça n'est pas  suffisant , ce n'est pas du intel i5/i7  bridge mais c'est moins cher ...

Concernant les tests IA, si quiconque peut trouver Fritz ChessBenchmark (v4.3) sans posséder Fritz 12, pourquoi le choix d'Houdini pro 2 ? Non seulement celui-ci est payant (récemment remplacé par la pro 3) mais aussi controversé dans le monde des échecs.  
Il existe pourtant l'excellent StockFish (v2.3.1) qui est open source ...
http://stockfishchess.org/

Houdini est le premier au classement, même sur le site de StockFish.

Sinon j'avais essayé StockFish à l'époque de la mise en place du protocole mais il donnait des résultats bizarres en 64 bits
http://forum.hardware.fr/hfr/Hardw [...] m#t8036502
En 32 bits c'était mieux par contre il ne semblait pas très bien scaler en fonction des thread, tout du moins avec l'HT.

Moi ce que je constate c'est que sur les apps AMD viens sérieusement taquiner les plus gros i7 et que pour le jeux il reste derrière a cause de la non exploitation des MT dans les jeux . Ce que je sais c'est que la prochaine gen de consoles va se dévelloper sur du 8 cores mini (xbox 8 ) en power PC comme d'habitude . Maintenant je me pose la question de l'avenir , oui AMD est à la "traîne" dans les jeux 3D avec ces CPU aujourd'hui mais demain ???? se peut il qu'en fait AMD ai sacrifié toute une génération pour mieux préparer demain ? c'est en tout cas ce qui me semble ressortir des résultats , j'aime a penser qu'avec la prochaine gen de jeu qui se basera sur du 8C AMD pourrais plus que surprendre et ce déjà avec ses processeurs actuels et qu'on pourrais , je dis bien pourrais , assister à de nouveau test sur ces processeurs .

Quand ca arrivera on aura vu 2 générations de CPU, alors bon, ce qui compte c'est quand même le maintenant avant tout.

Sans vouloir t'offenser la xbox 8 débarque très très bientôt et le nombre de jeu en dev's sur ce support sont déjà légion , donc ça m'étonnerais de voir plusieurs "gen " (si pour toi un passage Sandy --> ivy ) représente une gen . A moins que je t'ai mal compris .

Effectivement Houdini est un peu plus performant (entre 50 et 80 elo) que Stockfish, mais il est sujet à controverse (de même que Rybka) car basé sur le code de Fruit, free chess engine développé par le Français Fabien Letouzey (Cocoricooo). Cela dit, Stockfish reste le meilleur en open-source (http://www.computerchess.org.uk/ccrl/4040)
 
Il est probable (mais pas certain) que les soucis rencontrés l'année dernière soient résolus avec la version 2.3.2. Pour ma part, étant sous Seven 32, je n'ai jamais rencontré de pareilles contre-performances.

 
J'aimerais bien aussi... mais le souci n'est pas tant l'architecture des consoles mais la difficulté technique que représente le multithreading. Pour pouvoir faire un thread séparé il faut avoir un ensemble de calculs assez gros pour que créer un thread soit rentable et en même temps que cet ensemble de calculs soit relativement indépendante du reste. Si le thread principal doit attendre le résultat du thread secondaire pour continuer on ne gagne rien.

Merci pour cette éxplication technique mais justement il semblerais que difficulté technique lié à tout cela ne soit plus aussi grosse qu'il y a 2 ans . Et si Ibm fourni un hexa à la xbox 8 c'est surement lié à une demande des dev's . Bon après je sais pas car dans mon métier (gametester) je n'ai pas encore accès à la next gen . Mais par contre ce que je sais c'est que le PC est toujours obliger d'attendre l'évolution des consoles pour lâcher les chevaux ! Du coup je garde bon éspoir que la stratégie d'AMD que je suspecte soit la bonne car si je ne remet pas en cause la puissance d'Intel , je reste fidèle à la politique économique d'AMD qui ne demande pas de se couper une couille pour jouer ou bosser (d'ailleurs j'ai gardé mon bon viux phenom x6BE ) . Bref wait n' see mais si j'ai bien compris ce que tu m'explique , si l'unité de calcul dedié est assez puissante elle pourrais favoriser l'exploitation MT ??

plus de 8Ghz !  http://www.techpowerup.com/img/12-10-24/231a.jpg
 

Une pluie intense sur Abu Dhabi... AHAHHAHA
 
Bon moi je vais encore attendre un peu avant de changer mon 1090T

Bonsoir ,
 
on ne passe pas à Houdini 3 pour les tests ?

 
Je ne pense pas que la difficulté technique puisse évoluer au fil du temps, être contourné peut être, mais pas de sitôt. Quand on sais ce qu'on va faire, comme pour une compression de fichier ou un encodage de vidéo rien n’empêche de saucissonner le fichier en morceaux à traiter dans des threads séparés. Mais dans un jeu tout est en temps réel et tout interagis, on à un traitement qui se déroule au fur et a mesure. Ça complique sérieusement l'affaire.  
Pour répondre à ta question je pense qu'on va continuer de voir évoluer les utilisations annexes, pour une gestion de manette complexe par exemple (genre kinect), ou une IA très lourde. Certains traitements en marge du jeu principal qui sont actuellement légers pourront devenir lourds, sans les conséquences qu'on aurait eu dans le passé. On va probablement voir plus de gaspillage de puissance CPU dans les threads annexes ou les autres logiciels "parce qu’on peut se le permettre". Mais la problématique de base reste entier.
 
En revanche je suis 100% avec toi sur le coup de l'évolution graphique, j'en ai raz la cacahuète de voir qu'une grande majorité de titres édités sur PC continuent d'exploiter des textures cracra, un décor à tendance monobloc indestructible et des effets de lumière complètement dépassés à cause du nivellement vers le bas des consoles. (et de voir ma vieille 6850 se tourner les pouces )

Je suis assé impressionné par les progrès d'AMD sur ces nouveaux processeurs.
Ils sont très prochent des tous meilleurs processeurs Intel en ce en dépit d'un process de gravure de retard (32 nano contre 22 pour un 3770k).
 
Je ne sais pas quel gain apporte en moyenne un process de gravure plus fin, mais ça pourrais être interressant de l'imaginer.
 
Intel doit quand même se poser des questions ... parce que se faire taquiner par des procos qui ont une génération de gravure de retard ...
 
Bref ... vivement que le retard de gravure soit comblé.

AMD est quand même à la ramasse question efficacité énergétique, et je doute que ça soit uniquement dû à une gravure moins fine.
 
Au niveau des perfs par contre, c'est clair que c'est plus engageant que l'an dernier.

Il est vrais que du point de vue de l'efficacité energétique c'est pas ça ... mais encore une fois une finesse de gravure inférrieur aiderai surement à améliorer les choses.

Bon un petit commentaire sur la partie encodage vidéo que je connais particulièrement bien.
 
L'encodage vidéo est certainement le domaine où la puissance CPU est le plus primordial avec le rendu 3D mais l'encodage vidéo est un domaine applicatif beaucoup plus démochratisé que le rendu 3D. C'est à mon avis le roi des tests, celui qui permet de voir vraiment l'efficacité d'un CPU car les codec vidéo ont un niveau d'intégration très élevé et sont optimisés pour utiliser pleinement les fonctions MMX, MMXExt, SSE, SSE2, SSE3, SSE4, SSE5. C'est de plus un domaine applicatif qu'il est facile de Threader et les appli x264 et Mainconcept sont capable de tirer 100% du potentiel des CPU multicores (au moins 16 cores pour ces 2 codecs).  
 
Bon voici cependant quelques critiques de la part d'un lecteur qui connait particulièrement les codecs vidéos:
 
1) Vous ne faites pas une utilisation classique en terme d'encodage vidéo. Pour un utilisateur qui s'y connais la vitesse d'encodage est un élément secondaire. C'est la qualité qui prime. Le profil "fast" pour le x264 est donc un profil d'encodage qui n'est en pratique jamais utilisé (pas de recherche avancé tel que la RDO ou le trelli dans ce mode). De plus je ne suis pas sur que le mode "fast" soit le plus optimisé en terme de code par des dev du x264 alors le mode "ultra" est lui particulièrement optimisé. La vitesse d'encodage est un élément secondaire dans le sens où on sacrifiera toujours le temps d'encodage devant la qualité finale mais c4est tout de même un élément très important. Un réencodage de BD50 vers DVD9 en 1080p peut durer une dizaine d'heure (voir plus pour les acharnés de la qualité). Avoir un CPU particulièrement puissant pour réduire ce temps d'encodage est donc primordiale.  
 
2) Le codec x264 est parfaitement multithreadé même en mode fast. Le problème pour la première passe vient du fait que StaxRip utilise un serveur de frame externe pour alimenter l'appli x264.exe. Le serveur de frame AviSynth n'est en effet pas multitheadé. Le codeur x264 attend donc des frames qui ne viennent pas assez vite du fait de la lenteur de décodage du serveur de frame. Vous avez donc une limitation de la vitesse (effet goulot de avisynth) dans le mode fast first pass mode du codec x264. Votre test d'encodage n'est donc pas au sens strict un test d'encodage mais plutôt une test de décodage (flux H264 à 30 Mbps très lourd à décoder en software), de frameserver (Avisynth est lent) et enfin d'encodage.  
 
 
Si voulez vraiment faire un test d'encodage au sens strict du terme vous devriez utiliser le codec x264 directement en ligne de commande en utilisant en input un fichier video RAW (non compressé). La seule limitation externe dans ce mode serait la rapidité du disque de stockage (un fichier RAW non compressé c'est environ 250 Go par heure en 1080p YV12) et il faudra donc utiliser un SSD rapide pour être certain de s'en affranchir. Mais bon si l'encodage est fait en mode "ultra", on sera toujours très loin d'un encodage temps réel en 1080p (24 fps ou plus) et même un DD assez lent sera suffisant ici.
 
Si vous voulez vérifiez les informations précédente je vous conseil la lecture du forum doom9.org.

Et voici l'exemple d'un patch relatif à l'utilisation des fonctions SSSE3/SSE4/AVX pour l'analyse sur les blocs intra 8x8. Les optimisations sont bien plus importantes en mode "slower":

Merci pour les précision, attention toutefois les gains plus importants en mode slower ne signifie pas qu'il est plus optimisé, mais qu'il profite plus des optimisations, ce qui est très différent.  Pour le fait de passer directement par du RAW je ne suis pas fan. J'ai cru voir qu'il y'avait des tentatives de versions MT d'avisynth Ou sinon il faudrait passer par un autre logiciel et serveur de frame, mais avisynth est très utilisé. Si tu as des propositions, n'hésite pas a m'en faire part en MP.

 
1) Disons pour être plus précis que les gains obtenus avec les fonctions câblées seront plus facile à mettre en évidence avec le mode "ultra" car les optimisations sont bien plus visibles sur les calculs lourds et ces optimisations sont particulièrement recherchées par les devs pour ces calculs lourds (et donc intrinsèquement plus lents). En clair si vous voulez bénéficiez des dernières optimisations pour les derniers types d'architectures et réellement savoir ce qu'elles ont dans le ventre il vaut mieux utiliser le mode de qualité "ultra" qui les mettra mieux en évidence. En plus cela correspond bien mieux à l'utilisation réelle de ces codecs.
 
2) Il existe des version avisynth MT et 64 bits mais non officielles. Il n'existe pas vraiment d'alternative en OpenSource.
 
3) Je vais essayer de vous fournir (en MP) des scénaris réalistes d'encodages pour coller à la réalité de l'encodage actuel:
- réencodage BR vers H264 720p 1.4 Go (le standard idéal actuel sur la scène underground)
- encodage BR avec les outils pro d'authoring
 
4) j'ai aussi trouvé très intéressant votre test sur les encodeurs hardwares. Du point de vue de la forme vraiment exceptionnel. Sur le fond la comparaison d'un point de vue qualitatif était difficile du fait que les codecs hardwares ne possèdent pas de gestion ABR en multipasse. Si vous vouliez vous en affranchir il fallait utiliser un mode 1 passe à quantizer constant. Mainconcept propose ce mode en encodage CUDA. Mainconcept dispose aussi d'une build H264 en OpenCL. Je vous invite à les contacter pour tester et comparer leurs builds (CPU, CUDA, OpenCL). Vous auriez là un test applicatif populaire pour comparer ces différentes solutions.

1/ Tu noteras que dans l'exemple d'optimisations SSE3/4/AVX, sur cette partie du traitement les gains entre les presets medium et slower sont comparables, seul le mode faster est en retrait. Les écarts entre les différentes archi sur cette partie post patch sont par contre très proches que ce soit en faster, medium et slower : SNB est 38, 39 et 37% plus rapide que Penryn et Bulldozer est 5, 4 et 6% plus rapide que SNB.

2/ Dommage. Dans x264 HD Benchmark, utilisé par pas mal de nos confrères anglophones, ils utilisent la build de JoshyD
Sinon l'autre solution serait de ne faire qu'un encodage 1 passe CRF, mais ce seraitune perte d'information car le classement serait similaire à la seconde passe.

3/ Ok.

4/ Le but n'était pas vraiment de comparer ces solutions gratuites ou très abordables avec la solution MainConcept à 350$ le plugin Adobe Premiere. Concernant le choix du 2 passe vs 1 passe à quantizer constant, cf. http://forum.hardware.fr/hfr/Hardw [...] #t8028910. Mais oui ce serait interressant de regarder ce que donne Mainconcept en versions CUDA / OpenCL