Salut tout le monde,
 
Voilà, tout est dans le titre, je possède maintenant une carte-mère ASRock 939DUAL-SATA2, et j'hésite entre ces processeurs  
(AMD Athlon 64 X2 3800+ et AMD Athlon 64 4000+).
Ils sont au même prix (+/- 160 euros). En sachant que mon utilisation poussée sera tournée vers le jeu, lequel me conseilleriez-vous ?
 
Merci de votre aide.

Simple core c'est bon, 4000+ c'est top
 
EDIT: 200 € le Core 2 Duo 6300... et là y'a pas photo niveau perf quand même... tu devrais rajouter les 40 €...

l'avenir est au dual core, x2 3800+ si tu overclcock
 
sinon 4000+

x2 3800+ ... en plus d'être plus cohérent avec les nouveaux jeux, cela t'apportera un nouveau confort d'utilisation en 2D

NON !
 
Les jeux actuels ne tirent pas un profit du Dual Core signifiant, ça se joue à <2% (un soit disant allègement du Thread principal...), lorsque les jeux tiendront profit de ça  les jeux EXIGERONT une machine dual core car le codage sera effectué en conséquence. De plus toutes les machines actuelles seront à la rue niveau puissance (y compris les Core 2 Duo).
 
Dans les jeux le X2 3800+ se fait massacrer par le 4000+ sans problème ! Maintenant si le monsieur pratique un truc qui s'appelle l'overclocking évidemment... le X2 sera meilleur choix quand même (même si le 4000+ peut aussi s'aligner en FX-57...).
Mais attention hein ! Uniquement dans les jeux, si tu fais autre chose évidemment c'est plus pareil...
 
Actuellement le simple core est le meilleur choix si on fait QUE du jeu
 
Mais entre un 4000+ à 160 € et un Core 2 Duo E6300 à 190 € le choix est normalement mathématique et immédiat... ou alors un 3700+, y'en a à 95 € sur LDLC je trouve que c'est une méchante affaire (et dire que j'en ai fait prendre à un pote y'a 3 mois en le payant presque le triple ! ) !

Certes, mais on ne fait pas forcément que du jeu sur un PC. Sinon on s'achète une console (moins cher et conçue pour).
 
Du coup, saisir l'occasion de passer à du multi-core est une bonne chose en soi

Arem, oui...
 
Mais sur PC on peut faire des choses qu'on ne peut pas sur console  

Je crois que je vais prendre un X2 3800+, et de l'overclocker un peu.
Parce que je fais evidemment du jeu qui demande beaucoup de puissance, mais également plus occasionnellement du traitement vidéo.
Et le dual core semble plus tourner vers l'avenir.
Merci de votre aide.

ah dans ce cas évidemment...
 
mais je te dis de prendre un E6300 t'es à 30 € près ?

Ben ... ASRock 939DUAL-SATA2

Je dirais le X2 3800+, plus adapté à une configuration censée durer un minimum. Avec le temps les applis vont se généraliser pour les multi-core grand public

merci de le repréciser, je l'avais pas lu

X2 3800+, le dual core c'est franchement sympa, tu joues tout en faisant un encodage ou un scan AV, bref franchement le simple core c'est obsolète maintenant...
Sinon c'est clair que le dualcore n'est pas conçu pour le jeu, d'ailleurs comme le dit si bien starconsole, quand les jeux optimisés dualcore sortiront, les core 2 duo seront à la rue...

Oui et non ... les jeux multi-core seront d'actualité à la sortie de la prochaine génération des moteurs graphiques

NON, et pour cause !
 
Utiliser de dual core nécessite une programmation spécifique afin de permettre d'attribuer des fonctions à chaque coeur. Une opération comme ça oblige l'utilisateur à posséder une telle machine... ce qui n'est pas le cas de tout le monde.
 
Et mets toi à la place des éditeurs... tu crois qu'ils vont se cantonner à faire des jeux pour une minorité de personnes ?
Non, bien sûr, les jeux développés pour le Dual Core ne sortiront pas avant 2010 quand la grande majorité des PC seront équipés ainsi...
 
Et la prochîne génération de moteurs graphique celà ne concerne justement pas le dual core, mais les GPUs et DirectX.

tu devrais lire ceci alors : http://www.matbe.com/actualites/11 [...] r-ut-2007/
 

Houlaaaaaaaa ! ... l'utilisation des multi-core ou multi-processeur passe par la programmation multi-process (plusieurs fichiers exe) et/ou par le multi-thread.  
 
Windows (les MFC) sont multi-threadés depuis des années. Maintenant, la programmation multi-thread demande de reposer le problème sur une feuille blanche afin de l'analyser d'une façon différente. Et dans le cas des jeux, il s'avère que cette analyse est BEAUCOUP plus simple (programme devant gérer plein d'évènements différentes et asynchrones).
 
Quant aux processeurs mono-core, la gestion des threads se fait par semi-parallélisme grâce à la notion de noyau pré-emptif.
 
Le véritable problème qui se pose pour les studios de développement, c'est que ça fait des années qu'ils se sont débarassé des personnes ayant un véritable savoir-faire technique et que maintenant, ben, ils vont en avoir besoin pour passer cette étape. Utiliser un AGL n'a jamais été de la programmation.

et ?
 

C'est seulement mentionné "de préférence", tu auras juste une petite optimisation de rien du tout pour alléger le thread principal et gagner 2% de perfs... c'est top ! wah !

oui effectivement, mais ce n'est pas valable pour les jeux !

je t'aurais cru si t'était un dev de chez epic  
mais bon...

Oh et puis Zut, si tu veux jouer tu attends le 17 Novembre et tu débourses 600 € sur une PS3

C'est chiant de lire toujours cet argument. Non, si on ne fait que du jeu on achete pas une console. Tout simplement parce que sur console, si le jeu a des bugs, on a pas de patch pour les corriger. Les jeux sur consoles ne sont pas forcement les memes que sur PC.
Bref, arretez avec cet argument, ca veut rien dire du tout.
Il est pas contre toi ce message TNZ, mais j'en ai marre de lire toujours cet argument stupide. C'est comme si on disait, j'sais pas moi, si on fait que marcher, on achete des chaussures de marche, c'est fait pour. Ben non, tout simplement parce qu'il y a plusieurs types de marches comme il y a plusieurs types de jeux.
Desolee pour ce HS et achete le x2 3800+
 
Théa.

y'a pas de bugs sur console aussi... parce qu'il y a pas un Système d'exploitation pourri pour le gérer... (bon j'exagère, XP est un bon système )

Va dire ca aux joueurs d'Oblivion sur console.
 
Théa.

Lis l'intégralité de mon post ...  
 
Mais l'avenir est aux vrais programmeurs et donc finie la technologie de la grosse boucle inifinie centralisante et séquentielle hérité de la programmation DOS.

 
C'est buggé ?

soure : http://www.anandtech.com/cpuchipse [...] i=2377&p=3
si aprés, tu me dit encore que l'unreal engine 3 n'est pas multithreadé, je veux bien acheter la ps3  
[HS/]

