Reprise du message précédent :
J'ai le donc le fx 8350, carte mère Asus sabertooth 8 go Kingston +hd 6970 et un I7 3930k carte mère Asus rampage 4 battlefield 8 go kingston + 690 gtx (la 2 eme config, on me la donné !!!). Forcément, il y a une grosse différence de prix entre les deux et de performance, sa on le sait.
J'ai voulu inversé les 2 carte graphiques 690 gtx avec Amd et inversement.
J'ai fait un test performance Windows aussi, je peux en parler !

Avec Amd et la nvidia 690 Gtx, pas de problême, pour les jeux sur un écran 23 pouces en 1080p tous a fond sur Grid 2 ou Battlefield 3, (je ne suis pas un joueur exigeant), là ou sa se gate, c'est si je met le pc sur un grand écran tous s'effondre, sa saccade par moment !
Les mise à jour bien sur fait !

Rien de tel que ce genre de titre pour attisé le débat ' intel vs AMD ' qui enflamme notre bon forum depuis si longtemps

J'ai toujours eu que du Amd, il fonctionne bien le fx 9370 ?

Le FX-9370 n'est rien d'autre d'un FX-8350 overclocké de 400Mhz ... rien d’impressionnant (sauf la consommation). Donc oui il fonctionne. Après, est-il meilleur qu'un i5.  

 
Ouais en gros le FX se fait laminer quoi    
(En même temps le contraire aurait fait peur vu le prix du i7)

OUi et non, ils sont bon tous les deux, en encodage vidéo, le Fx 8350 est pas mal, même si le I7 est meilleur mais pas le même prix !!!

Pour le test Windows, avec les même barettes, le même SSD samsung 830, pour le I7 : 7.8
pour le 8350 fx :7.9
Ah ah ah c'est curieux quand même.!!!

Les tests Windows ne veulent rien dire.

Oui et c'est pour cela qu'un bon bench à la maison, rien de tel pour ce faire une bonne idée.

Avec un 3Dmark par exemple !

C est un 4k ton grand écran ? Parce que sinon pas de rapport entre perf et diagonale a résolution identique (1080p)

Tous dépend des jeux encore une fois, dés que j'ai que sa a faire, je refais un test, et sur grand écran si y a pas de rapport, je vois moi que sa baisse en perf sur un Samsung 46 pouces tous à fond.

Si tu changes pas les réglages du jeu les perfs ne changent pas en fonction de l écran .

Un 46 pouces ou 23 pouces 1080p les deux c est idem.

Après ton 46 pouces est peut être une grosse daube

Il est où Draculax pour fermer le sujet
 
Moi aussi j'ai un 3930K O/C @ 4.6 et un X6 @ 4GHz j'ai testé mon tri CF 5870 O/C
 

 
Le i7 est à des années lumières du X6, pas les chiffres en tête, mais ça dépotait sec sur le i7
 
Bon le X6 à cette fréquence tient à peine la route face au FX8350...
 
J'imagine même pas ce que ça donnerait avec une 7990+7970

Un test Sandy Bridge vs Ivy Bridge vs Haswell  :

http://www.ocaholic.ch/modules/sma [...] 185&page=3
Le meilleur rapport/prix/conso/oc est là 3570K

J'arrive sur mon cheval avec ses grands sabots...lis la méthodologie de test d' hfr, en gros il s'agit de cas extreme en jeu(d'où le 14 vs 20fps sur certains tests).
 
Celui qui a ouvert ce topic a raison ça ne représente pas l'expérience en jeu.

ledesillusionniste avec son cheval tout juste bon pour l'abattoir ...
 
On a compris que tu ne vois que par AMD, que c'est trop génial, qu'Intel c'est de la merde & Cie ...  

Absolument pas.
les fx8 ont 8 alu et peuvent donc gérer 8threads. Ce ne sont pas des cpu "4 threads".
 
Par contre ils ont 4 fpu.
 
Il suffit de compiler un soft avec 10jobs au lieu de 5 ou encore d'encoder avec 8threads au lieu de 4 pour s'en convaincre. Si ça serait un 4threads il n'y aurait pratiquement pas de différence.
 

