Single Machine Graph Analytics on Massive Datasets Using Intel Optane DC Persistent Memory

TL;DR

This paper explores how to efficiently perform graph analytics on massive datasets using Intel Optane DC Persistent Memory, proposing principles that improve runtime performance and demonstrate competitiveness with cluster-based systems.

Contribution

It introduces key runtime and algorithmic principles for graph analytics on large-memory systems with Optane PMM and evaluates their effectiveness on real-world data.

Findings

Frameworks based on proposed principles outperform others

Achieve performance comparable to large cluster systems

Effective for analyzing extreme-scale graphs

Abstract

Intel Optane DC Persistent Memory (Optane PMM) is a new kind of byte-addressable memory with higher density and lower cost than DRAM. This enables the design of affordable systems that support up to 6TB of randomly accessible memory. In this paper, we present key runtime and algorithmic principles to consider when performing graph analytics on extreme-scale graphs on large-memory platforms of this sort. To demonstrate the importance of these principles, we evaluate four existing shared-memory graph frameworks on large real-world web-crawls, using a machine with 6TB of Optane PMM. Our results show that frameworks based on the runtime and algorithmic principles advocated in this paper (i) perform significantly better than the others, and (ii) are competitive with graph analytics frameworks running on large production clusters.

Figures

Tables

Table 1. Table 1: Bandwidth (GB/s) of Intel Optane PMM.

Mode		Read		Write
		Local	Remote	Local	Remote
Memory	Random	90.0	34.0	50.0	29.5
	Sequential	106.0	100.0	54.0	29.5
App-direct	Random	8.2	5.5	3.6	2.3
	Sequential	31.0	21.0	10.5	7.5

Table 2. Table 2: Latency (ns) of Intel Optane PMM.

Mode	Local	Remote
Memory	95.0	150.0
App-direct	164.0	232.0

Table 3. Table 3: Inputs and their key properties.

	kron30	clueweb12	uk14	iso_m100	rmat32	wdc12
$\left|V\right|$	1,073M	978M	788M	76M	4295M	3,563M
$\left|E\right|$	10,791M	42,574M	47,615M	68,211M	68,719M	128,736M
$\left|E\right|/\left|V\right|$	16	44	60	896	16	36
max $D_{out}$	3.2M	7,447	16,365	16,107	10.4M	55,931
max $D_{in}$	3.2M	75M	8.6M	31,687	10.4M	95M
Est. diameter	6	498	2498	83	7	5274
Size (GB)	136	325	361	509	544	986

Table 4. Table 4: Execution time (sec) of benchmarks in Galois on Optane PMM (OB) machine using efficient algorithms (non-vertex, asynchronous) and D-Galois on Stampede cluster (DM) using vertex programs with minimum number of hosts that hold the graph (5 hosts for clueweb12, and uk14, and 20 hosts for wdc12). Speedup of Optane PMM over Stampede. Best times highlighted in green.

Graph	App	Stampede (DM)	Optane PMM (OB)	Speedup (DM/OB)
clueweb12	bc	51.63	12.68	4.07$\times$
	bfs	10.71	6.43	1.67$\times$
	cc	13.70	11.08	1.24$\times$
	kcore	186.03	51.05	3.64$\times$
	pr	155.00	385.64	0.40$\times$
	sssp	33.87	16.58	2.04$\times$
uk14	bc	172.23	11.53	14.9$\times$
	bfs	28.38	7.22	3.93$\times$
	cc	14.56	21.30	0.68$\times$
	kcore	56.08	7.94	7.06$\times$
	pr	82.77	254.95	0.32$\times$
	sssp	52.49	39.99	1.31$\times$
iso_m100	bc	6.97	11.57	0.60$\times$
	bfs	7.94	3.69	2.15$\times$
	cc	16.32	23.69	0.69$\times$
	kcore	1.21	0.48	2.52$\times$
	pr	191.21	824.54	0.23$\times$
	sssp	61.90	15.66	3.95$\times$
wdc12	bc	775.84	56.48	13.7$\times$
	bfs	71.50	35.25	2.03$\times$
	cc	69.21	76.00	0.91$\times$
	kcore	105.42	49.22	2.14$\times$
	pr	118.01	1706.35	0.07$\times$
	sssp	136.47	118.81	1.15$\times$

Table 5. Table 5: Execution time (sec) of benchmarks in Galois on Optane PMM in Memory Mode (MM) and the state-of-the-art out-of-core graph analytics framework GridGraph on Optane PMM in App-direct Mode (AD). A 512 by 512 partition grid was used for GridGraph. Best times are highlighted in green. ”—” indicates that system failed to finish in 2 hours.

Graph	App	GridGraph (AD)	Galois (MM)	Speedup (AD/MM)
clueweb12	bfs	5722.75	6.43	890.0$\times$
	cc	5411.23	11.08	488.4$\times$
uk14	bfs	—	7.22	NA
	cc	5700.48	21.30	267.6$\times$

Full text

To demonstrate the importance of these principles, we evaluate four existing shared-memory graph frameworks and one out-of-core graph framework on large real-world graphs using a machine with 6TB of Optane PMM. Our results show that frameworks using the runtime and algorithmic principles advocated in this paper (i) perform significantly better than the others and (ii) are competitive with graph analytics frameworks running on large production clusters.

1 Introduction

Graph analytics systems must process graphs with tens of billions of nodes and trillions of edges. Since the main memory of most single machines is limited to a few hundred GBs, shared-memory graph analytics systems like Ligra [53], Galois [45], and GraphIt [65] cannot be used to perform in-memory processing of these large graphs. Two approaches have been used in the literature to circumvent this problem: (i) out-of-core processing and (ii) distributed-memory processing.

In out-of-core systems, the graph is stored in secondary storage (SSD/disk), and portions of the graph are read into DRAM under software control for in-memory processing. State-of-the-art systems in this space include X-Stream [50], GridGraph [67], Mosaic [39], and BigSparse [32]. Secondary storage devices do not support random accesses efficiently: data must be fetched and written in blocks. As a consequence, algorithms that perform well on shared-memory machines often perform poorly in an out-of-core setting, and it is necessary to rethink algorithms and implementations when transitioning from in-memory graph processing to out-of-core processing. In addition, the graph may need to be preprocessed to organize the data into an out-of-core friendly layout.

