Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
il ne faut pas être trop gourmand, la plupart des taches ne se découpent pas en 100000
mes taches par exemple, se coupent en 2 ou 4 par threads, éventuellement 8 mais pas plus
les taches sont "divisibles", c'est a dire qu'on peut les couper en deux, puis chaque moitié encore en 2 etc etc
il y a donc :
- temps de division * n*threads
- temps d'affectation d'une tache * n*threads
- temps d'addition * 100000 / threads
comme tu le sous entend, il faut découper les taches en gardant à l'esprit qu'il y a un cout au multithreading
genre tu as 100 objets à déplacer, tu ne vas pas lancer 1 tache pour chaque objet à déplacer
mais plutot lancer une tache pour chaque thread lui demandant de déplacer une partie des objets (que le manager lui assigne)
Post très intéressant (en fait le lag compensation m'intéresse bien plus. Promis je vais aller y ajouter mon grain de sel juste après)
Attention aux optimisations "à priori" !Envoyé par shenron666
Perso, je préfère 100 fois prendre quelques minutes pour faire un ou deux tests et évaluer la charge réelle que va générer cette partie de l'application, voir même commencer par une version mono-threadée pour voir ce que ça donne.
Si effectivement la charge est telle qu'elle pourra handicaper la bonne exécutiion du reste de mon programme, alors oui on peut envisager de trouver des solutions pour optimiser.
Par contre, si il s'avère que dans mon projet actuel l'utilisation d'une technique mono-threadée convient tout à fait et donne les résultats adéquats, je préfère 1000 fois coder une version mono-threadée car ça nous donne:
- un gain en temps pour l'analyse et le développement de la solution mono-threadée, par essence plus simple à conceptualiser et à coder.
- une diminution des risques de bugs (interblocage, etc...) donc gain en temps de déboguage.
Et le temps ce n'est pas gratuit (au sens figuré) !
Il faut bien se dire que tout le temps qu'on perd à faire une chose qui n'est pas réellement nécessaire pour le résultat final, c'est autant de temps qui ne sera pas mis à l'amélioration d'une autre partie du projet qui aurait - elle - mérité qu'on s'y attarde un peu plus.
c'est vrai que le développement multithread demande plus d'efforts, de temps, de rigueur qu'un développement monothread
c'est sûr que pour afficher un cube 3D qui tourne pas "besoin" de multithreading
seulement ici il est question d'un moteur, et un moteur se doit de gérer de nombreux éléments, événements, resources, calculs
la course aux GHz est terminée (enfin en suspend on dira) l'avenir est au multithread, un moteur monothread n'a plus de longs jour devant lui, il faut penser à l'avenir si on veut se faire une place, c'est un baggage qui déjà aujourd'hui ouvre des portes
c'était mon conseil du soir
Vu l'engouement pour ces discussions je pense qu'il peut être vraiment utile et sympa de faire des nouveaux post.
[edit] Pour ceux qui n'ont pas vu (comme moi au début), voici un lien vers une discussion sur le lag compensation ici[/edit]
En comptant les test de collision, et la mise a jour des structure décrivant la scène, moi je me le permet.
On est pas oblgé de stopper:démarrer un thread pour chaque tache.
non bien sûr, déjà si tu commence à créer plus de threads "workers" que le processeur est capable de supporter tu y perdra en performance à cause du "context switching"
lorsque l'OS met un thread en suspend pour qu'un autre puisse travailler, ça a un cout
encore une fois, il faut faire les choses intelligemment, et la première chose à faire c'est de se connaitre les choses à éviter comme lancer 1000 threads pour déplacer 1000 objets
de la même façon, on ne s'amuse pas à lancer un thread pour faire 1 tache ou une série de taches, on crée un pool de threads au début, à l'initialisation, mais ces threads ne se termineront que lorsque l'on quittera le programme
on implémente un système de communication par événement par exemple afin que le master demande aux workers de faire quelque chose quitte à devoir les réveiller mais surtout pas les (re)créer
créer un thread ça a un cout non négligeable, si on s'amuse à faire ça à chaque frame c'est du gaspillage contre-productif
Faut créer 1000 taches qui seront réparties entre les thread (nombre variable en fonction de la machine) par un taskManager
pas forcément 1000 non plus...
si il y a 4 processeurs, chaque processeur devrait en faire 250
il peut etre utile de diviser en plus de tache, au cas ou une dest aches dure plus longtemps, mais diviser en 250 taches par processeur c'est beaucoup trop aussi...
je pense qu'environ 4 par processeur est déjà optimal, au dela c'est beaucoup.
oui et non deadalnix, si tu as 1000 taches différentes à attribuer pourquoi pas
franchement je ne te vois pas avoir 1000 taches différentes mais bon
j'ai plutot la même optique que screetch, tu dois déplacer toutes tes entités entre 2 frames tu ne va pas faire une tache par objet mais des regroupement de taches, et tu prévois ton code pour cela bien entendu, tu assignes le déplacement à chaque "thread worker" que tu as et que tu as créé en fonction du nombre de processeurs de ta machine
le temps machine nécessaire pour créer n taches n'est pas nul et est à prendre en compte, quand on peut diminuer ce temps de manière intelligente
Oui, je vois bien.
J'ai de mon coté cherché a optimiser la creation/répartition des taches entre les workers. J'ai d'ailleurs un système dont je suis assez fier a ce niveau. Cela dit, il faudra surement chercher du coté regroupement de taches dans l'avenir.
l'idée de faire les calculs de physique, animation à l'avance est très intéressante. Seulement, j'aimerais savoir comment tu réagis aux entrées interactives du joueur, interactives directement à la dernière image affichée?
Je pense que l'interactivité avec des actions non prévisibles est une limitation de ta technique.
C'est pour ça qu'il y a un historique. On fait pas les choses a l'avance, mais au présent. Par contre, on reçoit les événements au passé du à la latence du réseau. n en vient donc a modifier le passé et appliquer les changements sur le présent.
Mais cela n'a rien avoir avec le multithread. c'est du lag compentation, et tu devrais continuer dans le topic dédié au sujet.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager