NE PAS AVOIR UN FIL PAR ENTITÉ . C'est la recette d'un désastre. Les fils n'ont pas été conçus pour cela. Les threads sont extrêmement lourds ; rappelez-vous que chaque thread consomme un million d'octets d'espace d'adressage virtuel immédiatement . N'oubliez pas non plus qu'à chaque fois que deux threads interagissent sur une structure de données partagée (comme votre monde simulé), ils doivent prendre des verrous pour éviter toute corruption. Votre programme sera un masse de centaines de fils bloqués, et les fils bloqués sont inutiles ; ils ne peuvent pas fonctionner. Une forte contention est anathème pour de bonnes performances, et un grand nombre de threads partageant une structure de données n'est rien d'autre qu'une contention constante.
Le nombre de threads dans votre programme doit être de un à moins d'avoir une très bonne raison d'en avoir deux. En général, le nombre de threads dans un programme doit être de aussi petit que possible tout en conservant les caractéristiques de performance dont vous avez besoin.
Si votre programme est réellement "embarrassingly parallel" (c'est-à-dire qu'il est extrêmement facile d'effectuer des calculs en parallèle sans verrouiller une structure de données partagée), le nombre correct de threads est égal au nombre de cœurs de processeur de la machine. N'oubliez pas, les fils se ralentissent mutuellement . Si vous avez quatre guichetiers et que chacun d'entre eux s'occupe d'un client, les choses vont vite. Vous décrivez une situation dans laquelle quatre guichetiers (cœurs d'unité centrale) s'occupent chacun d'une centaine de personnes en même temps en distribuant des centimes à la ronde.
Les simulations sont rarement d'un parallélisme gênant, car il est difficile de diviser le travail en plusieurs étapes. indépendant pièces. Le traçage de rayons, par exemple, est étonnamment parallèle ; le contenu d'un pixel ne dépend pas du contenu d'un autre pixel, de sorte qu'il peut être calculé en parallèle. Mais vous n'auriez pas un thread par pixel ! Vous auriez un thread par processeur, et vous laisseriez chacun des quatre processeurs travailler sur un quart des pixels. Il est difficile de faire cela avec des simulations parce que les entités faire interagir les uns avec les autres.
Les simulateurs professionnels de haute qualité, tels que les moteurs physiques, qui doivent gérer des entités en interaction, ne résolvent pas leurs problèmes avec des fils. En général, ils disposent d'un thread pour effectuer la simulation et d'un autre pour exécuter 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 de discussion qui tourne à plein régime pour faire la simulation. Travaillez tous les interactions des entités pour une seule image et signale ensuite au fil d'exécution de l'interface utilisateur qu'il doit être mis à jour. Cela vous permettra de déterminer votre fréquence d'images maximale, en mesurant le nombre de microsecondes nécessaires à l'élaboration de toutes les interactions de chaque entité.
