NE PAS AVOIR UN FIL PAR ENTITÉ. C'est une recette pour le désastre. Ce n'est pas à cela que les fils ont été conçus. Les fils sont extrêmement lourds; rappelez-vous, chaque fil consomme un million d'octets d'espace d'adresse virtuelle immédiatement. De plus, rappelez-vous que chaque fois que deux fils interagissent sur une structure de données partagée -- comme votre monde simulé -- ils doivent prendre des verrous pour éviter la corruption. Votre programme sera un amas de centaines de fils bloqués, et les fils bloqués sont inutiles; ils ne peuvent pas travailler. Une forte contention est l'antithèse d'une bonne performance, et de nombreux fils partageant une structure de données ne sont rien d'autre qu'une contention constante.
Le nombre de fils dans votre programme devrait être un à moins que vous n'ayez une excellente raison d'en avoir deux. En général, le nombre de fils dans un programme devrait être aussi petit que possible tout en obtenant les caractéristiques de performance dont vous avez besoin.
Si votre programme est vraiment "embarrassingly parallel" -- c'est-à-dire, il est extrêmement facile de faire des calculs en parallèle sans verrouiller une structure de données partagée -- alors le nombre correct de fils est égal au nombre de cœurs du processeur dans la machine. Rappelez-vous, les fils se ralentissent mutuellement. Si vous avez quatre guichetiers et que chacun sert un client, les choses vont vite. Vous décrivez une situation où vous avez quatre guichetiers (cœurs de CPU) chacun servant cent personnes en même temps en distribuant des centimes en tour de rôle.
Les simulations sont rarement embarrassingly parallel parce qu'il est difficile de diviser le travail en parties indépendantes. Le tracé de rayons, par exemple, est embarrassingly parallel; le contenu d'un pixel ne dépend pas du contenu d'un autre pixel, donc ils peuvent être calculés en parallèle. Mais vous n'auriez pas un fil par pixel! Vous auriez un fil par processeur, et laissez chacun des quatre processeurs travailler sur un quart des pixels. Il est difficile de le faire avec les simulations car les entités interagissent les unes avec les autres.
Les simulateurs professionnels de haute qualité tels que les moteurs physiques qui doivent traiter des entités interactives ne résolvent pas leurs problèmes avec des fils. Typiquement, ils auront un fil exécutant la simulation et un fil exécutant l'interface utilisateur, de sorte qu'un calcul de simulation coûteux ne bloque pas l'interface utilisateur.
La bonne architecture pour vous est probablement d'avoir un fil qui fonctionne rapidement en faisant simplement la simulation. Travaillez toutes les interactions des entités pour une seule image, puis signalez au fil UI qu'il doit se mettre à jour. Cela vous permettra de déterminer quel est votre taux d'images maximum, en mesurant combien de microsecondes il faut pour travailler sur toutes les interactions de chaque entité.
