Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
995 connectés 

 



 Mot :   Pseudo :  
 
 Page :   1  2
Page Suivante
Auteur Sujet :

[HFR] Dossier : Impact des compilateurs sur les architectures CPU x86/x64

n°8230798
Gigathlon
Quad-neurones natif
Posté le 29-02-2012 à 12:49:27  profilanswer
0Votes positifs
 

Reprise du message précédent :

hyksos_sowo a écrit :

Il y a une forte réticence à enlever le support sur le vieux hardware....


T'as aussi le droit de compiler pour plusieurs cibles, que ça soit de façon automatique ou manuelle.
 
Ca se faisait déjà il y a 20 ans, notamment à cause de la segmentation qui imposait d'avoir du code x86/x87.
 
A une autre époque ça aurait pu être problématique de gonfler l'exe, mais de nos jours c'est dérisoire, surtout si ça apporte un gain de perfs (sachant que pour les cas où la perf a assez peu d'importance, C#.NET est très clairement à privilégier, pour la propreté du code)

mood
Publicité
Posté le 29-02-2012 à 12:49:27  profilanswer
 

n°8230960
bigbigsock​et
Posté le 29-02-2012 à 15:21:38  profilanswer
0Votes positifs
 

J'aurais bien aimé avoir des informations sur l'impact du mode profiling pour la compilation: on compile avec l'option profiling, on execute le programme de test, puis on recompile avec les informations obtenues.
J'avais fait des tests de performances (il y a 2 ou 3 ans) entre visual studio et le compilateur intel, et pour mes tests, le compilateur intel n'etait interessant que si l'option de profiling était activée, autrement le code obtenu etait inutilement trop gros ou pas assez optimisé dans les parties du code frequemment utilisées.
De plus, un developpeur qui veut avoir les meilleurs performances utilisera ce mode là. Si son jeu de test pour le profiling est bien choisi, il peut améliorer les performances de facon importante. Il est donc interessant de voir le comportement du compilateur avec des informations sur le comportement du programme.

n°8230972
ledesillus​ionniste
Posté le 29-02-2012 à 15:36:28  profilanswer
0Votes positifs
 
n°8230976
ndrago
Posté le 29-02-2012 à 15:37:49  profilanswer
0Votes positifs
 

Pour ce rendre facilement compte de l'impact d'icc il suffit d'essayer différentes variantes de linux sur un acer aspire one avec sud "stock" (il est à chier cela dit en passant) dont meego, distrib linux compilée pour atom.
 
Elle est compilée entièrement avec ICC, là ou même sous gentoo en changeant de compilateur on ne peut le faire pour l'intégralité du système ...
 
Forcément sur ce netbook "moyen" cette version de linux est bluffante, surtout si vous avez essayé d'autres distrib ... (temps de boot moyen 7 secondes, alors que le sud d'origine est je le rappelle pourri ...)
Bon après c'est meego donc bon y a pas grand chose mais en tout cas c'est je pense une des meilleures démonstration pratique du compilateur ICC  pour qlq chose de "palpable" par l'utilisateur (car franchement ce netbook, avec quoi que ce soit d'autre dessus, vous le transformez en freesbee au bout d'une heure de lutte/attente d'utilisation :)

n°8230977
ndrago
Posté le 29-02-2012 à 15:38:45  profilanswer
0Votes positifs
 

excusez, sud -> ssd, putain d'assistant de frappe :)

n°8231015
hyksos_sow​o
Posté le 29-02-2012 à 16:24:13  profilanswer
0Votes positifs
 

Gigathlon a écrit :

hyksos_sowo a écrit :

Il y a une forte réticence à enlever le support sur le vieux hardware....


T'as aussi le droit de compiler pour plusieurs cibles, que ça soit de façon automatique ou manuelle.
 
Ca se faisait déjà il y a 20 ans, notamment à cause de la segmentation qui imposait d'avoir du code x86/x87.
 
