DSplay: An Efficient Dynamic Priority Queue Structure For Discrete Event Simulation

Transcription

1 DSplay: An Efficient Dynamic Priority Queue Structure For Discrete Event Simulation Rick Siow Mong Goh & Ian Li- Jin Thng Department of Electrical and Computer Engineering, National University of Singapore & Abstract. Priority queues are widely employed in numerous applications such discrete event simulations (DESs). The priority queue structure plays an integral role of managing the pending event set of a DES. The priority queue contains events where the minimum timestamp event has the highest priority and the maximum timestamp event has the lowest priority. A Calendar Queue (CQ) is a useful structure often employed in DESs. Its popularity is due to its expected O(1) access time for many simulation scenarios, provided the CQ resizes appropriately frequent to ensure that events are evenly distributed in the CQ structure. The resize operation is triggered whenever the number of events fluctuates significantly or when a skewed event distribution is detected. A resize operation is costly as it copies events from the old CQ structure to a newly-created one. Other CQ variants such as the Dynamic CQ and SNOOPy exhibit somewhat futile attempts to improve the heuristics involve in triggering the resize operation. This article introduces a novel priority queue implementation known as the Dynamic Splay Tree (DSplay) structure which does not require the resize operation to obtain near O(1) performance. The DSplay is also empirically shown to be on the average at least 100% faster than all the current priority queues. 1. INTRODUCTION Priority queues are used in a wide variety of applications such as data compression techniques, realtime systems, operating systems and discrete event simulations (DESs). DES is a type of simulation that involves discrete models where a system is modeled as a number of concurrent logical processes interacting by a set of pending event messages. An event may change the state of the system and has an associated timestamp that corresponds to the instance of its intended occurrence in the simulated time. The pending event set (PES) is defined as the set of all events generated during a DES that have not been simulated or evaluated yet. The PES is essentially a priority queue controlling the flow of simulation of events with the minimum timestamp having the highest priority and maximum timestamp having the least priority. These events should be processed in nondecreasing time-order with multiple events of equal timestamp being processed in the order that they are inserted into the PES. If processed in this manner, causality relations between these events would not be violated. A sequential DES frequently operates in a three-step cycle: dequeue removal of an event with the highest priority from the PES; execute to process this dequeued event; enqueue insertion of new event/s resulting from the execution into the PES. Comfort [1] has revealed that up to 40% of the computational effort in a simulation may be devoted on the management of the PES alone. In the management of the PES, the enqueue and dequeue operations account for as much as 98% of all operations on the PES [1]. Understandably, as a simulation system becomes larger, the length of simulation time may take days or weeks to yield results with an acceptable level of statistical error. Hence the priority queue employed should be efficient especially for large-scale simulations that involve large number of events during the execution of simulation models. The metric of interest in the variety of applications is the time required to perform the most common operations on the embedded priority queue within each application, namely, the enqueue and dequeue operations. This metric is referred to as access time [2]. For DES, the amortized (i.e. averaged over the number of events in the queue) access time [3] is undoubtedly the most important criterion in selecting the appropriate priority queue algorithm. This is because from a user s point of view, the total run-time of a simulation job is by far more important than the time-taken by each individual priority queue operation. The assortment of proposed priority queues can be characterized mainly into two categories: tree-based and list-based. Example of a popular tree-based priority queue is the Splay Tree [4], which is famous for its O(log(n)) amortized access time. The Splay Tree has been shown empirically to outperform other tree-based structures [2]. Examples of some applications of the Splay Tree include: the pending event set structure in the CelKit [5], the data structure for fast IP lookups [6] and in the block sorting process of Burrows and Wheeler [7]. List-based priority queues are mainly popularized by the widely used Calendar Queue (CQ) [8]. Although it has a worst-case amortized bound of O(n); equivalent to the bound of a linear linked list, the CQ has been employed in various simulation systems such as GTW[9], CSIM18 [10], Network Simulator v2 [11], as well as in a quality of service algorithm where it maintains the real-time packet requests [12]. However, the CQ is known to perform poorly at O(n) when the event distribution is highly skewed. A few CQ variants such as the Dynamic CQ (DCQ) [13] and SNOOPy CQ (SNOOPy) [14] have since been proposed to deal with

