<div dir="ltr">2016-09-19 17:55 GMT+02:00 Miles Fidelman <span dir="ltr"><<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@meetinghouse.net</a>></span><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">I'm actually thinking about military simulation - where the model is
    essentially:<br>
    <br>
    - every simulator (e.g., a flight sim, or a tank) is running on its
    own machine, complete with local world model and image generation
    (necessary to keep up with jitter-free image generation during
    high-g turns - you don't want pilots to puke all over the
    simulators)<br>
    <br>
    - there's a lot of dead reckoning going on locally - the only things
    that cross the network are deltas and events, generally sent by
    multicast<br>
    <br>
    - everything is synchronized by GPS time-stamp<br>
    <br>
    I discovered Erlang when I realized that we (the company I worked
    for) took a very different approach for simulating "virtual forces"
    (think non-player characters) - when we simulated 1000 tanks, on one
    machine, each tank would be an object, and we had 4 threads winding
    their way through every object, 20 time a second.  Turns out that
    the main loops are real spaghetti code that breaks every time a new
    property gets added to an object.<br>
    <br>
    I started wondering why we didn't just have a process per simulated
    object - essentially the way we treated the person-in-the-loop
    simulators.  The answer, of course, being context switching
    overhead.<br>
    <br>
    Then, I discovered Erlang.  And I started thinking - why not just
    have a process per object.<span class="gmail-"></span><br><span class="gmail-">
    </span>
  
    
  
  </div></blockquote><div><br></div><div>Back in the day, there was the Sim94 troop simulation project, which was pretty successful - and way before Erlang got multicore support:<br><a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.52.6023">http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.52.6023</a> <br></div></div><br></div><div class="gmail_extra">This related master's thesis might also be of interest (oops, turns out I was the examiner):<br><a href="https://www.scribd.com/document/184935294/Design-Patterns-for-Simulations-in-Erlang">https://www.scribd.com/document/184935294/Design-Patterns-for-Simulations-in-Erlang</a><br><br></div><div class="gmail_extra">I also found this newer work while searching, but I haven't read it myself:<br><a href="https://www.researchgate.net/publication/233985869_Parallel_Discrete_Event_Simulation_with_Erlang">https://www.researchgate.net/publication/233985869_Parallel_Discrete_Event_Simulation_with_Erlang</a><br><br></div><div class="gmail_extra">Finally, I found this, which made me double-check that I wasn't answering a post from 2012 :-) <a href="http://erlang.org/pipermail/erlang-questions/2012-March/065136.html">http://erlang.org/pipermail/erlang-questions/2012-March/065136.html</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">    /Richard<br><br></div></div>