un seul core actif

 
Partager Rechercher
Bonjour,
je suis sous seven 64 avec un core quad et j'ai remarqué que le jeu n'utilise qu'un seul core a 100% et rien sur les autres
Du coup ca doit etre un facteur bien limitant pour tous les calculs du jeu.

C pareil chez vous ?
Actuellement le jeu n'utilise effectivement qu'un seul core, faire un jeu multicore n'est pas si simple et ça demande beaucoup de développement. Il est vrai qu'actuellement la priorité est plutôt sur d'autres projets (les packs de contenu déjà prévus, le 1er GEM etc) mais on est en train d'évaluer comment ça peut être intégré dans notre planning pour pouvoir avancer dessus.
Oui.
je ne sais pas comment les acheteurs du jeu doivent prendre le commentaire c'est difficile à développer et ca prends du temps ...
En attendant les améliorations je me replonge dans Supreme commander qui est multicore depuis sa sortie début 2007
c un peu dommage car ce jeu réclame du gros cpu dès que la ville devient balaize
la prise en charge du multi-core doit être une priorité. Dommage qu'un quad 4ghz soit au taquet.

Wait & see...
Citation :
Publié par Gregory (MC)
Actuellement le jeu n'utilise effectivement qu'un seul core, faire un jeu multicore n'est pas si simple et ça demande beaucoup de développement. Il est vrai qu'actuellement la priorité est plutôt sur d'autres projets (les packs de contenu déjà prévus, le 1er GEM etc) mais on est en train d'évaluer comment ça peut être intégré dans notre planning pour pouvoir avancer dessus.
Bizarre , lors de la beta MC m'avait certifié lors d'un ticket que je jeu fonctionnerais avec 2 cœurs lors de la sortie. Les paroles de MC sont de plus en plus à mettre en doutes. J'aurais du faire une capture écran

Vous auriez du prendre une licence pour le moteur iriszoom...
C'est clair que c'est dommage mais bon.

Quand WoW est sortit, il n'était pas multi-core ce qui est le cas maintenant. Cela fait une bonne différence puisque beaucoup de partit de l'UI ont été threader.


Sinon, pour un jeux de simulation, c'est évidament un des endroit qui apporterais le plus.


Cependant il faut trouver un moyen ou que l'activation des autre core augmente les performances, ce qui n'est pas gagné. Il est possible de répartir la tache sur plus d'un core, mais si un thread a besoin de l'info d'un autre thread qui n'arrive pas, le CPU tourne en rond pendant ce temps.


Pour le post Original, le fait que un core soit a 100% est du à Windows 7 et son nouveau Kernel qui ne balance pas stupidement les thread d'un core à l'autre. Ceci donne un léger gain de performance. Ceci datait depuis NT 4.0 et n'avais plus sa place.

À l'époque ou les première machine à plus d'un processeur abordable sont sortit, il arrivais que les 2 CPU se désynchronisais quand un chauffait plus que l'autre ce qui entrainait un crash de la machine.

Pour évité se problème, le kernel transférais les thread d'un processeur à l'autre pour qu'il chauffe de manière égale.

Mais depuis le temps, d'énorme progrès on été fait en la matière. (les nouveau CPU peuvent avoir des cores qui ne fonctionnent pas à la même fréquence, ce qui était totalement impensable il y a quelques années

Tu peux toujours te consoler en te disant que le driver graphique (AMD et Nvidia) son multithreader et profite de tes autres core..


Peux être qu'à l'époque, ils utilisais plus d'un core, mais bon, si cela entrainais plus de bug que de gain de vitesse, je pense qu'il ont bien fait de finir le jeux et ensuite voir ce qu'il pourront faire.


sinon je pense que le premier truc qui sera threader sera l'UI. Multithreader la simulation sera complexe... même si sur papier, c'est la partit qui gagnerais le plus..
Il faut impérativement multi-threader ce jeu.

je rejoins l'avis a propos de l'UI. j'ajouterais la salle des marchés également.

clair que si le noyau du jeu était threadé ça serait vraiment le top pour les perfs.

