Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F30/00—Computer-aided design [CAD]
  • G06F30/20—Design optimisation, verification or simulation

Definitions

• the invention relates generally to discrete-event simulation (DES) and parallel processing.
• DES A general model of a DES is described, and is not specifically oriented to any particular simulation application domain. DES is discussed in terms of objects and events, event inputs and outputs, and time and event execution of a DES.
• a DES attempts to predict or reproduce the behavior of a specified system by decomposing the behavior into a sequence of state changes.
• Each state change for the system, and each instant in time at which a state change would be possible, is referred to as an "event.”
• the simulated system consists of a collection of system components, referred to as "objects.”
• Objects may be static entities (permanent and predefined) or dynamic entities (created and destroyed as needed) .
• Each object can maintain its own private state. This is referred to as
• object local state In addition, the system may have a state that belongs to no particular object. This is referred to as a "system global state.”
• an event is typically associated with a particular object. If, in a particular DES application, it is possible to have a single event associated with multiple objects, this system can be reduced to the general model by decomposing such events into a series of events for individual objects. In addition, if it is possible to have events associated with no particular object, a special "global object" is created to be the recipient of such events. Therefore, under the general model for a DES, exactly one object is considered “active" in response to an event. This object is called the "active object.”
• the new state of the system is computed as a function of some subset of the DES ' s state, referred to as the event's "inputs.”
• the event is associated with a single object, any part of the system's state may be examined during the event's computation. This includes the object local state for this and other objects, as well as the system-global state and other information, as described in Table 1.
• event specifics refers to a collection of information that describes the event that is to occur. It may include data that is "delivered” with the event, for instance, or it may represent the nature of the event itself. It should be noted that only causal DES ' s are considered. This means that event computations cannot be affected by information contained in future events and, therefore, future event specifics are not permitted as event inputs.
• the state of the system may change in several ways. The primary agent of change is the active object, which is able to perform "actions.”
• the parts of the DES which manage the objects and the simulation global state are able to effect state changes as well . Collectively, these parts of the DES are referred to as the "simulation kernel.”
• the simulation kernel is essentially the infrastructure of the DES, and is typically not specific to the particular system being simulated, although it may be, in the case of a dedicated simulation.
• Event outputs All system state changes are referred to as "event outputs.”
• a list of event outputs is given in Table 2. These event outputs are essentially the significant results of carrying out an event. It should be noted that insertion and deletion of new events to occur in the future are considered event outputs. Insertion of new events is the mechanism that feeds new work to the DES, allowing it to continue executing into the future. The set of future events is considered a special subset of the system global state, but is explicitly mentioned because it is a core state component in all DES ' s .
• Event list acts externally as a list in the sense that the events form a sequence E[0] ,
• the active object can cause zero, one, or more additional events to be inserted into the event list, or "scheduled.”
• the active object can schedule a new event for an arbitrary time in the future, including the special case of the same exact simulation time as the current event.
• Simulation time is defined as the time of the event that is currently executing. Therefore, simulation time "jumps" by typically irregular intervals throughout the simulation, as shown on the time axis of Figure 1.
• Some DES ' s fall into a category called “time- stepped, " which means that all events are evenly separated on the time axis (i.e., E [n+1] -E [n] is a constant) .
• This is merely a special case of the more general "event -scheduled” approach described above, which allows arbitrary spacing between events.
• the events in a DES are conventionally executed serially.
• the conventional architecture for execution of a DES maintains the events in a structure that provides list-like access to the events. Events are removed one at a time from the list for execution. All available computing resources are devoted to the computation of that event until it is completed, at which time the next event may begin processing.
• the events are typically maintained in an ordered state to allow constant-time access to the earliest event when it is time to begin a new execution.
• Such a conventional system is called a "serial event execution" (SEE) DES.
• SEE serial event execution
• X d + c + (n-i) where d is the average d, c is the average c, n is the average n, and i is the average i.
• X reduces to a simple sum of d, c, and i.
• d is essentially a very small constant time required to remove the head event of the list and call an appropriate handler for the head event.
• c depends primarily on the complexity of the events being simulated, and can be assumed to be a given value for a particular class of simulation problems.
• i is a function of the strategy used to manage the event list, since it requires ordered placement in the event list structure.
• the SEE DES has a natural bound on its event throughput. To improve further, the event throughput must be increased.
• all alternatives to SEE rely on concurrently processing multiple events by distributing them over multiple processors.
• a number of approaches have been proposed to accomplish this, and have been implemented in experiments or commercial products. Each has its advantages, making it applicable to a particular class of simulation problems, but none of these are able to increase the event throughput dramatically in the general case, and each presents disadvantages and difficulties in implementation and execution.
• An object of the invention is to provide increased event throughput for a DES using a single event list.
• a further object of the invention is to provide an architecture for implementing parallel simulations usable with any particular computer hardware implementation.
• An additional object of the invention is to provide a technique for accelerating the execution of DES ' s via concurrent use of multiple processors.
• Another object of the invention is to provide a DES in which the simulation programmers or users are unaware of the underlying event -processing architecture of the DES. For instance, the simulation programmers or users do not need to consider how to physically partition the DES system in order to allocate sub-parts to available processors. Instead, the invention automatically scales to take advantage of additional processors and reduces to a traditional DES when only one processor is available.
• the present invention can be embodied in a number of ways, including, but not limited to: a method; an apparatus comprising a computer system; and a computer-readable medium embodying a computer program.
• the invention embodied in a method comprises a method for increasing the event throughput of a discrete-event simulation comprising maintaining an event list for the discrete-event simulation, the event list having a head event; and determining whether the head event is uncomputed, in- computation, or pre-computed. If the head event is determined to be uncomputed, the head event is executed. If the head event is determined to be in-computation, the head event is indicated as pre-computed upon completion of a computation for the head event. If the head event is determined to be pre- computed, it is determined whether the computation of the head event is valid or invalid. If the computation of the head event is determined to be valid, the computation of the head event is applied, and if the computation of the head event is determined to be invalid, the head event is executed.
• the discrete-event simulation has a current system state
• applying the computation of the head event comprises changing the current system state based on the computation of the head event. Further, determining whether the computation of the head event is valid or invalid can use input invariance .
• the event list can be an ordered collection of events.
• the event list includes a plurality of events and at least one event indicated as uncomputed, and the method further comprises selecting the uncomputed events from the event list, and computing computations for the uncomputed events.
• the invention embodied in another method comprises a method for increasing the event throughput of a discrete-event simulation comprising maintaining an event list for the discrete-event simulation, the event list having a plurality of events and at least one event indicated as uncomputed, selecting an event indicated as uncomputed from the event list, assigning the selected event to an event pre-computation process, indicating the selected event in the event list as in-computation, computing a computation for the selected event using the event pre-computation process, receiving the computation from the event pre-computation process, and indicating the selected event in the event list as pre- computed.
• computing a computation for the selected event using the event pre-computation process comprises providing the event pre-computation process with event inputs, and determining a change to the system state based on the selected event and the event inputs.
• Receiving the computation from the event pre-computation process comprises receiving the event inputs and the change to the system state from the event pre-computation process, and indicating the selected event in the event list as pre-computed comprises associating the event inputs and the change to the system state with the selected event.
• the method further comprises: indicating the selected event as a pre-computed head event in the event list; and verifying the head event to determine if the head event is valid or invalid by comparing the current system state with the event inputs associated with the head event. If the head event is valid, the computation of the head event is applied by updating the current system state using the change to the system state associated with the head event. If the head event is invalid, the head event is executed.
• the invention embodied in' a further method comprises a method for increasing the event throughput of a discrete-event simulation comprising maintaining an event list for the discrete-event simulation, the event list having a plurality of events indicated as pre-computed, selecting an event indicated as pre-computed from the event list, and determining whether the selected event is valid or invalid. If the selected event is invalid, the selected event is assigned to an event pre-computation process, the selected event in the event list is indicated as in-computation, a computation for the selected event is computed using the event pre-computation process, the computation is received from the event pre- computation process, and the selected event in the event list is indicated as pre-computed.
• the invention embodied in an apparatus comprises a computer system for performing a discrete-event simulation comprising: means for maintaining an event list comprising a plurality of events, one event being indicated as a head event, each event being indicated as uncomputed, in- computation, or pre-computed; means for carrying out at least one event pre-computation process for computing a computation for an uncomputed event; means for selecting an uncomputed event, and transferring the uncomputed event to one of the event pre-computation processes; and means for executing uncomputed events and verifying pre-computed events.
• At least one processor can implement the means for maintaining an event list, the means for selecting an uncomputed event and transferring the uncomputed event, and the means for executing uncomputed events and verifying pre-computed events.
• a plurality of processors can implement the means for computing a computation for an uncomputed event .
• the computer system comprises a computer or a plurality of computers connected over a network. Further, each computer in the computer system can have a processor or a plurality of processors.
• the invention embodied in an article of manufacture comprises a computer-readable medium embodying code segments for performing a discrete-event simulation.
• the code segments comprise: a code segment of maintaining an event list having a plurality of events including a head event, each event indicated as uncomputed, in-computation, or pre-computed; a code segment for each of at least one event pre-computation process for computing a computation for an uncomputed event; a code segment for an event list scanning process for scanning the event list, selecting an uncomputed event, and assigning the uncomputed event to one of the event pre-computation processes to have a computation computed according to the code segment for the event pre-computation process; and a code segment for an event list manager for executing uncomputed events and verifying pre-computed events.
• the computer-readable medium embodying the computer program comprises code segments to control a processor or a plurality of processors to perform the invention.
• a "computer-readable medium” include a magnetic hard disk, a floppy disk, an optical disk, a magnetic tape, a memory chip, and a carrier wave used to carry electronic data, such as those used in transmitting and receiving electronic mail or in accessing an electronic data network, such as the Internet.
• code segments include software, instructions, computer programs, or any means for controlling a processor or a plurality of processors.
• Figure 1 illustrates irregular event spacing for a DES along a time axis.
• Figure 2 illustrates event processing using the selective pre-computation of events architecture of the invention.
• the invention uses selective pre-computation of events (SPE) as an acceleration mechanism that works within the paradigm of a single event list.
• SPE selective pre-computation of events
• SPE uses the conventional event list and relies on a single process, or thread, called the “event list manager” (ELM) to execute the events in the list.
• ELM event list manager
• process refers to one or more computer programs running on one or more processors.
• SPE also relies on additional processes, which may run on other processors, to "pre-compute” events whenever possible to increase the event throughput . These processes are referred to as “event pre-computation processes" (EPP's) .
• each EPP is run on a separate processor.
• the goal of SPE is to assign as many future events as possible to free processors for concurrent execution and to store the "work, " or computation, performed by these processors in the hope that the work will remain valid and usable when the event's actual simulation time is reached.
• ESP event -list scanning process
• UCE uncomputed events
• ICE in-computation events
• PCE pre-computed events
• UCE uncomputed events
• UPCE usable pre-computed event
• FIG. 2 illustrates event processing using the SPE architecture of the invention.
• ESP scans the event list for any UCE's. If a UCE is found, the ESP forwards the UCE to an EPP for processing, and the indication of the UCE in the event list is changed from UCE to ICE. Once the EPP finishes, the resulting PCE is output, and the ICE in the event list is changed to a PCE .
• the ELM must verify that the pre-computation work has remained valid (i.e., that the head event is also a UPCE) . If the head event is a UPCE, event execution consists only of an "application" of the stored results. In other words, recorded event outputs are used to modify the system state.
• Event inputs refers to the collection of all components of state information stored in any part of the DES which may be analyzed during the event computation .
• the invention increases the throughput of the DES by having the ELM validate events computed by the EPP's, rather than having the ELM compute the events.
• the event throughput of the DES is a function of how fast a single processor can validate events rather than how fast a single processor can compute events fully.
• a condition for the invention providing enhanced performance is that validating events is simpler than fully computing events.
• the PCE validation mechanism is a critical part of the SPE architecture.
• Each event output can cause one or more changes to the state of the DES. If an event E is being computed as a PCE, allowing these changes to occur will modify the view of the system state perceived by other ongoing event computations. Furthermore, allowing the changes to occur will modify the system state as perceived by PCE computations that would occur between the initial execution and the final execution of the event E .
• event outputs are essentially "buffered" until such time as they can be safely applied to the actual system state. This means that the changes occur, but that they are not allowed to affect the system state until the time of final event execution. As discussed above, if the PCE is determined to be invalid according to criteria, such as input invariance, all changes are discarded. Thus, the changes occur in a special context in such a manner as to satisfy two requirements.
• One of the key factors in an efficient implementation of the SPE architecture of the invention is the mechanism employed for transferring control of events to the EPP ' s . If this task is performed on the same processor that supports the ELM, which performs final execution of events, overhead of the EPP ' s will reduce the total event throughput, since only one event at a time can be validated and go through the apply phase of execution. Thus, event dispatching should either be performed using a separate processor that has access to the event list information, or should be implemented with care for efficiency.
• the goal of event dispatching for an event E which is a
• UCE is to provide ah EPP with all of the state information that the EPP requires to make event E into a PCE.
• Event output retrieval This mechanism is referred to as "event output retrieval.”
• event E is dispatched to the EPP, all of the inputs of event E must be accessible to the EPP. As noted earlier, it is difficult to know in advance which inputs event E will require prior to the actual computation of event E.
• the EPP must either be provided with all possible input information or have access to this information on an as- needed basis.
• event selection should be considered.
• the ESP need not simply choose events in the order in which the ESP encounters the events. Instead, the ESP can intelligently choose events based on heuristics that attempt to maximize the gains of the SPE architecture. An important consideration here is the likelihood that the PCE will remain valid and become a UPCE, based on information such as the type of the event, the associated object, etc. Also, certain more computationally- intensive events may be advantageous to pre- compute, given equal overhead for event dispatching and retrieval. Event selection heuristics may be complex and highly dependent on specific knowledge concerning the DES.
• process assignments should be considered.
• a single process or separate process can implement both the ELM and the ESP.
• the ELM and the ESP can be implemented to run on a single processor or separate processors . Additional processors can be used for the verify, apply, and full execution phases, as illustrated in Figure 2.
• Such an approach may reduce communication overhead for certain DES ' s .
• the state of the system becomes distributed in, a dynamic way to the available processors.
• the applicability of such a technique is highly dependent on the nature of the DES and the supporting hardware architecture .
• the EPP ' s can have access to the event list and themselves select UCE's to pre-compute.
• the ELM can perform the function of the ESP, and after an EPP polls the ELM for a UCE, the ELM can provide the EPP with a UCE.
• a UCE is transferred to an EPP, and this can be accomplished in a variety of ways .
• the events in the event list can be indicated with other labels, such as unprocessed, in-processing, and pre-processed.
• the event list is not limited to only the three types of events described herein, but can comprise other types of events as necessary for the implementation of the DES.
• the event list can have multiple head events.
• the multiple head events can be indicated as uncomputed, in-computation, or pre- computed.
• the multiple head events can be concurrently validated or executed by one or more ELM's, if the multiple head events are "sufficiently independent.” To be sufficiently independent, the output of each head event should not significantly affect the computations of the other head events. For example, if multiple events are labeled with the same simulation time (as in Table 1, where events E[l] and E[2] have the same time of 0.1) and arrive at the head of the event list, these multiple events can be deemed multiple head events and are sufficiently independent to be concurrently validated or executed. In general, using multiple head events involves application specific decisions about when the events are sufficiently independent, and can result in significant performance gains.
• the ELM can scan the event list for PCE's and apply the same methodology to the PCE in the event list as it does to the PCE that is a head event. For each PCE in the event list, the ELM determines whether the pre-computed work of the PCE is still valid. To select a PCE in the event list to verify, the ELM, or perhaps another process, can scan the event list periodically or non-periodically . Once selected, the ELM, or perhaps another processs, verifies the PCE in the event list. If the pre-computed work of the PCE is valid, the ELM does not modify the PCE.
• the ELM indicates the PCE as an ICE, and selects one of the EPP ' s to recompute the computation for the newly indicated ICE.
• the method for recomputing the computation is the same as that discussed above for computing a computation for an ICE.
• the ELM can first determine whether the PCE has been verified recently before again verifying it.
• each PCE can include a time of verification indicator.
• the time of verification indicator is initially set to the time when the event's indication in the event list is changed from ICE to PCE.
• the ELM checks whether the PCE has been verified recently by comparing to a threshold the difference between the current time and the time of verification indicator for the PCE. If the difference is less than the threshold, the
• PCE is not verified because it was verified recently. If the difference is greater than or equal to the threshold, the PCE was not verified recently and is verified using the verification method discussed above. Once the PCE is verified, the time of verification indicator is changed to the current time. The time of verification for each PCE is initially set to the time at which the event was indicated as a PCE.
• the invention can be implemented to increase the task throughput for any computer program implemented with a plurality of processors.
• the events are equivalent to tasks or sub-tasks.
• the execution speed of a computer program comprised of tasks and sub-tasks can be increased using a plurality of processors and the above methodology.
• the invention is applicable to any program that consists of a series of operations that have some degree of independence. As will be obvious to one of ordinary skill in the art, the extent to which these operations are independent is one of the factors determining the performance improvement that can be obtained. In many practical cases, DES ' s can be decomposed into events that are sufficiently independent to allow the approach of the invention to be utilized.

Landscapes

• Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Computer Hardware Design (AREA)
• Evolutionary Computation (AREA)
• Geometry (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (5)

Publications (1)

Family

ID=26731065

Family Applications (1)

Country Status (4)

Families Citing this family (1)

Family Cites Families (6)

• 1998
  • 1998-07-01 WO PCT/US1998/013696 patent/WO1999001816A1/en not_active Application Discontinuation
  • 1998-07-01 CA CA002295983A patent/CA2295983A1/en not_active Abandoned
  • 1998-07-01 EP EP98934228A patent/EP1010071A1/de not_active Withdrawn
  • 1998-07-01 JP JP50733699A patent/JP2002509629A/ja active Pending

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events