J'ai pas dit ça. On a compris surtout que pas mal de fanboy Intel n'ont pas lu la méthodologie de test et que donc les vidéos qui montrent peu de différence de perf en  partie ordinaire sont tout à fait crédible étant donné que les bench d'hfr représentent les pires cas, presque une compilation des framerate minimum.
 
Si il y a des troll de haut niveau ce n'est certainement pas chez amd (y a qu'a lire ce topic et les conneries qu'on y déniche, comme l'histoire des 4threads des fx8   )
 
à un certain moment faut arrêter de troller    un 3570 et 4570 se font dépasser en applicatif par les 8320/8350, ça c'est la vraie vie.
 
Je vais probablement me prendre un 4570 bien que largement derrière un 83xx en applications : raison la conso trop élevée des 83xx.
 
Enfin j'hésite encore vu que je me suis déjà bien fait entuber avec le q9550 inférieur aux ph2 945-955 (actuellement).

les FX ont 4 unités de fetch / decode, ils ne peuvent donc pas gérer plus de 4 threads en même temps. CQFD c'est pas un 8 threads.
et on ne compile pas un soft avec 5 threads ou 10 threads en claquant des doigts.
un logiciel DOIT être conçu avec 10 threads pour fonctionner sur 10 threads, si il est conçu pour 5, il ne pourra JAMAIS passer à 10 sans une reconstruction complète.
 
Pour finir, l'OS gère des CENTAINES de threads, tu ne verras pas la différences entre un vrai 4 cœurs et un faux 8 cœurs.
 

J'aime ces vidéos qui, sans rien prouver, sans rien démontrer, qui sont faite sur dieu sait quoi, puisque RIEN n'est vérifiable, et qui sont utilisées pour dire: AMD c'est aussi bien qu'Intel.
Moi aussi je peux faire une vidéo qui démontre qu'un 8086 c'est hyper puissant, et c'est 17645 fois plus puissant qu'un AMD 8350 à 8Ghz sous LN2.
Et pour ton édification oui, un test de processeur se fait sous charge maximale, sinon quel intérêt?
tester un processeur en IDLE, ou calibrer un test pour les charges nulles, ça ne sert à rien, puisque dans ce cas, autant prendre un APU, ou un bon vieux 8086 en CGA...

si parfaitement, on compile un soft avec 10 jobs en claquant des doigts.
 
Mais là pour le coup ce ne sont pas des threads mais des processus. Si je demande 10jobs il y aura 10processus quand c'est possible(dépendance de compilation)
 
Je parlais du travail de compilation pas du fonctionnement d'un logiciel, tu as l'air de confondre les deux mais peut-être que je me suis mal exprimé.
 
L'os gère certes des centaines de threads mais ils ne sont pas tous en occupation cpu en même temps.
 
Bah fait bouloter un fx8 avec 5 et 10 threads(ou processus) et tu verra presque un doublement des perf preuve que 4-5 threads/processus ne le sature pas du tout et qu'il est capable d'en gérer plus même si l'unité de décodage est partagée.
Si ça serait un cpu 4 threads tu n'aurais pratiquement pas de gain en utilisant 10jobs dessus.
 
D'ailleurs fait pareil avec un core i 4c 4t et tu ne verra presque aucun gain.
 

 

 
ce que l'auteur du post disait c'est que les graphs d'hfr ne représentent pas l'expérience d'un joueur sur deux machines intel et amd. Et il a tout à fait raison.
 
Tu as très bien compris ce que je voulais dire, certains ici semblent prendre pour comptant ces bench sans même en avoir lu les conditions comme si ça représenterait l'expérience qu'ils auront quand ils joueront.
 
Cela est totalement faux. Ces tests ne sont pas objectifs. à part chez les fanboy intel kikitoudur.

HFR présente parmi les meilleurs tests hardware sur la planète.
 
Si t'es pas d'accord avec ça, deal with it  

J'ai passé l'âge d’idolâtrer  

