On the Energy Behaviors of the Bellman–Ford and Dijkstra Algorithms: A Detailed Empirical Study

Abstract

The Single-Source Shortest Paths (SSSP) graph problem is a fundamental computation. This study attempted to characterize concretely the energy behaviors of the two primary methods to solve it, the Bellman–Ford and Dijkstra algorithms. The very different interactions of the algorithms with the hardware may have significant implications for energy. The study was motivated by the multidisciplinary nature of the problem. Gaining better insights should help vital applications in many domains. The work used reliable embedded sensors in an HPC-class CPU to collect empirical data for a wide range of sizes for two graph cases: complete as an upper-bound case and moderately dense. The findings confirmed that Dijkstra’s algorithm is drastically more energy efficient, as expected from its decisive time complexity advantage. In terms of power draw, however, Bellman–Ford had an advantage for sizes that fit in the upper parts of the memory hierarchy (up to 2.36 W on average), with a region of near parity in both power draw and total energy budgets. This result correlated with the interaction of lighter logic and graph footprint in memory with the Level 2 cache. It should be significant for applications that rely on solving a lot of small instances since Bellman–Ford is more general and is easier to implement. It also suggests implications for the design and parallelization of the algorithms when efficiency in power draw is in mind.

1. Introduction

One of the main issues with the latest generation of high-performance computing (HPC), developed mainly to surpass the performance of its predecessor, is power consumption. Due to the increased computation rates of the new systems, some problems may demand more care than others in terms of power draw, i.e., the rates at which they consume energy. In those settings, even a slight power advantage, when accumulated efficiently, may result in substantial savings due to the massive workload capacities. Previous studies along that line of thinking [1,2] encouraged a renewed look into classic HPC problems based on their energy behaviors. This work focuses on the Bellman–Ford and Dijkstra algorithms, two well-known methods for solving the single-source shortest paths (SSSP) problem.

The usual choices of algorithms based on time efficiency may not always be the best if aiming for a lower power footprint. For example, quicksort and mergesort are in the same average time complexity class. However, quicksort is invariably preferred since it runs faster. Work reported in [1,2] showed different versions of mergesort to be more power-efficient than quicksort. The first study examined bitonic mergesort, optimized for the GPU, while the second looked into the unoptimized natural version on a conventional CPU. In particular, the second one showed the natural mergesort to consume less power than a classically optimized 3-way fast quicksort, which the authors of that study interpreted as evidence pointing to mergesort having, perhaps, a natural algorithmic advantage. In [3], the study found that the faster 3-way version of the binary search consumed more power than the classic 2-way one in some practical scenarios. The savings in power, in some cases, may not have been impressive enough at face value. However, even little differences may cause consequential system-wide effects if a computation is a significant fraction of typical workloads, especially in huge systems with massive ones. The SSSP problem is a crucial component of some valuable high-performance workloads.

The SSSP problem is an extensively studied fundamental problem in graph theory with practical applications in diverse domains. Some of the most obvious can be found in navigation (e.g., Google Maps), goods distribution (e.g., warehouse to sales outlets), and telecommunication and computer networks (e.g., packet routing and broadcasting). Other prominent ones include optimizing communication and data movement in parallel systems [4], games [5], and path planning in self-driving cars [6]. Recent application areas include drones and smart cities. In the emerging field of cognitive computing, SSSP was proposed as a basis for a situationally adaptive scheduler for workloads in that domain [7]. Applications of shortest path problems, including the basic single-source version, may be found in networks where costs are associated with junctions also, such as waiting times or delays or some other node penalty [8]. Some networks of sensors and actuator nodes have applications that require efficient routing and propagation of signals [9] to help meet certain operational or quality of service needs. For example, in [10], Disjkstra’s algorithm was used as a blueprint for an energy-aware multicast routing for sensor actuator networks over wireless links using localized shortest path trees. It also served in [11] as the basis of the underlying routing topology while dealing with node placement, a fundamental problem for wireless sensor networks (WSNs). A good scheme could simplify routing and improve performance as a result. Dijkstra provided the shortest paths with the fewest hops between the signal source and sink nodes. Generally, sensor and actuator networks offer an array of potential applications for the SSSP problem and variants in diverse areas, such as production, healthcare, and automatic control [10].

In concept, consideration of SSSP is critical in optimizing routes and minimizing travel costs along links. The graph may be directed or undirected, and the edge weights may be positive or negative. The problem involves finding the shortest paths, in terms of total edge weights, from a given source vertex to all other vertices in a weighted graph. Technically, the solution is a family of paths that compose a singly rooted spanning tree. The weights of the shortest paths are unique but may be satisfied by different trees. Dijkstra’s algorithm [12] and the older Bellman–Ford [13,14] are the primary methods to solve the SSSP problem. Their approaches greatly vary, yielding strikingly different operational efficiency. Dijkstra uses a greedy approach based on a priority queue to solve in minimal steps [5]. It favors solutions with paths with fewer edges since it uses a breadth-first search (BFS) as a front end for vertex exploration. Its main advantage is reaching its destinations without traversing unnecessary nodes, but the edge weights may only be non-negative. The resulting time complexity is linearithmic if the queue uses a binary heap with the minimum key at the root and the graph is represented by its adjacency lists. A Fibonacci heap offers constant time queue insert operations [15] vs. logarithmic in a binary heap, leading to a better upper bound on the run time growth of Dijkstra under some conditions (see p. 585 in [16]). Bellman–Ford employs dynamic programming. It can navigate graphs to detect negative weight cycles [5]. It is more versatile than Dijkstra at the expense of quadratic time complexity. Programming these algorithms is not a trivial task. Achieving linearithmic efficiency in Dijkstra requires a properly implemented priority queue.

The preceding should highlight the foundational nature of the SSSP problem and its multidisciplinary role. Work reported in [7] was particularly interesting to the authors of this study. It sits at a crossroads of two main application areas: managing large high-performance workloads and cognitive computing. Hence, it is perhaps important to gain as much insight into the energy behaviors of its main algorithms as possible. The ongoing ubiquity of the SSSP computation and the power concerns of the new large systems motivated a new look into an old problem through a fresh approach. It may inspire, at least in some cases, a revisiting of old choices based on time complexity alone.

