SFML et consommation de ressources CPU.

[Lolilolight]

Salut,
j'ai juste un serveur qui mets à jour les positions de mon personnages avec un thread et reçois les messages en provenance du client avec un autre thread.
Dans mon client j'ai juste un thread qui, reçois les données en provenance du serveur et les mets à jour.
Mais ceci me fait consommer trop de ressource quand j'exécute les 2 (client et serveur.) sur la même machine pour faire des tests, au bout d'un moment, mon PC s'éteint tout seul, et pourtant, mes algorithmes sont "légé.".
Bref je ne comprend pas très bien...

[Cpl.Bator]

sans code minimaliste pas facile de répondre , as tu essayer de coller un sleep() dans ta boucle principale ?

@++

[Lolilolight]

Salut, non je n'ai pas essayer avec un sleep dans la boucle principale, avec un code minimal ça passe mais quand le code devient plus gros donc lorsque j'active plus de fonctionnalités de la sfml, ça commence à me bouffer beaucoup de perfs..., à tel point que je suis obligé d'exécuter le client et le serveur sur 2 machines différentes.

[domoi]

Je te conseil d'abandonner ton architecture multithread, c'est extrêmement compliqué et casse gueule de faire du multithreading et à priori ca t'apporte rien de bon, au contraire. C'est surement la meilleure solution que tu pourras mettre en oeuvre.

[Excellium]

Met des sleeps dans chaque thread ça réglera sans doute le problème.

[Lolilolight]

Salut, je suis obligé de faire plusieurs thread pour la réception de données.
Car pendant que je reçois les données en provenance du serveur il ne faut pas que mon interface graphique freeze.
Quoi que depuis que j'utilise udp et tcp j'ai du passé mes sockets en mode non-bloquant car dans ma boucle je fais 2 receives pour les données udp et tpc reçues, je pourrai à la limite peut être me passer du thread pour la réception de données, je vais essayer.
C'est sans doute ça qui ralentis, mon thread n'attend plus les données reçues en provenance du serveur vu que j'ai passé mes sockets en mode non bloquant mais rend la main directement, je vais peut être essayer de mettre un sleep dans ce thread là..., ou carrément supprimer ce thread en récupérant les données reçue par le serveur à chaque tour de boucle de jeux.
On verra si ça règle le problème.
Mais côté serveur je suis obligé d'en mettre un, à cause du selector.wait() et un pour chaque canal aussi.
Bref avec seulement 2-3 thread ça ne devrait pas consommer autant je pense, à moins que la sfml en utilise 1000 en interne, mais je pense pas mdr.

[Excellium]

Si tu tournes avec un processeur simple cœur, un thread sans sleep prendra 100% des ressources CPU. Avec deux coeurs 50%, etc... C'est pas à prendre à la légère, essaye et tu nous diras.

[Lolilolight]

Je travaille avec un i5 (quatre coeurs donc) de chez intel.
J'ai essayer de mettre un sleep dans ma boucle qui reçoit les données envoyées par le serveur mais, c'est encore pire, de plus, ça ne saccade que par moment, peut être que quand j'aurai le client et le serveur sur 2 PC différent ça ira mieux car là, au lieu d'avoir 4 thread j'en aurai que 2 par machine.

J'ai essayer de mono-threadé mais, comme j'utilise plusieurs interface graphique (sélection du personnage, identification, etc..., je n'exécute pas la boucle principale de jeux tout de suite du coup c'est embêtant car par chaque interface graphique je devrai appelé une fonction qui attend des données reçues, de plus je ne sais pas quand est ce qu'elle seront reçues, bref, faire ça sans thread, c'est un vrai cauchemar. :/
Je pense donc laisser comme ça pour le moment (...) et on verra plus tard quand j'aurai un bon serveur dédié pour les mmorpgs, ça ne saccadera surement plus.
Je voulais juste dire que ça m'étonne qu'avec un quadcore ça saccade comme ça, je ferai une vidéo pour vous montrer.
Et bon quand j'exécute le code mon CPU n'est pourtant pas à 100%, mais à 50% +/-.
Mon FPS m'indique un nombre par exemple 10 FPS mais vu comment ça saccade je pense pas quil fasse 10 fois le tour de boucle en 1 seconde mais c'est surement à cause des threads ça.
Donc je pense que quand j'exécuterai le client et le serveur sur 2 machine différents pour avoir moins de thread, ça résoudra surement le problème.

[Laurent]

"Ca saccade je comprends pas" n'est pas une fatalité, tu peux en savoir beaucoup plus avec les bons outils. Déjà regarde le pourcentage de consommation CPU (tes messages sous-entendent qu'il est maximal, mais il est à combien exactement ? et regarde ça pour chaque coeur plutôt que globalement), et s'il est bien à fond, alors utilise un profiler (VerySleepy est très simple d'utilisation, et lié à aucun compilo/EDI en particulier) pour analyser ton code.