Large graphs can also be processed with distributed-memory clusters. The graph is partitioned among the machines in a cluster using one of many partitioning policies in the literature [25]. Communication is required during the computation to synchronize node updates. State-of-the-art systems in this space include D-Galois [22] and Gemini [66]. Distributed-memory graph analytics systems have the advantage of scale out by adding new machines to provide additional memory and compute power. The overhead of communication can be reduced by choosing good partitioning policies, avoiding small messages, and optimizing metadata, but communication remains the bottleneck in these systems [22]. Obtaining access to large clusters may also be too expensive for many users.

Intel® OptaneTM DC Persistent Memory (Optane PMM) is new byte-addressable memory technology with the same form factor as DDR4 DRAM modules with higher memory density and lower cost. It has longer access times compared to DRAM, but it is much faster than SSD. It allows a single machine to have up to 6TB of storage at relatively low cost, and in principle, it can run memory-hungry applications without requiring the substantial reworking of algorithms and implementations needed by out-of-core or distributed-memory processing.

We explore the use and viability of Optane PMM for analytics of very large graphs such as web-crawls up to 1TB in size. We design and present studies conducted to determine how to run graph analytics applications on Optane PMM and large-memory systems in general. Our studies make the following points:

Non-uniform memory access (NUMA)-aware memory allocation of graph data structures that maximizes near-memory (DRAM treated as cache) usage is important on Optane PMM as cache misses on the platform are significantly slower than cache misses on DRAM. (Section 4) 2. 2.

Avoiding page management overhead while using Optane PMM is key to performance as kernel overhead on Optane PMM is higher due to higher access latency. (Section 4) 3. 3.

Algorithms must avoid high amounts of memory accesses on large memory systems: graph frameworks should give users the flexibility to write non-vertex, asynchronous programs with efficient parallel data structures. (Section 5)

We evaluate four shared-memory graph analytics frameworks – Galois [45], GAP [6], GraphIt [65], and GBBS [23] – on Optane PMM to show the importance of these practices for graph analytics on large-memory systems. We compare the performance of the best of these frameworks, Galois, with the state-of-the-art distributed graph analytics system, D-Galois, and show that a system running on Optane PMM that uses our proposed practices is competitive with the same algorithms run on D-Galois with 256 machines, and since the Optane PMM system supports more efficient shared-memory algorithms which are difficult to implement on distributed-memory machines, applications using the more efficient algorithms can outperform distributed-memory execution. We also evaluate the out-of-core graph analytics system GridGraph [67] using Optane PMM as external storage in app-direct mode (explained in Section 2) and show that using Optane PMM as main memory in memory mode (explained in Section 2) is orders of magnitude faster than app-direct as it allows for more sophisticated algorithms from shared-memory graph analytics systems that out-of-core systems currently do not support (in particular, non-vertex programs and asynchronous data-driven algorithms detailed in Section 5).

The paper is organized as follows. Section 2 introduces Optane PMM. Section 3 describes the experimental setup used in our studies. Section 4 describes how to efficiently use the memory hierarchy on large-memory systems and Optane PMM for graph analytics. Section 5 discusses graph algorithm design for large-memory systems. Section 6 presents our evaluation. Section 7 surveys related work.

2 Optane PMM

Optane PMM delivers a combination of affordable large capacity and persistence (non-volatility). As shown in Figure 1, Optane PMM adds a new level to the memory hierarchy. It comes in the same form factor as a DDR4 memory module and has the same electrical and physical interfaces. However, it uses a different protocol than DDR4 which means that the CPU must have Optane PMM support in its memory controller. Similar to the DRAM distribution in non-uniform memory systems in which memory is divided into sockets, the Optane PMM modules are distributed among sockets. Figure 1 shows an example of a two socket machine with 6TB of Optane PMM split between sockets. Optane PMM can be configured as volatile main memory (memory mode), persistent memory (app-direct mode), or a combination of both (Figure 2).

Memory Mode: In memory mode, Optane PMM is treated as as main memory, and DRAM acts as direct-mapped (physically indexed and physically tagged) cache called near-memory. The granularity of caching from Optane PMM to DRAM is 4KB. This enables the system to deliver DRAM-like performance at substantially lower cost and power with no modifications to the application. Although the memory media is persistent, the software sees it as volatile memory. This enables systems to provide up to 6TB of randomly accessible storage, which is expensive to do with DRAM.

Traditional code optimization techniques can be used to tune applications to run well in this configuration. In addition, software must consider certain asymmetries in machines with Optane PMM. Optane PMM modules on a socket can use only the DRAM present in its local NUMA node (i.e., socket) as near-memory. Therefore, in addition to NUMA allocation considerations, software using Optane PMM has to account for near-memory hit rate as the cost of a local near-memory miss is higher than the remote near-memory hit (discussed in Section 4). Therefore, it should allocate memory so that the system can utilize more DRAM as near-memory even if it means more remote NUMA accesses.

App-direct Mode: In app-direct mode, Optane PMM modules are treated as byte-addressable persistent memory. One compelling case for app-direct mode is in large memory databases where indices can be stored in persistent memory to avoid rebuilding them on reboot, achieving a significant reduction in restart time. Optane PMM modules can be managed using an API or a command line interface provided by the ipmctl [20] OS utility in Linux. ipmctl can be used to configure the machine to use x% of Optane PMM modules capacity in the memory mode and the rest in the app-direct mode 111ipmctl create -goal MemoryMode=x PersistentMemoryType=AppD-irect; for x $>$ 0, all DRAM on the machine is used as the cache (near-memory). When all the Optane PMM modules are in app-direct mode, DRAM is the main volatile memory.

Specifications for the Optane PMM machine used in our study are in Section 3. Tables 1 and 2 show the bandwidth and latency of PMM observed on our machine. Although Optane PMM is slower than DDR4, its large capacity enables us to analyze much larger datasets on a single machine than previously possible. In this paper, we focus on memory mode; we use app-direct mode for running the out-of-core graph analytics system GridGraph [67].

3 Platforms and Graph Analytics Systems