A une autre époque ça aurait pu être problématique de gonfler l'exe, mais de nos jours c'est dérisoire, surtout si ça apporte un gain de perfs (sachant que pour les cas où la perf a assez peu d'importance, C#.NET est très clairement à privilégier, pour la propreté du code)


 
C'est non problématique lorsque tu ne te préoccupe pas du load time ... pour nous le load time est primordiale. De plus, doubler ou tripler la grosseur de notre package est tout a fait hors de question, non pas par manque d'espace disque, mais car nous déployons par internet.
 
En plus que Visual studio ne supporte pas nativement le multi target en C++ et rendu la le plus simple serait de compiler 3/4 fois la même chose et avoir un package par target, un x87, un SSE, un SSE2, un SSE3, un AVX etc... mais ça aussi c'est inacceptable.

n°8231033
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 29-02-2012 à 16:44:18  profilanswer
0Votes positifs
 

camarade_tux a écrit :

Vous avez essayé mingw-w64 ? En mode i686-w64-mingw32 ou x86_64-w64-mingw32 (je sais, les noms sont à chier ; mingw-w64 fait 32bit et 64bit). Ça inclut une énorme amélioration au niveau des fonctions de maths et globalement, c'est un monde avec mingw.org.
 
Y'a des binaires précompilées sur mingw-w64.sf.net


Comme promis j'ai donc essayé la version -w64, en utilisant toujours les packages TDM ici : http://tdm-gcc.tdragon.net/download
 
Niveau compatibilité effectivement je confirme qu'il y a quelques petits problèmes, le test hmmer ne fonctionne pas par exemple. J'ai testé sur FX-8150 avec le profil bdver1.  
 
J'ai bien quelques petits gains, mais on est loin d'un monde de différence. Peut etre parce que les builds TDM classiques que j'avais utilisées dans le test étaient déjà plus optimisées (elles sont beaucoup plus à jour que les mingw traditionnelles qui sont très en retard, nottament sur la version de GCC). J'ai noté un gain assez variable, qui va jusque 2.8% sous h264ref, sinon on est en moyenne autour du pourcent.

n°8231072
ledesillus​ionniste
Posté le 29-02-2012 à 17:37:26  profilanswer
0Votes positifs
 

reste la voix royale ===> reste la voie royale


---------------
Le dépannage de votre pc sur Nivelles Gosselies Fleurus Genappe Les-Bons-Villers Liber chies http://www.monpcfonctionne.com
n°8231186
Invite_Sur​prise
Racaille de Shanghaï
Posté le 29-02-2012 à 19:33:15  profilanswer
0Votes positifs
 

Super article C_Wiz  :jap:

n°8231371
roukinette
Couple de geeks en RP
Posté le 29-02-2012 à 22:35:06  profilanswer
0Votes positifs
 

BlueScreenJunky a écrit :

J'ai pas tout compris ni tout lu dans le détail, mais je pense que les résultats n'indiquent pas forcément un gain de performance "partisan" avec les optimisations du compilateur Intel : Dans la mesure où il est le compilateur le plus performant avec les processeurs AMD, rien ne prouve qu'il aurait été possible de faire mieux, même si les ingénieurs d'Inter avaient bossé spécifiquement pour optimiser les perfs sur AMD.


justement, c'est bien de penser mais penser sans posséder toutes les données c'est comme calculer (1+x) en déduire que le résultat est 3
alors que hélas la valeur de x était en fait 4 ...
 
en clair, tes conclusions sont erronées par manque d'information !

mood
Publicité
Posté le 29-02-2012 à 22:35:06  profilanswer
 

n°8231428
camarade_t​ux
Posté le 01-03-2012 à 00:00:53  profilanswer
0Votes positifs
 

C_Wiz a écrit :

camarade_tux a écrit :

Vous avez essayé mingw-w64 ? En mode i686-w64-mingw32 ou x86_64-w64-mingw32 (je sais, les noms sont à chier ; mingw-w64 fait 32bit et 64bit). Ça inclut une énorme amélioration au niveau des fonctions de maths et globalement, c'est un monde avec mingw.org.
 
Y'a des binaires précompilées sur mingw-w64.sf.net


Comme promis j'ai donc essayé la version -w64, en utilisant toujours les packages TDM ici : http://tdm-gcc.tdragon.net/download
 
Niveau compatibilité effectivement je confirme qu'il y a quelques petits problèmes, le test hmmer ne fonctionne pas par exemple. J'ai testé sur FX-8150 avec le profil bdver1.  
 
J'ai bien quelques petits gains, mais on est loin d'un monde de différence. Peut etre parce que les builds TDM classiques que j'avais utilisées dans le test étaient déjà plus optimisées (elles sont beaucoup plus à jour que les mingw traditionnelles qui sont très en retard, nottament sur la version de GCC). J'ai noté un gain assez variable, qui va jusque 2.8% sous h264ref, sinon on est en moyenne autour du pourcent.


 
Super. Merci beaucoup. =)  
 
