Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!gatech!hubcap!matloff%mole.Berkeley.EDU
From: matloff%mole.Berkeley.EDU@ucbvax.Berkeley.EDU (Norman Matloff)
Newsgroups: comp.parallel
Subject: Re: Distributed simulation
Message-ID: <5362@hubcap.clemson.edu>
Date: 1 May 89 20:27:18 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 44
Approved: parallel@hubcap.clemson.edu

In article <5344@hubcap.clemson.edu> chandra%loligo@gatech.edu (Usha Chandra) writes:

Speaking of task-oriented simulators which put tasks, e.g. simulations of
different servers, on different machines, I had said:

>>It has always seemed to me that these methods are inherently wasteful.
>>Each processor is going to have a substantial amount of idle time.

>Thanks to the advances in parallel hardware, this method has exhibited
>good performance.  Please refer the recent publications by Chandy and 
>Sherman, Jefferson et al, Reed and Malony and Fujimoto.  

I've seen a number of these.  Again, there are inherent problems,
e.g. scaling.  Say the application to be simulated has 20 servers.
There is really no way that the task-oriented approach can be fruitful 
with much more than 20 processors.

>>Moreover, it seems to me that the best method is also the simplest  --
>>just have all P processors run the uniprocessor version of the program,
>>but for T/P amount of run time, instead of T.  [Of course, each processor 
>>needs to use a different random number seed.]

>Some work has been done by John Comfort.  He distributed the support 
>functions such as the random number generation, queue handling, 
>statistics collection, event processing etc on multiple processors and 
>got some performance out of it but not quite enough.

Yes, I also referred to this method in my original posting.  I think it
has even less potential than the task-oriented method.

>It is not that simple.  A uniprocessor version will use some form of 
>event list (a sequential list) and assigning the first n events to n
>processors may indeed lead to incorrect simulation.  For example, 
>consider an event-list with time stamps, t1,t2,t3 ... t1 <= t2 <= t3.  
>Processing the event with time stamp t1 may cause an event to be 
>inserted between t1 and t2.

Yes, I think that the recent work on methods for correct synchronization,
etc., by Chandy etc., are very elegant and impressive.  But my point is
still that for a stochastic system, these should have essentially the
same performance as the replication method, and they are a lot more 
difficult.

   Norm