[Lolilolight]

Mon CPU tourne entre 70 et 80% et mon FPS est bon.
Donc je ne pense pas que le problème vienne vraiment du CPU mais plutôt des threads ou bien du module réseau.
Pourtant j'ai mis au point un algorithme qui limite les transferts réseaux en ne faisant qu'un seul transfert des positions des entités toutes les secondes et non plus à chaque frame.
Et entre chaque requête je fais une interpolation des positions des entités côté client pour pas que j'aie des déplacements saccadés et que les entités bougent seulement toutes les secondes mais bien toujours à chaque frame.
Et à chaque mise à jour je fais une correction des positions en fonction du temps de latence.
Ca, ça marche nickel cependant il y a toujours cette mauvaise impression, de déplacement saccadés comme si le personnage ne se déplaçais pas à chaque frame mais toutes les 0.5 secondes, bref...

Je vais regarder une dernière fois du côté de mon moteur réseau qui stocke les message reçu dans une pile pour les traiter ensuite. (En fait je fais comme ça, le serveur envoie un message, il précise le type de message, le client vérifie si il a reçus un message (donc si la pile n'est pas vide) si oui il regarde le type de message et si c'est pas le bon il le remet dans la pile sinon il le lis et le supprime.
Sinon, si je ne vérifie pas si un message a été reçu mais que j'attend qu'un message quelconque j'ai mis un timeout.
Peut être là que ça bloque..., bref, je vais revérifier une dernière fois mais personnellement le timeout que j'ai mis est de 3 secondes et mon client ne bloque pas pendant 3 secondes.
Donc je ne pense pas que le problème vienne de mon moteur réseau.

PS : Pour préciser,  J'utilise la SFML avec Qt.
PS 2 : je dois utiliser aussi pas mal de sf::clock pour faire cela.

[Laurent]

Mon CPU tourne entre 70 et 80%

Comme je te l'ai dit, il faut voir ce que ça donne pour chaque coeur. 80% en global sur un quadricoeur, ça fait 3 coeurs qui tournent à 100%, c'est pas terrible du tout.

[...beaucoup de bla bla et d'hypothèses...]

Utilise un profiler

[Lolilolight]

Bon, j'ai trouvé un problème, quand le message est trop long (Même en TCP.), mon client ne reçoit pas le paquet.
Peut être ça qui faisait foiré tout.

[Lolilolight]

Bon j'ai essaye les 2 choses suivantes : envoyer toutes les données d'un coup avec un seul sf::Packet ou bien envoyer plusieurs sf::Packets successivement, la 2ème solution est la plus rapide.

J'ai encore améliorer d'un poil mon moteur réseau et ça va mieux.
Cependant, par moment, il y a un saccadement par-ci par là.
Et au niveau de la consommation de CPU ça ne change rien j'ai toujours 3 coeurs à fond, le problème sera régler quand j'aurai le serveur et le client sur 2 machines différentes mais je trouve que, ça consomme quand même beaucoup pour le peu que je fais.
Le profiler ne me dis rien de suspect avec mon code, c'est pour ça que j'aimerais voir avec celui de la SFML mais gproof ne me donne que mes propres fonctions, et celle de la STL. :/
Je pense aussi que le fait de devoir refaire à chaque fois un appel à display par renderTexture ralenti un peu aussi.
Car quand tu fais appel à une fonction et que c'est rapide avec un appel, ça n'a plus rien à voir lorsques tu l'appelles pleins de fois.
Normalement on ne fais qu'un appel a display par frame.

[Laurent]

sf::RenderTexture::display() ne fait rien.

Si tu veux des infos de profiling pour les fonctions SFML, il faudra peut-être la recompiler avec les bonnes options.

[Lolilolight]

Ha, peut être, oui. ^^