什么是生活模拟器的好架构 [英] Whats a good architecture for a life simulator

问题描述

前几天我正在考虑创建一个小生活模拟器.我只是略过这个想法，我想知道实现它的最佳方法，以便它能够有效地运行.

I was thinking the other day about creating a little life simulator. I have only brushed over the idea and I was wondering the best way to implement so it will run efficiently.

在最底层，会有男性和女性实体在附近徘徊，当它们相遇时，它们会产生后代.

At the lowest level there will be male and female entities wondering around and when they meet they will produce offspring.

我想使用多线程来管理实体，但我不确定线程​​数等.

I would like to use multithreading to manage the entities but im not sure of number of threads etc.

最好有几个线程来管理男性和女性，还是可以为每个实体启动一个线程以便每个实例都在自己的线程上运行?

Would it be best to have a couple of threads that manage males and females, or would it be ok to start a thread for each entity so each instance is running on its own thread?

我已经阅读了一些关于最大线程数和应用程序中线程数限制范围为 20-1000 的帖子.

I have read a few posts about maximum number of threads and the limit ranges from 20-1000 threads in an app.

有人对架构有什么建议吗?

Anyone have any suggestions on architecture?

N

推荐答案

每个实体没有一个线程.那是灾难的秘诀.这不是线程的设计目的.线程是非常重量级的；请记住，每个线程立即消耗一百万字节的虚拟地址空间.另外，请记住，每次两个线程在共享数据结构上交互时——就像您的模拟世界一样——它们需要取出锁以防止损坏.你的程序将是数百个阻塞线程的质量，阻塞线程毫无用处；他们不能工作.高竞争是良好性能的诅咒，许多线程共享一个数据结构只不过是持续的竞争.

DO NOT HAVE ONE THREAD PER ENTITY. That is a recipe for disaster. That is not what threads were designed for. Threads are extremely heavyweight; remember, every thread consumes one million bytes of virtual address space immediately. Also, remember that every time two threads interact on a shared data structure -- like your simulated world -- they need to take out locks to prevent corruption. Your program will be a mass of hundreds of blocked threads, and blocked threads are useless; they can't work. High contention is anathema to good performance, and lots of threads sharing one data structure is nothing but constant contention.

程序中的线程数应为一个，除非您有充分的理由拥有两个.一般来说，程序中的线程数应该尽可能小，同时仍能获得所需的性能特征.

The number of threads in your program should be one unless you have an extremely good reason to have two. In general the number of threads in a program should be as small as you can possibly make it while still getting the performance characteristics you need.

如果你的程序真的是令人尴尬的并行"——​​也就是说，在不锁定共享数据结构的情况下并行计算非常容易——那么正确的线程数等于机器.请记住，线程会相互减慢.如果您有四名银行出纳员，并且每名出纳员都为一位客户提供服务，那么事情就会进展得很快.您正在描述这样一种情况:您有四个银行出纳员(CPU 核心)，每个出纳员同时通过分发便士轮转法为一百人提供服务.

If your program really is "embarrassingly parallel" -- that is, it is extremely easy to do calculations in parallel without locking a shared data structure -- then the correct number of threads is equal to the number of processor cores in the machine. Remember, threads slow each other down. If you have four bank tellers, and each one is servicing one customer, things go fast. You are describing a situation where you have four bank tellers (CPU cores) each servicing a hundred people at the same time by handing out pennies round-robin.

模拟很少令人尴尬地并行，因为很难将工作分解为独立部分.例如，光线追踪是令人尴尬的平行；一个像素的内容不依赖于任何其他像素的内容，因此它们可以并行计算.但是每个像素不会有一个线程！每个处理器有一个线程，让四个处理器中的每一个处理四分之一的像素.使用模拟很难做到这一点，因为实体确实相互交互.

Simulations are rarely embarrassingly parallel because it is hard to break up the work into independent parts. Ray tracing, for example, is embarrassingly parallel; the contents of one pixel do not depend on the contents of any other pixel, so they can be calculated in parallel. But you would not have one thread per pixel! You'd have one thread per processor, and let each of four processors work on a quarter of the pixels. It's hard to do that with simulations because the entities do interact with each other.

需要处理交互实体的高质量专业模拟器(例如物理引擎)并不能解决线程问题.通常，他们将有一个线程进行模拟，一个线程运行用户界面，因此昂贵的模拟计算不会挂起 UI.

High quality professional simulators such as physics engines that need to deal with interacting entities do not solve their problems with threads. Typically they'll have one thread doing the simulation and one thread running the user interface, so that a costly simulation calculation does not hang the UI.

适合您的架构可能是让一个线程像火焰一样进行模拟.为单个帧计算实体的所有交互，然后通知 UI 线程它需要更新.这将允许您通过测量计算出每个实体的所有交互所需的微秒数来确定最大帧速率是多少.

The right architecture for you is probably to have one thread going like blazes just doing the simulation. Work out all the interactions of the entities for a single frame and then signal the UI thread that it needs to update. This will allow you to figure out what your maximum frame rate is, by measuring how many microseconds it takes to work out all the interactions of every entity.

这篇关于什么是生活模拟器的好架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！