Optane PMM experiments were conducted on a 2 socket machine with Intel’s second generation Xeon scalable processor (”Cascade Lake”) with 48 cores (up to 96 threads with hyperthreading) with a clock rate of 2.2 Ghz. The machine has 6TB of Optane PMM, 384GB of DDR4 RAM, and 32KB L1, 1MB L2, and 33MB L3 data caches (Figure 1). The system has a 4-way associative data TLB with 64 entries for 2KB pages (small pages), 32 entries for 2MB pages (huge pages), and 4 entries for 1GB pages. Code is compiled with g++ 7.3. We used the same machine for DRAM experiments by configuring the Optane PMM modules to run entirely in app-direct mode and use DRAM as the main volatile memory (equivalent to removing the Optane PMM modules). We also use Optane PMM modules in app-direct mode to run GridGraph, an out-of-core graph analytics system: DRAM is used as main memory and Optane PMM modules are used as external storage. Transparent Huge Pages (THP)  [38], which tries to allocate huge pages for an application without explicitly reserving memory for huge pages, are enabled (default in Linux; ). To collect hardware counters and analyze performance, we used Intel’s Vtune Amplifier [19] and Platform Profiler [18].

To show that our study of algorithms for massive graphs (Section 5) is independent of machine architecture, we also conducted experiments on a large DRAM 4 socket machine we call Entropy. Entropy uses Intel Xeon Platinum 8176 (”Skylake”) processors with a total of 112 cores with a clock rate of 2.2 Ghz, 1.5TB of DDR4 DRAM, and 32KB L1, 1MB L2, and 38MB L3 data caches. Code is compiled with g++ 5.4. For our experiments on Entropy, we use 56 threads, restricting our experiments to 2 sockets.

Distributed-memory experiments were conducted on the Stampede2 [54] cluster at the Texas Advanced Computing Center using up to 256 Intel Xeon Platinum 8160 (”Skylake”) 2 socket machines with 48 cores with a clock rate of 2.1 Ghz, 192GB DDR4 RAM, and 32KB L1, 1MB L2, and 33MB L3 data caches. The machines are connected with a 100Gb/s Intel Omni-Path interconnect. Code is compiled with g++ 7.1.

Table 3 specifies the input graphs: clueweb12 [49], uk14 [8, 7], and wdc12 [43] are web-crawls (wdc12 is the largest publicly available one), and iso_m100 [4] is a protein-similarity network (iso_m100 is the largest dataset in IMG isolate genomes publicly available as part of the HipMCL software [4]). kron30 and rmat32 are randomized scale-free graphs generated using kron [35] and rmat [11] generators (using weights of 0.57, 0.19, 0.19, and 0.05, as suggested by graph500 [1]). Table 3 also lists graph sizes on disk in Compressed Sparse Row (CSR) binary format. kron30 and clueweb12 fit into DRAM, so we use them to illustrate differences in workloads that fit into DRAM and those that do not. The other graphs – uk14, rmat32, and wdc12 – do not fit in DRAM on our Optane PMM machine. We observe that uk14 and wdc12 have non-trivial diameters, whereas rmat32 has a very small diameter. We believe that rmat32 does not represent real-world datasets, so we exclude it in all our experiments except to show the impact of diameter in our study of algorithms (Section 5). All graphs are unweighted, so we generate random weights.

Our evaluation uses 7 benchmarks: single-source betweenness centrality (bc) [29], breadth-first search (bfs) [17], connected components (cc) [51, 52], k-core decomposition (kcore) [21], pagerank (pr) [46], single-source shortest path (sssp) [44], and triangle counting (tc) [28]. The only benchmark that uses edge weights is sssp. The source node for bc, bfs, and sssp is the maximum out-degree node. The tolerance for pr is $10^{-6}$. The $k$ in kcore is $100$. All benchmarks are run until convergence except for pr, which is run for up to 100 rounds. We present the mean of 3 runs for the main experiments.

The shared-memory graph analytics frameworks we use are Galois [45], GAP [6], GraphIt [65], and GBBS [23] (all described in more detail in Section 6). D-Galois [22] is a distributed-memory framework. GridGraph [67] is an out-of-core framework that streams graph topology and data into memory from external storage (in this case, Optane PMM in app-direct mode).

4 Memory Hierarchy Issues

This section shows that on Optane PMM machines, the overhead of memory operations such as non-uniform memory accesses (NUMA) across memory sockets, cache misses handling, and page table maintenance are higher than DRAM machines. These overheads are reduced by intelligent memory allocation and by reducing the time spent in the kernel for page-table maintenance. We address three issues: NUMA-aware allocation (Section 4.1), NUMA-aware migration (Section 4.2), and page size selection (Section 4.3).

4.1 NUMA-aware Allocation

NUMA-aware allocation increases bandwidth and reduces latency of memory accesses by allocating memory on the same NUMA node as the cores that are likely to access it. Allocation falls into three main categories: (a) NUMA local, which allocates memory on a node specified at allocation time (if there is not enough memory available on the preferred node, other nodes are used), (b) NUMA interleaved, which interleaves pages across nodes in a round-robin fashion, and (c) NUMA blocked, which blocks the pages and distributes the blocks among nodes (illustrated in Figure 3).

There are several ways for application programs to specify the allocation policy. The policy can be set globally by using OS utilities such as numactl  [37] on Linux. To allow different policies to be used in different allocations, applications can use the OS-provided NUMA allocation library (numa.h in Linux), which contains a variety of numa_alloc functions. OS-based approaches, however, can only use the NUMA local or interleaved policies. Another way to get fine-grained NUMA-aware allocation is to manually allocate memory using anonymous mmap  [36] and have threads on different sockets inside the application touch the pages (called first-touch) to allocate them on the desired NUMA nodes. This method, unlike OS-provided methods, allows applications to implement application-specific NUMA-aware allocation policies.

To understand the differences in local, interleaved, and blocked NUMA allocation policies on our Optane PMM setup, we use a micro-benchmark that allocates different amounts of memory using different NUMA allocation policies and writes to each location once using $t$ threads where each thread gets a contiguous block to write sequentially. To explore the effects of NUMA on different platforms, we run this microbenchmark with two setups: one using only DDR4 DRAM (by setting Optane PMM into app-direct mode) and one using Optane PMM. The following micro-benchmark results show that on the Optane PMM machine, applications must not only maximize local NUMA accesses, but must also use a NUMA policy that maximizes the near-memory used in order to reduce DRAM conflict misses (recall that DRAM is direct-mapped cache called near-memory for Optane PMM in this mode, and limited cache size increases the probability of conflict misses due to physical addresses mapping to the same cache line).