Y'a une différence entre idôlatrer (ce que tu fais tout le temps avec AMD par exemple ...) et rendre hommage au travail effectué.
Hardware.fr est un des rares sites avec un protocole de test en béton armé.

oui si il a été conçu pour ça.
si il a pas été conçu pour ça, faut totalement le réécrire pour le faire passer en 10 threads.
 

hum.
processus = traduction en bon français de threads. je t'apprends quelque chose je parie...
et la dépendance de compilation n'a pas grand chose à voir avec les threads, par contre, ta façon de programmer a tout à voir.
c'est pas à la compilation que tu décides le nombre de threads qu'utilisera le programme, mais à la conception, ainsi qu'à l'exécution.
 

Je connais parfaitement le travail de compilation, j'ai fait ma thèse de maîtrise sur la parallélisation du processus de compilation.
 

non y en a 8 sur les i7 HT, 4 sur les AMD FX et les i5 Intel.
 

il est capable, comme les Intel, de gérer plusieurs centaines de  threads.
après, si le logiciel est correctement écrit, il sera capable de créer autant de threads qu'il faut pour saturer le processeur, ce qui n'est pas obligatoirement 8, ou 4, ou 16...

bof bof un proto de test en béton armé c'est un proto de test que tu peux reproduire toi même.
 
à la méthode scientifique, le reste c'est du flan.
 
Pas de reproduction possible = invalide.
 

Je ne te parle pas de l'execution du programme pour y tâche mais de sa compilation...
 
 
 

Franchement t'es bouché c'est pas possible je te parle de SA COMPILATION PAS DE SON EXECUTION.
Merci mais je sais très bien que pour qu'un programme utilise 5threads il doit être codé pour.
un processus et un thread sont deux choses très différentes mais je crois que tu apprends quelque chose.
 

 
alors comment tu peux confondre thread et processus    
 
quand tu demandes à gcc de compiler un programme avec 10jobs il créera 10processus là où il peut suivant les dépendances, pas besoin de réécrire le logiciel pour ça  

Je te conseille d'aller faire un tour chez Clubic alors. Tu pourras y apporter tes commentaires de haut vol  

oh le beau troll.
Il est évident qu'on peut parfaitement jouer sur un APU... pourquoi conseiller autre chose alors?
et tes vidéos au rabais sans aucune fiabilité ne sont pas plus objectifs, à part chez les AMD-idolâtre aux chevilles enflées.
 
PS: savoir qu'en condition de jeu, j'aurais 30fps minimum garanti au lieu de 25FPS, c'est EXTREMEMENT important pour la fluidité du jeu.
si ça, tu le comprends pas, c'est que t'es vraiment borné.

les fps min représente les microsaccades, 25 ou 30 tu les verra. et la diff de 5fps entre les deux n'y changera absolument rien quand tu passera de 50-60fps à 30 une fraction de seconde, tu verra une saccade, peu importe le framerate(20 vs 14 par exemple).

Quand tu demandes à GCC de compiler un programme avec 10 jobs...
ça n'a rien à voir avec le programme compilé, mais il lancera 10 processus (en français), ou threads (en anglais), pour compiler en parallèle, si il le peut, le programme.
ça n'a STRICTEMENT rien à voir avec le nombre de threads que pourras gérer, ou pas, le programme que tu compiles.
les threads que le programme va gérer sont créées par le programmeur,  par un fork() en C par exemple, dans le programme, à la discrétion de celui qui écrit le programme.
 
on parle de logiciels multi-thread... et lui il parle options de compilateur...

Non il lancera 10 processus et pas thread. Il n'y a aucune confusion possible gcc fait du multi processus pas du multithread.
 
processus en anglais c'est la même chose qu'en français.
thread ne se traduit absolument pas par processus en français sinon à vouloir confondre thread et processus.
 
Les threads sont intra-processus.
 
 
 
bordel t'en a pas marre...tout ce que tu me débite je le sais déjà...
 
 
 
 
Non je parle de temps de compilation je ne répondais absolument pas à vos exécutions de threads. Je dis qu'un fx8 compilera bien plus vite avec 10jobs qu'avec 5.
 
