Simulation with Erlang

David W. Bauer Jr. bauerd@REDACTED
Thu Dec 14 02:28:36 CET 2000

My roommate Shawn Pearce and I created the fastest known Time Warp
simulator.. and what he is saying is correct, in that the rollback
mechanism is the most efficient way known to handle out of order events in
a speculative execution engine, however, it can also be extremely
complicated to code.  I would suggest that you first implement a state
saving routine for reverse computations.  Also, I would suggest that you
might not want to use a Time Warp approach because of the GVT (global
virtual time) mechanism.  It requires the use of global variables
and may not work exactly in the typical way as a TW sim would expect that
GVT vars would be seen across all nodes simulataneously.  It definitely
could be done, but it is another issue to consider.  I would also suggest
that you take a more conservative approach in your simulation until you
had it running, then begin to add fancier routines such as rollback.


                                               ~~~  ~~  ~~~~     _o
  URL:             ~~~  ~~~~ ~~    _'|<,_
                                         ~~~~ ~~~   ~~~~     (*)/ (*)

On Wed, 13 Dec 2000, Jim Larson wrote:

#Take a look at the "Time Warp" multiprocessor simulation framework
#(sorry, my references aren't handy at the moment).  Instead of
#requiring all concurrent entities of the simulation to run in
#lock-step, each goes at its own pace.  The different simulation
#pieces interact with each other through timestamped messages.
#If a process receives a message with a timestamp earlier than its
#internal time, it is required to roll-back its internal clock and
#re-run its simulation with the new message factored in.  If the
#process had sent out messages to other processes based on the
#rolled-back state, it has to send out anti-messages to have the
#other processes undo *their* work, and so on.
#A global "commit" algorithm detects the progress of the system as
#a whole, deciding when some results are safe and can't possibly be

More information about the erlang-questions mailing list