This research investigated the energy behaviors of the two principal algorithms for solving the SSSP problem. The algorithms, particularly Dijkstra’s, were optimized extensively. This study, however, focused on the most basic forms to identify which of the pair offered some natural advantage, perhaps due to the fundamentally different way it solved the problem or how its logic interacted with the hardware. It is reasonable to assume that this approach could provide a better platform for further efforts. The energy behaviors were explored empirically using recently established techniques. The study aims to quantify and analyze those behaviors. Power, the energy time rate, was examined as a separate concern. The main contribution of this work is a step towards a thorough review, based on a concrete real-world assessment, of the power and energy characteristics of the main methodical approaches behind the computation of the SSSP. It hopes to offer insights and recommendations, with power and energy as primary concerns, usable in the numerous applications from diverse areas that rely in various ways of solving the problem. For example, the insights gained about power draw may help design better solutions for sensor and actuator networks that depend on limited power sources, such as batteries. A reduced power footprint should also help cases where the network operates in an environment prone to thermal failures. Networks deployed in smart city and municipal settings are examples. The work also supports, for energy concerns, a need to look beyond classic time analysis.

In the context of this paper, the terms energy and power are not interchangeable. They are used here in their proper physical sense, where power is strictly the time rate of energy expenditure in watts. The phrase “energy behaviors” refers to all energy concerns generically. Algorithms are colored consistently across the figures, with edge density indicated by tone of color. The paper is structured as follows: Section 2 reviews selected past research. Section 3 outlines the methodology and details the procedures and materials used for this research. The findings are presented and discussed in Section 4. Section 5 closes with suggestions for future work after some final thoughts and concluding remarks.

2. Literature Review

As mentioned earlier, the SSSP problem has been the subject of broad interest in the past 60–70 years since the Bellman–Ford algorithm was published separately by R. Bellman, L. Ford, and E. Moore [17] (hence, it is also referred to as Bellman–Ford–Moore), leading to a large body of published work. Previous work tended to focus on speed in various hardware or application environments. The energy studies, for the most part, relied on complex modeling or simulation under such conditions. There was a lack of realistic data on the essential energy interactions with the machines. In this section, the authors attempt to sample the ongoing work on the two algorithms in the past decade to address either energy or other classic optimization concerns, such as running time or efficiency for some valuable special conditions or application areas. The review is in chronological order.

Table 1. Summary of the papers reviewed in this section.

Study	Year	Algorithm(s)	Focus	Contribution	Study Method
Kalpana & Thambidurai [18]	2011	Dijkstra	Runtime	Significantly enhanced runtime and vertex visit count of Dijkstra’s algorithm.	Experimental (empirical data, code timers)
Zhang et al. [19]	2013	Dijkstra, Bellman–Ford	Runtime	Bellman–Ford was exceptionally efficient on grid maps, reducing processing time.	Experimental (data collected from simulation)
Hajela & Pandey [20]	2014	Bellman–Ford	Runtime	Achieved a 2.88x acceleration for SSSP and 3.3x for APSP problems.	Experimental (empirical data, code timers)
Abousleiman & Rawashdeh [21]	2015	Bellman–Ford	Energy	Optimized energy consumption for electric vehicle journeys.	Experimental (data collected from simulation)
Busato & Bombieri [22]	2015	Bellman–Ford	Runtime	Optimized Bellman–Ford for faster execution on Kepler GPU structures.	Experimental (emprical data, code timers)
Mishra & Khare [23]	2016	Dijkstra	Power	Identified optimal frequency pairs for power or performance gain.	Experimental (empirical data, physical power meter)
Cheng [24]	2017	Dijkstra, Bellman–Ford	Efficiency	Introduced extended algorithms solving GSSSP efficiently under specific conditions.	Math/modeling
Schambers et al. [25]	2018	Bellman–Ford	Energy	Generated energy-efficient routes with Bellman–Ford while maintaining performance standards.	Experimental (data collected from simulation)
Abderrahim et al. [26]	2019	Dijkstra	Energy	Minimized energy consumption in WSNs using clustering and relay selection.	Experimental (data collected from simulation)
Weber et al. [27]	2020	Bellman–Ford	Runtime	Effectively handled negative cost values and parallel execution.	Math/modeling
Rai [28]	2022	Bellman–Ford, Dijkstra	Runtime	Highlighted Bellman–Ford’s versatility in handling negative weights, but with higher time complexity.	Math/modeling

summarizes the reviewed works with their methods and contributions in contrast with the present work.

Kalpana and Thambidurai [18] introduced COAB, a method for optimizing shortest path queries through a blend of arc flags and bidirectional search. Executed on an AMD Athlon X2 Dual Core CPU paired with 4 GB of RAM and Ubuntu 9.04, using LEDA, COAB significantly enhanced the runtime and vertex visit count of Dijkstra’s algorithm, particularly on real-world graphs. However, the paper lacked a discussion on COAB limitations, such as scalability issues or performance variations on different graph types. Future work suggested, chiefly, was to explore combining the bidirectional arc flag vector with additional speedup techniques and parallelizing other preprocessing phases.

Zhang et al. [19] conducted an experimental evaluation to compare Dijkstra’s, Bellman–Ford, and the Shortest Path Faster Algorithm (SPFA) on random and grid maps. The key finding was an enhanced Bellman–Ford exceptional efficiency on grid maps, reducing processing time by two-thirds compared to SPFA. However, the improved version faced limitations. It was less efficient when the graph size was generated randomly, taking longer than the others. Additionally, it encountered challenges with depth problems, requiring excessive iterations in specific cases to find the shortest path.

Hajela and Pandey [20] proposed a hybrid implementation of the Bellman–Ford algorithm for solving shortest path problems using OpenCL. They divided the work between the CPU and GPU in a 1:3 ratio, which was the most efficient based on testing different ratios. The authors obtained a 2.88x acceleration compared to the parallel GPU implementation in solving SSSP problems and a 3.3x enhancement for All-Pairs Shortest Paths (APSP) problems. However, a limitation was that results were only from graphs with edge weights between $-10$ and 10. The authors suggested that future work could focus on partitioning the algorithm for hybrid implementation rather than dividing the vertices.