Tout comme un encodage x264 10threads ira bien plus vite sur fx8 qu'avec 5threads.

Une thèse, c'est bac+8 et pas niveau maîtrise (et je connais bien le sujet pour avoir encadré pas mal d'étudiants de maîtrise) .
 
 
Sinon, sous Gentoo (une distribution Linux), tu peux pratiquement tout paramétrer niveau compilation, genre :

Tu peux notamment voir le 'MAKEOPTS="-j6"' (j'ai un X6) .
Bref, tout est compilé comme tu veux.
 
Après, tu as plein d'outils sympa, genre, si tu veux voir le temps de compilation (à relativiser si le paquet n'est pas déjà téléchargé) :

 
Bref, les besoins et l'usage varient selon la personne .

t'es bouché à l'émeri, c'est pas possible.
un processus c'est un thread...
 
c'est exactement la même chose puisque c'est la traduction en bon français.
 
et sur un intel, tu compileras encore plus vite en lançant avec 100 jobs.

oui excuse moi, c'est un mémoire, pas une thèse.

Pourquoi n'utilises tu que 6jobs sur l'hexa core ? pour laisser un peu des ressources pour toi?

 
Non un processus ce n'est pas la même chose qu'un thread. Absolument pas. Merci de ne pas parler de ce que tu ne connais pas.
... arrête de dire des conneries, merci.
 
Avec tes 100jobs de compilation ça sera plus lent qu'avec 6  
 
Tout comme un rendu d'image de synthèse sur un quadcore sera plus lent avec 100threads qu'avec 6    
 
ça se voit que tu ne sais absolument pas de quoi tu parles    
 
sinon en anglais c'est process et en français processus
 
et thread pour "fil d'execution"
 
il ne faut pas utiliser processus car un "fil d'execution" ce n'est pas la même chose.

On m'a toujours dit de faire nombre de cores + 1. Et c'est ce qu'on trouve dans les wikis en général.

Donc -j7 ici.

Tout à fait. Compiler avec 6 jobs n'est pas optimal mais laisse plus de ressource pour toi faire autre chose à coté
En réalité il faut faire des essais, le +1 n'est pas forcément optimal non plus.
Personnellement +1 sur dualcore et +2 sur quadcore. mais ça dépend de l'application et d'autres paramètres comme l'utilisation mémoire qui peut exploser sur la compilation de certains logiciels.
 

Je te met au défi de faire un rendu plus rapide avec 100threads au lieu de 6 sur un quadcore ou encore de compiler plus vite avec 100 jobs qu'avec 6.
 
J'en rigole d'avance.    
 
Tu as fait une thèse en connerie je pense.
 
 
La réalité c'est que tes 100jobs et 100threads seront contre-productif à coté de 5-6(qui seront plus efficaces que 4 car 4 n'arriveront pas à occuper chaque cœur à 100%) sur un quadcore.
 
 
C'est bien d'être plus formé que moi mais apparemment ça ne t'aide pas à ne pas débiter des âneries.
 
Quand à dire qu'un thread c'est un processus, il va falloir retourner en cours.

Pour moi, je préfère le -j6, ce qui me permet de continuer à utiliser mon pc sans être plus chagriné que cela par la compilation.
Mais, ça me tente bien de tester un FX à l'occasion (avec -j8), bien que je pense que ça risque de ne pas être une révolution, comme vu ici (aussi posté là).
 
edit : pas évident de poster en préparant dans la cuisine un petit apéro sympa pour bien commencer le réveillon !
 
edit2 :  
ClioWilliams, en effet, mais c'est une affirmation qui date un peu (je faisais comme cela avec mon Athlon64).
master71 : pas de souci, c'était juste pour préciser.
 
Sinon, bon réveillon à tous .
 
 

hmm c'est vrai que le gain par rapport au ph2 6cores ne me donnerait pas envie de sauter le pas...un petit 18%

Y'a la 4670 K aux même prix que la 3570 K.