NUMA Local. Figure 4(a) shows the execution time of the microbenchmark on DDR4 DRAM and Optane PMM for the NUMA local allocation policy using $t=96$ and different allocation amounts. Using NUMA local, all the memory of socket 0 is used before memory from socket 1 is allocated. We observe that going from 80GB to 160GB increases the execution time by $2\times$ for both DRAM and Optane PMM: this is expected since we increase the work by $2\times$. Going from 160GB to 320GB also increases the work by $2\times$. For DRAM, a 320GB allocation spills to the other socket (each socket has only 192GB), increasing the effective bandwidth by $2\times$, so the execution time does not change much. In Optane PMM , however, the 320GB is allocated entirely on socket 0 as our machine has 3TB per socket. Since there is no change in bandwidth, one would expect the performance to degrade by $2\times$, but it degrades by $5.6\times$. This is because the machine can only use 192GB of DRAM as near-memory; this cannot fit 320GB, so the conflict miss rate of the DRAM accesses increase by roughly 1.8$\times$. This illustrates that (i) near-memory conflict misses are detrimental to the performance for Optane PMM and (ii) NUMA local is not suitable for allocations larger than 192GB on our setup.

NUMA Interleaved and Blocked. The execution times of the microbenchmark on DDR4 DRAM and Optane PMM for the NUMA interleaved and blocked allocation policies using an allocation of 320GB and different thread counts are shown in Figure 4(b). For DRAM, both policies are similar for different $t$. When $t\leq 24$ on Optane PMM, NUMA blocked only allocates memory on socket 0 (because it uses first-touch), so performance degrades 39$\times$ compared to 48 thread execution as 320GB does not fit in the near-memory of a single socket. This illustrates that the cost of local near-memory misses is much higher than the cost of remote near-memory hits. In contrast, the NUMA interleaved policy for 24 threads uses both sockets and improves performance by 9$\times$ over NUMA blocked even though 50% of accesses are remote when $t\leq 24$. NUMA interleaved performs worse than blocked when $t=48$, as both allocation policies are able to fit 320GB in the near-memory of 2 sockets (384GB); however, NUMA interleaved results in more remote accesses as compared to NUMA blocked.

4.2 NUMA-aware Migration

When an OS-level NUMA allocation policy is not specified, the OS can dynamically migrate data among NUMA nodes to increase local NUMA accesses. NUMA page migrations are helpful for multiple applications sharing a single system as they try to move pages closer to the cores assigned to each application. However, for a single application, this policy may not always be useful, especially when application has specified its own allocation policy.

NUMA migration has overheads: (a) it requires book-keeping to track accesses to the pages to select pages for migration, and (b) migration changes the virtual-to-physical address mapping, which makes the Page Table Entries (PTEs) cached in CPU’s Translation Lookaside Buffers (TLBs) stale, causing TLB shootdown on each core to invalidate stale entries. TLB shootdown involves slow operations such as issuing inter-processor-interrupts (IPIs), and it also increases TLB misses.

Graph analytics applications tend to have irregular access patterns: accesses are arbitrary, so there may be many shared accesses across NUMA nodes. To examine the effects of page migration on graph analytics applications, we run breadth-first search (bfs) (similar trends observed for other benchmarks) with Galois [45] using NUMA interleaved allocation on both Optane PMM and DDR4 DRAM with NUMA migration on and off. We also examine the effects of page migration for different page sizes (which affects the number of pages migrated): (a) 4KB small pages and (b) 2MB huge pages. The results suggest that NUMA migration should be turned off for graph analytics applications on Optane PMM.

Figure 5 shows the effect of NUMA migration where the number on each bar presents the % change in the execution time when NUMA migration is turned off. A positive number means turning migration off improves performance. Performance improves in most cases if migration is turned off. Figure 6 shows that the time spent in user code is not affected by the migrations, which shows that they add kernel time overhead without giving significant benefits. Another way to measure the efficacy of the migrations is to measure the % of local near-memory (DRAM) accesses in Optane PMM: if migration is beneficial, then it should increase. However, this does not change by more than $1\%$. Figure 6 shows that migrations hurt performance more on Optane PMM compared to DRAM as kernel time spent is higher. This is due to (a) higher bookkeeping cost as accesses to kernel data structures are more expensive on Optane and (b) higher cost of TLB shootdown as it increases the access latency to the near-memory (DRAM) being used as a direct-mapped cache since TLB translation is on the critical path.222Since near-memory is physically indexed and physically tagged direct-mapped cache, virtual addresses are translated to physical addresses before cache (near-memory) can be accessed.. Larger graphs exacerbate this effect as they use more pages.

4KB small page size shows more performance improvement than 2MB huge pages when turning page migrations off. We observe that the number of migrations is in the millions for small pages and in the hundreds for huge pages. The finer granularity of small pages makes them more prone to migrations, leading to more TLB shootdowns and data TLB misses. Therefore, for small pages, the number of data TLB misses reduces by $\sim 2\times$ by turning off the migrations for all the graphs. The number of small pages being 512$\times$ the number of huge pages also increases the bookkeeping overhead in the OS. This is reflected in time spent in the OS kernel seen in Figure 6: the time spent in the kernel is more for the smaller page size than for the larger page size if migration is turned on.

4.3 Page Size Selection

When memory sizes and workload sizes grow, the time spent handling TLB misses can become a performance bottleneck since large working sets need many virtual-to-physical address translations that may not be cached in the TLB. This bottleneck can be tackled (a) by increasing the TLB size or (b) by increasing the page size. The TLB size is determined by the micro-architecture and cannot easily be changed by a user. On the other hand, processors allow users to customize page sizes as different page sizes may work best for different workloads. For example, x86 supports traditional 4KB small pages as well as 2MB and 1GB huge pages.

We studied the impact of page size on graph analytics using a 4KB small page size and a 2MB huge page size. We did not include the 1GB page size as it requires special setup; moreover, we do not expect to gain from 1GB pages as the hardware supports fewer TLB entries for 1GB page size. We run bfs (similar behavior observed for other benchmarks) using Galois [45] with no NUMA migration and NUMA interleaved allocation for various large graphs on (a) Optane PMM and (b) DDR4 DRAM. The results suggest that a page size of 2MB is good for graph analytics on Optane PMM.

Figure 5 shows bfs runtimes with various page sizes, and we observe that using huge pages is always beneficial on large graphs as huge pages reduce the number of pages by 512$\times$, reducing the number of TLB misses (3.2$\times$ for clueweb12, 11.2$\times$ for uk14 and 1.9$\times$ for wdc12) and CPU cycles spent on page walking on TLB misses (7.3$\times$ for clueweb12, 12.5$\times$ for uk14 and 8.8$\times$ for wdc12). We also observe that the benefits of huge pages are higher on Optane PMM than on DRAM because TLB misses increase the near-memory access latency. Huge pages increase the TLB reach (TLB size $\times$ page size), thereby reducing the TLB misses.