2 this scenario. But experiments conducted by the authors show that these CQ variants too have shortcomings in some benchmark scenarios. This paper proposes a novel yet simple approach of using a single Splay Tree with traditional linked lists, henceforth referred to as the Dynamic Splay (DSplay) structure. Employing deferred sorting methodology and uniquely eliminating the costly resize operations suffered by current O(1) priority queues, the DSplay achieves excellent performance. The rest of the paper is organized as follows: Section 2 focuses on the DSplay algorithm; Section 3, the experimental results; finally in Section 4, the conclusion. 2. DYNAMIC SPLAY (DSPLAY) PRIORITY QUEUE The poor performance of the CQ is often due to two reasons. Firstly, the static-resize rule in which the CQ resizes only if the number of events doubles or halves compared to the number of events after the last resize. The CQ computes the new bucketwidth by sampling some high-priority events before transferring all the events to the newly constructed structure. However, under highly-skewed distributions, most events may fall into some few lists. If the number of events does not vary much, the CQ does not resize due to its static rule. As such, the enqueueing of events in those congested buckets can be as expensive as O(n) per enqueue since a linear search is required to find the correct position of the event to be enqueued in that crowded bucket. Secondly, large overheads in the O(n) resize operation, which can be frequent if the number of events in the PES fluctuates greatly. This occurs when there are many successive enqueues or dequeues that leads to frequent resizing of the number of buckets in the CQ. During a resize operation, the overhead incurred is considered significant as most or all the events are redistributed in a newly-created queue with new operating parameters such as a newly-calculated bucketwidth. Furthermore, the events in the CQ are already sorted. To re-enqueue these sorted events is highly inefficient. The CQ variants such as DCQ and SNOOPy use different approaches of determining the optimum operating parameters of CQ to attempt to solve some of these problems. DCQ and SNOOPy are however experimentally found to have performed worse than CQ in some scenarios (see section 3). The design of DSplay is based on the desirable characteristics of both tree-based (i.e. Splay Tree) and list-based priority queues (i.e. CQ): worst-case bound of O(log(n)) and the expected O(1) amortized access time respectively. DSplay improves over the CQs by not requiring a resize operation. It depends on its list-based structure of spreading out events to deal with skewed distributions. Unlike the CQs, no heuristic event sampling is required to obtain the appropriate bucketwidth of its list-based structure and this further reduces its overhead. Also, the DSplay utilizes a deferred sorting methodology in which a small number of high priority events are sorted in the tree-based portion (i.e. Splay Tree) of its structure, leaving the far future events unsorted. The Splay Tree ensures that the worst-case amortized bound is O(log(n)) per event instead of O(n) which is the amortized complexity of the CQs while the list-based portion of DSplay facilitates in achieving an expected O(1) amortized access time for many simulation scenarios. 2.1 The DSplay Structure The main building blocks of the DSplay are made of three tiers. The first-tier (T 1 ), is a Splay Tree. This is the primary tier of the DSplay in which the events with the minimum timestamps are sorted and stored. Second-tier (T 2 ) is an array of buckets each containing a singly linked list (i.e. a sub-list). This list-based secondary tier stores events differently from the CQs as the CQs employ sorted sub-lists discipline while T 2 uses an unsorted sub-lists discipline. Also, events in the sublists of the CQs could span multiple years while the DSplay s T 2 is a list-based structure which only spans a calendar year. Finally, the third-tier (T 3 ) is an unsorted singly linked list. Acting as an overflow list to contain far future events, T 3 buffers events that do not affect T 1 and T 2. This reduces the number of events in both T 1 and T 2 and is responsible for ensuring that T 2 spans a calendar year. In addition, this last tier is the novelty behind the dynamic mechanism of the DSplay. 2.2 The DSplay Algorithm The DSplay marks the first departure from the CQs heuristic method of determining the number of buckets as well as the bucketwidth by making its T 2 to be dependent on its T 3. T 2 s length of 1 year, the number of buckets and the bucketwidth are dynamically assigned only when T 3 transfers events into T 2. This will become more vivid when the dequeue and enqueue operations are explained. The DSplay keeps a set of variables to function and they are defined as follow: T 1 _num: Number of events in T 1. T 2 _start: Set equal to T 3 _min whenever events are being transferred from T 3 to T 2. It is used to calculate the correct bucket-index when an event is enqueued in T 2. T 2 _cur: Minimum timestamp which events can be enqueued in T 2. This is updated when T 2 transfers a bucket of events to T 1. T 2 _num: Number of events in T 2. T 2 _bw: Bucketwidth of T 2. T 2 _idx: Bucket-index of T 2 when events are transferred from T 2 to T 1. T 3 _cur: Minimum timestamp of an event that can be enqueued in T 3. This value will be set equal to T 3 _max at each transfer of events from T 3 to T 2. T 3 _min: Minimum timestamp in T 3. T 3 _max: Maximum timestamp in T 3. T 3 _num: Number of events in T 3.

