simulation@ufl.edu (SIMULATION MODELING & ANALYSIS) (05/16/88)
Volume: 2, Issue: 5, Mon May 16 12:16:29 EDT 1988 +----------------+ | TODAY'S TOPICS | +----------------+ (1) Distributed Simulation - Issues (2) Emulation versus Simulation? ---------------------------------------------------------------------------- Date: Thu, 12 May 88 13:08:03 PDT From: unni@sm.unisys.com (Unni Warrier) Newsgroups: comp.simulation Subject: Re: SIMULATION DIGEST VOL. 2, NUM. 3 References: <15443@uflorida.cis.ufl.EDU> Reply-To: unni@sm.unisys.com (Unni Warrier) Distribution: Organization: Unisys Santa Monica Keywords: To: simulation@ufl.edu In article <15443@uflorida.cis.ufl.EDU> simulation@ufl.edu writes: > >In Vol. 2, Num. 1, Jerry Freedman writes: > >> Distributed Simulation is a waste of time.period. >> I have been working with communication network simulations >> for about 6 years. Most of what follow has NO theoretical basis >> at all and is entirely pragmatic. > >So, which type of "distributed simulation" >do you mean? : > Paul, I think what Jerry is referring to is a the kind: 5) a simulation that is partitioned into many (interacting) threads. Notice that this kind may be run on one processor, or many processors. Each thread is referred to as a "Logical Process"" (LP), and each LP models a real-life process, or a "Physical process" (PP). The idea is that the collection of LPs models the collection of PPs. (well, the map from LP to PP could be many to many. In any case, the idea is that the communications between LPs is via messages, and that is the ONLY way by which an LP will know of the progress of other LPs it is tied to, ie there is no global simulation clock. An excellent reference is the article by Misra in Computing Surveys (Feb 86 or 87??). There are two ways of implementing this, one is to assure the receiver LP that the message the sender LP send s is always correct (called the Bryant-Chandy-Misra scheme), or the message could be rolled back by the sending LP later (Muntz, Jefferson..). The latter has come to be called TimeWarp. (Apologies to avid followers for gross simplifications here..). Jerry is one of the few people to actually try to implement one of these schemes for a large simulation, and hence his experience in this matter is invaluable. However, I disagree with him, too ! a. Jerry talks of the difficulty of debugging multiple threads of LPs. I think this is a problem with the TimeWarp (TW) scheme. It should not be so much a problem with the BCM scheme. In any case, the need here is for "distributed debugging tools". I can understand Jerry's frustration in being a pioneer, but I think it is because software development in this field is in its infancy. In spite of Jerry's: >> parameters. (Please hold the flames on sophiticated tracing, >> distributed debugging etc. I'm talking pragmatics here - not >> the lates ACM published academic vapor). > >> Now, I claim the the largest number of threads of control ( >> cpus, tasks, whatever you may call them ) you could possibly >> have any hope to follow and understand (or purchase ) is >> 10. The best you could do in a perfect world is a speed up >> factor of ten. But the world is imperfect- you probably couldn't >> do better that 3, 5 at best. Hardly worth it in light b. Jerry also questions speedup. I feel that speedup really depends on the semantics of the simulation. For example, if the LPs were all independent, I could run one on each SUN (or even more than one) and get lots of speedup. Hence the interconnection structure of the LPs is probably the determinant of the speedup. I agree with Jerry that the # of threads you could possibly follow is max 10. In fact, for me, it is max 1! But my heart goes out to someone trying to follow 10 threads of logic WITH the possibility of rollback! This was a point Jerry made in modsim a while back, but the point was not emphasised quite enough.... unni@cs.ucla.edu -- UUCP: ..sdcrdcf!unni ARPA: unni@cam.unisys.com Ma Bell (may she rest in peace!): (213) 829-7511 X 5694 Snailmail : Unni Warrier, Unisys, 2400 Colorado Ave, Santa Monica CA 90406 ---------------------------------------------------------------------------- [originally posted in group "comp.parallel" -pf] From: pallab@caip.rutgers.edu (Pallab Dutta-Choudhury) Newsgroups: comp.parallel Subject: Emulation vs Simulation Message-ID: <1631@hubcap.UUCP> Date: 16 May 88 13:42:51 GMT Sender: fpst@hubcap.UUCP This is my first posting to this group, I must say that I find the expertise and knowledge of the contributers to be excellent. I've learned quite a bit just reading the discussions. That being the case, can someone out there in net land explain the difference between the SIMULATION and EMULATION of a multicomputer system. Specifically, I was reading an article in the current issue of IEEE Computer Magazine, the author made a distinction between EMULATION and SIMULATION. It seems to be a very subtle difference, I've got a slight handle on the difference but it would be appreciated if someone with more expertise could explain it more clearly. Paul Dutta-Choudhury Rutgers Univ. +--------------------------+ | END OF SIMULATION DIGEST | +--------------------------+