Le multicore prend de l'ampleur dans les jeux

Et voilà, on y arrive petit à petit... Maintenant cluclu vous devriez faire des benchs de proc sur des jeux qui utilisent le multicore, ça serait plus representatif de ce que valent reellement les procs. Et puisqu'on parle de l'avenir, qqun s'est déjà inquiété de la limitation 4go en 32 bits et de la viabilité 64bits à l'heure actuelle?

Moi j'ai un P4 Prescott même pas Hyper Threading.....

Nesskiller a écrit:
enfin dire que les dualcore sont à portée de toutes les bourses ne résout pas le fait que c'est toujours un casse tête pour développer... Et puis bon développer pour 2 coeurs c'est bien, mais il y a les tri,quad... Donc tant qu'il n'y aura pas un développement pour x coeurs...

Il existe des librairies très performantes comme TBB développée par Intel qui permet de programmer pour N cores très facilement

->zarmathoustra
Tout à fait, 64 bits obligatoire pour 4 go de ram. Avis à ceux qui pensent que ça sert à rien... On disait la même du giga lorsque l'on avait 256 mo de ram.

+1 pour la répétitivité, je suis obligé de laisser passer un jour ou deux entre deux chapitres pour ne pas avoir l'impression de refaire la même chose sans
arrêt.

et j'ai quand même l'impression :-)

Sergent huggies a écrit:
optimiser les jeux pour le multicore c'est bien beaux, mais si le jeu est nul (oui assassin creed est nul, il est beau certes, mais il n'a aucun gameplay et est répétitif a souhait), cela ne changera rien a l'affaire.

Avant de faire marcher plusieurs core, essayer au moins de develloper un jeu qui tiennent la route...

attention, troll inside......

+1 pour la répétitivité, je suis obligé de laisser passer un jour ou deux entre deux chapitres pour ne pas avoir l'impression de refaire la même chose sans
arrêt.

et j'ai quand même l'impression

et bien, il ne fallait pas l'acheter si c'est pour baver autant dessus.......
ah pardon, piraté, oui, c'est la grande mode aussi en ce moment... c'est répétitif ça aussi...

Perso, je ne trouve pas le jeu répétitif pour un poil
Edité le 30/04/2008 à 13:37

Je tien a preciser, et cela n'as jamais été evoqué par clubic (il me semble pas en tout cas), que des titre tels que Call Of Duty 4 ou encrore Unreal Tournament 3 sont manifestement optimisé pour le multi-core (et non dual core, c'est pas pareil), ce qui permet a des gens comme moi (c-a-d avec un X2 3800+ & une 7900GS) d'y jouer tres confortablement.
Et c'est la ou c'est dommage car d'autres titre plus ancien et pas forcement aussi jolis ne passe pas, ou mal, pour la raison inverse....
Edité le 30/04/2008 à 13:41

C'est n'importe quoi ce truc, impossible d'avoir plus de 2 fois les perfs. C'est juste qu'ils l'ont développé nativement pour les dual core, du coup les perfs sont pourries sur les simples core. On ne peux pas vraiment savoir quel est le gain réel dans ce cas, ça représente peut être 20% ce qui serait déjà vraiment très bien par rapport à la majorité des jeux actuels.
Mais bon c'est pas générique vu que ça ne peux pas s'adapter automatiquement au CPU.
On sait très bien en plus que maintenant ce sont surtout les GPU qui font la différence.
Edité le 30/04/2008 à 13:44

Patoch a écrit:
Ils sont culottés de se plaindre les développeurs. Qu'ils apprennent à optimiser leurs créations avant de se plaindre.

:super:, trop dur pour les programmeurs....

---

Londo- a écrit:

Patoch a écrit:
Ils sont culottés de se plaindre les développeurs. Qu'ils apprennent à optimiser leurs créations avant de se plaindre.

Apprends à programmer en multi-coeur avant d'interdire aux autres de se plaindre...