Y a des quetes qui ne peuvent pas etre terminees. C'est tout ce que j'ai entendu dire, mais ca ne m'etonnerait pas qu'il y ai autre chose (comme des bugs au niveau des traductions par exemple), je ne m'interesse pas aux consoles. La derniere que j'ai eu etait une Mega Drive II (c'est pour dire), donc je ne peux pas etre plus precise au niveau des bugs sur console.
 
Théa.

 
C'est très grave comme bug
A la mega drive, ça c'était de la console, pas comme ces trucs tout fragile d'aujourd'hui...
Les consoles c'était mieux avant, le PC c'est mieux maintenant  

En même temps, je ne vois absolument aucune raison pour qu'une boite de jeu développe des applications spécifique aux doubles coeurs...
Pour moi le vrai gain sera un windows qui n'est pas pénalisé par l'application au premier plan et vice et verçà..
Mettre le système, tous les services associés, modules des driver et autres appli vitale (comme AV, FW etc...) sur un Core, et le reste sur l'autre core par défaut, et rien que çà, il y aura un gain de perf.
 
Sans parler d'une optimisation de DirectX pour qu'il puisse fonctionner sur un autre core que celui du Jeu en cours histoire que l'ordonanceur de tache n'ait pas à swaper vers le core de DirectX pour executer les fonctions appelés puis revenir au jeu... surtout s'ils veulent intégrer des calculs physique dans l'API... (et encore s'ils sont lourd, partagé les taches sur chaque core peut aussi aider dans ce cas, surtout si le moteur du jeu ne fou plus grand chose).
 
Et je parle même pas même pas du loadbalancing sur les ressources (réseau, accès disque/etc...) afin de ne rien dégrader inutilement.
 
Et tout çà, sans rien toucher au code du jeu en lui même.
 
La meilleure optimisation n'est pas forcément là ou cela parait le plus évident (l'application elle même).
 
Mais j'imagine de toute façon qu'il faudra attendre Vista et DirectX10 avant de voir vraiment des impacts sérieux dans les jeux.

Dire que parceque un jeu est sur console alors il n'y a pas de bug c un peu se foutre du monde :-).
 
Le principe est simple, plus ya de ligne de code, plus ya de risque d'avoir des bugs et ca quelquesoit la plateforme.
Nonobstant un jeu sur console aura des probabilites de bugs moindres car il y aura moins de ligne de code, tous simplement parceque le jeu est sompile et optimiser pour le hardware console, alors qu un jeu PC doit tenir compte de plusieurs chipset (graphique/audio/proc) etc...
Certe les drivers sont censer virtualise l'acce au device mais bon les codeurs essayent d optimiser et quelquefois, l'interaction moteur du jeu/directX/driver natif/OS/chat noir/human factor fait que ca ne marche pas aussi bien que prevu.
 
Donc oui sur console il y aura en moyenne (si on prend l ensemble des jeux console/PC sur une annee) moins de bug que sur PC, de la a affirmer qu'un code pour console est bug free, compte tenu du cout de devellopement et de ce que peut rapporter un jeu, et du temps que prend une phase de test complete, je pense qu on peut raisonablement dire qu'il est possible de trouver des bugs dans un jeu sur console.
 
Quand a dire qu'il n'y a pas de systeme d'exploitation sur ta console :-), une console ou un PC sans OS, c'est un gros tas de silicium sans valeur.

cyberlau » tu mélanges tout !
 
Par défaut, l'attribution d'une unité de calcul se fait par l'ordonnanceur et pour un thread.
 
Ensuite, DirectX stune librairie, donc du code utilisé par les programmes et leurs plus ou moins nombreux threads. Il n'y a aucune notion de core du point de vue OS.
 
Et la meilleure optimisation restera l'application elle même ! ... en fait il n'y a plus qu'elle qui ne soit pas multi-threadée massivement. Et je t'avoue, pour en avoir mangé beaucoup, que des applis mono-threadées devant faire de l'évènementiel asynchrone, et bien, le code n'est pas d'une lisibilité exemplaire. Voire même que la principale cause de bugs vient de la logique séquentielle pure et dure générant des kilomètres de lignes de code très souvent approximatives et rarement testées.
 
Le fait de programmer en multi-thread demande à changer de méthode d'analyse.
 

Vista et DirectX10 n'ont rien à voir avec cet aspect là. WinXP est déjà multi-thread, et DX9, à ma connaissance, n'a pas forcément les pré-requis nécessaire à une utilisation multi-thread (comprendre gestion de la réentrance).
 
En fait la commercialisation des moteurs graphiques multi-threadés et leurs applications correspondera à la période Vista/DX10 ... simple concours de circonstances. Maintenant la vraie question est : est ce que DX10 est massivement réentrant ? (adapté au multi-threading)

ah ?    
 

J'ai jamais dit le contraire, avec tout le changement de contexte qui va bien. Mais y a t il un load balancing sur les processeurs autres que celui de la charge (ou le pif) ? Quand le nombre de tâche (je vais utiliser ce terme pour identifier de manière indifférente les processus et les threads) devient important, le coût du changement de contexte pour les executer  devient d'autant plus grand (voir occupe 99% du temps quand ca swap à mort cf vieil ordi ).
Quand on lance un jeu qui occupe beaucoup de la charge du processeur, on peut espérer que le système fera en sorte que beaucoup de thread "court" (en temps d'éxecution) soit sur l'autre processeur, ce qui en pratique n'est quasiment jamais le cas. Donc pour moi, il y a encore matière a travailler sur le sujet (mais je te rassure, c'est déjà dans les cartons depuis belle lurette et mieux optimisé sur de nombreux autres systèmes et cela continue de progresser, preuve que le domaine n'est pas figé, rien qu'à voir le noyau 2.4 et 2.6 de nunux et la grosse optimisation sur la gestion multithread).
 

Oui et non, directX n'est pas qu'une simple librairie linké, sinon les perfs serait pas bien grande. Il y a le coté interface utilisé par les programmes qui communiquent à des "services" de toutes sortent, qui ont leur existance propre eux.
 

Je n'ai pas dit que les applications ne pouvait pas être optimisé pour une environment multiprocesseur (suffit de voir l'exemple bateau du raytracing ou chaque core trace une partie de l'image finale)
Et moi aussi j'en ai bouffé... ceci dit, du mono-threadé, j'avoue aujourd'hui que ca m'épate, à moins de faire du code en ligne de commande ?
Rien que l'IHM doit être threadé pour ne pas provoquer de lock sur l'application (après, pour la gestion d'évenement de fenêtre et sa relative lisibilité, c'est lié au langage et la librairie utilisé, MFC en C++ ou VB, c'est le jour et la nuit).
 
Mais là n'est pas le débat, on parle de JEU ici, un jeu c'est quoi son pipeline graphique ?
Calcul entrée/sortie => Calcul physique/IA/.. => Transfo/déplacement graphique => rendu ?
A part fouttre les entrée/sortie sur un thread (déjà fait dans 99% des cas), tout le resque ne peut se mettre qu'en séquence dans le pipe, parce que rien ne peut avancer sans que l'étape précédente soit terminée.
La seule chose qui pourrait être parallélisé est le rendu, mais pas de bol, c'est fait coté GPU....
Le calcul de la physique tant à la mode pourrait être affiné effectivement... mais pas de bol encore... la tendance pousse les dev à utiliser les GPU ...
 
Quékonfé ? ben rien, on optimise là ou on peut, à savoir sur ce qui est quasi immuable sur 99% des jeux et qui pourrait apporterait le plus de gains... à savoir les librairies utilisé genre DirectX et le système qui fait tourner tout çà.
 
A la rigueur, jusqu'à présent, le progrés était réalisé en amont du pipe avec des algo d'approximation et d'anticipation sur les actions suivante avant même d'avoir reçu confirmation sur les I/O (coté serveur ou autre) afin de rendre plus fluide l'action.
 

Ca je ne peut pas laisser passer, cela fait des siècles qu'elles existent, et qu'elles sont utilisés, mais je te l'accorde, plus souvent du multi processus que multithread, mais bon, pourquoi utiliser un truc qui sera plus lent au final sans l'architecture qui va avec ?
Les softs vont y passer (les archiveurs par exemple passe déjà au multiproc genre winrar, 7zip & co..), ils n'ont pas besoin de cours pour çà, et les méthodes d'analyse qu'on utilise aujourd'hui le prennent déjà en compte (heureusement), sinon me demande pourquoi sun veut sortir son octocore...
Me souvient encore de mes premiers cours avec ce bête algo de calcul des nombres premiers sur n thread   complêtement inutile, mais peut être pas pour demain qui sait.
 

Comme expliqué plus haut, WinXP est certe multithread, mais il y a encore du chemin... pour DX9, c'est ce que je m'evertu de dire depuis le début, le plus de gain (et les plus rapide à atteindre) seront du coté des lib de jeu, pas des jeux eux mêmes.
 

Moi je ne crois pas au hasard, sachant que les roadmap sont prévu presque 10 ans à l'avance
Pour ta vrai question, DX9 est déjà "massivement réentrant" dans la mesure il peut être appelé par N processus sans foutre le système en rade.
La vrai question est, est ce qu'un jour il traitera toutes ces entrées de manière efficace sur plusieurs processeurs ?
 
J'ai tous mes espoirs la dessus  vu que l'IHM de Vista sera en grande partie découplé du proco, et passera par DirectX et/ou OpenGL (plutot que la GDI toute pourri qui fait ramer quand on fait click droit ou qu'on ouvre une fenêtre), faudra bien qu'elles soient béton leur lib pour faire tourner des applications en sus de çà de plus en plus gourmande    
 
ps: bizarre, j'ai un peu l'impression que je prèche un convaincu et qu'au final, on dit un peu la même chose, bah pas grave, c'est fait