Abousleiman and Rawashdeh [21] presented a novel approach to energy-efficient routing for electric vehicles via the Bellman–Ford algorithm. The authors proposed a modified version of the algorithm that considered some factors to optimize energy consumption during a journey, such as road gradient and traffic conditions. The methodology involves using real-world data and simulation to verify the efficacy of the proposed method. However, the paper acknowledged limitations in the accuracy of energy consumption models and the need for extensive computational resources for large-scale implementation. Further research was suggested to address these challenges and improve the practical applicability of the proposed method.

Busato and Bombieri [22] introduced a streamlined Bellman–Ford algorithm implementation tailored for Kepler GPU structures. The authors utilized the parallel processing capabilities of GPUs to significantly speed up the execution of the Bellman–Ford algorithm, which is traditionally computationally intensive. They optimized the use of shared memory and reduced thread divergence to achieve the increase. However, the paper acknowledges that the proposed implementation may not be as effective on non-Kepler architectures due to differences in hardware design. Furthermore, the paper does not address how the algorithm would perform with larger datasets that exceed the memory capacity of the GPU.

Mishra and Khare [23] investigated the efficacy of the Dijkstra algorithm on actual GPU hardware, delving into power, energy, and performance analysis. They employed Dynamic Voltage Frequency Scaling (DVFS) for energy conservation. They analyzed the algorithm at various frequency pairs and identified the optimum frequency pair for achieving either energy or performance gain. However, the paper did not address how the algorithm would perform with larger datasets that exceed the memory capacity of the GPU. Further research is needed to extend this methodology to a broader range of data sizes.

Cheng [24] introduced an extended version of the Dijkstra and Moore-Bellman–Ford algorithms to address the general SSSP problem (GSSSP). They presented novel ideas, such as order-preserving within the path function last road (OPLR). The author developed an extended Moore–Bellman–Ford algorithm (EMBFA) and an extended Dijkstra’s algorithm (EDA) tailored to specific conditions for GSSSP. Key findings included proof of efficiency, solving the problem in $O\left(n^2\right)M\left(n\right)$ time for EDA and $O\left(mn\right)M\left(n\right)$ time for EMBFA, with n as vertices, m as edges, and $M\left(n\right)$ as the time to obtain the path function value. However, the effectiveness of the algorithms depends on specific conditions, and their time complexity may be high for large graphs.

Schambers et al. [25] presented a novel approach to energy-efficient route planning for electric vehicles. The authors suggested a parallel adaptation of the Bellman–Ford algorithm for an embedded GPU system. This system can process negative edge weights, a functionality absent in conventional algorithms like Dijkstra’s or A*. Such an approach enabled the generation of routes with significantly lower energy consumption, all while upholding the performance standards of standard route planning software. However, the increased computational complexity of the Bellman–Ford algorithm and the need for reasonable processing speeds were acknowledged as limitations, leading to the suggestion of further research to address these challenges and improve the practical applicability of the proposed method.

Abderrahim et al. [26] introduced an energy-efficient multi-hop transmission method tailored for Wireless Sensor Networks (WSNs), utilizing the Dijkstra algorithm. The approach encompasses clustering sensor nodes, appointing cluster heads, and categorizing nodes into active and dormant states. Additionally, it selects a set of dependable relays to transmit data with minimal power consumption. This advancement builds upon earlier research by significantly mitigating power usage, surpassing the efficiency of prior transmission techniques. Nonetheless, the study overlooked assessing the performance with larger datasets beyond the network’s capacity.

Weber et al. [27] gave a generalized Bellman–Ford algorithm for symbolic optimal control. The algorithm was designed to handle cost functions that can take arbitrary values, including negative ones, and allowed for parallel execution. The authors demonstrated effectiveness through a detailed four-dimensional numerical example of aerial firefighting with UAVs (unmanned aerial vehicles). The key findings included the ability to handle negative cost values and efficient parallel execution. However, the performance depended on the dimensionality of problems, with challenges when the state-space dimension was high. The algorithm also required defining the cost functions in a specific way, which may limit its applicability in some scenarios.

Rai [28] conducted a comparative study on the Bellman–Ford and Dijkstra algorithms for shortest paths detection in Global Positioning Systems (GPSs). The author implemented both algorithms on a graph and analyzed their results. The key findings suggest that while both algorithms can effectively find the shortest path, the Bellman–Ford algorithm is more versatile as it can handle negative weights and visit a vertex more than once, thus providing an optimal path. However, the time complexity of Bellman–Ford was not better than Dijkstra, which could be a limitation for large networks. The author suggests that future research could focus on developing new algorithms based on Bellman–Ford for use in GPS systems.

3. Methods, Tools, and Procedures

This section starts by outlining the methodology used for the research, highlighting its main features, and proceeds to describe the experimental work in the following subsections. These detail the test datasets and the process used to generate them, the tools and materials used to obtain the code and the measurements, and the test environment and the measures employed to ensure credible results.

3.1. Methodology

The objective of the investigation is to gauge power consumption that may be attributed credibly to the computational characteristics of the algorithms. An algorithm, of course, is an abstract object. It may manifest its characteristics through compiled code, a run environment, and a physical machine with certain hardware assets and organizations. Each of the previous may contribute to an attempted measurement. Those additions obscure the desired behaviors. They are unwelcome and may be considered noise. Therefore, a methodology to ensure a reliable estimation by eliminating as much of that noise as reasonable is crucial. The researchers chose one based on ideas first developed in [2] and later refined and used in [29,30] on different CPU platforms. Three key features form the basis of the methodology:

• Eliminate as much of the effects due to the process used to generate the code. In particular, compilers use optimizations that may reduce the resemblance of the code to the original method. Moreover, they implement them differently. So they must be turned off as much as possible.
• Eliminate as many sources of power consumption from the run environment as possible. Modern operating systems multitask, constantly trying to do all sorts of things besides running user code. Of particular concern as noise are those that are heavy on energy.
• Use reliable, on-chip instrumentation to measure the targeted energy behaviors after eliminating hardware features that optimize or alter the natural power consumption. This empirical approach black-boxes complex behaviors and removes the need for involved modeling or complex simulations. Those methods require detailed knowledge of the processor and the memory and may not capture the whole behavior as faithfully.

