请告诉我一个很好的架构，一个生活模拟器 [英] 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

推荐答案

没有一个线程每个实体。这是一个灾难。这是不是线程设计的。线程是非常重量级的;记住，每一个线程占用的虚拟地址空间的一百万字节立即的。此外，请记住，每次两个线程上的共享数据结构进行交互 - 就像你的虚拟世界 - 他们需要拿出锁prevent腐败。你的计划将是一个的质量的数百阻塞的线程，并且阻塞的线程是无用的;他们无法正常工作。高争是诅咒良好的性能，和大量的线程共享一个数据结构的不过是不断的争论。

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.

高品质的专业仿真器，如物理引擎需要处理的交互实体没有解决他们的问题与线程。通常情况下，他们将有一个线程执行仿真和一个线程运行的用户界面，使昂贵的模拟计算，不挂的用户界面。

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屋！