Il me semble qu'Intel a fournit des docs et des outils de dév pour les multicoeurs, donc c'est sûr que se renouveller, c'est pas toujours facile, les gens aiment le status quo....

:neutre:

Dites les pros du dual-core (et plus si affinités), ptite question à la con :

Optmiser un prog (jeu ou autre) pour un cpu n-core c'est beau, mais de mémoire, un prog ne peut accéder directement au matériel (ram, cpu) et se doit de passer par l'OS non ? Hors, si l'Os en lui même se comporte comme une @!#$?* dans la répartition des process (? Thread ?), l'optimisation sera fatalement limitée non ? (voire nulle dans le pire des cas)

A partir de là, l'OS utilisé (Windows XP SP2 ou Vista SP1, voire Linux) aura une influence dans les benchs et un comparo serait nécessaire entre les OS, non ?

ouais mais j'aurais bien aimé voir le même test sans SLI, parce que bi-GPU + bi-CPU j'veux bien croire que ce soit bon mais pas sur que SLI+Quad soit mieux que SLI+Dual ou mono-GPU+multicore :neutre:

->ariakas stop troll. "ah pardon, piraté, oui, c'est la grande mode aussi en ce moment... c'est répétitif ça aussi..."

Pour tous les gens qui disent que les développeurs n'ont qu'à s'adapter, il faudrait quand même voir que le développement mono-thread et le développement Multi-thread n'ont plus grand chose en commun.

Dans le cas du mono-thread, les méthodes de développement, les librairies etc existent depuis de nombreuses années. Les développeurs sont formés à ça et ont de l'expérience.

Le besoin de faire du multi-thread est relativement nouvelle, il n'existe donc pas de forcément de méthodes fiables ni de librairies.
Rome ne s'est pas fait en un jour et il faudra un bout de temps avant que tous les outils soient adaptés.