Therefore, in a nutshell, the methodology calls for measures that turn off CPU features that alter power consumption, reduce OS activity not focused on the test code, and avoid compiler optimizations that shape the code in ways that make it behave in ways that differ from the algorithm significantly. Other environmental factors should also be addressed, such as thermal noise due to ambient and cross effects. The rest of this discussion highlights other notable features and the rationale.

Readings were averaged over 300 runs for a sound convergence as recommended by [2] based on experimentation in a similar setting. The CPU was allowed to cool down between trials. The input datasets were statically embedded into the code to eliminate factors, such as disk or network loading, that could impact timing or power consumption. These measures help control and reduce variability due to OS and other environmental factors. Collecting timing data is recommended to ensure correct programming and check for the complexity expected from the theory.

3.2. Dataset Generation

The selection of the input datasets is essential to generate the full extent of behaviors that allow reasonable insights into consumption patterns. Carefully chosen ones ensure the experiment’s validity. Before going for random graphs, available datasets on the Stanford Large Network Dataset Collection [31] were explored. Although this repository offers a wide range of graph datasets, none met the specific requirements of the experiment, which required graphs with randomly assigned edge weights within a specified range and a controlled probability of edge existence.

Randomization was employed to determine the edge weights to introduce variability in the input data. It involved assigning a random weight value to each edge in the graph, representing the distance associated with traversing that edge. The randomization ensured that each edge had a randomly chosen weight. The range should approximate practical scenarios. While the distances between vertices in a graph may vary widely depending on the application, a broad range of values allows for versatility in simulating the different scenarios. The range should be wide enough for comprehensive testing. The experiment utilized the Erdős–Rényi model [32], a foundational framework in network theory used to create random graphs $G(n,p)$ characterized by a probability p for edge formation between n vertices, where $G=(V,E)$, $V,E$ are sets of vertices and edges, and $n=\left|V\right|$. This model is known for its simplicity and effectiveness. It enables the understanding of fundamental behaviors in random graphs. The model proved to be highly beneficial for the experiment. It was instrumental in providing a wide range of random graphs. It allowed the exploration of various graph structures by controlling the probability of edge formation between nodes. Different graph densities could be represented simply by adjusting its parameters.

The function directed_gnp_random_graph [33] in the rustworkx library, an open source package for network algorithms [34] used in this research, generates a random directed graph based on the $G(n,p)$ Erdős–Rényi model. Values of p as low as 0.2 yielded fairly dense graphs, i.e., $\left|E\right|\gg \left|V\right|$. Two input datasets were created with different edge densities and a range of vertices from 10 to 2000 with random integer weight values in 1–99,999,999. The sets represent two cases of edge density as follows:

• Fully dense, i.e., complete graphs, where every pair of vertices is connected, generated by setting the probability p to 1. The number of distinct edges is ${\displaystyle \frac{n}{2}}(n-1)$ for a complete graph, but twice that must be created in the adjacency list of the digraph.
• Moderately dense graphs, generated by setting $p=0.6$.

It is reasonable to expect energy behaviors to escalate as the number of edges increases since most graph algorithms must work harder. Therefore, the first case will be an upper bound on energy and power consumption, while the second provides a comparison point for variability in edge density.

3.3. Tools and Materials

Correct programming is vital for the experiment, especially for the relatively intricate Dijkstra algorithm. In addition, the implementation must comply with the purposes of the research. For example, a priority queue based on a sequential data structure or optimized versions of the algorithms will give correct answers but is inappropriate for the investigation. For those reasons, the authors decided to use well-known published code. The experiment’s programs were written in C++ with algorithm code from [35]. The program set up the code to run on a single thread with affinity to core 0 via the CPU_SET and sched_setaffinity functions from the GNU C library. These functions implement the Linux kernel interfaces for controlling the threads’ core affinity. The graph resided in adjacency lists of sink vertices and corresponding weights whose values randomized 27 bits of the 4-byte words used to store them. Priority queue operations relied on the C++ standard library container std::priority_queue. This queue implementation provides constant time access to the top priority element with logarithmic inserts and retrieves [36]. It includes an option for a min-heap, which allows for the efficient extraction of the minimum element for the distance checks. The gcc compiler produced the executables with the optimization option -O0. It only involves optimizations focused on reducing the cost of compilation and having a standard debugging experience [37], i.e., the statements are left independent, which works with the objectives of this research. Higher optimization levels tamper with the code to reduce its size or speed, which is undesirable in this context.

The Linux command perf [38] was used to acquire energy consumption data, run time, and other processor metrics. It is a robust command-line performance profiler available within the OS kernel. It works with RAPL (running average power limit), a hardware feature from Intel. The tool implements the RAPL interface to provide reliable readings from the CPU sensors. The researchers set up shell scripts to automatically execute binaries from specified directories, monitor temperatures, enforce delays, and systematically record the results. The Linux command sensors was used to monitor the CPU temperature. The -C option restricted perf to collecting data on core 0 to minimize its footprint. Some testing was initially conducted with LIKWID [39], the other notable instrumentation tool, but perf was preferred since it had better support and enjoys widespread use.

3.4. Experimental Environment and Procedures

Table 2. Specifications of the experimental environment (powered by a Haswell-EP CPU). Most notably, the tiny, split Level 1 (L1) core caches and the relatively large, high-associativity L3 cache.

CPU	Intel Xeon E5-2680v3 (2.50 GHz, 12-Core)
Cache Memory	L1/core: 32 KiB data, 32 KiB instruction
	L2/core: 256 KiB
	L3: 30 MiB (20-way)
Main Memory	8 GB DDR4-2133
OS	Linux 64-bit (Lubuntu 18.04.6 LTS)
Compiler	GNU Compiler Collection 7.5.0
Profiler	perf 4.9