3 2.2.1 Dequeue Operation At the onset, all enqueued events are placed in T 3 in a FIFO manner without time-order thus leaving T 1 and T 2 being empty. On the first dequeue, all the events are transferred from T 3 to T 2. The length of 1 year in T 2 = T 3 _max T 3 _min. T 2 _bw = 1 year in T 2 / T 3 _num, where T 3 _num is the number of buckets to be created in T 2, giving an average of one event per bucket on the assumption that the event distribution is a uniform distribution. Though in practical scenarios this may not be true, the DSplay is not much affected in terms of performance because the enqueue of events into T 2 is still O(1) per event since events are merely appended to the sub-lists in the appropriate buckets. Thereafter, the events in the first bucket of T 2 (where T 2 _idx = 1 and that T 2 _cur = T 2 _start = T 3 _min have been initialized) will be transferred to T 1 (i.e. a Splay Tree) where events are sorting according to the native operations of a Splay Tree. T 2 _idx is incremented to 2 and T 2 _cur is then set = T 2 _start + T 2 _idx * T 2 _bw. Thus the highest priority event would be the first event in T 1. On each dequeue, the highest priority event would be removed from T 1 and then processed. Events in T 1 would continue to be dequeued until T 1 is empty. Subsequently, the events in the second non-empty bucket of T 2 would be transferred to T 1 and so on till all the buckets are empty. Thus, essentially a Splay Tree is dynamically created on each transfer of a bucket in T 2 to T 1 and then depleted. These reiterations led to the coining of the name DSplay. Once T 2 is empty, the whole cycle repeats itself with T 3 treating the next dequeue to be alike the first dequeue as mentioned Enqueue Operation For each enqueue operation, DSplay checks if that event timestamp is greater than T 3 _cur. If so, the event is simply placed at the end of the linked list in T 3. If the event is not inserted in T 3, DSplay then checks if the event timestamp is greater than T 2 _cur. If so, the event is enqueued in T 2. On enqueueing in T 2, the bucketindex of the bucket where this event is to be inserted in T 2 is set = (timestamp T 2 _start) / T 2 _bw, and the event is appended at the tail of the sub-list in that bucket with this bucket-index. Else if the event is not enqueued in T 2 or T 3, that event will be enqueued in T EXPERIMENTAL RESULTS The performance of priority queues are often measured by the average access time of the enqueue and dequeue operations under different load conditions. The parameters to be varied for each priority queue performance benchmark are: the access pattern, the priority increment distribution and the queue size. The access pattern models used are the Classic Hold and Up/Down. They emulate the steady-state and the transient phase of a typical simulation respectively. The various priority increment distributions tested are as shown in Figure 1, which return random numbers [0,1], and the queue sizes range from 1,000 to 30,000. These benchmark scenarios had also been commonly applied in [2],[13],[14],[15]. The experiments were carried out on an AMD Athlon MP 1.2GHz dual-processor server running the priority queues sequentially. Required memory was pre-allocated. All code was written in the C programming language. Rectangle NegTriangle Triangle Camel Figure 1: Various Priority Increment Distributions Employed in the Experiments The Camel(x,y) distribution is used to model bursty traffic in computer and communication networks which represents a highly-skewed distribution. The parameters used for Camel(x,y) result in two humps with x probability mass being concentrated in the two humps. The duration of the humps makes up y of an interval, where x and y are (0,1). Change(A,B,x) is a compound distribution that combines priority distribution A and B, with x priority increments being alternately drawn by A and B. In our experiments, Camel(0.7,0.2), Camel(0.98, 0.01), and Change(Camel(0.98, 0.01),Triangle, 2000) are used. Figure 2: Classic Hold and Rectangle

4 Figures 2 to 7 illustrate the results obtained under the Classic Hold model commonly employed to test the steady-state performance of priority queues. The obvious knee seen in the curves plotted is due to the declining cache performance and occurs when the queue size is about 6,000 events. This phenomenon is also observed in the graphs found in [2] where the experiments were done on SUN and Intel architectures. Figures 6 and 7 vividly reveal the weaknesses found in the CQs which are mainly due to their static size-based resize and their poor sampling heuristics which are unable to handle skewed distributions. The Splay Tree performs predictably at O(log(n)) and is only convincingly better than the CQs for the Change distribution. The speedup DSplay offers over the Splay Tree is two to three times in almost all the scenarios. Figure 5: Classic Hold and Camel(0.7,0.2) Figure 3: Classic Hold and Triangle Figure 6: Classic Hold and Camel(0.98,0.01) Figure 4: Classic Hold and NegTriangle Figure 7: Classic Hold and Change(Camel(0.98, 0.01), Triangle, 2000)

