Non, la difference de prixn’en vaut vraiment pas la peine, a part si on veut peter des records d’overclock :ane:
Serieusement, meme Photoshop n’est meme pas quad-core optimized !
Les quad-core, sont vraiment trop peu utilise a mon gout. Ils sont un tres bon potentiel, certes, mais tant et aussi longtemps que la programmation ne suivra pas, ils resteront sous utilises.
J’aime mieux un dual-core qui est de plus en plus utilise qu’un quad-core qui stagne dans l’inutilite.
Il y a moins de différences (au point de vue archi) entre le Q6600 et le Q9550 qu’entre un P4 (qui n’existe pas à ma connaissance en version Quad Core…) et un Core 2 Duo. :jap:
Les quad-core, sont vraiment trop peu utilise a mon gout. Ils sont un tres bon potentiel, certes, mais tant et aussi longtemps que la programmation ne suivra pas, ils resteront sous utilises.
J’aime mieux un dual-core qui est de plus en plus utilise qu’un quad-core qui stagne dans l’inutilite.
[/quote]
Oui, et alors, certains programmes (rendu 3d et encodage vidéo en tête) tirent parti des 4 cores. (sans compter le multitaches lourd.)
2 et 3) « Qui stagne dans l’inutilité », si tu le dis …
(et c’est reparti dans le « les quad core c’est de la daube » :riva: )
Tu as essayé de faire le même encodage sur un Core 2 Duo et sur un Quad (de même fréquence évidemment) pour voir si tu gagnais du temps? (Bien entendu avec un programme qui tire parti du multicore, pas avec un truc du genre itunes qui reste monothread)
Donc un E8400 suffit amplement pour les jeux et ceux à venir si j’ai bien comprit ?
ouais largement 
En même temps, quand on peut se payer une licence Photoshop on peut bien se payer un CPU quad-core :ane:
(PS: photoshop en lui-même n’a pas besoin d’etre optimisé quad… certains filtres par contre c’est une autre affaire et là on en trouve qui exploitent le quad)
Les P4 existent bel et bien en quad-core.
C’etait les Pentium D. Deux P4 sur un die. Seulement l’appellation change.
Justement, faut les trouver !!! Disons que c’est pas la gamme de software des plus nombreux !! Par contre, pour le multi-threading, c’est vrai, je l’accorde. C’est sa vrai « reelle » utilite, puisque 90 % des utilisateurs de quad-core CPUs ne savent pas comment l’utilise a part faire rouler plusierus applications ( dans les cas ou seul Windows est le programme quad-core optimized, ce qui n’est pas rare chez les utilisateurs de ce type de CPU ). Si on sait que l’on va travailler sur de tel applications a longeur de journee ou qu’on a un reel interet envers ce genre d’appli, un quad est plus approprie, bien sur. Mais si ce n’est pas la princiaple utilisation du PC, j’irai pas conseiller un CPU qui vaut 150 $ de plus pour le fun et qui n’apportera strictement rien ou presque et meme pas un « meilleur futur »…
Mon opinion est fait et je crois qu’elle est tres juste et basee sur une logique. Les quad, c’est pas de la daube, I’ve never said that. Comme je l’ai dit, ils ont un tres bon potentiel dans le futur. Pourquoi seulement dans le futur ? Car la programmation n’a pas encore suivit, ce qui est tres dommage. J’envie le jour ou 100 % de nos applications seront dual-core voir quad-core optimized. Mais c’est certes pas demain et je crois meme que l’on verra une generation de CPU passer ! Je me souviens d’avoir lu une news qui portait sur le sujet. Intel avait un rapport dans ce projet de nouveaux codes de programmations pour ameliorer le support des multi-core CPUs. Et je me rappelle egalement que le projet se mettrait a terme vers 2010, voir 2011. Donc ce ne serait que vers 2010 que l’on verrait un reel gain en programmation pour optimiser toute application a etre multi-core ready.
Et pour l’instant et dans le futur, les dual-core sont loin d’etre mort et viveront aussi longtemps qu’un quad-core. Je ne dis pas cela sur la defensive puisque j’ai un dual-core, non. Mais logiquement parlant, les dual-core auront la meme duree de vie que les quad-core. C’est pas parce que un a deux cores de plus qu’il suivra la technologie plus longtemps ou sera moins desuet. Tant que les programmes n’exploiteront pas a 100 % l’archiecture ( qui est la meme, dual ou quad ) et qu’ils ne tiront pas tout le profit des CPU et qu’en plus qu’ils satisferont les besoins de l’utilisateur, ils ne seront pas desuets. Donc dire qu’un quad a tendance a etre futureproof, presentement, je le prend avec un grain de sel et je n’en suis pas convaincu.
Oui, j’ai essaye. Le gain est assez bien. Certes encore mieux si l’appli est quad-core optimized. Mais si on sort de cette gamme d’appli, le quad-core perd vraiment toute credibilite ou interet, a moins encore une fois qu’on aime faire rouler plusieurs applications en meme temps, ce qui demeure, je le repete, l’utilisation fort d’un quad-core CPU puisque ce n’est que sa reellle utilite.
EDIT : Desole, jetais dans la lune carrement pur le P4 ! lol !
Edité le 24/10/2008 à 21:20
Ghost > Pour vous un E8400 est suffisant pour faire tourner tous les jeux d’aujourd’hui et ceux à venir ou vaut mieux passer sur un E8600 ?
C’est pas une difference de 300 Mhz qui va faire quelque chose … loin de la.
Donc entre un E8400 et un Q9550 si l’utilisation est pour le jeux autant prendre le E8400 c’est bien sa ?
je répéte ce que j’ai dis plus haut : OUI
Meme pout gta 4 , far cry 2 il n y aura pas de souci ?
Aucun soucis, dual core à 3Ghz faut pas l’oublier 
, loin d’être dépasser pour les jeux^^ .
Ce topic va finir par me faire changer d’avis…je suis un peu proQuad. Moi je pensais vraiment que 2 coeurs de plus pourraient faire une différence dans le futur. Si il faut attendre 2011 pour voir les jeux être optimisés multicoeurs ça fait du chemin c sur.
Je ne comprends pas comment les programmeurs bloquent pour faire tourner les 2 coeurs en plus. L’architecture core est optimisée alors pourquoi arriver à programmer sur 2 et pas sur 4 coeurs???
De plus il existe déjà un jeux optimisé multi (SupremeCommander) ; qui est donc le programmeur…un géni. Pourquoi personne ne suit cette prog.
J’ai même lu des tests de Crysis témoignant d’une préférence pour les Quads (bench à l’appui)… bon ct les QX et le Q9550 qui étaient en tête.
Oui, et?
2 Pentium 4 sur le même die ça donne un Pentium 4 Dual Core …
Je ne vois pas où tu as entendu parler de P4 Quad.
De toute evidence les mathématiques et toi c’est pas l’amour.
Petit rappel élémentaire:
1+1 = 2
Pentum4 = 1
Pentium D = Pentium4+Pentium4 = 1+1 = 2
Quad = 4, il t’en manque toujours 2 pour faire le compte.
:ange:
Par contre un Core 2 Quad aujourd’hui c’est bel et bien 2 core 2 Duo sur le meme socket (et non pas le meme Die, vu que ce sont 2 Die collés ensembles)
=> 2+2 = 4
Edité le 24/10/2008 à 08:46
Même pas besoin d’un E8400 pour ça, le E8400 c’est plus pour avoir de la marge avec les jeux à venir
Il faut aussi surtout voir que dans un jeux c’est extrêmes difficile de tout paralléliser pour que ce soit vraiment optimum sur un Quad.
L’élément le plus facile à paralléliser l’est déjà à très forte dose, c’est le moteur graphique et nos GPU sont des monstres de calcul parallèle. Et il se trouve que ce moteur graphique c’est aussi l’élément le plus gourmand quand il s’agit de faire le rendu d’un jeu. Apres il reste quoi?
Alimenter le GPU en données à traiter
Le moteur physique
L’intelligence artificielle
Les routines de jeux
Etc.
Pour le premier on sait que c’est possible et les derniers moteurs exploitent déjà une forte de dose de parallélisme.
Pour l’IA et les routines de jeux ça dépend du type de jeu. Certains en ont plus besoin que d’autre, Supreme Commander c’est le genre d’exception à la règle.
Reste à alimenter le GPU en données, et c’est là que le plus gros du boulot reste à faire. C’est très difficile de paralléliser tout ça parce que les données sont interdépendante. Donc quand un cur travaille sur une donnée il est très probable qu’un autre cur ai besoin de cette même données pour en calculer une autre etc, au final on perd plus de temps en échange entre les curs qu’à tout faire faire par le même.
C’est toute la façon de voir le processus qu’il faut changer, pour peu que ce soit possible.
Faut pas non plus oublier que les développeurs connaissent la chanson depuis quelques temps. Ils travaillent quasiment tous pour faire des jeux Xbox360 et PS3. La 360 possède un CPU tri-core, le Cell c’est un peu spécial mais on peut dire qu’on est en environnement « à fort parallélisme ». Je pense que c’est surtout grâce à cela qu’on commence à avoir des jeux qui exploitent des bi voir des quadri-curs et non pas grâce à la démocratisation des quadri dans nos PC.
Je ne pense pas que ce soit réellement si difficile, notamment pour le moteur physique et l’IA, les 2 choses qui prennent le plus de temps CPU.
Ca dépend, il existe des techniques pour ça, notamment au niveau de la gestion des caches. Je n’ai pas dit que c’était facile, mais c’est comme tout, ça s’apprend (au boulot on ne fait que ça, et sur des algos qui au départ ne semblaient pas facilement parallélisable car il y avait beaucoup d’interdépendances justement, mais maintenant on arrive à les faire tourner sur 8 coeurs)
Edité le 24/10/2008 à 10:28
C’est ce que j’ai dit. Le moteur physique on sait que c’est possible à haute dose (notamment depuis qu’Ageia a lancé son pavé). Pour l’IA, encore faudrait-ils qu’ils développent de vrais IA, parce que pour l’instant c’est très pauvre. Et les jeux en ayant le plus « besoin » sont les STR qui utilisent le pathfinding qui effectivement est très gourmand si le nombre d’unités est très important. Et qui peut se paralléliser assez facilement (tout est relatif bien sur)
Oui mais est-ce que vos algo font du « temps réel » (terme à prendre avec des pincettes en l’occurrence)?
Si tu perds x cycles pour la resynchro des données entre thread ou processus cela ne va pas forcement se voir sur le temps de clacul final.
Là si un traitement en bloque un autre ça peut avoir un impact sur le rendu final qui est censé être instantané: le joueur clic pour tirer, il doit voir la roquette partir tout de suite et les dégâts qui en découleront.
La gestion des caches ne permet pas tout car pour l’instant on ne sait pas faire travailler 2 (ou plus) curs sur la même donné qui est en cache. La donnée est forcément utilisée par un cur, puis mise à jour dans le cache. Un autre cur pourrait tres bien lire cette même donnée mais qui entre temps aura été modifiée par le premier cur, il travaille donc sur une donnée erronée.
C’est de l’encodage vidéo temps réel
L’astuce c’est d’arriver à traiter les données par lot et de n’avoir besoin de se resynchroniser que de temps en temps. Il faut aussi arriver à masquer les latences dûes à la synchro (en faisant autre chose pendant l’attente des données par ex.)