details the features of the machine used for the experiments. The main component is the HPC-class Haswell-EP CPU. The processor circa 2014 may seem at first to be a bit outdated. It is arguably still a suitable platform for the line of research conducted here for the following reasons. First, the relevant characteristics of this CPU platform are well documented in studies, such as [40]. Second, it features fully integrated voltage regulators (FIVR), i.e., on the CPU die, for finer control and reporting for different regions (CPU domains) of the chip package. Therefore, it can control the frequency and power states of cores efficiently and enable readings at a higher resolution as follows: Fairly accurate power readings for a core are possible if the rest were idle. In a realistic situation, those readings should still be credible as long as activity on the other cores is sufficiently low. Third, [41] showed that estimates reported by RAPL in the Haswell architecture matched plug power readings well. Thus, this well-known CPU part with reliable power numbers remains a reasonable test bed for probing the algorithmic behaviors.

Aljabri et al. [2], based on the same CPU, recommended a list of measures to reduce the effects of factors that may act as noise. A light OS further reduces the noise related to the OS environment. Lubuntu is an official release of Ubuntu that features a lighter runtime environment. In addition, the following are the measures implemented for this study:

• Open system case conditions while keeping the ambient temperature consistent under moderate air conditioning and the CPU fan turned on at a constant speed.
• Turn off hyper-threading features as it results in a more intricate power model since the extra threads consume disproportionately less power by design.
• Deactivate Turbo Boost power management to maintain the CPU’s base frequency so the results are less affected by unpredictable patterns of internal thermal variation between runs.
• Terminate unnecessary operating system processes and services to run the system with minimal resource usage.
• Introduce a cool-off period between test case trials to allow the CPU to return to a consistent initial temperature of 40 °C as reported by the system sensors tool.
• Assign core 0 to execute the experimental code and allocate other processes to cores 2, 3, 4, and 5 to prevent costly context switching. Core 1 was left idle to limit temperature effects from neighboring cores.

4. Results and Discussion

This section first presents and discusses energy behaviors based on the data obtained from the experiment, then examines the resulting cache miss data to make sense of those behaviors.

Table 3. Average energy and power consumption and the percent difference in drawn power relative to Dijkstra (negative means better performance). Highlighted lines indicate a region where power performance seems to be about the same, within 5%.

Vertices	Fully Dense (Complete)						Moderately Dense
	Edges	Energy (J)		Power (W)			Edges	Energy (J)		Power (W)
		B–F	Dijkstra	B–F	Dijkstra	% Adv		B–F	Dijkstra	B–F	Dijkstra	% Adv
10	90	0.08	0.13	8.6	11.2	31.2	53	0.03	0.06	5.3	6.9	31.0
20	380	0.11	0.15	9.2	11.8	28.4	227	0.04	0.08	5.6	7.2	28.4
30	870	0.13	0.20	9.7	12.7	30.6	521	0.06	0.11	6.0	7.8	30.6
40	1560	0.16	0.24	10.3	13.0	26.5	925	0.07	0.14	6.3	8.0	26.4
50	2450	0.19	0.27	10.9	13.7	26.1	1454	0.10	0.18	6.7	8.4	25.8
60	3540	0.24	0.33	11.7	14.2	21.8	2120	0.12	0.22	7.2	8.7	21.8
70	4830	0.33	0.43	12.2	14.3	17.1	2866	0.13	0.25	7.5	8.8	17.1
80	6320	0.42	0.56	13.1	14.7	11.9	3785	0.18	0.29	8.1	9.0	12.0
90	8010	0.54	0.67	14.0	15.2	8.7	4754	0.24	0.32	8.6	9.3	8.6
100	9900	1	0.80	16.3	15.7	−3.7	5932	0.29	0.36	9.5	9.6	1.6
150	22,350	2	1	16.8	16.0	−4.9	13,385	1	0.43	10.3	9.8	−4.9
200	39,800	4	1	17.2	16.3	−5.0	23,841	2	1	10.5	10.0	−4.9
250	62,250	7	1	17.6	16.4	−6.5	37,282	3	0.5	10.8	10.1	−6.5
300	89,700	13	2	18.0	16.9	−5.9	53,755	5	1	11.0	10.4	−6.0
350	122,150	19	2	18.4	17.0	−7.5	73,202	7	1	11.3	10.4	−7.5
400	159,600	27	2	18.8	17.4	−7.3	95,606	10	1	11.5	10.7	−7.4
450	202,050	37	2	19.3	17.9	−7.1	121,036	14	1	11.8	11.0	−7.0
500	249,500	49	2	19.6	18.1	−7.7	149,430	18	1	12.0	11.1	−7.7
550	301,950	68	3	20.2	18.4	−8.8	180,880	25	1	12.4	11.3	−8.7
600	359,400	87	3	20.6	18.8	−8.9	215,251	32	1	12.6	11.5	−8.8
650	421,850	111	4	20.9	19.0	−9.2	252,806	41	1	12.8	11.6	−9.1
700	489,300	143	4	21.4	19.6	−8.7	293,051	52	2	13.1	12.0	−8.7
750	561,750	178	4	21.9	19.8	−9.7	336,645	65	2	13.4	12.1	−9.7
800	639,200	221	5	22.6	20.0	−11.5	383,059	81	2	13.8	12.3	−11.4
850	721,650	268	5	23.0	20.5	−11.0	428,357	98	2	14.1	12.5	−10.9
900	809,239	315	6	23.5	20.9	−11.0	484,763	116	2	14.4	12.8	−11.1
950	901,550	391	6	24.2	21.2	−12.3	540,280	144	2	14.8	13.0	−12.2
1000	999,000	466	7	24.8	21.7	−12.3	598,440	171	3	15.2	13.3	−12.3
1050	1,101,450	548	8	25.3	22.0	−13.0	653,798	201	3	15.5	13.5	−13.0
1100	1,208,900	644	9	25.9	22.4	−13.6	717,578	237	3	15.9	13.7	−13.7
1150	1,321,350	750	9	26.5	22.9	−13.6	791,382	276	3	16.2	14.0	−13.6
1200	1,438,800	873	11	26.9	23.4	−13.1	854,042	321	4	16.5	14.3	−13.2
1250	1,561,250	1003	12	27.4	23.7	−13.6	935,063	369	4	16.8	14.5	−13.6
1300	1,688,700	1165	12	28.3	24.1	−14.8	1,011,396	428	5	17.4	14.8	−14.9
1350	1,821,150	1332	13	28.9	24.4	−15.8	1,080,998	489	5	17.7	14.9	−15.8
1400	1,958,600	1521	14	29.7	25.0	−15.9	1,173,749	559	5	18.2	15.3	−15.9
1450	2,101,050	1734	15	30.5	25.4	−16.6	1,247,141	637	6	18.7	15.6	−16.6
1500	2,248,500	1943	17	30.8	25.9	−16.0	1,346,941	714	6	18.9	15.9	−16.0
1550	2,400,950	2195	18	31.6	26.4	−16.4	1,437,976	807	7	19.3	16.2	−16.5
1600	2,558,400	2483	19	32.5	26.6	−18.0	1,533,197	913	7	19.9	16.3	−18.0
1650	2,720,850	2751	20	32.9	27.5	−16.5	1,615,042	1011	7	20.1	16.8	−16.4
1700	2,888,300	3131	23	34.1	27.9	−18.2	1,730,900	1151	8	20.9	17.1	−18.2
1750	3,060,750	3466	23	34.6	28.2	−18.5	1,834,246	1274	9	21.2	17.3	−18.5
1800	3,238,200	3878	24	35.6	28.7	−19.3	1,922,130	1426	9	21.8	17.6	−19.4
1850	3,420,650	4334	27	36.6	29.4	−19.8	2,030,429	1593	10	22.4	18.0	−19.8
1900	3,608,100	4778	29	37.3	29.8	−20.2	2,141,696	1756	10	22.8	18.2	−20.1
1950	3,800,550	5258	32	38.0	30.4	−20.0	2,276,225	1933	12	23.3	18.6	−20.0
2000	3998000	5818	34	38.9	30.9	−20.7	2394482	2138	12	23.8	18.9	−20.7

