AMD X2 3800+ ou AMD 4000+ - Carte mère - Hardware
Marsh Posté le 24-08-2006 à 11:57:11
Thalys a écrit : Salut tout le monde, |
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 ...
Marsh Posté le 24-08-2006 à 11:59:00
l'avenir est au dual core, x2 3800+ si tu overclcock
sinon 4000+
Marsh Posté le 24-08-2006 à 12:06:46
x2 3800+ ... en plus d'être plus cohérent avec les nouveaux jeux, cela t'apportera un nouveau confort d'utilisation en 2D
Marsh Posté le 24-08-2006 à 12:10:17
TNZ a écrit : 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 ! ) !
Marsh Posté le 24-08-2006 à 12:15:49
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
Marsh Posté le 24-08-2006 à 12:16:46
TNZ a écrit : 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). |
Arem, oui...
Mais sur PC on peut faire des choses qu'on ne peut pas sur console
Marsh Posté le 24-08-2006 à 13:47:56
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.
Marsh Posté le 24-08-2006 à 15:01:22
ah dans ce cas évidemment...
mais je te dis de prendre un E6300 t'es à 30 près ?
Marsh Posté le 24-08-2006 à 15:04:51
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
Marsh Posté le 24-08-2006 à 15:13:40
ReplyMarsh Posté le 24-08-2006 à 15:29:11
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...
Marsh Posté le 24-08-2006 à 15:45:18
Oui et non ... les jeux multi-core seront d'actualité à la sortie de la prochaine génération des moteurs graphiques
Marsh Posté le 24-08-2006 à 15:59:40
TNZ a écrit : 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.
Marsh Posté le 24-08-2006 à 16:14:08
starconsole a écrit : NON, et pour cause ! |
tu devrais lire ceci alors : http://www.matbe.com/actualites/11 [...] r-ut-2007/
Marsh Posté le 24-08-2006 à 16:15:31
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.
Marsh Posté le 24-08-2006 à 16:17:06
pure 3d a écrit : tu devrais lire ceci alors : http://www.matbe.com/actualites/11 [...] r-ut-2007/ |
et ?
Citation : Configuration minimum : |
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 !
Marsh Posté le 24-08-2006 à 16:19:21
TNZ a écrit : Houlaaaaaaaa ! ... l'utilisation des multi-core ou multi-processeur passe par la programmation multi-process (plusieurs fichiers exe) et/ou par le multi-thread. |
oui effectivement, mais ce n'est pas valable pour les jeux !
Marsh Posté le 24-08-2006 à 16:20:34
starconsole a écrit : et ?
|
je t'aurais cru si t'était un dev de chez epic
mais bon...
Marsh Posté le 24-08-2006 à 16:23:39
Oh et puis Zut, si tu veux jouer tu attends le 17 Novembre et tu débourses 600 sur une PS3
Marsh Posté le 24-08-2006 à 16:24:08
TNZ a écrit : 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). |
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.
Marsh Posté le 24-08-2006 à 16:26:17
Thea a écrit : 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. |
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 )
Marsh Posté le 24-08-2006 à 16:26:49
ReplyMarsh Posté le 24-08-2006 à 16:33:14
starconsole a écrit : oui effectivement, mais ce n'est pas valable pour les jeux ! |
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.
Marsh Posté le 24-08-2006 à 16:34:50
ReplyMarsh Posté le 24-08-2006 à 16:34:54
starconsole a écrit : Oh et puis Zut, si tu veux jouer tu attends le 17 Novembre et tu débourses 600 sur une PS3 |
Citation : we certainly expect Unreal Engine 3 titles to see significant gains on multi-core platforms |
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/]
Marsh Posté le 24-08-2006 à 16:37:03
mrdoug a écrit : C'est buggé ? |
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.
Marsh Posté le 24-08-2006 à 16:52:01
Thea a écrit : 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. |
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
Marsh Posté le 24-08-2006 à 17:22:34
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.
Marsh Posté le 24-08-2006 à 17:37:11
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.
Marsh Posté le 24-08-2006 à 17:56:36
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.
Citation : 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. |
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)
Marsh Posté le 25-08-2006 à 08:37:05
TNZ a écrit : cyberlau » tu mélanges tout ! |
ah ?
TNZ a écrit : Par défaut, l'attribution d'une unité de calcul se fait par l'ordonnanceur et pour un thread. |
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).
TNZ a écrit : 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. |
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.
TNZ a écrit : 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. |
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.
TNZ a écrit : Le fait de programmer en multi-thread demande à changer de méthode d'analyse. |
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.
TNZ a écrit :
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).) |
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.
TNZ a écrit : 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) |
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
Marsh Posté le 24-08-2006 à 11:55:21
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.