4.4 Summary

For high-performance graph analytics on Optane PMM, we recommend (i) NUMA interleaved or blocked allocation rather than NUMA local, particularly for large allocations ($>$ 192GB), (ii) turning off NUMA page migration, and (iii) using 2MB huge pages.

5 Efficient Algorithms for Massive Graphs

Generally, there are many algorithms that can solve a given graph analytics problem; for example, the single-source shortest-path (sssp) problem can be solved using Dijkstra’s algorithm [17], the Bellman-Ford algorithm [17], chaotic relaxation [12], or delta-stepping [44]. These algorithms may have different asymptotic complexities and different amounts of parallelism. For a graph $G=(V,E)$, the asymptotic complexity of Dijkstra’s algorithm is $O(|E|{*}log(|V|))$ while Bellman-Ford is $O(|E|{*}|V|)$, but for most graphs, Dijkstra’s algorithm has little parallelism compared to Bellman-Ford. Complicating matters further is the fact that a given algorithm can usually be implemented in different ways that can affect parallel performance dramatically; implementations with fine-grain locking, for example, usually perform better than those with coarse-grain locking.

This section presents a classification of graph analytics algorithms that is useful for understanding parallel performance [48]. We also present experimental results that provide insights into which classes of algorithms perform well on large input graphs.

5.1 Classification of Graph Analytics Algorithms

Operators In graph analytics algorithms, each vertex has one or more labels that are initialized at the start of the computation and updated repeatedly during computation until a quiescence condition is reached. Label updates are performed by applying an operator to active vertices in the graph. In some systems, such as Galois [45], an operator may read and update an arbitrary portion of the graph surrounding the active vertex; this portion is called its neighborhood. Most shared-memory systems such as Ligra [53, 23] and GraphIt [65] only support vertex programs in which operator neighborhoods are only the immediate neighbors of the active vertex. The more general non-vertex programs, conversely, have no restriction on an operator’s neighborhood. A push-style operator updates the labels of the neighbors of the active vertex, while a pull-style operator updates the label of only the active vertex. Direction-optimizing implementations [5] can switch between push and pull style operators dynamically but require a reverse edge for every forward edge in the graph, doubling the memory footprint of the graph.

Schedule To find active vertices in the graph, algorithms take one of two approaches. A topology-driven algorithm executes in rounds. In each round, it applies the operator to all vertices; Bellman-Ford sssp is an example. These algorithms are simple to implement, but they may not be work-efficient if there are few active vertices in a lot of rounds. To address this, data-driven algorithms track active vertices explicitly and only apply the operator to these vertices. At the start of the algorithm, some vertices are active; applying the operator to an active vertex may activate other vertices, and operator application continues until there are no active vertices in the graph. Dijkstra and delta-stepping sssp algorithms are examples. Active vertices can be tracked using a bit-vector of size $V$ if there are $V$ vertices in the graph: we call this a dense worklist [53, 23, 65]. Other implementations keep an explicit worklist of active vertices [45]: we call this a sparse worklist.

Some implementations of data-driven algorithms execute in bulk-synchronous rounds: they keep a current and a next worklist, and in each round, they process only vertices in the current worklist and add activated vertices to the next worklist. The worklists can be dense or sparse. In contrast, asynchronous data-driven implementations have no notion of rounds; they maintain a single sparse worklist, pushing and popping active vertices from this worklist until it is empty.

5.2 Algorithms for Very Large Graphs

At present, very large graphs are analyzed using clusters or out-of-core systems, but these systems are restricted to vertex programs and round-based execution. This is not considered a serious limitation for power-law graphs since they have a small diameter and information does not have to propagate many hops in these graphs. In fact, no graph analytics framework other than Galois provides sparse worklists, so they do not support asynchronous data-driven algorithms, and most of them are restricted to vertex programs.

Using Optane PMM, we use a single machine to perform analytics on very large graphs, and our results suggest that conventional wisdom in this area needs to be revised. The key issue is highlighted by Table 3: clueweb12, uk14, and wdc12, which are real-world web-crawls, have a high diameter (shown in Table 3) compared to kron30 and rmat32, the synthetic power-law graphs. We show that for standard graph analytics problems, the best-performing algorithms for these graphs may be (a) non-vertex programs and (b) asynchronous data-driven algorithms, which require sparse worklists. These algorithms have better work-efficiency and make fewer memory accesses, which is good for performance especially on Optane PMM where memory accesses are more expensive.

Figure 7 shows the execution time of different data-driven algorithms for bfs, cc, and sssp on Optane PMM using the rmat32, clueweb12, and wdc12 graphs on the Galois system. For bfs, all algorithms are bulk-synchronous. A vertex program with direction optimization (that uses dense worklists) performs well for rmat32 since it has a low-diameter, but for the real-world web-crawls which have higher diameter, it is outperformed by an implementation with a push-style operator and sparse worklists since this algorithm has a lower memory footprint and makes fewer memory accesses. For cc, bulk-synchronous label propagation [51] combined with short-cutting (LabelProp-SC) [55], which uses a non-vertex operator, is used. It is a variant of the Pointer-Jumping algorithm [52] where after a round of label propagation it jumps one level unlike Pointer-Jumping where it goes to the common ancestor. LabelProp-SC exhibits better locality compared Pointer-Jumping and significantly outperforms the bulk-synchronous algorithm that uses a simple label propagation vertex operator for the real-world web-crawls. For sssp, the asynchronous delta-stepping algorithm, which maintains a sparse worklist, significantly outperforms the bulk-synchronous data-driven algorithm with dense worklists. These findings do not apply only to Optane PMM: Figure 8 shows the same experiments for bfs, sssp, and cc conducted on Entropy (DDR4 DRAM machine). The trends are similar to those on Optane PMM machine.

Summary Large real-world web-crawls, which are the largest graphs available today, have a high diameter unlike synthetically generated rmat and kron graphs. Therefore, conclusions drawn from experiments with rmat and kron graphs can be misleading. On current distributed-memory and out-of-core platforms, one is forced to use vertex programs, but on machines with Optane PMM, it is advantageous to use algorithms with non-vertex operators and sparse worklists of active vertices that allow for asynchronous execution. Frameworks with only vertex operators or no sparse worklists are at a disadvantage on this platform when processing large real-world web-crawls, as we show next.