displays the main results of the experiment. The energy numbers were based on readings reported by the profiler, whereas the corresponding power numbers were calculated from the run times reported by the tool. The numbers in the table were obtained from averages over 300 trials, as detailed in the previous section. They were rounded to enhance presentation. Shaded lines highlight cases where the power consumption for both algorithms was close, to the extent that they seem to perform similarly, more or less.

4.1. Energy Behaviors

Even a cursory glance at the main results table shows that Dijkstra’s algorithm consumed much less energy than Bellman–Ford at both edge densities for most cases. For the smaller graphs, however, Bellman–Ford was more energy efficient (not by much, though, at an average of 86 and 75 mJ, corresponding to 28.5% and 41.1%, less for the fully and moderately dense cases, respectively). Figure 1 plots the energy data to reveal more. The steeper slope of the Bellman–Ford indicates that it increases at a higher rate as the vertex count increases. The rate seems higher for the greater edge density (see Figure 1a). The shaded region highlights the most intriguing feature, marking the change of trend where energy efficiency shifts towards Dijkstra. The averaged readings indicate that the inflection point occurred at 90–100 in the fully dense graphs and a little later, perhaps at 100–150, in the moderately dense ones.

The substantial energy efficiency advantage seen in Dijkstra as the graphs grew in size and edge density should not be surprising. Figure 2 shows that the energy trend tracked the run time behavior (the regions of interest identified from the energy plots are marked). The shape of the curves suggests that the energy consumption pattern is perhaps similar to the time complexity of the algorithms, which explains the energy findings for the graph instances where Dijkstra was more energy-efficient. Bellman–Ford was slightly faster for the small cases, particularly at lower edge density, at an average of 13% and 30%, perhaps due to overheads of the priority queue in Dijkstra or due to a better fit in local memories. The timing data alone do not fully explain those cases (gains in energy were much higher at 29%, 41% than in time). Energy, after all, is the product of time and power.

Energy behaviors are closely tied to the physical hardware, not just the frequency of operations, like in classic time analysis of algorithms. Power consumption takes both time and the hardware used into account. For example, addition and multiplication are often the most frequent operations of an algorithm whose rates of growth of their time costs or counts are the basis for quoting time efficiency. Multiplication hardware is, of course, more expensive and, therefore, expected to be less energy efficient. Flowing instructions efficiently through processors demands multiplication to respond in fewer clock cycles, preferably 1–2, like addition. It leads to more complex circuitry that must consume energy at high rates, i.e., power levels. Even if the energy budget is the same, the tighter timing necessitates higher power consumption. Examining the power may help better explain the energy behaviors. Higher rates could reflect dependence on an over-achieving energy-intensive functional unit or a poor fit in power-efficient local memories. An algorithm may fix both of those factors at the root. It may trade expensive operations for cheaper ones or try to improve the locality.

The power consumption in Figure 3 confirms a significant event in the region of interest identified earlier. The first observation was that while very clearly Dijkstra was considerably more efficient as the graphs grew both in size and complexity, the differences were not as pronounced as they were for the energy figures—in the low tens of watts in both cases. It is notable that while the energy consumption of Bellman–Ford was much higher, by up to two orders of magnitude, its rate of consumption was not that far behind Dijkstra’s. The second salient observation is the instance size region where Bellman–Ford was more power-efficient. The relative power advantage of Bellman–Ford in the small datasets was an average of 22.5% and 22.4% for the fully and moderately dense groups, respectively, resulting in 2.36 and 1.31 watts on average. One may add sizes that yielded negligible difference to extend the range where Bellman–Ford is competitive energy-wise. For example, the highlighted rows in Table 3 can be regarded as a region of performance parity, within a 5% difference in wattage, to extend the Bellman–Ford range to 200 vertices. Both algorithms consumed energy at an increasing rate as the graphs grew in size and density. Also, while the slope of the curve seems to not change for Dijkstra for all size instances in both density cases, Bellman–Ford noticeably changed after the power event. Therefore, energy consumption patterns may not be attributed only to time efficiency.

The early power advantage of Bellman–Ford seems to point towards behaviors related to memory interactions. The graph data structure grows quadratically, reflecting sizes in $O\left(\right|V{|}^2)$ regardless of implementation. Figure 4 shows a sampling of the memory footprints expected of the random graphs used in the experiment (the odd growth pattern is due to the design of the underlying C++ data structure). It indicates that one may expect some memory event to occur within the cache memory range where the energy behavior changes. The cache also stores instructions and other data items, but the graph data structure should dominate, especially for small sizes. In Dijkstra, it competes with the priority queue for space in the cache. The SRAM-based cache in modern CPUs tends to be on the same chip as the cores (as in the Haswell unit used here) in the same power-efficient CMOS technology. As a result, it has significant energy advantages over the off-chip DRAM-based main memory due to the physical proximity [42] and technology.