Sinon pour ceux qui doutent de l'écart de complexité, il faut savoir que ce n'est même pas comparable. La complexité augmente de manière exponentielle avec le passage en multi-tâches.
En mono tâche, on est dans un système déterministe. On sait à tout instant ce qui se passe, quelle instruction est exécutée.
En multi tâches, il est impossible (en tout cas avec nos OS, cf http://fr.wikipedia.org/wiki/Syst%C3%A8me_temps_r%C3%A9el) de prévoir où en est l'exécution de l'autre thread. Il est donc nécessaire de mettre en place des systèmes de synchronisation et de communication entre les threads.

Un exemple simple, imaginez que vous avez une donnée en mémoire, et deux threads t1 & t2. t1 commence à lire la donnée. Au milieu de la lecture, l'OS donne la main à t2 (t1 est arrété au milieu de sa lecture). t2 modifie la donnée. Lorsque t1 reprend la main, il lira une donnée qui a été corrompue, et certainement sans aucun sens.
Il faudra donc mettre en place un système de protection autour de cette donnée pour qu'un seul thread y accède à tout instant. Cependant àa peut créer des problèmes d'embouteillage voire d'inter blocage (deadlock, le pire du pire en multi tâche) http://fr.wikipedia.org/wiki/Interblocage.

Bref avant de critiquer les développeurs sachez qu'il y a une raison à ce que les jeux optimisé multi core soient rares

yplenet a écrit:

Le besoin de faire du multi-thread est relativement nouvelle, il n'existe donc pas de forcément de méthodes fiables ni de librairies.
Rome ne s'est pas fait en un jour et il faudra un bout de temps avant que tous les outils soient adaptés.

Les bi-pro ça date pas d'hier... les dévs auraient du s'adapter depuis longtemps :o

Sinon, les problèmatiques de lock et cohérence de lecture ça date pas non plus d'hier, ce qui a été fait depuis plus de 30 ans dans les SGBD notamment devrait pouvoir resservir.. c'est pas comme si il fallait tout réinventer :neutre:
Edité le 30/04/2008 à 13:56

Ca parle mutex içi ou quoi ?

edit :
yplenet : bravo enfin qqn qui a l'air de savoir de quoi il parle , tache mère tache fille etc... :)
megadub : oué enfin un sgbd les contraintes temporelles sont pas les mêmes..
Edité le 30/04/2008 à 14:00

yplenet a écrit:

Bref avant de critiquer les développeurs sachez qu'il y a une raison à ce que les jeux optimisé multi core soient rares

On comprend bien, tinkiet.
Il y a juste une phase d'adaptation, de création d'outils pour faire ça, qui sont nécessaires.
Voire même une autre manière de programmer, changer la façon dont on pense (et donc la manière dont c'est enseigné aussi).

C'est comme tout. Le progrès technologique engendre de la complexité temporaire apparente, et on s'adapte...ou pas.

:oui:

megadub a écrit:
Les bi-pro ça date pas d'hier... les dévs auraient du s'adapter depuis longtemps :o

Si tes chefs te disent de faire du mono, que le multicore, ça sert à rien, bah, tu stagneras sur le mono...
C'est aussi con que ça...
C'est comme dans mon taff, on nous soule qu'il n'y a que la 2D de vrai, résultat en 3D, on vaut que dalle parce que se former par soit même, c'est chaud et très, très long. :(

->yplenet ok avec toi, mais bon les mutex et autres systèmes de partage des ressources sont enseignés en IUT IUP et autres écoles d'ingé... donc bon ca va.
Edité le 30/04/2008 à 14:04

colonel_remy a écrit:
de toute façon meme les console next gen son en tri core (xbox 360 3 x 3.2 ghz) et hocto core (ps 3 8 X 3 ghz)
donc les dev sont bien oblige de develope des titre multis core

Colonel, le CELL est un processeur monocore épaulé par 8 SPE. C'est très différent d'un processeur octo-core. Dans un proc octo core, ce serait du travail en parallèle, les développeurs pouvant taper dans n'importe quel core directement comme ils veulent. Le CELL c'est du travail distribué : toutes les données passent par le core qui réparti après dans les SPE, les résultat des SPE étant alors renvoyé au core qui fait suivre et redonne du travail au SPE. Les SPE ne peuvent pas être attaqué directement, c'est le core qui orchestre leur travail. De plus, dans le cas de la PS3, un SPE est désactivé et un autre et dédié au contrôle des données, donc la PS3 c'est plutôt un core (3Ghz) + 6 SPE est réalité.

Un processeur avec 9 cores à 3 Ghz exploserait le CELL (1 core + 8 SPE) en terme de perf (en supposant des programmes adaptées).

@yplenet: la programmation multi-cores pour un jeu vidéo ne veut pas forcément dire programmation multi-thread au sens pur du terme, avec toute les problématiques d'accès mémoire qu'elle entraine.

Pour un jeu vidéo, on va plutôt profiter des deux cores pour répartir un gros calcul (vertices, IA, path finding, etc.), en donnant à chaque core la moitié des données à traiter.

En ce qui concerne l'article a proprement parlé, c'est n'importe quoi. Il est théoriquement impossible de gagner plus de deux fois en FPS avec deux cores. Et encore c'est vraiment théorique, car ce qui prend surtout du temps machine sont les accès/transferts mémoires (qui ne sont pas doublés avec un bicore) et l'affichage 3D, pas le calcul CPU pur.

Donc soit l'article est complètement pipoté, soit Assassin Creed est vraiment programmé en natif pour du bicore et "émule" un bicore sur un simple core, ce qui est catastrophique en terme de perfs.

En tout cas ce graphe n'a aucun intérêt dans une optique de comparaison simple/double core. Il y a même un endroit où on a un rapport de 1 à 10 entre simple et double cores.... n'importe quoi. :MDR
Edité le 30/04/2008 à 14:19