Je note pour la compat et je vais taper sur quelqu'un jusqu'à ce qu'il corrige. ;p  
 
Pour la différence de perf, la plus grosse différence viendrait sans doute des fonctions de maths et donc ça va changer en fonction du bench et de l'utilisation qu'il fait de ces fonctions. Il me semble que mingw.org (la version truc-*pc*-bidule) ne peut pas du tout utiliser la nouvelle lib de maths (truc-*w64*-bidule) (je crois que c'est déterminé par "pc" vs. "w64", ce qui est choisissable à la compile de gcc lui-même).
 
Mais je viens de penser à un truc assez particulier : GCC peut évaluer certains calculs à la compilation, ou simplifier des expressions. Souvent ça dépend de libs externes genre GMP, MPFR, Cloog, PPL (des polyhédrons pour optimiser du code, il fallait y penser :p )... et c'est activable ou pas à la compilation de GCC justemen. Ça doit pouvoir faire varier pas mal.
 
PS : si les temps de build ne sont pas négligeables, est-ce qu'il serait possible de les avoir (pour le futur). (par contre, là, pour le coup, un proco dont la fréquence diminue peut être _incroyablement_ plus lent comme je l'ai découvert par hasard. ='( [/mylife])

n°8231529
fofo9012
Posté le 01-03-2012 à 08:35:48  profilanswer
0Votes positifs
 

ragondin a écrit :

Quel compilateur compile le compilateur qui compilera les programmes en question ?
Cela a t-il un impact car un compilateur compilé avec certaines optims compilera t-il mieux certains programmes ?
OK je suis déhors...


C'est un vil troll, mais bon :
Le langage dansd lequel est codé le compilateur n'influence pas le code compilé. On pourrait imaginé un compilateur en basic, ou javascript : la compilation serait très lente mais le code compilé a priori le même.
 
Un compilateur ne fait que "traduire" un langage en un autre: enfin en vrai il commence par analyser/reconnaitre les mots (mots clés, variables, constantes, fonctions...), puis les instructions, vérifier que les instructions sont grammaticalement correctes (genre si une variable et attendu, on doit pas avoir un mot clé), et enfin procède la compilation.
Un compilateur peut très bien produire un code illisible sur le proc en cours. L'exemple typique et le dev sur des architectures pas performante : Tu compiles ton programme ARM sur ton quad Core i7, tu copies le binaire sur ton pda sous arm et tu tests. Compiler directement sur le PDA faut déjà être motivé...

n°8231616
brokensoul
Posté le 01-03-2012 à 10:41:49  profilanswer
0Votes positifs
 

Article excellent, énorme boulot, merci beaucoup ! ça va rester la référence pendant plusieurs années, tant les discussions sur les optimisations et mérites respectifs des compilateurs ont souvent besoin d'être étayées, super. Quelques tests dans le même genre sont souvent réalisés sur phoronix (sous linux, avec llvm et gcc principalement), mais bien moins complets.

n°8232374
DayWalker ​II
Marchez dans ma lumière !
Posté le 01-03-2012 à 23:12:55  profilanswer
0Votes positifs
 

Voilà un dossier "qu'il est bien torché"... non franchement, super ! Ce dossier me rappelle à moi aussi les heures de gloires de x86-secret (quoique son successeur est pas mal aussi ;) ). Très intéressant, et technique aussi. Il faudrait que je le relise !

