From: ted.dunning@gmail.com   
      
   Thuan Seah Tan wrote:   
   > Hi all,   
   >   
   >     I wonder for a multiagent system simulating traffic flow where each   
   > vehicle is an agent, is it common to have a thread for each agent? Having a   
   > thread for each agent doesn't seem to be a good idea if we are looking at   
   > large numbers vehicle say >100 am I right to assume so? How do people using   
   > implement such a system then? Hope someone can advice me on this. Thanks in   
   > advance.   
   >   
   > Thuan Seah Tan   
   >   
      
   You need to define what kind of simulation you are trying to build.   
      
   If you are trying to do computational simulations of traffic without   
   tying things to real-time, then you should be looking exclusively at   
   computational efficiency so that you can simulate as many agents as   
   possible within a certain amount of computation on the hardware you   
   have.  With this mode, throughput rules.   
      
   If, on the other hand, you are trying to do simulation that is   
   specifically tied to real-time progress such as for interactive   
   displays where a user might be changing the situation directly and   
   looking at what happens, then you need to focus on methods that   
   maintain the correlation between real-time and computation time.   
   Getting more than the required throughput buys you nothing, but getting   
   shorter latency is very important.   
      
      
   Almost all important traffic simulations fall into the first category   
   because the questions are generally to do with what various long-term   
   interventions such as building new roads, changing traffic rules or   
   changing control software might do rather than what effect a god-like   
   controller might have.   
      
   Once you make that assumption, then it become highly counter-productive   
   to imagine that you will require each vehicle be mapped to exactly one   
   execution thread.  Such an assumption might simplify your code a little   
   bit, but it will limit you to handling no more than a few thousand   
   vehicles.  The limitation is primarily due to inefficient use of memory   
   ... a vehicle's state is only a few bytes, but a thread generally   
   requires several thousand bytes of stack to execute safely.  Spending   
   all that memory to store the state is dreadfully wasteful, even when   
   you have many GB to play with.  If you don't need more than, say,   
   20,000 vehicles, then building your sim this way is fine and if this is   
   only a toy that you are building then simple development is good.   
      
   If you want much higher throughput, you need to divide the work   
   differently.  The good news is that this is pretty easily done because   
   vehicles are constrained to interact only with other vehicles within a   
   close geograpical region.  This means that you can divide your problem   
   geographically.  Each location will need to communicate with   
   neighboring regions in order to pass "control" over vehicles from one   
   cell to another and there will need to be some information passed about   
   vehicle state so that the vehicles can "see" each other, but the   
   communication paths are very sparse and highly stable.  Moreover, since   
   the number of vehicles that can even be in a geographical region is   
   limited, you can have nice bounding properties on the amount of   
   computation required per cell.  Individual geographical patches can be   
   distributed across multiple threads as well as across multiple   
   processes and physical computers.   
      
   These are pretty similar (in broad outline) to the methods used by   
   large-scale multi-user interactive games.   
      
   [ comp.ai is moderated ... your article may take a while to appear. ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)