Table 4. Memory access latencies (from [40]).

Memory	Latency (ns)
L1	1.4
L2	3.9
L3	16.1
Main	88.6

lists the memory access delays for the Haswell CPU, reflecting the proximity expected to have an energy impact. Therefore, a closer look at the cache activity is necessary to make sense of the energy behaviors. The next part of this section examines the cache miss data.

4.2. Cache Analysis

Table 5. Average cache miss data.

Vertices	Fully Dense (Complete)				Moderately Dense
	L2 Miss		L3 Miss		L2 Miss		L3 Miss
	B–F	Dijkstra	B–F	Dijkstra	B–F	Dijkstra	B–F	Dijkstra
10	8	13	2	3	6	4	2	1
20	10	14	3	2	6	5	3	2
30	13	16	2	4	7	6	3	3
40	23	16	1	5	7	6	5	1
50	14	18	2	4	10	7	4	2
60	21	20	3	6	11	8	3	3
70	22	25	4	2	13	5	3	4
80	24	30	6	7	13	6	3	4
90	30	35	10	9	14	4	5	2
100	8077	4034	70	32	17	9	5	2
150	9070	5474	80	33	6519	3447	20	15
200	10,186	5929	82	34	7131	3767	22	17
250	11,143	6486	86	35	9128	4127	23	20
300	14263	7025	4155	36	9886	4457	30	24
350	15447	10,071	4557	3198	11,289	6340	1876	32
400	17,640	11,731	4996	3493	14,696	7392	3205	2189
450	20,145	15,462	5492	3830	16,622	10,644	3576	2451
500	22,784	18,879	6037	4200	20,507	11,994	3870	2688
550	28,109	24,883	6619	4605	23,824	15,819	4301	2947
600	32,655	30,340	7258	5050	28,317	18,971	4595	3232
650	38,813	37,097	7927	5551	30,614	23,556	5061	3552
700	41,962	39,446	8657	6101	30,762	25,077	5501	3904
750	42,165	40,097	9492	6663	34,792	25,508	6009	4264
800	47,689	43,795	10,434	7306	39,734	27,369	6662	4675
850	54,461	47,154	11,395	7979	44,938	29,452	7271	5106
900	61,595	50,490	18,129	8771	49,397	31,535	11,477	5613
950	67,705	53,563	23,322	12,917	54,298	34,033	14,766	8266
1000	74,422	62,573	25,637	15,592	59,275	39,465	16,380	9978
1050	81,245	70,036	27,996	17,097	64,736	44,526	17,888	10,942
1100	88,729	78,241	30,699	18,672	70,672	48,928	19,603	11,950
1150	96,865	82,150	33,527	20,524	77,492	52,228	21,422	13,135
1200	106,213	88,777	36,851	22,559	84,630	56,510	26,299	14,437
1250	115,996	99,920	40,507	24,637	93,025	62,908	28,364	17,767
1300	127,503	108,929	44,417	27,015	102,253	68,079	30,387	19,010
1350	140,150	120,196	48,824	29,695	112,121	76,417	32,513	20,341
1400	153,675	130,818	53,535	32,640	123,243	83,220	34,473	21,765
1450	168,919	147,369	60,795	35,647	134,545	93,750	37,202	23,288
1500	184,410	155,416	66,663	38,930	146,936	97,910	39,468	24,919
1550	201,394	176,144	72,802	42,687	161,512	111,853	42,231	26,663
1600	221,373	190,421	80,023	46,619	176,323	120,105	45,575	28,529
1650	241,672	212,108	87,962	51,118	192,563	134,853	48,350	30,527
1700	263,930	233,081	96,450	56,189	210,221	148,366	52,147	32,663
1750	288,133	270,908	106,018	61,763	231,075	170,976	55,865	34,950
1800	316,716	285,083	116,251	67,451	253,374	179,490	59,776	37,396
1850	347,279	334,600	127,781	74,142	277,824	210,794	63,960	40,014
1900	380,792	351,362	139,551	80,971	305,385	223,657	68,437	42,815
1950	418,567	379,312	152,404	88,785	335,679	238,961	73,140	45,812
2000	460,088	433,785	167,522	93,457	366,596	273,443	77,640	49,019

lists cache miss counts for Level 2 (L2) and Level 3 (L3) caches as reported by the profiler. The Level 1 (L1) caches are typically split, with data and instructions stored separately, and are too small to hold complete computations except for the tiniest ones. Any computation small enough to fit in L1 will have very little run time, which will pose challenges to profiling. In this experiment, the 32 KiB L1 caches generated thousands of misses immediately with the smallest test datasets (3248/4265 and 1410/2534 for the fully and moderately dense cases; the higher number was by Dijkstra). Therefore, the following analysis will lump the L1 cache with L2. The latency numbers in Table 4 justify the decision.

Since the profiler reports miss counts, the cache miss events are evident in the table. However, plotting the numbers elucidates the effects visually. The discussion will initially focus on the fully dense case to uncover the trends at the worst case for graph complexity. Figure 5 shows the two main cache miss events in L2 and L3 caches at 90–100 and 250–350, respectively. After 350, both algorithms worked from the DRAM. The computation spilling from the L2 to L3 cache seems to be behind the region of interest from the energy and power curves where the trends reversed in favor of Dijkstra, i.e., its operational efficiency started to show in terms of energy behaviors. The effects of the second spill event, marking a shift to the less power-efficient DRAM, seem more subtle. The shaded parts in Table 5 highlight the two spill events in the fully dense case.