n°8232698
bjone
Insert booze to continue
Posté le 02-03-2012 à 12:49:44  profilanswer
0Votes positifs
 

ragondin a écrit :

Quel compilateur compile le compilateur qui compilera les programmes en question ?
Cela a t-il un impact car un compilateur compilé avec certaines optims compilera t-il mieux certains programmes ?
OK je suis déhors...


 
Nope ce sont les algos d'optimisations du compilateur qui joue, pas comment il a été lui-même compilé. (par contre plus il a été compilé bien ciblé pour la machine de compilation, plus la compilation/optimisation est rapide)

n°8233540
letreb
Posté le 03-03-2012 à 12:21:02  profilanswer
0Votes positifs
 

est-ce que la mkl (math kernel library de intel) est utilisée dans les benchmark ? Si oui ca peut faire une tres grosse difference si seul icc peut les utiliser. Elle est tres optimisée (assembleur je crois) et peut faire gagner énormément.

n°8233740
sagittaire
Posté le 03-03-2012 à 15:42:02  profilanswer
0Votes positifs
 

Euh je suis le developpement du codec x264 pratiquement depuis le début. Il me semble que si on veux bénéficier des instructions SSE, SSE2, SSE3, SSE4, SSE5 ... il faut que l'algo est un codage adéquat.
 
En somme s'il n'y a pas d'optimisations du code pour les instructions SSE2 et bien l'executable n'utilisera pas correctement les instructions SSE2 du CPU même si celui ci en dispose et le compilateur n'y changera rien. Dans ces conditions je ne vois pas a quoi ça sert de comparer des compilations optimisées manuellement pour telles ou telles intructions si le code n'a pas été écrit pour en bénéficier. C'est visiblement le cas pour plusieurs algo dans votre comparatif.
 
De plus pour bien connaitre le x264, seules certaines parties du code peuvent aussi reellement beneficier de telles ou telles intructions CPU. Par exemple DCT, SSE, SAD, SADT, RDO ... etc ... ne necessiteront pas toute d'être optimisées pour un codage SSE5 car cette intsruction n'apportera pas de gain mesurable par rapport a une optimisation SSE2 ou SSE3. Il sera donc facile de mettre en avant telle ou telle optimisation avec le x264 en fonction des profils d'encodages choisi. Par exemple un bitrate très fort entrainera un calcul sur le CABAC très lourd qui mettra lui-même en évidence les intructions utilisées pour le CABAC. De même si vous voulez mettre en évidence les instructions du nouveau CPU AMD, il vous faudra utiliser un profil x264 particulier pour avoir un gain visible.
 
Pour finir le code peut encore être optimisé pour chaque classe de CPU et ce même s'ils possèdent les mêmes instructions. Ainsi un code pourra être optimisé particulèrement pour Intel et pas pour AMD. Et là encore la compilation ne pourra rien y changer. A mon avis le code pourra aussi être lui-même optimisé pour s'adapter aux différents compilateurs.
 
 
Bon après je ne suis pas un spécialiste et je me trompe peut-être ... ???

n°8234009
sagittaire
Posté le 03-03-2012 à 20:17:17  profilanswer
0Votes positifs
 

Et si vous voulez un exemple pour le x264:
http://x264.nl/x264/changelog.txt
 
