前几天我在考虑创建一个小型生活模拟器。我只是略过这个想法，我想知道最好的实现方式，以便它能够高效运行。
在最底层，会有雄性和雌性实体四处游荡，当它们相遇时就会产生后代。
我想使用多线程来管理实体，但我不确定线程数等。
最好有几个线程来管理男性和女性，还是可以为每个实体启动一个线程以便每个实例都在自己的线程上运行？
我已经阅读了一些关于最大线程数和应用程序中 20-1000 个线程的限制范围的帖子。
有人对架构有什么建议吗？
N
最佳答案
每个实体不要有一个线程。那是灾难的根源。这不是设计线程的目的。线程非常重量级；请记住，每个线程立即消耗一百万字节的虚拟地址空间。另外，请记住每次两个线程在共享数据结构上交互时——就像您的模拟世界一样——它们需要取出锁以防止损坏。您的程序将大量 成百上千个阻塞线程，而阻塞线程是无用的；他们不能工作。高争用是良好性能的诅咒，许多线程共享一个数据结构只是不断争用。
程序中的线程数应该是一个，除非您有充分的理由拥有两个。一般来说，程序中的线程数应该尽可能少，同时仍能获得所需的性能特征。
如果您的程序真的是“令人尴尬的并行”——也就是说，在不锁定共享数据结构的情况下并行计算是极其容易的——那么正确的线程数等于处理器内核的数量机器。请记住，线程会互相减慢速度。如果您有四个银行出纳员，并且每个出纳员都为一位客户服务，那么事情就会进行得很快。您描述的情况是您有四个银行出纳员(CPU 内核)，每个出纳员同时通过分发便士循环为一百个人服务。
模拟很少会令人尴尬地并行，因为很难将工作分解成独立部分。例如，光线追踪是令人尴尬的并行；一个像素的内容不依赖于任何其他像素的内容，因此它们可以并行计算。但是你不会每个像素有一个线程!每个处理器有一个线程，让四个处理器中的每一个处理四分之一的像素。很难通过模拟做到这一点，因为实体确实彼此交互。
高质量的专业模拟器，例如需要处理交互实体的物理引擎，并不能用线程解决它们的问题。通常，他们会有一个线程执行模拟，一个线程运行用户界面，这样代价高昂的模拟计算就不会挂起 UI。
适合您的架构可能是让一个线程像大火一样进行模拟。计算出单个框架的所有 实体交互，然后向 UI 线程发出它需要更新的信号。这将使您能够通过测量计算出每个实体的所有交互所需的微秒数来计算出您的最大帧速率。
关于c# - 什么是生活模拟器的好架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5686605/