6 Evaluation of Graph Frameworks

In this section, we evaluate several graph frameworks on Optane PMM in the context of the performance guidelines presented in Sections 4 and 5. In Section 6.1, four shared-memory graph analytics systems - Galois [45], GAP [6], GraphIt [65], and GBBS [23] - are evaluated on the Optane PMM machine using several graph analytics applications. Section 6.2 describes experiments with medium-sized graphs stored either in Optane PMM or DRAM. These experiments provide end-to-end estimates of the overhead of executing applications with data in Optane PMM rather than in DRAM. Section 6.3 describes experiments with large graphs that fit only in Optane PMM, and performance is compared with distributed-memory performance on a production cluster with up to 128 machines. Section 6.4 presents our experiments with GridGraph [67], an out-of-core graph analytics framework, using Optane PMM’s app-direct mode to treat it as external memory.

6.1 Galois, GAP and GraphIt on Optane PMM

Setup. To choose a shared-memory graph analytics system for our experiments, we evaluate (1) Galois [45], which is a library and runtime for graph processing, (2) GAP [6], which is a benchmark suite of expert-written graph applications, (3) GraphIt [65], which is a domain-specific language (DSL) and optimizing compiler for graph computations, and (4) GBBS [23], which is a benchmark suite of graph algorithms written in the Ligra [53] framework.

The choice of these frameworks was made as they exemplify different approaches to shared-memory graph analytics. GraphIt is a DSL that only supports vertex programs, and it has a compiler that uses auto-tuning to generate optimized code; the optimizations are controlled by the programmer. Galois is a C++-based general-purpose programming system based on a runtime that permits optimizations to be specified in the program at compile-time or at runtime, giving the application programmer a large design space of implementations that can be explored. GBBS programs are expressed in a graph processing library and runtime, Ligra. Therefore, Galois and GBBS require more programming effort than GraphIt. GBBS includes theoretically efficient algorithms written by experts, while Galois includes algorithms written using expert-provided concurrent data structures and operator schedulers. GAP is a benchmark suite of graph analytics applications written by expert programmers; it does not provide a runtime or data structures like Galois.

The kcore application is not implemented in GAP and GraphIt, so we omit it in the comparisons reported in this section. We omit the largest graph wdc12 for GAP and GraphIt because neither can handle graphs that have more than $2^{31}{-}1$ nodes (they use a signed 32-bit int for storing node IDs). GAP, GraphIt, and GBBS do not use NUMA allocation policies within their applications, so we use the OS utility numactl to use NUMA interleaved. For Galois, we use the best-performing algorithm with a runtime option, and we did not try different worklists or chunk-sizes. Galois allows programmers to choose NUMA interleaved or blocked allocation for each application by modifying a template argument in the program; we choose interleaved for bfs, cc, and sssp and blocked for bc, and pr. For GraphIt, we used the optimizations recommended by the authors [65] in the GraphIt artifact.

Results. Figures 9 shows the execution times on Optane PMM (GraphIt does not have bc). Galois is generally much faster than GraphIt, GAP, and GBBS: on average, Galois is $3.8\times$, $1.9\times$, and $1.6\times$ faster than GraphIt, GAP, and GBBS, respectively. There are many reasons for these performance differences.

Algorithms and implementation choices affect runtime (discussed in Section 5.2). For all algorithms, GAP, GBBS and GraphIt use a dense worklist to store the frontier while Galois uses a sparse worklist except for pr (large diameter graphs tend to have sparse frontiers). All systems use the same algorithm for pr. For bfs, all systems except Galois use direction-optimization which accesses both in-edges and out-edges (increasing memory accesses). For sssp, GAP, GBBS, and Galois use delta-stepping [44]; GraphIt does not support such algorithms. For cc, GAP and GBBS use a union-find based pointer-jumping [52] algorithm, Galois uses label-propagation with shortcutting [55], and GraphIt uses label propagation [51] because it supports only vertex programs. Furthermore, Galois uses asynchronous execution for sssp and cc unlike the others.

Another key difference is how the three systems perform memory allocations. Galois is the only framework that explicitly uses huge pages of size 2MB whereas the others use small pages of size 4KB and rely on the OS to use Transparent Huge Pages (THP). As discussed in Section 4, huge pages can significantly reduce the cost of memory accesses over small pages even when THP is enabled. Galois is also the only one to provide NUMA blocked allocation, and we chose that policy because it performed observably better than the interleaved policy for some benchmarks such as bc and pr (the performance difference was within 18%). In general, we observe that NUMA blocked performs better for topology-driven algorithms, while NUMA interleaved performs better for data-driven algorithms. In addition, GAP, GBBS, and GraphIt allocate memory for both in- and out-edges of the graph while Galois only allocates memory only for the direction(s) needed by the algorithm. Allocating both increases the memory footprint and leads to conflict misses in near-memory when both in-edges and out-edges are accessed.

To conclude, our experiments show that in order to acheive performance for large graphs, a framework should support asynchronous, non-vertex programs as well as allow users explicit control over memory allocation. As Galois supports these features out-of-the-box, we use it for the rest of our experiments.

6.2 Medium-size graphs: Using Optane PMM vs. DDR4 DRAM

Setup. In this subsection, we determine the overhead of using Optane PMM over DRAM by examining the runtimes for graphs that are small enough to fit in DRAM (384 GB). We use with kron30 and clueweb12 (Table 3) which both fit in DRAM. We use algorithms in Galois that perform best on 96 threads.

Results. Figure 10 shows strong scaling on DRAM and on Optane PMM with DRAM as cache. kron30 requires $\sim 136$GB, which is a third of the near-memory available, so Optane PMM is almost identical to DRAM as it can cache the graph in near-memory effectively. On the other hand, clueweb12 requires $\sim 365$GB, which is close to the near-memory available, so there are significantly more conflict-misses ($\approx 26\%$) in near-memory. On 96 threads, Optane PMM can take up to 65% more execution time than DRAM, but on average, it takes only $7.3\%$ more time than DRAM.

Another trend is that if the number of threads is less than 24, Optane PMM can be slower than DRAM because of the way Galois allocates memory. Interleaved and blocked allocation policies in Galois interleave and block among threads, not sockets. If threads used is less than 24, all threads run on one socket, and all memory is allocated there, leading to under-utilization of the DRAM in the entire system: this results in more conflict-misses in near-memory.

