We study the impact of using different priority queues in the performance of Dijkstra’s SSSP algorithm. We consider only general priority queues that can handle any type of keys (integer, floating point, etc.); the only exception is that we use as a benchmark the DIMACS Challenge SSSP code [1] which can handle only integer values for distances. Our experiments were focussed on the following: 1. We study the performance of two variants of Dijkstra’s algorithm: the well-known version that uses a priority queue that supports the Decrease-Key operation, and another that uses a basic priority queue that supports only Insert and Delete-Min. For the latter type of priority queue we include several for which high-performance code is available such as bottom-up binary heap, aligned 4-ary heap, and sequence heap [33]. 2. We study the performance of Dijkstra’s algorithm designed for flat memory relative to versions that try to be cache-efficient. For this, in main part, we study the difference in performance of Dijkstra’s algorithm relative to the cache-efficiency of the priority queue used, both in-core and out-of-core. We also study the performance of an implementation

The priority queue is an useful data structure in computation. There currently exist many implementations of this data structure, including some that are cache-aware and some cache-oblivious. In this study, we compare the performance of several implementations of priority queues in Dijkstra’s Single Source Shortest Path algorithm. We compare high performance heaps, such as the 4ary Aligned Heap, Fast Binary Heap and Sequence Heap against in-house heap implementations, namely Buffer Heap and Auxiliary Buffer Heap, and against well-known implementations such as the textbook Binary Heap. We focus our analysis on the benefit of supporting decrease-key operations within the priority queue. Results indicate that graph density affect the relative performance of the different priority queues, and that using the Decrease-Key operation incurs unexpected performance hits. Furthermore, we will propose a parallel version of Buffer Heap which remains cache-oblivious and scales to a high level of parallelism. 1