Both algorithms were evicted from L2 at the same computation size. However, from Figure 5b, Dijkstra stayed in L3 longer than Bellman–Ford. Moreover, checking the highlighted values in the shaded parts in Table 5 under L3 reveals that once the computations settle in L3, Dijkstra generates fewer misses. The effect may also be observed in L2 data (compare the highlighted values under L2: about 10K at 350 vertices vs. 200 for Bellman–Ford). Bellman–Ford initially had the best locality with the smaller caches, but Dijkstra demonstrated a better fit in local memories once it moved to L3. The initial power efficiency of Bellman–Ford was probably due to fitting well with L1/L2 local memories relatively better than Dijkstra there. The increase in energy consumption rates seems to be due to increased reliance on the DRAM as computation sizes increase. However, Dijkstra seemed to exhibit better locality when the computation was in the DRAM, with L3 effectively operating as its power-efficient local memory, as evidenced by its lower miss counts as computation size increased. Hence, the better power efficiency, with a widening gap.

Comparing L2 miss data from the moderately dense case in Figure 6a, the previously described patterns seem to hold for the less complex graphs. However, they seem to have stayed in L2 slightly longer (evicted at 100–150 vs. 90–100), generating fewer misses. Having a lower edge density, it seems, resulted in a better locality. Figure 6b displays this effect on the power consumption patterns. It is tempting to infer from the plots that the relative advantage of Dijkstra increases with edge density, but a look back at Table 3 quickly confirms that is not the case according to the data.

In closing, from the viewpoint of the computations, there seem to have been two energy consumption patterns. One may say that they experienced two different power environments depending on the hardware involved in the work. The first was power-efficient low-latency cache-dominated, and the other was influenced predominantly by the less efficient DRAM. Dijkstra displayed better locality in the second environment, with fewer edges and better so. In addition to the edge density, the memory footprint of the graph depends on the data structure. It is, therefore, beneficial, from an energy viewpoint, to reduce the bytes used to store the graph to a bare minimum, which depends on the application. Both algorithms would see a benefit. Bellman–Ford would extend its advantageous power environment, and Dijkstra would reduce the competition with the priority queue in both power environments.

5. Conclusions

This research demonstrated that the Bellman–Ford algorithm outperformed Dijkstra’s algorithm in power efficiency when dealing with datasets small enough to fit in the upper layers of the memory hierarchy. The advantage correlated with the interaction of the memory footprint of the graph with the L2 cache in particular. Otherwise, for all cases from mid-size graphs onwards, the energy advantage was decisively in favor of Dijkstra, in line with its runtime behavior. The energy result should be unsurprising due to the massive time efficiency gap. Therefore, the corresponding gap in energy should follow in like fashion as graph sizes grow. As expected, more edges lead to more power and energy consumption. The findings were consistent, to an extent, with those reported in [23] from a GPU implementation, which is worth noting, considering the vast architectural differences between the processing environments. That GPU study, however, was limited, so more investigation may be needed before one can draw solid conclusions there.

The findings suggest that the graph size and processor setup (e.g., cache configuration) may play crucial roles when choosing between Dijkstra and Bellman–Ford with energy or power concerns in mind. The most obvious conclusion is that Bellman–Ford seems to be a better choice when processing a lot of small graphs. In particular, a power-sensitive massive high-performance system, where this computation is a significant fraction, should be expected to see notable benefits with Bellman–Ford. Moreover, the findings encourage when implementing Dijkstra to switch to Bellman–Ford when the remaining graph is small enough or maybe the overheads of the priority queue are no longer worth it. In parallel versions, they favor finer-grained partitioning for Bellman–Ford and the opposite for Dijkstra, tuned to the sizes of the inner cache levels in both cases.

The other major conclusion is about the edge density. Many practical applications, such as social and collaboration networks or web-page link structures, rely on sparse graphs. In those cases, a massive number of vertices remains relatively stable. Meanwhile, the edge counts, in addition to being relatively low, are expected to be more variable. The density findings suggest that one should expect those applications to enjoy some relative power and energy efficiency naturally. More importantly, the energy behavior of graph algorithms that share the $O\left(\right|E|log|V\left|\right)$ efficiency of Dijkstra, such as Prim’s algorithm, should also scale steadily there, effectively linearly, with the edge count. From an energy behaviors perspective, those algorithms may benefit from monitoring and actively culling those edges, likely from dead/broken relations, to keep consumption in check.

The findings, in total, underscore the significance of factoring in power and energy consumption alongside the usual time and space performance metrics when designing the algorithms. This concern is critical in HPC settings where energy behavior is vital in terms of both cost and, ultimately, performance. The exceedingly low energy figures reported for Dijkstra in the highest test cases may be deceptive (see the last line in Table 3). They hide relatively high energy consumption rates at about 19–31 watts, almost comparable to Bellman–Ford. Interestingly, an Intel Haswell still powered 11 systems in the renowned TOP500.ORG lineup as of June 2024 [43]. Therefore, these high numbers may be considered fair representations of the power draw to expect in some contemporary HPC environments, which is remarkable. To put those figures in perspective, the SSSP computation consumed as much as the rated TDP (thermal design power) for some consumer ultraportable devices in 2023–24. It highlights the importance of looking at power and energy as separate concerns. A final insight from this research is, perhaps, the need to go beyond the classic time analysis for a nuanced understanding of energy behaviors. Carefully mapping basic algorithmic behaviors to energy-significant hardware is fruitful. While time is a rigidly enforced physical quantity, we have choices with energy. We can choose operations and functional units and tune behaviors to influence energy budgets and how fast we spend those budgets.

Looking ahead to future research, the preceding part of this section has perhaps already alluded to some directions. In particular, a comprehensive study in a GPU setting would be interesting. Corroborating the power finding may support a notion of algorithmic origins for that trend. A hybrid that merges features from both algorithms in some way to strike a good balance between power and time efficiency may be attractive. Moreover, one may want to explore an algorithm with active edge management for sparse graph applications, such as those described above. In particular, it would be interesting to have an AI-based “oracle” that dynamically suggests likely dead or less relevant edges to ignore temporarily to help keep the power draw within desired power envelopes. As a final suggestion, it seems from the cache miss data that a larger L2 cache, e.g., 512 KiB as in the AMD Epyc 7003 (Milan) Series, likely extends the range of instance sizes that can enjoy the power advantage of Bellman–Ford beyond the 90–100 vertex marks reported here. More work is needed to confirm that, including looking into other valuable workloads to check for the effect. It could lend more support for increasing the size of that cache in HPC-class processors.