commit 2f0384dcd68bb85f98fb566b70b863b40082c83e r2102
Author: Loren Merritt <pengvado@akuvian.org>
Date:   Mon Oct 10 05:42:36 2011 +0000
 
    SSSE3/SSE4/AVX 9-way fully merged i8x8 analysis (sa8d_x9)
    x86_64 only for now, due to register requirements (like sa8d_x3).
     
    i8x8 analysis cycles (per partition):
     penryn sandybridge bulldozer
    616->600  482->374  418->356  preset=faster
    892->632  725->387  598->373  preset=medium
    948->650  789->409  673->383  preset=slower
 
commit 46d1f3ab24e8aead7ccb3f89a382e7c92721ba96 r2101
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Fri Sep 30 19:09:19 2011 -0700
 
    SSSE3/SSE4/AVX 9-way fully merged i8x8 analysis (sad_x9)
    ~3 times faster than current analysis, plus (like intra_sad_x9_4x4) analyzes all modes without shortcuts.
 
Avant cette revision les fonctions d'analyses des blocs i8x8 ne pouvaient pas utilser les instructions SSSE3/SSE4/AVX (certainement optimisées MMX/SSE/SSE2 précedement). Cette révision à permis un calcul trois fois plus rapide pour la fonction intra_sad_x9_4x4 dans le code x264.

n°8235373
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 05-03-2012 à 02:00:19  profilanswer
0Votes positifs
 

letreb a écrit :

est-ce que la mkl (math kernel library de intel) est utilisée dans les benchmark ? Si oui ca peut faire une tres grosse difference si seul icc peut les utiliser. Elle est tres optimisée (assembleur je crois) et peut faire gagner énormément.

Non elle n'est pas utilisée, nous l'avons volontairement laissée de côté pour éviter d'accentuer les écarts.

n°8235516
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 05-03-2012 à 10:50:20  profilanswer
0Votes positifs
 

sagittaire a écrit :

Euh je suis le developpement du codec x264 pratiquement depuis le début. Il me semble que si on veux bénéficier des instructions SSE, SSE2, SSE3, SSE4, SSE5 ... il faut que l'algo est un codage adéquat.


sagittaire a écrit :

Avant cette revision les fonctions d'analyses des blocs i8x8 ne pouvaient pas utilser les instructions SSSE3/SSE4/AVX (certainement optimisées MMX/SSE/SSE2 précedement). Cette révision à permis un calcul trois fois plus rapide pour la fonction intra_sad_x9_4x4 dans le code x264.


Comme nous l'avons expliqué dans l'article, x264 est un cas à part (que nous avons d'ailleurs traité à part) dans le sens où il dispose d'un dispatcher interne et de codepath assembleur pour différentes architectures. L'exemple que vous donnez est issu de cela, il s'agit d'une fonction optimisée en assembleur. Tout le code de x264 n'est cependant pas dispatché.  
 
On peut également compiler x264 en desactivant ces fonctions assembleur. Un code générique en C est alors utilisé.  
 
Nous avons testé dès lors deux choses. D'une, est-ce que la génération de code SSE/AVX (pour le code qui n'est pas écrit en assembleur) peut avoir un impact sur les performances (la réponse étant oui, de légers gains) ? La seconde consistait à regarder, pour la version sans assembleur, ce qu'était capable de produire GCC comme optimisations via ses algorithmes de vectorisation automatique (dans ce cas, une baisse de performance par rapport au code générique).

n°8242490
lapin
Posté le 12-03-2012 à 13:57:47  profilanswer
0Votes positifs
 

ça me rappel l"époque de x86 secret, ça fait du bien!!!

n°8245321
gliterr
Posté le 15-03-2012 à 10:33:48  profilanswer
0Votes positifs
 

Il fait pqrler de lui cet article:
http://www.realworldtech.com/forum [...] 3&roomid=2

n°8247468
pascal16
Posté le 17-03-2012 à 11:52:22  profilanswer
1Votes positifs
 

L'article donne une idée de ce qu'est l'optimisation sans tomber dans le trop c'est trop. On sent bien qui si on rajoute bientôt la compilation AMR en plus, et les processeurs à dizaines de cores, ça va être sympa.
 