Je suis du métier donc je peux en parler.

Toute application, jeux video ou autre, doit etre codé en couche d'objets avec héritage, Iinterface etc... ce qui permet d'ajouter une gestion des thread sur les ancêtres très facilement.... (sur les constructeurs/destructeurs d'objets par exemple)

mais rare sont les devs formés ou investis dans ce genre d'architecture logicielle... plus longue a coder donc plus cher, mais permet des extensions de dev impressionnantes a moindre cout en temps record.
Oué, moi je suis OC à 4ghz en quadcore et un sli de 9800, j'avoue n'avoir aucun prb de perf même sur les villes balaizes....même si oui en carte postale, ça ramotte un peu, mais c'est tout a fait acceptable...une fois toute les texture chargées, c fluide. Je pense que ce jeu nécessite un gros CPU.

vivement la prise en charge du multicore
C'est bizarre, sur le forum de Simtropolis, j'ai posé la question directement sur la possibilité de changer le jeu de « one core » à « multicore » et on m'a dit que c'était techniquement impossible car ça implique la réécriture du jeu pratiquement au complet. Or, ici on prétend au contraire que c'est tout à fait faisable...
En réalité, certaine partie du jeux sont multithreader.


Sauf que les bout de code "Threader" ne sont pas nécessairement ceux que l'on voudrais. Dans une ville, il y a environs 40 thread du process de cities XL mais la plupart doit être dormant ou ne fessant que de petites taches et doivent dormir la plupart du temps.


La ou il y a le plus de multithreading est quand l'on retourne au mode planète. Dans ce cas le jeux pompe jusqu'à 2 core. Je pense que cela est du au fait que le jeux envois la dernière sauvegarde en même temps qu'il synchronise les villes de la planète.


Ce n'est pas l'endroit ou on aimerais mieux le voir, mais c'est mieux que rien.

Concernant le post de simtropolis qui dit que c'est impossible, c'est faux. C'est très possible mais ce n'est pas une tâche facile. et je ne m'attend pas vraiment à voir cela arrivé d'ici la version 2.0

Mais bon on sais jamais. Il faut dire que vu que Cities XL inclus une grosse partie simulation, il est plus facilement "threadable" que WoW ou il n'y a que très peu de chose à Threader. Dans wow, il y a le contenu qui arrive en provenance du serveur, le contenu qui part, le moteur graphique et l'interface graphique qui sont facilement séparable

Mais après ça, par exemple multithreader plus une partie comme le moteur graphique c'est effectivement très difficile. La plupart des élément dépendre d'un autre élément et ainsi de suite.

Mais je pense que si le jeux se vend bien, il vont avoir les ressources pour le multithreader et permettre ainsi des plus grosses villes plus complexe.

Je pense qu'il serais assez facile de séparer la simulation du rendu graphique. Les 2 n'ayant pas nécessairement besoin de l'autre pour fonctionner.
Comme je l ai précisé plus haut dans les post, étant du métier, je répète que la gestion du threading est très simple si les dev ont architecturés leur applications comme il faut.

pour ceux qui comprennent, la programmation objet avec constructeur et héritage permet ce genre d'ajout de spécifications très facilement et rapidement.

pour ceux qui comprennent pas, prenez exemple du passage à l'euro il y a quelques années. Et bien certains programmeurs ont fait évoluer les programmes en quelques jours alors que d'autres ont mis 6 mois...

un prg est comme un batiment... il faut faire en sorte que si on change le toit, on ne soit pas obligé de toucher à la cave ^^

En info c'est pareil... "faire" est simple si on a prévu au départ de rendre simple.
Maintenant si c'est codé façon usine à gaz old-scool SSII pressée, mode pompier tout à l'arrache-> ...RIP.

enfin je pense pas que MC soit une SSII de merde.
Bon on en est ou avec le multi-core la et les 100% d'utilisation CPU ?

le coup des guirlandes de noel ils me la referont pas deux fois.

Gestion de projet MC -> nulle
 

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés