Future Event List

1
Future Event List
2
Outline

• Preliminaries Required Operations
• Jones Comparison of Approaches
• Sleator/Tarjan Splay Trees
• Brown Calendar Queues
• Tang, et al. Ladder Queue

3
Event-Oriented Simulation
Event handler procedures
state variables
Event Handler k Schedule
Event Hander 1 Schedule
Integer InTheAir Integer OnTheGround Boolean
RunwayFree
Simulation application
Simulation engine
Event processing loop
While (simulation not finished) E smallest
time stamp event in FEL Remove E from FEL Now
time stamp of E call event handler procedure
Now 845
FEL Data Structure Priority Queue
4
Priority Queue Operations

• Required Operations
• Insert (FEL, event, timestamp)
• Add event ev with timestamp ts to event list FEL
• Event Delete (FEL)
• Remove smallest time stamp event and return a
  pointer to it
• DeleteArbitrary (FEL, event)
• Sometimes necessary to unschedule an event
• Delete an arbitrary event (not necessarily one
  with smallest timestamp)
• Constraints for a general simulation engine
• Maximum number of events required at one time
  unknown
• Memory allocation issues
• Amount of computation per event might be small
• event list computation time may dominate overall
  execution time
• Sequence of Insert and Delete operations unknown
• Distribution of timestamps on successive Insert
  operations unknown

5
Performance Comparison
D. Jones, An Empirical Comparison of
Priority-Queue and Event Set Implementations,
Communications of the ACM, 29, 4 (April 1986),
300-311.

• A number of priority queue data structures had
  been developed
• Linear linked lists
• Tree-based Heaps, splay tree,
• Hybrid Henricksens algorithm
• Which one yields the best performance?
• Approach empirical comparison of several
  different data structures

6
Example Data Structures

• Linked list sorted vs. unsorted single linked
  vs. double linked
• Implicit Heap
• Binary tree stored in array A with two properties
• n elements A1 An, children of Ai at
  A2i, A2i1
• Heap PropertyHP Ai.time ?A2i.time
  Ai.time?A2i1.time
• Delete smallest timestamped event (in A1)
• Let vAn, move v to spot vacated by A1
• Let ilocation where v resides if HP violated
  (A2iltv or A2i1ltv)
• Swap v with smaller of A2i and A2i1 to
  preserve HP
• Repeat this step
• Insert v
• An1v Let in1
• Let ii/2 (parent of v) if vltAi
• Swap v and Ai to preserve HP
• Repeat this step
• Worst case O(log2 n) swaps per insert or delete
  operation

7
Example
10
50
30
100
40
70
60
110
150
100
90
200
210
80

• Delete()

8
Example (cont.)
30
50
40
100
80
70
60
110
150
100
90
200
210

• Insert(35)

9
Example (cont.)
30
50
35
100
80
70
40
110
150
100
90
200
210
60
10
Methodology

• Hold model
• Repeatedly
• Remove smallest timestamp event (ts t)
• Compute a timestamp increment t from some
  distribution
• Insert new event (ts tt)
• Metric time to perform delete followed by insert
• Parameters varied in the study
• Event list algorithm linear list, heaps and
  trees, hybrids (e.g., Henriksen)
• Timestamp increment distribution exponential,
  uniform, biased, bimodal, triangular
• elements in event list (constant in hold model)
• Machine architecture (why does this affect
  performance?)

11
Performance Comparison

• Comparison of different data structures using
  exponential timestamp increment
• Exponential worst case for splay tree average
  case for others (based on empirical tests)

12
Conclusions Jones

• Linear list fastest nlt10, but very bad if ngt50
• Splay trees
• Stable items with same priority treated in FIFO
  order
• Supports delete arbitrary operation
• Reasonably good performance across different
  distributions
• Results tend to be architecture dependent (caches)

13
Splay Trees
D. Sleator, R. Tarjan, Self-Adjusting Binary
Search Trees, Journal of the ACM, 32, 3 (July
1985), 652-686.

• Binary search tree for any node (timestamp t)
• Left subtree nodes have timestamp lt t
• Right subtree nodes have timestamp ? t
• Smallest timestamp is at leftmost node
• Operations
• Delete remove leftmost item
• Insert traverse tree downward, insert at proper
  location
• Repeated insert/delete operations (e.g., repeated
  deletes) leaves unbalanced tree
• Could carefully rebalance after each operation
  (AVL tree)
• Splay tree
• Heuristic to blindly restructure tree using
  rotation operations
• Does not guarantee tree will be rebalanced worst
  case time per operation is O(n), but
• Amortized complexity (average over many
  operations) O(log2 n)

14
Binary Search Tree Example
100
40
180
20
130
80
210
10
30
70
90
110
170
200

• Repeated insert/delete operations unbalance tree
• Performance O(n0.5) Kingston, 1985

15
Splaying Operation
16
Calendar Queues
R. Brown, Calendar Queues A Fast O(1) Priority
Queue Implementation for the Simulation Event Set
Problem, Communications of the ACM, 31, 10
(October 1988), 1220-1227.

• Analogous to desk calendar
• Array of buckets denoting a time interval
  (e.g., 365 buckets, 1 day/bucket, spanning a
  year)
• Each bucket points to sorted linear list of
  events scheduled for that day
• Events scheduled for next year simply placed in
  corresponding bucket (day)
• Keep pointer to bucket with smallest timestamp
  event (today)

17
Calendar Queue Example
18
Calendar Queue Operations(preliminary version)

• Insert
• Map timestamp to appropriate bucket
• Perform linear list insertion into list
• Delete
• Starting from current (today) bucket
• If first event in current year, remove it
• Else, go to next bucket if last bucket, advance
  to next year

• Potential problems
• Long linear list
• Need to scan many buckets on delete operation

19
Problems and Solutions

• Wrong number of buckets
• If events gtgt buckets
• Long linear list, long insert time
• If events ltlt buckets
• Long delete time (scan many empty buckets)
• Solution resize number of buckets
• If events gt 2 buckets, double buckets
• If events lt 0.5 buckets, halve buckets
• Resizing requires copying events expensive
• Poor choice of length for a day
• Ideally, about one event per day
• If day too long, many events in today bucket
  (long insert time)
• If day too short, many events in later years
  (long delete time)
• Solution Sample some events to estimate average
  time between events and set day length to that
  value perform at each resize operation

20
Problems and Solutions (cont.)

• Bimodal distribution of events
• Many events in current year, next events many
  years in future
• After removing current year events, must cycle
  through all buckets repeatedly to reach far
  future events
• Solution If scan through all buckets w/o
  success, search for smallest timestamp event by
  scanning all buckets

21
Performance Measurements

• Hold model, exponential distribution

22
Timestamp Increment Distribution

• Claim O(1) insertion and deletion times
• Do you agree with this conclusion?

23
Dynamic Queue Size
24
Calendar Queues

• Well behaved (i.e., hold like) behavior results
  in excellent performance for test cases
• Often significantly faster the O (log n) data
  structures
• In practice, extremely poor performance sometimes
  observed, due to excessive resizing operations or
  many items mapping to the same bucket (e.g., see
  Tang et al.)
• More recent refinements (e.g., Ladder Queue)
  offer variations on original calendar queue idea

25
Performance Comparison
W.T. Tang, R.S.M. Goh, I.L-J. thng, Ladder
Queue An O(1) Priority Queue Structure for
Large-Scale Discrete Event Simulation, ACM
Transactions on Modeling and Computer Simulation,
15, 3 (July 2005), 175-204. (Fig. 5, p196)
26
Conclusions

• Priority queue performance can be important for
  some very large simulations (hundreds of
  thousands to millions of events in FEL)
• Variety of implementations exist no consensus on
  the fastest available data structure
• Linear list generally fastest for small event
  lists
• O(1) data structures offer best performance for
  many applications, but can yield surprisingly
  poor performance in some cases
• O (log n) data structures more predictable,
  though often not the fastest available approach
• Depends on machine architecture (e.g., memory
  locality)