Sur ma calculette (du genre 8bits à 1khz), j'avais une boucle de suite récurrente qui n'allait pas vite.
J'ai commencé par calculer 2 termes de la suite dans la même boucle et avancer de  2 pas-> ça accéléré pas mal. Je suis passé à 3 termes, c'était encore plus rapide. Je suis passé à 4 et là, boom, c'était très lent. J'ai compris que je venais de dépasser le nombre de de variables contenues dans le cache le plus profond du processeur.
 
Quand un programme tourne seul, c'est une chose, mais quand il en en multitâche, c'est plus compliqué (les gros lag des accès disque par exemple).
 
Pour optimiser un programme, les instructions pour charger des variables en cache sont apparues, mais comme pour un rien, tout le monde mettait tout en cache, ça n'accélérait plus rien.  
 
Donc une recette qui marche ne marche n'est pas forcément répétable à l'infini.

n°8250575
Guillaume7​8Fr
Posté le 20-03-2012 à 10:43:42  profilanswer
0Votes positifs
 

Bonjour,
 
Cet article est très intéressant, d'autant plus que le sujet n'est pas traité si couramment... ;)
 
Par contre, une petite question me taraude. MinGW montre de grosses faiblesses côté optimisation en C++, ce qui n'est pas très logique... Voici donc la question :
Avez-vous recompilé TDM-GCC pour chacune des architectures?
 
Je pense que ça pourrait avoir une certaine importance étant donné que les binaires fournis pour TDM-GCC, le sont pour la seule architecture i686, soit pentium pro (pas de SSE, SSE2, ...).
 
Quoiqu'il en soit je trouve que cet article est une excellente initiative!

n°8250620
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 20-03-2012 à 11:37:52  profilanswer
0Votes positifs
 

Guillaume78Fr a écrit :

Avez-vous recompilé TDM-GCC pour chacune des architectures?
 
Je pense que ça pourrait avoir une certaine importance étant donné que les binaires fournis pour TDM-GCC, le sont pour la seule architecture i686, soit pentium pro (pas de SSE, SSE2, ...).


La seule chose que recompiler TDM-GCC changerait, c'est le temps de compilation. Le code généré resterait strictement identique. Donc non, cela ne présentait pas d'intérêt de le faire.

n°8250653
Guillaume7​8Fr
Posté le 20-03-2012 à 12:10:56  profilanswer
0Votes positifs
 

C_Wiz a écrit :

Guillaume78Fr a écrit :

Avez-vous recompilé TDM-GCC pour chacune des architectures?
 
Je pense que ça pourrait avoir une certaine importance étant donné que les binaires fournis pour TDM-GCC, le sont pour la seule architecture i686, soit pentium pro (pas de SSE, SSE2, ...).


La seule chose que recompiler TDM-GCC changerait, c'est le temps de compilation. Le code généré resterait strictement identique. Donc non, cela ne présentait pas d'intérêt de le faire.


 
OK, merci pour cette réponse (rapide qui plus est ;) ).

n°8251163
ipsenexion
Posté le 20-03-2012 à 19:01:36  profilanswer
0Votes positifs
 

pas mal l'article. Est-ce que les testes sont fait en 32bits? les ABI windows/linux changent pas mal avec x64 et x87 n'est plus utilisé directement.

n°8383679
djip007
Posté le 16-07-2012 à 17:20:27  profilanswer
0Votes positifs
 

Il existe un autre compilateur que les 3 grands: PGI capable d'optimisaton poussé...
http://www.pgroup.com/
  y a t'il une raison de ne pas l'avoir inclu? Est-t'il possible de l'inclure?

n°9243517
nikau7
Posté le 19-08-2014 à 18:42:26  profilanswer
0Votes positifs
 