5 Figure 8: Up/Down and Rectangle Figure 11: Up/Down and Camel(0.7,0.2) Figure 9: Up/Down and Triangle Figure 12: Up/Down and Camel(0.98,0.01) Figure 10: Up/Down and NegTriangle Figure 13: Up/Down and Change(Camel(0.98, 0.01), Triangle, 2000) Figures 8 to 13 show the results obtained under the Up/Down model that is generally used to test the transient state performance of priority queues. This model tests the performance of the priority queues during transient periods when the queue size fluctuates frequently and it indeed uncovers the CQs weaknesses

6 manifested in the form of the various plateaus in the figures. The Splay Tree performs well and is stable for all queue sizes and distributions. The DSplay performs more than 100% better than the priority queues almost all the scenarios. Figures 14 and 15 demonstrate the strengths of the DSplay priority queue. It performs stably and offers good performance for all queue sizes and is considerably insensitive to event distribution. Figure 14: Classic Hold Model DSplay Figure 15: Up/Down Model DSplay 4. CONCLUSION The current expected O(1) priority queues do not exhibit O(1) average time complexity in some scenarios tested under the commonly used benchmarking models and distributions. A new priority queue implementation for the pending event set has been illustrated and tested with empirical results showing performance surpassing current structures and consistently exhibits better performance in all distributions and queue sizes tested. The DSplay s performance improvement of 100% on the average and up to 10 times more than some current priority queues in certain scenarios is owed to the fact it does not have the costly resize operations that severely affect the current priority queues. To handle skewed distributions, the DSplay employs two list-based structures with deferred sorting methodology, as well as a Splay Tree to efficiently manage a small number of sorted events. These mechanisms contribute to the low management overheads and consequently ensure the DSplay s superiority over the current expected O(1) priority queues. These results provide testimonial that the DSplay priority queue structure is suitable for implementation in sizable application scenarios such as, but not limited to discrete event simulation. REFERENCES 1. Comfort, J.C. (1984) The simulation of a master-slave event set processor, Simulation, vol. 42, pp Rönngren, R. & Ayani, R. (1997) A Comparative Study of Parallel and Sequential Priority Queue Algorithms, ACM Trans. Modeling and Computer Simulation, vol. 7, no. 2, Apr, pp Tarjan, R.E. (1985) Amortized computational complexity, SIAM Journal on Algebraic and Discrete Methods, vol. 6, no. 2, pp Sleator, D. & Tarjan, R. (1985) Self adjusting binary search trees, Journal of the ACM, vol. 32, pp Gomes, F., Franks, S., Unger, B., Xiao, Z., Cleary, J., & Covington, A. (1995) SimKit: A high performance logical process simulation class library in C++, Proc. of the 1995 Winter Simulation Conference, pp Narlikar, G. and Zane, F. (2001) Performance modeling for fast IP lookups, Proc. of the 2001 ACM SIGMETRICS international conference on Measurement and modeling of computer systems, pp Yugo, K. I. R., Moffat, A., & Ngai, C. H. A. (2002) Enhanced word-based block-sorting text compression, Proc. of the twenty-fifth Australasian conference on Computer science, pp Brown, R. (1988) Calendar queues: a fast O(1) priority queue implementation for the simulation event set problem, Communications of the ACM, vol. 24, no. 12, pp Das, S., Fujimoto, R., Panesar, K., Allison, D., & Hybinette, M. (1994) GTW: a time warp system for shared memory multiprocessors, Proc. of the 1994 Winter Simulation Conference, pp Schwetman, H. (1996) CSIM18 User s Guide. Austin, TX: Mesquite Software, Inc. 11. Fall, K. and Varadhan, K. (2002) The ns Manual. UCB/LBNL/VINT Network simulator v Stoica, I., Zhang, H., & Ng, T.S.E. (2000) A hierarchical fair service curve algorithm for link-sharing, real-time, and priority services, IEEE/ACM Trans. Networking, vol. 8, no. 2, Apr, pp Oh, S-H. & Ahn, J.S. (1998) Dynamic Calendar Queue, Proc. 32nd Annual Simulation Symposium, pp Tan, K.L. & Thng, L-J. (2000) SNOOPy calendar queue, Proc Winter Simulation Conference, pp Jones, D.W. (1986) An empirical comparison of priority-queue and event-set implementations, Communications of the ACM, vol. 29, no. 4, pp