The strong scaling for all the applications is similar whether DRAM or Optane is used as main memory. We also measured the performance of all applications for larger graphs on 8 and 96 threads of Optane. The geo-mean speedup of all applications on 96 threads over 8 threads is $4.3\times$, $4.2\times$, $4.7\times$, and $3.5\times$ for kron30, clueweb12, uk14, and wdc12 respectively. Thus, the strong scaling speedup does not vary by much as the size of the graph grows.

6.3 Very large graphs: Using Optane PMM vs. a Cluster

Setup. For very large graphs that do not fit in DRAM, the conventional choices are to use a distributed or an out-of-core system. In this subsection, we compare execution of Galois on Optane PMM to execution of the state-of-the-art distributed graph analytics system D-Galois [22] on the Stampede2 [54] cluster to determine the competitiveness of Optane PMM compared to a distributed cluster. We chose D-Galois because it is faster than existing distributed graph systems (like Gemini [66], PowerGraph [27], and GraphX [61]) and on each machine, it uses the same computation runtime as Galois, which makes the comparison fair. To partition graphs between machines, we follow the recommendations of a previous study [25] and use Outgoing Edge Cut (OEC) for 5 and 20 hosts and Cartesian Vertex Cut (CVC) [9] for 256 hosts. D-Galois supports only bulk-synchronous vertex programs with dense worklists as they simplify communication. Therefore, it cannot support some of the more efficient non-vertex programs in Galois. We exclude graph loading, partitioning, and construction time in the reported numbers. For logistical reasons, it is difficult to ensure that both platforms use the exact same resources (threads and memory). For a fair comparison, we limit the resources used on both platforms.

Results. Table 4 compares the performance of Optane PMM (on a single machine) running non-vertex, asynchronous Galois programs (referred to as OB) with the distributed cluster (Stampede2 [54]) running D-Galois vertex programs using the minimum number of hosts required to hold the graph in memory (5 hosts for clueweb12, and uk14, and 20 hosts for wdc12; 48 threads per host and referred to as DM). Optane PMM outperforms D-Galois in most cases (best times highlighted), except for pr on clueweb12, uk14, and wdc12 and cc on uk14, and wdc12. Optane PMM gives a geomean speedup of $1.7\times$ over D-Galois even though D-Galois has more cores (240 cores for clueweb12 and uk14; 960 cores for wdc12) and memory bandwidth. In pr, almost all nodes are updated in every round (similar to the topology driven algorithms); therefore, on the distributed cluster, it benefits from the better spatial locality in D-Galois resulting from the partitioning of the graph into smaller local graphs and more memory bandwidth.

Table 4 also shows the performance of many applications on Optane for input graphs of different sizes (smallest to largest). Most applications take more time for larger graphs. Although wdc12 is $\sim 3\times$ larger (in terms of edges) than clueweb12, kcore and pr take less time on wdc12 than clueweb12, but the other applications take on average $\sim 7\times$ more time on wdc12 than clueweb12. This provides an estimate for the weak scaling of these applications.

Further Analysis. The bars labeled O_ in Figure 11 show times on the Optane PMM system with the following configurations:- OB: Performance using the best algorithm in Galois for that problem and all 96 threads (same as shown in Table 4); OA: Performance using the best vertex programs in Galois for that problem and all 96 threads; OS: Same as OA but using only 80 threads. The bars labeled D_ show times on the Stampede2 system with the following configurations:- DB: Performance using D-Galois vertex programs on 256 machines (12,288 threads); DM: Performance using D-Galois vertex programs using the minimum number of hosts required to hold graph in memory (same as shown in Table 4). DS: Same as DM but using a total of 80 threads across all machines.

Results. Figure 11 shows the experimental results. For bars DS and OS, the algorithm and resources are roughly the same, so in most cases, OS is similar or better than DS. The notable exception to this is pr (reason is explained above). On average, OS is 1.9$\times$ faster than DS for all inputs and benchmarks. Bars OB and OA show the advantages of using non-vertex, asynchronous programs on the Optane PMM system. Bars DB and OB show that with the more complex algorithms that can be implemented on the Optane PMM system, performance on this system matches the performance of vertex programs on a cluster with vastly more cores and memory for bc, bfs, kcore, and sssp. The main takeaway is that Optane PMM enables analytics on massive graphs using shared-memory frameworks out-of-the-box while yielding performance comparable or better than that of a cluster with the same resources as the framework may support more efficient algorithms.

6.4 Out-of-core GridGraph in App-direct Mode vs. Galois in

Memory Mode

In addition to our main shared-memory experiments, we use an out-of-core graph analytics system with app-direct mode on Optane PMM to determine if an out-of-core system that uses Optane PMMas external storage is competitive with a shared-memory framework that uses it as main memory.

Setup. We use the state-of-the-art out-of-core graph analytics framework, GridGraph [67] (some recent out-of-core graph analytics frameworks [64, 58] are faster than GridGraph but they handle only a subset of algorithms that GridGraph handles). We compare GridGraph in Optane PMM’s app-direct (AD) with Galois in memory mode (MM). The Optane PMM machine was configured in AD mode as described in Section 2. In AD, GridGraph manages the available DRAM (memory budget given as 384GB) unlike in MM where DRAM is managed by the OS as another cache level. The input graphs (preprocessed by GridGraph) are stored on the Optane PMM modules which are used by GridGraph during execution. We used a 512 by 512 grid as the partitioning grid for GridGraph (the GridGraph paper used larger grid partitions for larger graphs to better fit blocks into cache). 333We have tried larger grids, but preprocessing fails as GridGraph opens more file descriptors than the machine supports. GridGraph uses a signed 32-bit int for storing the node IDs, making it impractical for large graphs with $>2^{31}-1$ nodes such as wdc12. We conduct a run of bfs and cc: it does not have bc, kcore, or sssp, and we have observed pr failing due to assertion errors in the code.

Results. Table 5 compares the performance of Optane PMM in memory mode (MM) running shared-memory Galois and app-direct mode (AD) running out-of-core GridGraph. We observe that Galois using MM is orders of magnitude faster than GridGraph (GridGraph bfs on uk14 failed to finish in 2 hours). This can be attributed to the more sophisticated algorithms (in particular, non-vertex programs and asynchronous data-driven algorithms supported in Galois using MM unlike out-of-core frameworks that only support vertex-programs) and the additional IO overhead required by out-of-core frameworks, especially for real-world web-crawls with very high diameter such as clueweb12 (diameter $\approx 500$). We note that after few rounds of computation on bfs for clueweb12, very few nodes get updated: however, the blocks containing its corresponding edges still must be loaded from the storage to be processed. Note other out-of-core systems [58, 64] that are optimized for a subset of graph algorithms are no more than an order of magnitude faster than GridGraph; therefore, we expect Galois to outperform those systems in Optane PMM as well.

To summarize, although out-of-core graph analytics systems can also use Optane PMM via app-direct mode, the lack of expressibility and the IO requirement of out-of-core systems hurt runtime compared to a shared-memory framework that does not have these limitations.

6.5 Summary and Discussion

Our experiments show that graph analytics on Optane PMM is competitive with analytics on both DRAM and distributed clusters. This is important as the monetary cost of Optane PMM technology is much less than that of large DRAM or machine clusters. In addition, unlike distributed execution which requires a system designed for distributed analytics that typically restricts algorithmic choices for graph applications, Optane PMM allows running shared memory graph analytics without changes to existing programs.

Our study only uses a selection of existing graph benchmarks that exist in different existing graph analytics systems, but our findings generalize further to other graph analytics benchmarks, including those with more attributes similar to edge weights in sssp. Additional attributes will increase the memory footprint and require more memory accesses: therefore, our principles of reducing memory accesses with efficient data-driven algorithms, accounting for near-memory cache hit rates, and intelligent NUMA allocation would matter even more with the increased memory footprint.

While our study was specific to Optane PMM, the guidelines in summarized below apply to other large-memory analytics systems as well.

• $\bullet$

Studies using synthetic power-law graphs like kron and rmat can be misleading because unlike these graphs, large real-world web-crawls have large diameters (Section 5).

• $\bullet$

For good performance on large diameter graphs, the programming model must allow application developers to write work-efficient algorithms that need not be vertex programs, and the system must provide data structures for sparse worklists to enable asynchronous data-driven algorithms to be implemented easily (Section 5).

• $\bullet$

On large-memory NUMA systems, the runtime must manage memory allocation instead of delegating it to the OS. It must exploit huge pages and NUMA blocked allocation. NUMA migration is not useful. (Section 4)

Finally, our study identifies several avenues for future work. As Optane PMM suffers if near-memory is not utilized well, techniques can be developed to improve near-memory hit rate to increase efficiency of graph analytics on Optane PMM. In addition, this study focused on memory mode and showed graph analytics in memory mode is faster than that in app-direct mode. Work remains to be done to determine the best manner of using app-direct mode for out-of-core graph analytics systems.

7 Related Work

Shared-Memory Graph Processing. Shared-memory graph processing frameworks such as Galois [45], Ligra [53, 23], and GraphIt [65] provide users with abstractions to do graph computations that leverage a machine’s underlying properties such as NUMA, memory locality, and multicores. Shared-memory frameworks are limited by the available main memory on the system in which it loads the graph into memory for processing: if a graph cannot fit, then out-of-core or distributed processing must be used. However, if the graph fits in memory, the cost of shared memory systems is less than out-of-core or distributed systems as they do not suffer disk reading overhead or communication overhead, respectively.

Optane PMM increases the memory available to shared-memory graph processing systems, and our evaluation shows that algorithms run with Optane PMM are competitive or better than D-Galois [22], a state-of-the-art distributed graph analytics system. This is consistent with past work in which it was shown that shared-memory graph processing on large graphs can be efficient [23], and our findings extend to cases where a user has large amounts of main memory (it is not limited to Optane PMM).

Out-of-core Graph Processing. Out-of-core graph processing systems such as GraphChi [34], X-Stream [50], GridGraph [67], Mosaic [39], Lumos [58], CLIP [2], and BigSparse [32] compute by loading appropriate portions of a graph into memory and writing back out to disk in a disciplined manner to reduce disk overhead. Therefore, these systems are not limited by main memory like shared-memory systems. The overhead of disk operations, however, greatly impacts performance compared to shared-memory systems.

Distributed Graph Processing. Distributed graph processing systems such as PowerGraph [27], Gemini [66], D-Galois [22], and others [26, 10, 13, 30, 40, 61] process large graphs by distributing the graph among many machines which increases both available memory and computational power. However, communication among the machines is required, and this can add significant runtime overhead. Additionally, getting access to a distributed cluster can be expensive to an average user.

Persistent Memory. Prior work on non-volatile memory includes file systems designed for persistent memory [16, 62, 24, 14], making sure access to persistent memory is efficient while being semantically consistent [15, 57, 33, 42], database systems in persistent memory [3, 63, 56].

Optane PMM Evaluation. Many studies have evaluated the potential of Optane PMM for different application domains. Izraelevitz et al. [31] presented a detailed analysis of the performance characteristics of Optane PMM with evaluation on SPEC 2017 benchmarks, various file systems, and databases. Optane PMM has also been evaluated for HPC applications with high memory and I/O bottlenecks [59, 60]. Malicevic et al. [41] use app-direct-like mode to study graph analytics applications using emulated NVM system. However, they only study vertex programs on very small graphs. Peng et al. [47] evaluates the performance of graph analytics applications on Optane PMM in memory mode. However, they only use artificial Kronecker [35] and RMAT [11] generated graphs, which, as we have shown in this work, exhibit different structural properties compared to real-world graphs.

Our study evaluates graph applications on large real-world graphs using efficient and sophisticated algorithms (in particular, non-vertex programs and asynchronous data-driven algorithms) and is also the first work, to our knowledge, to compare the performance of graph analytics applications on Optane PMM using Galois with the state-of-the-art distributed graph analytics framework, D-Galois [22], on a production level cluster (Stampede [54]) as well as to the out-of-core framework, GridGraph [67], on Optane PMM.

8 Conclusions

This paper proposed guidelines for high-performance graph analytics on Intel’s Optane PMM memory and highlighted the principles that apply to graph analytics for all large-memory settings. In particular, our study shows the importance of NUMA-aware memory allocation at the application level and avoiding kernel overheads for Optane PMM as poor applications of both concepts are more expensive on Optane PMM than on DRAM. In addition, it shows the importance of non-vertex, asynchronous graph algorithms for large memory systems as synchronous vertex programs do not scale well as graphs grow. We believe that Optane PMM is a viable alternative to clusters with similar computational power for graph analytics because they support a wider range of efficient algorithms while providing competitive end-to-end performance.