Article très certainement commandé et payé par intel. Les tests sont bidons. Finalement le message c'est quoi. Récemment Intel a eu des problème quant au fait qu'ils optimisé moins bien les processeur AMD. Cour dur pour leur réputation il fallait réagir. Cet article fait parti de la réaction. Quel est la conclusion ? Intel c'est le meilleure, et Intel c'est même plus performant avec AMD qu'avec leurs propres processeurs, alors qu'ils optimisent moins pour les procs AMD, ils l'ont avoués, reconnu. Comment c'est possible ? Ça c'est ce que l'on appelle de la propagande, c'est de la pub déguisée en information.

n°9243684
xixou2
Posté le 19-08-2014 à 20:41:36  profilanswer
0Votes positifs
 

L'article ne dis pas le choix à faire sur le compilateur Intel ou Microsoft.
Premier commentaire, et dernier ?
 


---------------
http://boincstats.com/signature/-1/user/839477/sig.png
n°9243741
master71
ça manque de place.
Posté le 19-08-2014 à 21:25:59  profilanswer
0Votes positifs
 

déterrage de première par un adepte du complot...
 
et en quoi ces tests seraient bidon? argumente un peu...


---------------
un jour, moi aussi, je serais grand...
n°9243754
Marc
Super Administrateur
Chasseur de joce & sly
Posté le 19-08-2014 à 21:46:48  profilanswer
0Votes positifs
 

nikau7 a écrit :

Article très certainement commandé et payé par intel. Les tests sont bidons. Finalement le message c'est quoi. Récemment Intel a eu des problème quant au fait qu'ils optimisé moins bien les processeur AMD. Cour dur pour leur réputation il fallait réagir. Cet article fait parti de la réaction. Quel est la conclusion ? Intel c'est le meilleure, et Intel c'est même plus performant avec AMD qu'avec leurs propres processeurs, alors qu'ils optimisent moins pour les procs AMD, ils l'ont avoués, reconnu. Comment c'est possible ? Ça c'est ce que l'on appelle de la propagande, c'est de la pub déguisée en information.

:sarcastic:

n°9243906
xixou2
Posté le 20-08-2014 à 04:31:41  profilanswer
0Votes positifs
 

master71 a écrit :

déterrage de première par un adepte du complot...
 
et en quoi ces tests seraient bidon? argumente un peu...


 
Tu fais référence à ses commentaires là bas ?
 
http://www.leparisien.fr/reactions [...] 932323.php


---------------
http://boincstats.com/signature/-1/user/839477/sig.png
n°9243934
Neji Hyuga
Modérateur
:grut:
Posté le 20-08-2014 à 08:38:28  profilanswer
0Votes positifs
 
n°9245662
xixou2
Posté le 21-08-2014 à 17:11:59  profilanswer
0Votes positifs
 

ça veut dire quoi ?


---------------
http://boincstats.com/signature/-1/user/839477/sig.png
n°10363618
j_c_p
Linux user
Posté le 03-05-2018 à 21:41:05  profilanswer
0Votes positifs
 

Un très bon article dont je me demandais si une mise à jour est prévue, un de ces quatre matins ;) avec les derniers processeurs Intel et AMD.

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
[HFR] Actu : Asus HD 7950 DirectCU II : défaut, attention !Recherche Benchmark CPU et uniquement CPU Gratuit
[HFR] Actu : Z7K500 : 500 Go et 7200 tpm en 7mm chez Hitachi[HFR] Actu : Un nouveau ventirad Noctua, le NH-L12
[HFR] Actu : Pilotes Nvidia GeForce 295.73 WHQL[HFR] Actu : Cyclos aide AMD à réduire la consommation
Un problème de ventilation CPU...Ventilateur du CPU ne fonctionne plus.
[HFR] Actu : AMD Catalyst 12.2 Pre-certifiés[HFR] Actu : Trois nouveaux AMD FX 95W
Plus de sujets relatifs à : [HFR] Dossier : Impact des compilateurs sur les architectures CPU x86/x64


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR