A Locality-Activated Matrix Reordering Framework for SpMV

Abstract

Sparse Matrix-Vector Multiplication (SpMV) is a fundamental kernel in many scientific and graph applications, and its performance is often limited by the poor locality of input-vector accesses. Matrix reordering is an efficient approach for improving such locality; however, existing methods, such as GOrder, suffer from two major limitations: they are applied without estimating whether a matrix has sufficient relabeling headroom, and they can incur substantial preprocessing overhead on large graphs. To address these issues, we propose a locality-activated parallel matrix reordering framework consisting of two components. First, we introduce a reuse-distance-based locality headroom predictor that estimates the potential SpMV speedup after applying matrix reordering; reordering is activated only when the expected benefit is sufficiently large. Second, we propose a two-phase parallel matrix reordering algorithm, termed pGOrder. It decomposes the sequential greedy process of GOrder into global coarse-grained batch generation and local fine-grained refinement. In the first phase, reuse-aware vertex batches are generated on the GPU according to global reuse signals. In the second phase, the ordering within each batch is refined concurrently on multi-core CPUs. Experimental results show that the proposed predictor effectively identifies matrices with meaningful locality headroom, and pGOrder preserves most of the locality benefit of GOrder while substantially reducing order-generation overhead. On the selected matrices, pGOrder retains over 95% of GOrder’s average SpMV speedup while requiring less than 5% of its order-generation time.

1. Introduction

SpMV is a fundamental kernel in a wide range of applications, including numerical linear algebra, graph analytics, scientific computing, and iterative solvers [1,2,3]. On modern architectures such as GPUs, SpMV is typically memory-bound rather than compute-bound, and its performance is therefore determined largely by memory-access efficiency. For a sparse matrix stored in CSR format, accesses to the matrix arrays (values and col_ind) are largely streaming and well coalesced, leaving limited room for improvement. In contrast, accesses to the input vector are indirect gathers driven by col_ind, and are often highly irregular. As shown in Figure 1, input-vector accesses account for a substantial fraction of the overall SpMV time, reaching up to 80% on some datasets. Therefore, improving the locality of input-vector accesses is critical for accelerating SpMV.

Figure 1. Fraction of SpMV time attributable to input-vector gather accesses. The dashed line indicates the 0.75 reference level.

One practical way to improve such locality is matrix reordering. From the graph perspective, a sparse matrix can be viewed as an underlying graph together with a vertex labeling. Changing the labeling modifies the ordering of rows and columns, and thus changes the access pattern to the input vector during SpMV. If topologically related vertices are assigned nearby labels, accesses to the corresponding input-vector entries become more locality-friendly. Therefore, many matrix reordering methods have been proposed to improve data locality [4,5].

Among existing approaches, GOrder [6] is a strong baseline. By greedily maximizing a reuse-oriented objective, it can achieve substantial SpMV speedup on a wide range of graphs. Nevertheless, its practical use in large-scale SpMV workloads is limited by two issues:

• GOrder always performs reordering, even though some matrices already exhibit favorable locality and therefore have limited optimization headroom. In such cases, reordering may provide little practical benefit, while the preprocessing cost still has to be paid.
• GOrder is computationally expensive because its greedy vertex selection process is inherently sequential. Its preprocessing overhead can be several orders of magnitude larger than that of a single SpMV execution, making it difficult to apply to large-scale graphs.

These two limitations suggest that an effective reordering system should answer two questions: when should reordering be activated, and how can high-quality reordering be performed at low cost?

The first question motivates the need for headroom prediction. Before performing reordering, one should estimate whether a given matrix is likely to benefit from it. Since reordering affects SpMV primarily through the induced access pattern of column indices, a natural way to characterize such a benefit is through locality-related statistics derived from the input-vector access stream. In this work, we adopt reuse distance (RD) as the key locality descriptor. The RD distribution of the column indices provides a compact summary of how reuse is distributed across short, medium, and long distances. Intuitively, matrices with substantial mass in long-distance RD bins often exhibit poorer locality and thus greater reordering headroom, whereas matrices concentrated in short-distance bins are already locality-friendly and may benefit less from further reordering.

The second question motivates a low-cost reformulation of GOrder. Although GOrder is sequential in its original form, its objective naturally suggests a batched generalization. Instead of selecting one vertex at a time, one may first select a group of promising vertices according to global reuse signals and then refine their local order independently. This observation leads to a two-phase design consisting of global coarse-grained batch generation and local fine-grained refinement. In the first phase, vertex batches are generated efficiently on the GPU. In the second phase, the ordering within each batch is refined concurrently on multi-core CPUs. Such a design preserves the core locality objective of GOrder while substantially reducing its order-generation overhead.

Motivated by these observations, we propose a locality-activated matrix reordering framework for SpMV. The main contributions are summarized as follows:

(1)

We formulate matrix-reordering headroom estimation as a supervised prediction problem based on the cache-line RD distribution. We develop a parallel sampled RD extractor using fixed-size HyperLogLog sketches and use the resulting features to construct a conservative gating mechanism that avoids expensive order generation and matrix permutation when the predicted benefit is insufficiently clear.

(2)

We propose a two-phase reordering algorithm, pGOrder. The algorithm decomposes the sequential greedy process of GOrder into global coarse-grained batch generation and local fine-grained refinement. This design preserves most of the locality benefit of GOrder while substantially reducing order-generation overhead.

(3)

We conduct extensive experiments on real-world and synthetic datasets. Using MERBIT as the primary SpMV backend, the results show that the RD-based predictor provides effective headroom estimation, and pGOrder retains over 95% of GOrder’s average SpMV speedup while requiring less than 5% of its order-generation time on the matrices selected for relabeling. In particular, the end-to-end results indicate that the predictor avoids expensive reordering on matrices whose expected gains are insufficient to amortize the preprocessing cost within a practical reuse horizon.

The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 introduces matrix reordering, reuse distance, and GOrder. Section 4 presents the RD-based headroom predictor. Section 5 describes the two-phase matrix reordering algorithm, pGOrder. Section 6 analyzes the computational complexity of the framework. Section 7 reports the experimental results, including the end-to-end cost–benefit analysis. Finally, Section 8 concludes this paper.

2. Related Work

Various matrix reordering methods have been proposed and can be broadly grouped into four categories: degree-based methods, BFS-based methods, community-based methods, and locality-objective heuristic methods. Table 1 summarizes the main advantages and limitations of representative approaches.

Table 1. Qualitative comparison of representative matrix reordering approaches.

Method	Advantages	Limitations
DegSort	Low order-generation cost	Limited locality improvement
DBG	Low cost with partial order preservation	Sensitive to the original labeling
RCM	Effective bandwidth reduction	High order-generation cost on some graphs
SlashBurn	Effective hub separation	Sensitive to the community structure
RabbitOrder	Effective community-aware locality	Sensitive to the community structure
GOrder	Strong reuse-oriented locality	High order-generation cost

Degree-based methods reorder vertices according to degree statistics, with representative examples including degree sorting [7], hub sorting [8], and hub clustering [9]. These methods are motivated by the observation that high-degree vertices are frequently accessed in many graph workloads. By assigning nearby labels to high-degree vertices, they aim to reduce the working-set footprint and improve cache reuse. Their main advantage is simplicity: the preprocessing cost is usually low, and the resulting order can be generated efficiently even for large graphs.

However, degree information alone provides only a coarse structural signal. Aggressively clustering hubs may disrupt the latent structure preserved in the original labeling, and the resulting order may not match the actual reuse pattern of SpMV input-vector accesses. To mitigate this issue, Degree-Based Grouping (DBG) [10] adopts a coarse-grained grouping strategy that reduces the hot-vertex footprint while attempting to preserve the original graph structure. Nevertheless, the effectiveness of degree-based methods remains sensitive to the initial labeling quality and is often limited when the original order is nearly random.

BFS-based methods reorder vertices according to traversal order or level structure. Classical sparse-matrix ordering methods such as Cuthill–McKee [11] and Reverse Cuthill–McKee (RCM) [12] aim to reduce matrix bandwidth by placing vertices in nearby BFS levels close together. These methods have a long history in sparse matrix computations and are attractive because of their simple traversal logic. Parallel variants have also been proposed to improve scalability on modern architectures [13].

However, BFS-based methods are mainly designed around traversal order or bandwidth-related structural objectives. They do not explicitly model the reuse-distance distribution of the input-vector access stream. Moreover, when a graph has many BFS levels or weak level locality, the preprocessing cost can become high, while the resulting locality improvement remains unstable.

Community-based methods exploit the community structure of graphs. Representative methods include SlashBurn [14] and RabbitOrder [15]. These methods assign nearby labels to vertices within the same community or dense substructure, so that graph algorithms and sparse-matrix kernels can benefit from improved locality. They are often effective on social and web graphs, where community structure is strong.

However, their effectiveness depends heavily on how clearly the graph exhibits community organization. For graphs with weak, overlapping, or diffuse communities, the detected ordering may not provide stable improvements. In addition, community detection or community-aware ordering may introduce nontrivial preprocessing overhead, which limits their applicability when the sparse matrix is used only for a small number of SpMV iterations.

Locality-objective heuristic methods directly optimize locality-related objectives or their proxies, rather than relying on a single structural property such as degree, bandwidth, or community membership. GOrder [6] is a representative method in this category. It greedily constructs a vertex order by maximizing a reuse-oriented objective based on neighbor and sibling relationships. Because its objective is more closely related to cache reuse, GOrder often produces high-quality vertex labelings and achieves strong SpMV acceleration across diverse datasets.

However, this benefit comes at a high preprocessing cost. The greedy vertex selection process is inherently sequential, and repeated score updates over unlabeled vertices make the method expensive for large graphs. Therefore, locality-objective heuristic methods usually exhibit a clear trade-off: they can deliver stronger locality improvements, but they are less scalable than lightweight ordering methods.

Beyond the design of matrix reordering algorithms, another question is whether a given matrix is worth reordering. Most existing reordering methods focus on how to construct a new order, but they are applied regardless of whether the matrix has sufficient locality optimization headroom. This can be inefficient because some matrices already exhibit favorable locality under their original labeling, and further reordering may provide little practical benefit while still incurring preprocessing overhead.

Balaji [16] proposed a lightweight analytical metric, termed Packing Factor, to estimate the potential benefit of lightweight matrix reordering, especially Hub Sorting. The metric supports selective reordering by applying reordering only to graphs with sufficient expected benefit. However, Packing Factor is designed for a specific degree-based lightweight reordering method, and its ability to generalize across other reordering algorithms and SpMV backends is limited.

Overall, existing matrix reordering algorithms face two limitations. First, lightweight methods are scalable but often provide limited locality improvement, while stronger methods such as GOrder can achieve substantial speedup; however, their preprocessing overhead is high. Second, little prior work has studied relabeling headroom estimation as a general problem. These observations motivate our locality-activated matrix reordering framework: instead of always applying reordering, the RD-based predictor first estimates whether a matrix has sufficient locality-related headroom. For matrices selected by the predictor, pGOrder then performs reordering through global coarse-grained batch generation and local fine-grained refinement, preserving most of the locality benefit of GOrder while substantially reducing preprocessing overhead.

3. Preliminary

In this section, we first explain how matrix reordering affects the locality of input-vector accesses in SpMV and reformulate it from a functional perspective. We then introduce reuse distance as a locality descriptor for the input-vector access stream. Finally, we review GOrder, including the gscore metric and the GOrder algorithm, which motivate the proposed two-phase parallel reordering algorithm.

3.1. Matrix Reordering

Let $\mathbf{M}\in {\mathbb{R}}^{n\times n}$ denote a sparse matrix stored in CSR format using the arrays offset, col_ind and values. Let $G(V,E)$ denote the underlying directed graph with $\left|V\right|=n$ and $\left|E\right|=m$, and let $\pi :V\mapsto \left[n\right]$ denote a vertex labeling. Then, the matrix can be viewed as the combination of the graph structure and the labeling, i.e.,

$$\mathbf{M}=⟨G(V,E),\pi ⟩.$$

(1)

Changing the vertex labeling does not change the graph structure itself. Instead, it changes how vertices are mapped to row and column indices. Equivalently, matrix reordering applies a simultaneous row and column permutation to the sparse matrix. Therefore, different labelings of the same graph may induce different input-vector access streams during SpMV.

Let $\mathbf{x}$ and $\mathbf{y}$ denote the input and output vectors, respectively. For SpMV $\mathbf{y}=\mathbf{M}\mathbf{x}$, computing $y_i$ requires loading $\mathit{values}\left[j\right]$, $\mathit{col}\_\mathit{ind}\left[j\right]$, and gathering $\mathbf{x}[\mathit{col}\_\mathit{ind}[j\left]\right]$ for

$$\mathit{offset}\left[i\right]\le j<\mathit{offset}[i+1].$$

These accesses are served through the cache hierarchy. Since data transfer between adjacent memory levels occurs at cache-line granularity, the locality of the access stream largely determines the resulting memory traffic. The accesses to the matrix arrays themselves are mostly streaming and relatively regular and therefore cause limited locality loss. In contrast, accesses to $\mathbf{x}$ are indirect gathers driven by $\mathit{col}\_\mathit{ind}$, and are often highly irregular. As a result, the corresponding cache-line utilization can be poor.

Figure 2 illustrates the effect of vertex labeling on the memory traffic of input-vector accesses, assuming a cache-line size of $C=3$ and a cache capable of holding one cache line. Under labeling $\pi$, computing $y_1$ requires loading $x_3$, $x_5$, and $x_7$, which reside in three different cache lines. Since adjacent rows exhibit little cross-row reuse, the total number of cache-line loads is 23. In contrast, under labeling $\tilde{\pi }$, the work previously associated with $y_1$ is mapped to $y_4$, and the required entries $x_1$, $x_2$, and $x_3$ fall into the same cache line. Moreover, several neighboring rows now reuse previously loaded cache lines, reducing the total traffic to 14 cache-line loads. This example shows that vertex labeling directly affects the locality of input-vector accesses and, consequently, SpMV performance.

Figure 2. Impact of different vertex labelings on the memory traffic of input-vector accesses. Letters denote vertex labels under different labelings, and different colors indicate cache-line groups of the input vector; entries with the same color reside in the same cache line.

From a functional perspective, different vertex labelings induce different SpMV execution times on the same graph. This observation leads to the following formulation.

 Problem 1. 

Given $\mathbf{M}=⟨G(V,E),\pi ⟩$, let t denote the execution time of the corresponding SpMV $\mathbf{y}=\mathbf{M}\mathbf{x}$, then there exists a mapping

$$F_G:\mathsf{\Pi }\to \mathbb{R},F_G\left(\pi \right)=t.$$

The goal of matrix reordering is to find the optimal labeling ${\pi }^{★}$ such that the induced matrix ${\mathbf{M}}^{★}=⟨G(V,E),{\pi }^{★}⟩$ minimizes the SpMV execution time, i.e.,

$${\pi }^{★}=\arg \underset{\pi \in \mathsf{\Pi }}{\min }{F}_G\left(\pi \right).$$

This formulation emphasizes that matrix reordering is a data-layout optimization, and its purpose is to find a vertex labeling that improves the memory behavior of SpMV while preserving the underlying graph structure.

3.2. Reuse Distance

To characterize such locality of input-vector accesses, we need a metric that captures how far apart two consecutive reuses occur in the access sequence. In this work, we use reuse distance (RD) for this purpose.

Let

$$T=(a_1,a_2,\dots ,a_m)$$

denote an access trace over an element set S. For an access $a_k=s\in S$, suppose that the most recent previous access to the same element s occurs at position $p<k$. Then, the reuse distance of $a_k$ is defined as the number of distinct elements accessed between positions p and k, i.e.,

$$\mathrm{RD}\left(a_k\right)=\left|\{a_t\mid p<t<k\}\right|.$$

If the element s has not appeared before, then $a_k$ is treated as a first access and does not contribute to finite-distance reuse.

Intuitively, a small reuse distance means that the corresponding data item is reused within a short access window and is therefore more likely to remain in cache. In contrast, a large reuse distance indicates weaker temporal locality and a higher probability that the data has been evicted before reuse. Under a fully associative LRU cache model, an access whose reuse distance is smaller than the cache capacity is likely to hit in cache, while an access with a very large reuse distance is more likely to miss.

In SpMV, the access trace of interest is induced by the column-index sequence. Specifically, each entry col_ind[k] determines one gather access to the input vector. Therefore, the reuse-distance behavior of the column-index-induced access stream provides a useful characterization of input-vector locality. A trace whose RD distribution is concentrated in short distances usually indicates favorable locality, whereas a trace with substantial long-distance reuse suggests poor locality and potentially larger room for improvement through matrix reordering.

A straightforward way to compute reuse distance is to scan the interval between two consecutive accesses to the same element and count the number of distinct elements in that interval. However, this direct method may require repeated range counting and has $O\left(m^2\right)$ time complexity in the worst case.

The key observation is that reuse-distance computation can be transformed into a range-counting problem. During a left-to-right scan of the access trace, we maintain an indicator array b over access positions. At any time, $b\left[t\right]=1$ if position t is the most recent occurrence of the corresponding element $a_t$, and $b\left[t\right]=0$ otherwise. Suppose the current access $a_k=s$ has appeared previously at position $p<k$. Then, the distinct elements accessed between p and k are exactly those whose most recent occurrences lie in the interval $(p,k)$. Therefore,

$$RD\left(a_k\right)={\displaystyle \sum _{t=p+1}^{k-1}}b\left[t\right].$$

To compute this range sum efficiently, we use a Fenwick tree to maintain prefix sums of b. Let $\mathrm{sum}(·)$ denote the prefix-sum query. Then

$$RD\left(a_k\right)=\mathrm{sum}(k-1)-\mathrm{sum}\left(p\right).$$

After the query, the indicator at the previous occurrence is cleared and the indicator at the current position is activated, which corresponds to updating $b\left[p\right]$ from 1 to 0 and $b\left[k\right]$ from 0 to 1. Since each Fenwick-tree query and update takes $O\left(\log m\right)$ time, the overall complexity of RD computation is reduced to $O\left(m\log m\right)$. The detailed procedure is given in Appendix A and Algorithm A1.

3.3. GOrder

GOrder [6] is a representative locality-oriented matrix reordering algorithm. Its basic idea is to construct a new vertex labeling by greedily maximizing the potential cache reuse between nearby vertices in the relabeled order. In this subsection, we briefly review the gscore objective and the GOrder algorithm.

3.3.1. Gscore

Given a directed graph $G(V,E)$, let $N_I\left(u\right)$ and $N_O\left(u\right)$ denote the sets of in-neighbors and out-neighbors of vertex u, respectively. For any two vertices $u,v\in V$, GOrder defines their pairwise reuse score as

$$S(u,v)=S_n(u,v)+S_s(u,v),$$

(2)

where

$$S_n(u,v)={\mathbf{1}}_{\left\{\right(u,v)\in E\}}+{\mathbf{1}}_{\left\{\right(v,u)\in E\}},$$

(3)

and

$$S_s(u,v)=|N_I\left(u\right)\cap N_I\left(v\right)|.$$

(4)

Here, $S_n(u,v)$ captures the direct neighbor relationship between u and v, while $S_s(u,v)$ measures their sibling relationship through the number of shared in-neighbors. Intuitively, if two vertices share more in-neighbors, then the corresponding SpMV rows are more likely to access common input-vector entries. Placing such vertices close in the labeling order is therefore more likely to improve cache reuse.

Based on $S(u,v)$, the global reuse under a vertex labeling $\pi$ can be expressed as

$$F\left(\pi \right)={\displaystyle \sum _{i=2}^n}{\displaystyle \sum _{j=1}^{i-1}}S(v_i,v_j),$$

(5)

where $(v_1,v_2,\dots ,v_n)$ is the vertex order induced by $\pi$. Since real caches have limited capacity, GOrder further introduces a sliding window of size $\omega$ and only accounts for reuse among the most recent $\omega$ vertices. The resulting objective, referred to as gscore, is defined as

$$F_{\omega }\left(\pi \right)={\displaystyle \sum _{i=2}^n}{\displaystyle \sum _{j=w_i}^{i-1}}S(v_i,v_j),$$

(6)

where $w_i=\max \{1,i-\omega \}$. This formulation reflects the fact that cache reuse is inherently local in the labeling order: the closer two vertices are placed, the more likely their induced accesses are to reuse data before eviction.

Maximizing $F_{\omega }\left(\pi \right)$ is computationally difficult. In particular, when $\omega =1$, maximizing the above objective can be reduced to a Traveling Salesman Problem on a complete weighted graph whose edge weights are given by $S(u,v)$, which is NP-hard [17]. Therefore, GOrder adopts a greedy heuristic to approximate a high-quality labeling.

3.3.2. GOrder Algorithm

As shown in Algorithm 1, GOrder constructs the labeling incrementally. The vertices are partitioned into a labeled set stored in perm and an unlabeled set $V_R$. Initially, perm is empty, and $V_R=V$. At each iteration, the algorithm selects the unlabeled vertex with the highest current gscore and appends it to perm. Afterward, the gscore values of the remaining unlabeled vertices are updated according to the current sliding window.

The effectiveness of GOrder comes from the fact that each selection step explicitly favors vertices that can best reuse the data induced by recently labeled vertices. As a result, the generated ordering often improves locality substantially. However, this benefit comes at a high computational overhead. The algorithm updates and compares gscore values repeatedly across the unlabeled vertices, and the selection process is inherently sequential.

Algorithm 1 GOrder

Require:  $G(V,E)$, $\omega$.  Ensure:  perm.   1: $s_v\leftarrow 0(\forall vs.\in V)$;   2: $V_R\leftarrow V$;   3: $i\leftarrow 0$;   4: while $|V_R|>0$ do   5:       $\mathit{perm}\left[i\right]\leftarrow vs.\mathrm{for}vs.\in V_R\mathrm{with}\mathrm{the}\mathrm{highest}{s}_v$;   6:       $V_R\leftarrow V_R-\left\{v\right\}$;   7:       $r_i\leftarrow \max \{0,i-\omega +1\}$;   8:       for $v\in V_R$ do   9:             $s_v\leftarrow {\sum }_{j=r_i}^{i}S(\mathit{perm}\left[j\right],v)$;  10:       end for  11:       $i\leftarrow i+1$;  12: end while

An optimized implementation of GOrder can use a priority queue to reduce redundant score recomputations. Instead of recomputing all gscore values from scratch at every iteration, the priority-queue version updates only the vertices affected by the most recently appended or evicted vertices in the sliding window. This optimization reduces overhead in practice, but the algorithm remains fundamentally sequential because vertices are still selected one at a time.

This observation is important for the development of our method. Although GOrder is effective, its sequential greedy procedure limits scalability. In Section 5, we show that its reuse-oriented objective can be reformulated into two complementary stages: global coarse-grained batch generation and local fine-grained refinement. This reformulation preserves the core locality signal of GOrder while enabling much lower preprocessing cost through parallel execution.

4. RD-Based Headroom Predictor

In this section, we formulate relabeling headroom estimation as a supervised prediction problem. For a given CSR matrix, we extract RD features from its input-vector access stream and predict the potential SpMV speedup after relabeling. The predicted speedup is then used as a gating signal to determine whether relabeling should be activated. In this way, the framework avoids unnecessary reordering cost on matrices with limited locality optimization headroom.

4.1. Overall Design

Figure 3 illustrates the overall workflow of the proposed RD-based headroom predictor. The predictor consists of an offline training phase and an online decision phase.

Figure 3. Overall framework of the proposed RD-based headroom predictor. The numbers indicate the main workflow steps: RD feature extraction, speedup measurement, model training, online RD feature extraction, and speedup prediction/gating.

In the offline phase, a collection of CSR matrices is used to construct the training set. For each matrix, we first extract the RD distribution of its input-vector access stream and encode it as a normalized feature vector $\mathbf{r}=(r_1,r_2,\dots ,r_K)$ (Step 1). We then measure the SpMV speedup achieved after applying locality-oriented relabeling and use it as the target value y (Step 2). The resulting feature–target pairs $⟨\mathbf{r},y⟩$ are subsequently used to train a regression model for headroom prediction (Step 3).

In the online phase, given an input CSR matrix, we extract its RD distribution $\mathbf{r}$ (Step 4) and apply the trained predictor to estimate the relabeling speedup $\widehat{y}$ (Step 5). A gate policy is then applied to determine whether relabeling should be activated. If the expected gain is sufficiently large, the matrix is passed to pGOrder for relabeling; otherwise, the original labeling is kept.

Notably, although the final framework applies pGOrder, we use the GOrder speedup as the prediction target. This choice is made for two reasons. First, the purpose of the predictor is to estimate whether a matrix has sufficient intrinsic locality headroom, rather than to predict the exact speedup of a particular implementation. Second, GOrder is a strong baseline and provides a faithful estimate of the potential benefit of relabeling. Since pGOrder is designed as a low-cost reformulation of GOrder and preserves most of its locality benefit, the GOrder speedup serves as a suitable target for headroom estimation.

4.2. Reuse-Distance Distribution

To characterize the locality of the input-vector access stream, we compute reuse distance at cache-line granularity rather than at raw element granularity. Specifically, instead of directly using the original col_ind sequence, each column index is first mapped to a cache-line identifier

$${\mathsf{\ell }}_k=⌊{\displaystyle \frac{\mathit{col}\_\mathit{ind}\left[k\right]}{C}}⌋,$$

where C denotes the number of input-vector elements contained in one cache line. In our implementation, $C=32$, corresponding to the single-precision elements covered by a 128-byte cache line. For other data types or hardware settings, C can be adjusted accordingly. This mapping aligns the RD features with the granularity of memory transfers in the cache hierarchy.

We summarize the resulting cache-line access stream using a fixed-length RD histogram. Let

$$\mathcal{B}=\{B_1,B_2,\dots ,B_K\}$$

denote K predefined RD bins. In this work, $K=10$, and the boundary set is

$$\{1,112,512,\mathrm{18,432},\mathrm{36,864},\mathrm{73,728},\mathrm{147,456},\mathrm{294,912},\mathrm{589,824}\}.$$

Accordingly,

$$B_1=[0,1),B_2=[1,112),\dots ,B_{10}=[\mathrm{589,824},\infty ).$$

These boundaries reflect different reuse ranges in the target GPU memory hierarchy. The first bins capture immediate and short-range reuse, whereas the later bins describe progressively longer reuse distances. In particular, the boundary at 512 corresponds to the effective L1 capacity in our setting, and the remaining large-distance boundaries approximately correspond to fractions of the L2 cache capacity. Therefore, the resulting feature vector characterizes how cache-line reuse is distributed from short to long distances. Intuitively, a distribution concentrated in the short-distance bins indicates that the original matrix already exhibits favorable input-vector locality and may have limited relabeling headroom. In contrast, substantial probability mass in the long-distance bins indicates a heavier reuse tail and potentially greater opportunity for reordering.

4.2.1. Exact RD Distribution

The exact RD distribution is obtained by computing the reuse distance of every non-first access in the cache-line trace. Let $n_k^{\left(e\right)}$ denote the number of finite exact RD values that fall into bin $B_k$. The normalized exact feature is

$$r_k^{\left(e\right)}={\displaystyle \frac{n_k^{\left(e\right)}}{{\sum }_{j=1}^K{n}_j^{\left(e\right)}}},k=1,2,\dots ,K,$$

which yields

$${\mathbf{r}}^{\left(e\right)}=\left(r_1^{\left(e\right)},r_2^{\left(e\right)},\dots ,r_K^{\left(e\right)}\right).$$

The exact implementation uses the Fenwick-tree procedure described in Appendix A. Although the exact distribution provides a precise locality description, processing every access introduces substantial feature extraction overhead. As the predictor requires only the normalized RD distribution rather than the reuse distance of every individual access, we introduce a parallel sampled RD estimator for online deployment.

4.2.2. Parallel Sampled RD Distribution

The estimator randomly selects S positions from the cache-line access stream and estimates the reuse distance associated with each sampled access. The RD queries associated with different sampled positions are independent and can therefore be handled in parallel. Each processor scans the trace backward from one sampled position until it encounters the nearest preceding occurrence of the same cache line. Let $n_k^{\left(s\right)}$ denote the number of valid sampled estimates assigned to $B_k$. The sampled feature vector is normalized as

$$r_k^{\left(s\right)}={\displaystyle \frac{n_k^{\left(s\right)}}{{\sum }_{j=1}^K{n}_j^{\left(s\right)}}},k=1,2,\dots ,K,$$

yielding

$${\mathbf{r}}^{\left(s\right)}=\left(r_1^{\left(s\right)},r_2^{\left(s\right)},\dots ,r_K^{\left(s\right)}\right).$$

An exact calculation of $n_k^{\left(s\right)}$ would require maintaining the complete set of distinct cache lines observed during the backward scan. The size of this set may substantially exceed the available memory capacity. Consequently, the sampled implementation replaces the explicit set with a fixed-size HyperLogLog sketch [18].

HyperLogLog estimates the number of distinct elements in a multiset by partitioning uniformly hashed values among multiple registers and recording, in each register, the maximum leading-zero rank. The register values are subsequently combined using a bias-corrected harmonic-mean estimator to obtain the final cardinality estimate.

Let $R=2^p$ be the number of registers. Let $h\left(x\right)$ be a uniformly distributed 32-bit hash value of cache-line identifier x, i.e.,

$$h\left(x\right)\in {\{0,1\}}^{32}.$$

The first p bits of $h\left(x\right)$ are interpreted as an integer in $\{0,\dots ,R-1\}$ and used to select one of the R registers. The remaining bits form a binary string w. Define

$$\rho \left(w\right)=1+\mathrm{the}\mathrm{number}\mathrm{of}\mathrm{leading}\mathrm{zeros}\mathrm{in}w.$$

The selected register $R_j$ is updated as

$$R_j=\max \left\{R_j,\rho \left(w\right)\right\}.$$

For a uniformly distributed binary string,

$$Pr\{\rho \left(w\right)\ge k\}=2^{-(k-1)}.$$

As more distinct cache-line identifiers are inserted into one register, its maximum observed rank grows approximately as

$$R_j\approx {\log }_2\left({\displaystyle \frac{n_s}{R}}\right),$$

where $n_s$ is the number of distinct inserted identifiers. Hence, $2^{-R_j}$ is approximately proportional to ${\displaystyle \frac{R}{n_s}}$. HyperLogLog combines the registers through a harmonic-mean estimator

$${\widehat{n}}_{\mathrm{s}}=\alpha R^2{\left({\displaystyle \sum _{j=1}^R}{2}^{-R_j}\right)}^{-1},$$

where $\alpha ={\displaystyle \frac{0.7213}{1+1.079/R}}$.

For reuse intervals containing relatively few distinct cache lines, many HLL registers remain zero, and the raw estimator exhibits increased bias. Let

$$\tilde{R}=\left|\left\{j\mid R_j=0\right\}\right|$$

be the number of zero-valued registers. When ${\widehat{n}}_{\mathrm{s}}\le 2.5R$ and $\tilde{R}>0$, the implementation applies the linear-counting correction

$${\widehat{n}}_{\mathrm{s}}=Rln\left({\displaystyle \frac{R}{\tilde{R}}}\right).$$

Algorithm 2 presents the pseudocode of the sampled RD extraction procedure.

4.3. Prediction Model

To predict the SpMV speedup after reordering based on $\mathbf{r}$, we formulate this task as a supervised regression problem:

$$f:\mathbf{r}\mapsto \widehat{y},$$

where y denotes the measured SpMV speedup achieved after relabeling relative to the original labeling, and $\widehat{y}$ is the predicted speedup.

Instead of regressing directly on y, we train the model on the logarithmic target

$$z=\log y.$$

The predictor therefore learns a mapping

$$f:\mathbf{r}\mapsto \widehat{z},$$

and the final speedup prediction is recovered as

$$\widehat{y}=\exp \left(\widehat{z}\right).$$

This formulation is advantageous because the logarithmic transform makes overestimation and underestimation around unity more symmetric.

To instantiate $f(·)$, we employ Ridge regression:

$$\widehat{z}={\mathbf{w}}^{\top }\mathbf{x}+b,$$

where $\mathbf{x}\in {\mathbb{R}}^K$ denotes the standardized RD feature vector, and $\mathbf{w}$ and b are the model parameters. The feature vector is standardized using the mean and standard deviation computed from the training set. The model parameters are obtained by minimizing the regularized least-squares objective:

$$\underset{\mathbf{w},b}{\min }{\displaystyle \sum _{i=1}^N}{\left(z_i-({\mathbf{w}}^{\top }{\mathbf{x}}_i+b)\right)}^2+\alpha {\parallel \mathbf{w}\parallel }_2^2,$$

where N is the number of training samples and $\alpha$ is the regularization coefficient.

Algorithm 2 Parallel Sampled RD Extraction

Require:  Cache-line trace $\mathcal{T}=({\mathsf{\ell }}_0,\dots ,{\mathsf{\ell }}_{m-1})$; sample count S; HLL precision p; bins $\{B_1,\dots ,B_K\}$; largest finite boundary $d_{\mathrm{cap}}$  Ensure:  Sampled normalized RD distribution ${\mathbf{r}}^{\left(s\right)}$    1: Initialize histogram $n_1,\dots ,n_K\leftarrow 0$    2: for all$s=1,\dots ,S$in parallel do    3:       Sample ${\mathsf{\ell }}_s\in \mathcal{T}$    4:       Initialize $R=2^p$ HLL registers to zero    5:       $\mathit{found}\leftarrow \mathbf{false}$    6:       $\mathit{large}\leftarrow \mathbf{false}$    7:       for trace chunks preceding ${\mathsf{\ell }}_s$ in reverse order do    8:             Find the nearest position f in the current chunk satisfying ${\mathsf{\ell }}_f={\mathsf{\ell }}_s$    9:             if f exists in the current chunk then   10:                  ${\widehat{d}}_s\leftarrow \mathrm{HLLE}\mathrm{STIMATE}$   11:                  $\mathit{found}\leftarrow \mathbf{true}$   12:                  break   13:             else   14:                  $\mathrm{HLLU}\mathrm{PDATE}$   15:             end if   16:             if an intermediate estimate is required then   17:                    $\widehat{d}\leftarrow \mathrm{HLLE}\mathrm{STIMATE}$   18:                    if $\widehat{d}>1.03d_{\mathrm{cap}}$ then   19:                          $\mathit{large}\leftarrow \mathbf{true}$   20:                          break   21:                    end if   22:             end if   23:       end for   24:       if $\mathit{found}$ then   25:             Assign ${\widehat{d}}_s$ to its bin and increment the corresponding $n_k$   26:       else if $\mathit{large}$ then   27:             $n_K\leftarrow n_K+1$   28:       else   29:             Exclude the sampled cold access   30:       end if   31: end for   32: $N_{\mathrm{valid}}\leftarrow {\displaystyle \sum _{k=1}^K}{n}_k$   33: for  $k=1,\dots ,K$  do   34:        $r_k^{\left(s\right)}\leftarrow n_k/N_{\mathrm{valid}}$   35: end for   36: return${\mathbf{r}}^{\left(s\right)}=(r_1^{\left(s\right)},\dots ,r_K^{\left(s\right)})$

We choose Ridge regression for two reasons. First, the RD feature vector is low-dimensional, and a lightweight linear model is sufficient for capturing the dominant relationship between RD distribution and relabeling headroom. Second, because the normalized RD features satisfy ${\parallel \mathbf{r}\parallel }_1=1$, different feature dimensions are correlated. Ridge regularization improves numerical stability and reduces overfitting under such feature correlation.

4.4. Dataset Construction

We construct the dataset using both real-world and synthetic sparse graphs. The data are organized into one original real-world set, one augmented training set, and one external synthetic test set.

4.4.1. Original SuiteSparse Set

We select 90 graphs from the SuiteSparse Matrix Collection (https://sparse.tamu.edu/ accessed on 22 December 2025), as listed in Appendix B and Table A1. For each graph, we extract its RD feature vector and measure the SpMV speedup after applying GOrder relative to the original labeling. This process yields 90 original samples. These samples are used to evaluate whether the predictor can generalize across different real-world matrices.

4.4.2. Augmented SuiteSparse Set

To enrich the diversity of locality patterns, we generate perturbed vertex labelings using the local-swap strategy described in Appendix B and Algorithm A2. Specifically, for each of the 90 SuiteSparse graphs, local swap is applied under nine different parameter settings, producing nine relabeled instances per graph and yielding a total of 810 augmented samples.

The motivation for this augmentation is that different labelings of the same graph can induce different input-vector access streams while preserving the underlying graph structure. Therefore, local swap increases the diversity of RD distributions without changing the structural identity of the graph. Figure 4 shows the RD distributions of four representative matrices under different local-swap settings. As can be seen, local swap effectively reshapes the RD distribution and produces diverse locality profiles, thereby improving the coverage of the training data over the relationship between RD distribution and relabeling speedup.

Figure 4. RD distributions under different local-swap parameters for four representative graphs.

4.4.3. RMAT External Test Set

To examine robustness under distribution shift, we construct an external test set consisting of 75 matrices generated by the RMAT random graph generator [19]. RMAT is parameterized by the number of vertices, the average degree, and the quadrant probabilities $(a,b,c,d)$ satisfying $a+b+c+d=1$.

Starting from $(a,b,c,d)=(0.43,0.26,0.26,0.05)$, we progressively increase a by 0.02 while decreasing b and c by 0.01 until reaching $(0.91,0.02,0.02,0.05)$. For each probability setting, three matrices are generated with average degrees 4, 8, and 12, respectively. The complete RMAT configurations are summarized in Appendix B and Table A3. This construction produces a synthetic test set with gradually varying structural skewness, which is useful for evaluating whether the predictor remains informative beyond the locality patterns observed in the SuiteSparse dataset.

4.5. Gate Policy and Threshold Selection

Based on the predicted speedup, we design a gate policy to determine whether relabeling should be applied. Given two thresholds, ${\tau }_l<1$ and ${\tau }_h>1$, we adopt the following band-based decision rule:

$$\mathrm{decision}\left(\widehat{y}\right)=\left\{\begin{array}{cc}\mathrm{relabel},\hfill & \widehat{y}\ge {\tau }_h,\hfill \\ \mathrm{skip},\hfill & \widehat{y}\le {\tau }_l,\hfill \\ \mathrm{uncertain},\hfill & \mathrm{otherwise}.\hfill \end{array}\right.$$

(7)

Under this policy, only predictions sufficiently above 1 are mapped directly to relabel, and only predictions sufficiently below 1 are mapped directly to skip. Predictions close to $\widehat{y}=1$ are treated as uncertain, because small prediction errors in this region may easily change the final decision.

The threshold pair $({\tau }_l,{\tau }_h)$ controls the trade-off between decision coverage and decision reliability. A narrower uncertainty band increases coverage by assigning definitive actions to more matrices, but may also increase the risk of incorrect decisions near the neutral point. In contrast, a wider band improves the reliability of decided samples by reserving borderline cases as uncertain, at the cost of leaving more inputs unresolved.

In practical deployment, the framework can adopt a conservative policy: relabeling is activated only when $\widehat{y}\ge {\tau }_h$, while both skip and uncertain cases keep the original labeling. This conservative rule avoids incurring preprocessing costs when the predicted benefit is not sufficiently clear.

5. Two-Phase Matrix Reordering Algorithm

In this section, we present pGOrder, a low-cost parallel reformulation of GOrder. We first revisit GOrder from an algebraic perspective and show that its reuse-oriented objective naturally suggests a batched approximation. Based on this observation, we decompose the sequential greedy procedure of GOrder into two complementary stages: global coarse-grained batch generation and local fine-grained refinement. The first stage captures dominant global reuse structure on the GPU, while the second stage recovers fine-grained ordering quality within each batch on multi-core CPUs. Finally, we discuss the parameter selection strategy of pGOrder.

5.1. GOrder from an Algebraic Perspective

Let $\mathbf{M}=⟨G(V,E),\pi ⟩$ denote the matrix induced by graph $G(V,E)$ under labeling $\pi$, and let $\mathbf{A}={\left(a_{ij}\right)}_{n\times n}$ denote the corresponding adjacency matrix, where $a_{ij}=1$ indicates a directed edge from $v_j$ to $v_i$. Let ${\mathbf{e}}_i\in {\mathbb{R}}^n$ be the i-th standard basis vector, whose i-th entry is 1 and all other entries are 0. Then the neighbor term of the pairwise reuse score can be written as

$$S_n(v_i,v_j)={\mathbf{e}}_j^T(\mathbf{A}+{\mathbf{A}}^T){\mathbf{e}}_i,$$

(8)

and the sibling term can be expressed as

$$S_s(v_i,v_j)={\mathbf{e}}_j^T\mathbf{A}{\mathbf{A}}^T{\mathbf{e}}_i.$$

(9)

Therefore, the total pairwise reuse score is

$$S(v_i,v_j)={\mathbf{e}}_j^T(\mathbf{A}{\mathbf{A}}^T+\mathbf{A}+{\mathbf{A}}^T){\mathbf{e}}_i.$$

(10)

Let $\mathbf{B}=\mathbf{A}{\mathbf{A}}^T+\mathbf{A}+{\mathbf{A}}^T$. From Equation (6), the GOrder objective can be rewritten as

$$F_{\omega }\left(\pi \right)={\displaystyle \sum _{i=2}^n}{\displaystyle \sum _{j=w_i}^{i-1}}{\mathbf{e}}_i^T\mathbf{B}{\mathbf{e}}_j={\displaystyle \sum _{i=2}^n}{\mathbf{e}}_i^T\mathbf{B}{\displaystyle \sum _{j=w_i}^{i-1}}{\mathbf{e}}_j.$$

(11)

Let

$${\mathbf{r}}_i={\displaystyle \sum _{j=w_i}^{i-1}}{\mathbf{e}}_j,$$

(12)

which represents the current sliding window. Then

$$F_{\omega }\left(\pi \right)={\displaystyle \sum _{i=2}^n}{\mathbf{e}}_i^T\mathbf{B}{\mathbf{r}}_i.$$

(13)

This form reveals that the GOrder objective is determined by the interaction between each newly appended vertex and the current sliding window. In other words, the ordering quality depends on how well each selected vertex can reuse the data induced by recently labeled vertices.

Let $\mathbf{P}={(p_1,p_2,\dots ,p_n)}^T$ denote the resulting permutation, and let ${\mathbf{S}}^{\left(i\right)}={(s_1^{\left(i\right)},s_2^{\left(i\right)},\dots ,s_n^{\left(i\right)})}^T$ denote the vector of current gscores at the beginning of iteration i, where $s_j^{\left(i\right)}$ is the score of vertex $v_j$. Then GOrder can be interpreted as the following iterative process:

(1)

select the best current vertex, i.e.,

$$p_i=j,s_j^{\left(i\right)}={\parallel {\mathbf{S}}^{\left(i\right)}\parallel }_{\infty };$$

(14)

(2)

update the score vector according to the new sliding window:

$${\mathbf{S}}^{(i+1)}=\mathbf{B}{\displaystyle \sum _{j=w_{i+1}}^i}{\mathbf{e}}_{p_j}.$$

(15)

The priority-queue implementation accelerates this process by exploiting incremental updates. Specifically,

$$\begin{array}{cc}\hfill {\mathbf{S}}^{(i+1)}& =\mathbf{B}{\displaystyle \sum _{j=w_{i+1}}^i}{\mathbf{e}}_{p_j}\hfill \\ \hfill & =\mathbf{B}{\displaystyle \sum _{j=w_i}^{i-1}}{\mathbf{e}}_{p_j}-\mathbf{B}{\mathbf{e}}_{p_{i-\omega }}+\mathbf{B}{\mathbf{e}}_{p_i}\hfill \\ \hfill & ={\mathbf{S}}^{\left(i\right)}-\mathbf{B}{\mathbf{e}}_{p_{i-\omega }}+\mathbf{B}{\mathbf{e}}_{p_i}.\hfill \end{array}$$

(16)

This update shows that the next score vector can be obtained by removing the contribution of the oldest vertex in the sliding window and adding the contribution of the newly appended vertex.

The above reformulation reveals two optimization opportunities.

First, the sibling term is the dominant contributor to SpMV input-vector reuse. A larger $S_s(v_i,v_j)$ means that the corresponding rows share more input-vector entries and are therefore more likely to benefit from cache reuse. In our implementation, we focus on the sibling term because it directly captures shared input-vector entries between rows and is the dominant locality signal targeted by pGOrder. Therefore, pGOrder retains only the sibling term and uses

$$\mathbf{B}=\mathbf{A}{\mathbf{A}}^T,$$

(17)

which reduces computational cost while preserving the main locality signal.

Second, Equation (16) suggests a batched generalization. Instead of appending only one vertex at a time, one may append a set of high-score vertices simultaneously. Let $q\in {\mathbb{N}}^{+}$ denote the batch size. Then, the score update can be generalized as

$${\mathbf{S}}^{(i+q)}={\mathbf{S}}^{\left(i\right)}-\mathbf{B}{\displaystyle \sum _{j=w_i}^{w_{i+q-1}}}{\mathbf{e}}_{p_j}+\mathbf{B}{\displaystyle \sum _{j=i}^{i+q-1}}{\mathbf{e}}_{p_j}.$$

(18)

When $q=\omega$, the entire sliding window is replaced in one step, yielding

$${\mathbf{S}}^{(i+\omega )}=\mathbf{B}{\displaystyle \sum _{j=i}^{i+\omega -1}}{\mathbf{e}}_{p_j}.$$

(19)

By introducing the batch index k, this can be rewritten as

$${\mathbf{S}}^{\left(k\right)}=\mathbf{B}{\displaystyle \sum _{j=(k-1)\omega }^{k\omega -1}}{\mathbf{e}}_{p_j}.$$

(20)

Equation (20) implies a batched variant of GOrder: in each iteration, a group of high-score vertices can be selected to form a batch, and the score vector can then be recomputed with respect to that batch. Once the batches are generated, the vertices within each batch can be refined independently. This observation directly motivates the proposed two-phase design.

5.2. Overview of pGOrder

As shown in Algorithm 3, pGOrder decouples the global coarse-grained selection from local fine-grained refinement. In Phase 1, the vertex set is partitioned into reuse-aware vertex batches according to global sibling-reuse signals. In Phase 2, a localized GOrder-style refinement is applied within each batch to determine the final intra-batch ordering.

Algorithm 3 pGOrder

Require:  $G(V,E)$, $\mathsf{\Omega }$, $\omega$, $\tau$.  Ensure:  perm.   1: $\left\{V^{\left(i\right)}\right\}\leftarrow \mathtt{GlobalBatchGeneration}(G(V,E),\mathsf{\Omega },\tau )$;   2: for$i=0,1,\cdots ,\lceil {\displaystyle \frac{n}{\mathsf{\Omega }}}\rceil -1$in parallel do   3:        $\mathit{perm}[i·\mathsf{\Omega }:(i+1)·\mathsf{\Omega })\leftarrow \mathtt{LocalRefine}(B(V,V^{\left(i\right)}),\omega )$;   4: end for

5.3. Phase 1: Global Coarse-Grained Batch Generation

As shown in Algorithm 4, Phase 1 generates vertex batches iteratively on the GPU. Given a batch size $\mathsf{\Omega }$, the algorithm produces $\lceil {\displaystyle \frac{n}{\mathsf{\Omega }}}\rceil$ batches. In each iteration, the top-$\mathsf{\Omega }$ unlabeled vertices with the highest current scores are selected to form one batch. The score values of the remaining unlabeled vertices are then recomputed with respect to the newly selected batch. The graph is represented by four arrays: offset1, col_ind1, offset2, and col_ind2. The first two arrays encode the in-neighbor lists, while the latter two encode the out-neighbor lists. This representation supports efficient traversal of sibling relationships, at the cost of moderate additional storage overhead.

Phase 1 mainly consists of three operations: (i) sorting the unlabeled vertices according to their current scores, (ii) extracting the top-$\mathsf{\Omega }$ vertices to form a batch, and (iii) recomputing the scores of the remaining unlabeled vertices. Since this stage operates on the full graph and repeatedly updates a large number of candidate vertices, the GPU is well suited for accelerating its parallel workload.

Algorithm 4 GlobalBatchGeneration

Require:  $G(V,E)$, $\mathsf{\Omega }$, $\tau$.  Ensure:  $\left\{V^{\left(i\right)}\right\}$.   1: Each $v\in V$ maintains a score value $s_v$;   2: $s_v\leftarrow \mathtt{0}\mathtt{x}\mathtt{80000000}\mathtt{u}(\forall vs.\in V)$;   3: $V^{\left(0\right)}\leftarrow \mathtt{Initial}\left(\right)$;   4: for$i=1;i<\lceil {\displaystyle \frac{n}{\mathsf{\Omega }}}\rceil ;++i$do   5:        Sort vertices in descending order according to $s_v$;   6:        $V^{\left(i\right)}\leftarrow$ the top-$\mathsf{\Omega }$ vertices;   7:        $s_v\leftarrow s_v\&\mathtt{0}\mathtt{x}\mathtt{80000000}\mathtt{u}(\forall vs.\in V)$;   8:        $s_v\leftarrow \mathtt{0}\mathtt{x}\mathtt{0}\mathtt{u}(\forall vs.\in V^{\left(i\right)})$;   9:        $\mathtt{UpdateGScore}(G(V,E),V^{\left(i\right)},\tau )$;  10: end for

5.3.1. Sorting Unlabeled Vertices

To accelerate sorting, we employ a compact bit-field encoding in which the labeling flag and the score value are packed into a single unsigned integer. Specifically, the highest bit indicates the labeling status, where 1 denotes an unlabeled vertex and 0 denotes a labeled vertex, while the remaining 31 bits store the current score. This encoding provides two useful properties. First, unlabeled vertices are always ranked ahead of labeled vertices as their highest bit is set. Second, among unlabeled vertices, the relative order is still determined by the lower 31 bits, thereby preserving the order induced by the score values. Based on this design, SortPairsDescending can be directly utilized.

5.3.2. Maintaining the Top-$\mathsf{\Omega }$ Vertices

After sorting, the top-$\mathsf{\Omega }$ unlabeled vertices are located in the first $\mathsf{\Omega }$ positions and can therefore be extracted directly to form the current batch. The labeling flags of these selected vertices are then cleared so that they will not participate in subsequent iterations. To ensure correctness in later score recomputation, the score fields of all vertices are restored after the labeling flags have been modified.

5.3.3. Updating the Unlabeled Vertices

Recomputing the scores of the remaining unlabeled vertices may dominate the computational cost of Phase 1. For each selected vertex $x\in V_i$, updating the relevant scores requires first visiting every in-neighbor $y\in N_I\left(x\right)$ and then traversing all out-neighbors $z\in N_O\left(y\right)$. This operation effectively enumerates the sibling vertices affected by the newly selected batch. As shown in Algorithm 5, we adopt a hierarchical parallel scheduling strategy:

• Each selected vertex x is assigned to one thread block;
• Each in-neighbor $y\in N_I\left(x\right)$ is assigned to one warp within that block;
• Each out-neighbor $z\in N_O\left(y\right)$ is assigned to one thread within the warp.

Atomic addition is used to accumulate score contributions for the affected vertices.

This hierarchical mapping exploits the nested structure of sibling traversal and provides substantial parallelism for GPU execution. Since the score updates are additive and localized to affected sibling vertices, the kernel scales naturally with the size of the selected batch.

Algorithm 5 UpdateGScore

Require:  $G(V,E)$, $V^{\left(i\right)}$, $\tau$.   1: $\mathit{wid}\leftarrow \mathit{threadIdx}.\mathit{x}/32$;   2: $\mathit{lid}\leftarrow \mathit{threadIdx}.\mathit{x}mod32$;   3: $\mathit{xid}\leftarrow V^{\left(i\right)}[\mathit{blockIdx}.\mathit{x}]$;   4: $\mathit{start}\_\mathit{y}\leftarrow \mathit{offset}\mathit{1}\left[\mathit{xid}\right]$;   5: $\mathit{end}\_\mathit{y}\leftarrow \mathit{offset}\mathit{1}[\mathit{xid}+1]$;   6: if$\mathit{end}\_\mathit{y}-\mathit{start}\_\mathit{y}<\tau$then   7:       for $\mathit{idy}=\mathit{start}\_\mathit{y}+\mathit{wid};\mathit{idy}<\mathit{end}\_\mathit{y};\mathit{idy}+={\displaystyle \frac{\mathit{blockDim}.\mathit{x}}{32}}$ do   8:             $\mathit{yid}\leftarrow \mathit{col}\_\mathit{ind}\mathit{1}\left[\mathit{idy}\right]$;   9:             $\mathit{start}\_\mathit{z}\leftarrow \mathit{offset}\mathit{2}\left[\mathit{yid}\right]$;  10:             $\mathit{end}\_\mathit{z}\leftarrow \mathit{offset}\mathit{2}[\mathit{yid}+1]$;  11:             if $\mathit{end}\_\mathit{z}-\mathit{start}\_\mathit{z}<\tau$ then  12:                   for $\mathit{idz}=\mathit{start}\_\mathit{z}+\mathit{lid};\mathit{idz}<\mathit{end}\_\mathit{z};\mathit{idz}+=32$ do  13:                         $\mathit{zid}\leftarrow \mathit{col}\_\mathit{ind}\mathit{2}\left[\mathit{idz}\right]$;  14:                         $\mathit{sts}\leftarrow s\left[\mathit{zid}\right]>>31$;  15:                         if sts then  16:                               $\mathtt{atomicAdd}(\&s[\mathit{zid}],1)$;  17:                         end if  18:                   end for  19:             end if  20:       end for  21: end if

5.3.4. Initialization

The construction of the initial batch has a noticeable impact on the final labeling quality. Whereas GOrder starts from the single vertex with the maximum in-degree, pGOrder adopts a structured warm-start strategy to construct the first batch.

Specifically, the warm-start procedure first selects the top-32 vertices with the largest in-degrees and recomputes the scores of the remaining unlabeled vertices according to these selected vertices. It then repeatedly appends high-score vertices to the initial batch. The number of appended vertices doubles after each stage, following the sequence 32, 64, 128, and so on, until the initial batch reaches the batch size $\mathsf{\Omega }$. After each append operation, the scores of the remaining unlabeled vertices are recomputed with respect to the enlarged initial batch.

This progressive initialization provides a more stable starting point than a single-vertex seed and improves the quality of the early batches.

5.4. Phase 2: Local Fine-Grained Refinement

After Phase 1 has generated the vertex batches, Phase 2 refines the local ordering within each batch independently on multi-core CPUs. Since different batches are disjoint, they can be processed concurrently. This phase recovers additional locality benefit that may be lost when Phase 1 performs only coarse-grained batched selection.

As shown in Algorithm 6, the refinement procedure is based on a localized variant of GOrder. Compared with the original GOrder, pGOrder introduces two modifications. First, the incKey and desKey operations are triggered only by sibling vertices, rather than by both neighboring and sibling vertices. Second, these updates are restricted to vertices whose in-degree and out-degree are both below the threshold L, so that expensive traversals through very high-degree vertices can be avoided.

These modifications are motivated by the observation that sibling relationships dominate useful cache reuse and that very high-degree vertices can introduce disproportionate update cost. By focusing on sibling-induced updates and restricting expensive traversals through the threshold L, Phase 2 preserves the main locality benefit of GOrder while remaining efficient enough to be applied independently to many batches.

Algorithm 6 LocalRefine

Require:  $B(V,V^{\left(i\right)})$, $\omega$.  Ensure:  perm.   1: Construct priority queue Q and push all $v\in V^{\left(i\right)}$ into it;   2: $i\leftarrow 0$; $L\leftarrow {\displaystyle \frac{\sqrt{n}}{4}}$;   3: while$\left|Q\right|>0$do   4:       $u\leftarrow Q.\mathrm{pop}\left(\right)$;   5:       $\mathit{perm}\left[i\right]\leftarrow u$;   6:       if $d_I\left(u\right)<L$ then   7:            for $v\in N_I\left(u\right)$ do   8:                  if $d_O\left(v\right)<L$ then   9:                        for $w\in N_O\left(v\right)$ do  10:                             if $w\in Q$then$Q.\mathrm{incKey}\left(w\right)$;  11:                        end for  12:                  end if  13:            end for  14:       end if  15:       if $i\ge \omega$ then  16:            $u\leftarrow \mathit{perm}[i-\omega ]$;  17:            if $d_I\left(u\right)<L$ then  18:                  for $v\in N_I\left(u\right)$ do  19:                        if $d_O\left(v\right)<L$ then  20:                             for $w\in N_O\left(v\right)$ do  21:                                  if $w\in Q$then$Q.\mathrm{desKey}\left(w\right)$;  22:                             end for  23:                        end if  24:                  end for  25:            end if  26:       end if  27:       $i\leftarrow i+1$;  28: end while

From a graph perspective, the sibling search in local refinement can be interpreted as a two-step traversal on a bipartite representation of the graph. Given $G(V,E)$, we construct a bipartite graph $B(P_1,P_2,E_B)$, where $P_1=P_2=V$ and

$$E_B=\{(u,v):(u,v)\in E\left(G\right),u\in P_1,v\in P_2\}.$$

For a vertex u in the current sliding window, the algorithm first traverses from $u\in P_2$ backward to its in-neighbors in $P_1$, and then traverses forward from these intermediate vertices back to $P_2$. The vertices reached in the second step share at least one in-neighbor with u, and therefore correspond to the sibling term $S_s(u,v)=|N_I\left(u\right)\cap N_I\left(v\right)|$.

This view provides an intuitive explanation of pGOrder’s two-phase design. Phase 1 performs a coarse partition of the $P_2$ side into reuse-aware vertex batches, while Phase 2 refines the ordering within each induced subgraph $B(P_1,V^{\left(i\right)},E_B)$. Since these induced subgraphs are processed independently, the local refinement can be executed in parallel across batches.

From an optimization perspective, pGOrder can be viewed as a two-level approximation to GOrder. The global coarse-grained batch generation phase captures the dominant reuse structure at low cost, while the local fine-grained refinement phase recovers part of the ordering quality lost by batching. Their combination preserves most of the locality benefit of GOrder while substantially reducing order-generation overhead.

5.5. Parameter Selection

pGOrder involves four parameters: the global batch size $\mathsf{\Omega }$, the local sliding-window size $\omega$, and the degree thresholds $\tau$ and L. $\tau$ is set to be a sufficiently large value. $\omega$ and L are inherited from GOrder, and we retain their original settings, namely $\omega =5$ and $L={\displaystyle \frac{\sqrt{n}}{4}}$. Here, n denotes the number of vertices in the original graph, rather than the size of an individual batch. Therefore, this subsection mainly discusses the choice of $\mathsf{\Omega }$, which affects both preprocessing overhead and final relabeling quality.

The parameter $\mathsf{\Omega }$ controls the granularity of global coarse-grained batch generation. In general, a larger $\mathsf{\Omega }$ reduces the number of global batch-generation rounds and therefore helps reduce order-generation time. However, an excessively large $\mathsf{\Omega }$ also weakens the ability of the global phase to capture large-scale reuse structure. Once the coarse-grained batches become too large, the subsequent local fine-grained refinement may not fully recover the lost ordering quality. As a result, the choice of $\mathsf{\Omega }$ reflects a trade-off between preprocessing overhead and locality improvement.

Searching for the optimal $\mathsf{\Omega }$ for each matrix is impractical because such a search would require repeatedly performing relabeling and measuring the resulting SpMV performance. Instead, we adopt an empirical piecewise rule as the default parameter setting. Let $d=m/n$ denote the average out-degree of the graph. We use $\sqrt{{\displaystyle \frac{n}{d}}}$ as a coarse indicator that jointly reflects graph scale and sparsity, and set

$$\mathsf{\Omega }=\left\{\begin{array}{cc}{2}^{10},\hfill & {\log }_2\left(\sqrt{{\displaystyle \frac{n}{d}}}\right)<10,\hfill \\ 2^{14},\hfill & 10\le {\log }_2\left(\sqrt{{\displaystyle \frac{n}{d}}}\right)<12,\hfill \\ 2^{18},\hfill & {\log }_2\left(\sqrt{{\displaystyle \frac{n}{d}}}\right)\ge 12.\hfill \end{array}\right.$$

(21)

This rule is not intended to guarantee the optimal $\mathsf{\Omega }$ for every input matrix. Instead, it provides a practical default configuration that avoids per-matrix tuning while balancing preprocessing cost and relabeling quality across different graph scales and sparsity levels. Unless otherwise stated, this default rule is used in all pGOrder experiments.

6. Complexity Analysis

We focus primarily on sampled RD extraction and pGOrder, as these two components account for the dominant computational overhead, compared with Ridge inference, gating evaluation, and matrix permutation. Since both components involve irregular and data-dependent traversals whose costs depend strongly on the graph structure, deriving a tight complexity expression is generally difficult. We therefore characterize their principal computational operations and derive conservative upper bounds.

6.1. Sampled Reuse-Distance Extraction

The dominant costs of sampled RD extraction are HLL register updates during backward scanning and periodic HLL cardinality estimation. For query s, let ${\mathsf{\ell }}_s$ denote the number of trace positions inspected before the query terminates. Each inspected position performs at most one constant-time HLL update. Therefore, the total update work for query s is $O\left({\mathsf{\ell }}_s\right)$.

The trace is processed in chunks of T positions. The number of HLL estimates for query s satisfies

$$E_s=O\left({\displaystyle \frac{{\mathsf{\ell }}_s}{T}}\right).$$

Since each estimate scans all R HLL registers, the total work of one sampled query is therefore

$$W_s^{\mathrm{RD}}=O\left({\mathsf{\ell }}_s+E_{s}R\right)=O\left({\mathsf{\ell }}_s+{\displaystyle \frac{R}{T}}{\mathsf{\ell }}_s\right).$$

The total work over all sampled queries is

$$W_{\mathrm{RD}}=O\left((1+{\displaystyle \frac{R}{T}}){\displaystyle \sum _{s=1}^S}{\mathsf{\ell }}_s\right).$$

Under the current configuration $T=R$, this simplifies to

$$W_{\mathrm{RD}}=O\left({\displaystyle \sum _{s=1}^S}{\mathsf{\ell }}_s\right).$$

6.2. Complexity of pGOrder

6.2.1. Complexity of Global Coarse-Grained Batch Generation

Phase 1 consists primarily of sorting, key maintenance, and two-hop sibling traversal. All n vertices are sorted during each iteration round, including both labeled and unlabeled vertices. For fixed-width integer radix sorting, the number of radix passes is constant, and one full sort requires $O\left(n\right)$ work. The sorting and key-maintenance work is therefore

$$W_{\mathrm{sort}}=O\left(⌈{\displaystyle \frac{n}{\mathsf{\Omega }}}⌉n\right).$$

For each selected vertex x, the update kernel first traverses the in-neighbors $y\in N_I\left(x\right)$ and then traverses the out-neighbors $z\in N_O\left(y\right)$. A selected vertex x is expanded only when $d_I\left(x\right)<\tau$, and the out-neighbor list of an intermediate vertex y is expanded only when $d_O\left(y\right)<\tau$. Consequently, the total number of innermost adjacency-list iterations is

$$H_{\tau }=\sum _{x\in V}{\mathbf{1}}_{\{d_I\left(x\right)<\tau \}}\sum _{y\in N_I\left(x\right)}{\mathbf{1}}_{\{d_O\left(y\right)<\tau \}}{d}_O\left(y\right).$$

Changing the order of summation gives the upper bound

$$H_{\tau }\le \sum _{\begin{array}{c}y\in V\\ d_O\left(y\right)<\tau \end{array}}{d}_O{\left(y\right)}^2.$$

Since every expanded intermediate vertex satisfies $d_O\left(y\right)<\tau$, hence

$$H_{\tau }\le \tau \sum _{y\in V{d}_O\left(y\right)<\tau }{d}_O\left(y\right)\le \tau m.$$

Therefore, the complexity of Phase 1 is

$$W_{\mathrm{P}1}=O\left(⌈{\displaystyle \frac{n}{\mathsf{\Omega }}}⌉n+\tau m\right).$$

6.2.2. Complexity of Local Fine-Grained Refinement

Each vertex can trigger a sibling traversal when it is inserted into the local sliding window and when it leaves the window. The total number of innermost adjacency-list iterations in $V^{\left(i\right)}$ is

$$G_i=2\sum _{x\in V^{\left(i\right)}}{\mathbf{1}}_{\{d_I\left(x\right)<L\}}\sum _{y\in N_I\left(x\right)}{\mathbf{1}}_{\{d_O\left(y\right)<L\}}{d}_O\left(y\right).$$

Since each vertex belongs to exactly one batch $V^{\left(i\right)}$, the total local adjacency-scanning work

$$G=\sum _i{G}_i\le 2\sum _{\begin{array}{c}v\in V\\ d_O\left(v\right)<L\end{array}}{d}_O{\left(v\right)}^2\le 2Lm.$$

For the batch $V^{\left(i\right)}$, each successful score update requires $O\left(\log \right|V^{\left(i\right)}\left|\right)$ work in the priority queue. The complexity of Phase 2 is therefore

$$W_{\mathrm{P}2}=O\left(Lm\log \mathsf{\Omega }\right).$$

Combining the two phases, the complexity of pGOrder is

$$W_{\mathrm{pGOrder}}=O\left(⌈{\displaystyle \frac{n}{\mathsf{\Omega }}}⌉n+(\tau +L\log \mathsf{\Omega })m\right).$$

6.3. Complete Online Framework

For a matrix selected for reordering, the complexity of online framework can be bounded by

$$W_{\mathrm{selected}}=W_{\mathrm{RD}}+W_{\mathrm{pGOrder}}=O\left({\displaystyle \sum _{s=1}^S}{\mathsf{\ell }}_s+⌈{\displaystyle \frac{n}{\mathsf{\Omega }}}⌉n+(\tau +L\log \mathsf{\Omega })m\right).$$

Note that we analyze total computational work rather than parallel span or measured runtime. Furthermore, $W_{\mathrm{selected}}$ is a conservative upper bound, as it does not take the matrix structure into account. Nevertheless, this bound still reflects the influence of the batch size $\mathsf{\Omega }$ and filtering parameters $\tau$ and L.

7. Experiments

The experiments are organized to verify the main contributions of the proposed framework. First, we evaluate the fidelity and extraction cost of the sampled RD features, followed by the prediction accuracy of the headroom predictor. Second, we compare pGOrder with representative matrix-reordering methods in terms of order-generation cost and SpMV performance. Third, we use ablation experiments to quantify the contributions of global batch generation and local refinement, and finally evaluate the complete online cost and per-matrix break-even point of the locality-activated framework. The source code of this work is available at https://github.com/Zhangq388/MATRIX-REORDER (accessed on 21 June 2026).

7.1. Experimental Settings

All experiments are conducted on a server equipped with Intel(R) Xeon(R) Platinum 8352V CPUs and an NVIDIA GeForce RTX 4090 GPU. The detailed hardware configuration is summarized in Table 2. All evaluated methods are implemented in CUDA C++ and compiled with the -O3 optimization flag under Ubuntu 20.04.1 LTS.

Table 2. Hardware configuration.

Processor	Core Configuration	L1 Cache	L2 Cache	L3 Cache	DRAM
CPU	2 × Intel Xeon Platinum 8352V, 144 threads, 2.10 GHz	3.4 MB	90 MB	108 MB	512 GB
GPU	NVIDIA RTX 4090, 128 SMs/16,384 CUDA cores, 2.60 GHz	64 KB	72 MB	–	24 GB

We evaluate two SpMV backends, MERBIT [20] and CSR. MERBIT is used as the primary GPU SpMV backend because it provides a strong baseline and exposes the remaining bottleneck caused by irregular input-vector gather accesses. CSR is included as a reference backend to examine whether the proposed RD-based predictor is tied to a specific SpMV implementation or remains informative for identifying locality-related headroom across different SpMV backends.

For each backend, the relabeling speedup is measured independently using the same set of matrices and the same relabeling protocol. For each matrix and each labeling method, we repeatedly execute SpMV 400 times and report the average execution time. Unless otherwise stated, SpMV speedup is normalized to the runtime under the original labeling for the corresponding backend.

7.2. RD-Based Headroom Prediction

7.2.1. Fidelity and Cost of Sampled RD

We first evaluate whether the sampled RD distribution provides a sufficiently accurate approximation of the exact RD distribution. For each matrix, the exact and sampled features are constructed from the same cache-line access trace using identical RD bins and normalization rules. The common access-stream construction is excluded from both timings. Let

$$D_1={∥{\mathbf{r}}^{\left(e\right)}-{\mathbf{r}}^{\left(s\right)}∥}_1={\displaystyle \sum _{k=1}^{10}}\left|r_k^{\left(e\right)}-r_k^{\left(s\right)}\right|$$

measure the absolute difference between the two normalized distributions. We also report their cosine similarity:

$$C_{\cos }={\displaystyle \frac{{\mathbf{r}}^{\left(e\right)}·{\mathbf{r}}^{\left(s\right)}}{{∥{\mathbf{r}}^{\left(e\right)}∥}_2{∥{\mathbf{r}}^{\left(s\right)}∥}_2}}.$$

Table 3 summarizes the results. Across all three datasets, the mean $L_1$ difference is below 0.016, while the mean cosine similarity is above 0.9998. These results indicate that the sampled method closely preserves the shape of the exact RD distribution. At the same time, sampled RD substantially reduces feature-extraction cost. Therefore, all results reported below are obtained using the sampled-RD predictor.

Table 3. Fidelity and extraction cost of sampled RD relative to exact RD. Times are arithmetic means over the corresponding dataset.

Dataset	Matrices	Mean ${\mathit{D}}_1$	Mean ${\mathit{C}}_{\mathbf{cos}}$	Exact (ms)	Sampled (ms)
Augmented SuiteSparse	810	0.0153	0.999824	8733.36	510.92
SuiteSparse-origin	90	0.0093	0.999941	6674.72	712.40
RMAT	75	0.0137	0.999884	25,285.09	787.05

7.2.2. Prediction Accuracy and Backend Sensitivity

We next evaluate prediction accuracy using three regression metrics:

$$\mathrm{MAE}\left(\log \right)={\displaystyle \frac{1}{N}}{\displaystyle \sum _{i=1}^N}\left|z_i-{\widehat{z}}_i\right|,$$

$$\mathrm{MAE}\left(\mathrm{speedup}\right)={\displaystyle \frac{1}{N}}{\displaystyle \sum _{i=1}^N}\left|y_i-{\widehat{y}}_i\right|,$$

and

$$\mathrm{MAPE}={\displaystyle \frac{1}{N}}{\displaystyle \sum _{i=1}^N}{\displaystyle \frac{\left|y_i-{\widehat{y}}_i\right|}{y_i}}.$$

We also report the Spearman correlation coefficient to measure the rank consistency between the predicted and measured speedups.

Table 4 reports the predictor performance under three evaluation protocols and two SpMV backends. The GKF protocol performs 5-fold GroupKFold validation on the 810 augmented SuiteSparse samples, where the split is performed by original graph. Therefore, all augmented samples derived from the same original matrix are assigned to the same fold. The S2O protocol evaluates generalization to the original labelings of previously unseen real-world matrices using a strictly graph-disjoint five-fold protocol. In each fold, all nine local-swap samples derived from 72 of the 90 SuiteSparse graphs (648 augmented training samples) are used for training. The original labelings of the remaining 18 graphs are used exclusively for testing. Therefore, none of the local-swap samples derived from a held-out graph appears in the corresponding training set. The S2R protocol trains the model on the augmented SuiteSparse samples and tests it on the 75 RMAT matrices, thereby evaluating robustness under synthetic distribution shift.

Table 4. Prediction performance of the sampled-RD-based headroom predictor under the MERBIT and CSR backends.

Backend	Protocol	Spearman	MAE (Log)	MAE (Speedup)	MAPE
MERBIT	GKF	0.8863	0.0792	0.1291	7.84%
	S2O	0.6561	0.0591	0.0716	5.77%
	S2R	0.9544	0.1609	0.3101	18.35%
CSR	GKF	0.8368	0.0900	0.1339	9.05%
	S2O	0.6433	0.0789	0.0972	7.73%
	S2R	0.8686	1.6691	1.2372	597.38%

First, under the GKF protocol, the predictor achieves Spearman correlations of 0.8863 and 0.8368 under MERBIT and CSR, respectively. The corresponding MAPE values are 7.84% and 9.05%. These results indicate that the RD distribution can effectively characterize reordering headroom within the augmented SuiteSparse domain under both backends.

Second, under the S2O protocol, the predictor achieves an MAE(speedup) of 0.0716 and 0.0972 under MERBIT and CSR, respectively. The corresponding MAPE values are 5.77% and 7.73%. Since every test graph is excluded from both model training and local-swap augmentation, these results rule out information leakage between augmented variants of the same underlying graph. The predictor remains informative for estimating the reordering headroom of previously unseen real-world matrices.

Third, the S2R results should be interpreted separately for the two backends. Under MERBIT, the predictor achieves a high Spearman correlation of 0.9544 on RMAT, although the MAPE increases to 18.35%. This indicates that exact numerical prediction becomes more difficult under synthetic distribution shift, but the RD features still preserve a strong rank relationship with the measured reordering benefit.

Backend Limitation: The RMAT–CSR Case

The external RMAT evaluation reveals an important limitation of the RD-based predictor. Under the CSR backend, GOrder consistently increases the SpMV runtime of the evaluated RMAT matrices, although their substantial long-distance RD mass leads the predictor to identify locality headroom. This behavior does not imply that the RD signal is incorrect. Instead, it shows that reducing input-vector reuse distances does not necessarily translate into runtime improvement for every SpMV backend.

To examine this case, we profile the CSR kernel on three representative RMAT matrices using NVIDIA Nsight Compute. Table 5 reports the ratios after GOrder relative to the original labeling. Although the kernel time increases by $2.99\times$–$30.96\times$, the DRAM-read traffic and L2-sector requests are reduced, while the executed instruction count remains almost unchanged. Therefore, the slowdown is not caused by increased memory traffic or additional computation. In contrast, SM throughput and the number of active warps decrease substantially, indicating poor GPU utilization.

Table 5. Nsight Compute profiling ratios of the CSR kernel after GOrder relative to the original labeling on three representative RMAT matrices.

RMAT	Kernel Time	SM Thr.	Act. Warps	Inst.	DRAM Read	L2 Sec.
25	2.99	0.31	0.92	0.97	0.91	0.86
55	8.23	0.11	0.72	0.96	0.93	0.67
75	30.96	0.03	0.35	1.00	0.93	0.63

To further investigate the utilization loss, we analyze how the nonzeros are distributed along the reordered row sequence. Given a window size W, the rows are partitioned into $K_W=⌈{\displaystyle \frac{n}{W}}⌉$ consecutive windows. The workload of the k-th window is defined as

$$H_k\left(W\right)={\displaystyle \sum _{i=kW}^{\min \left(\right(k+1)W,n)-1}}{m}_i,$$

where $m_i$ denotes the number of nonzeros in row i. The mean window workload is

$$\overline{H}\left(W\right)={\displaystyle \frac{1}{K_W}}{\displaystyle \sum _{k=0}^{K_W-1}}{H}_k\left(W\right),$$

and the coefficient of variation is defined as

$${\mathrm{CV}}_W={\displaystyle \frac{\sqrt{\frac{1}{K_W}{\displaystyle \sum _{k=0}^{K_W-1}}{\left(H_k\left(W\right)-\overline{H}\left(W\right)\right)}^2}}{\overline{H}\left(W\right)}}.$$

${\mathrm{CV}}_W$ measures how unevenly the nonzeros are distributed across consecutive row ranges. We additionally define

$$H_{\max }\left(W\right)=\underset{k}{\max }{H}_k\left(W\right)$$

to characterize the heaviest contiguous row range.

Table 6 reports the ratios of window-level workload statistics after GOrder relative to the original row ordering. Both the ${\mathrm{CV}}_W$ and $H_{\max }\left(W\right)$ increase after reordering, indicating that GOrder concentrates rows with large numbers of nonzeros into a small number of contiguous row ranges. This concentration is consistent with the profiling results in Table 5: although memory traffic is reduced, the evaluated row-oriented CSR kernel exhibits substantially lower SM utilization. The fixed-row windows used above do not necessarily correspond exactly to GPU thread blocks. Instead, they serve as multi-scale proxies for contiguous-row workload concentration, which is particularly relevant to the scheduling behavior of the evaluated CSR kernel.

Table 6. Ratios of window-level workload statistics after GOrder relative to the original row ordering.

RMAT	W	${\mathbf{CV}}_{\mathit{W}}$ Ratio	${\mathit{H}}_{\max }\left(\mathit{W}\right)$ Ratio
25	32	5.47	10.59
	128	10.30	22.06
	512	19.55	50.73
55	32	5.51	12.02
	128	10.43	26.10
	512	19.54	61.12
75	32	5.56	13.33
	128	10.72	31.02
	512	20.51	76.58

The failure is therefore not an intrinsic property of the ordering alone. It arises from the interaction between the reordered row sequence and the workload-mapping strategy of the target SpMV kernel. The same ordering can consequently behave differently under CSR, MERBIT, or another execution backend. This analysis clarifies the scope of the current feature set. The RD distribution characterizes locality-related headroom in the input-vector access stream, but it is not a complete backend-independent runtime descriptor.

7.2.3. Feature Interpretation

Table 7 shows the Ridge regression coefficients trained on the augmented SuiteSparse set under MERBIT and CSR backends. For each backend, the model is trained using the same RD features but different backend-specific speedup targets.

Table 7. Standardized Ridge regression coefficients of the sampled-RD predictors trained on the augmented SuiteSparse set under the MERBIT and CSR backends.

Backend	${\mathbf{r}}_{\mathbf{1}}$	${\mathbf{r}}_{\mathbf{2}}$	${\mathbf{r}}_{\mathbf{3}}$	${\mathbf{r}}_{\mathbf{4}}$	${\mathbf{r}}_{\mathbf{5}}$	${\mathbf{r}}_{\mathbf{6}}$	${\mathbf{r}}_{\mathbf{7}}$	${\mathbf{r}}_{\mathbf{8}}$	${\mathbf{r}}_{\mathbf{9}}$	${\mathbf{r}}_{\mathbf{10}}$
MERBIT	−0.065	−0.043	−0.017	−0.011	0.029	−0.002	−0.005	−0.025	0.187	0.153
CSR	−0.063	−0.050	0.000	−0.011	0.046	−0.015	0.033	−0.037	0.120	0.163

The coefficient patterns are consistent across the two backends. Under MERBIT, the largest positive coefficients correspond to $r_9$ (0.187) and $r_{10}$ (0.153), while the most negative coefficients correspond to $r_1$ (−0.065) and $r_2$ (−0.043). Under CSR, $r_{10}$ (0.163) and $r_9$ (0.120) again have the largest positive coefficients, and $r_1$ (−0.063) and $r_2$ (−0.050) remain the most negative coefficients.

This pattern is consistent with the intuition behind the RD distribution. A larger proportion of short-distance reuse usually means that the original labeling already provides favorable input-vector locality, leaving limited room for further improvement. In contrast, a larger proportion of long-distance reuse indicates a heavier reuse tail and poorer temporal locality, suggesting greater potential benefit from relabeling.

This observation also agrees with the design of the RD bins. The early bins mainly describe short-range reuse, such as cache-line-level locality and thread-block-level locality, whereas the later bins correspond to longer reuse distances, especially those approaching or exceeding the L2-cache range. Therefore, the predictor tends to treat short-distance reuse as a signal of limited headroom and long-distance reuse as a signal of larger reordering headroom.

The similar coefficient trends under MERBIT and CSR suggest that the RD distribution captures a backend-shared input-vector locality signal. However, as indicated by the RMAT-CSR results, this locality signal alone is not sufficient for backend-specific end-to-end speedup prediction. This distinction is important for interpreting the CSR-S2R case: the model can still rank matrices according to locality-related headroom, but the realized speedup of a specific backend may also depend on scheduling, load balance, and row-order effects.

7.2.4. Gate Performance

Besides prediction accuracy, we further evaluate whether the predictor can serve as a gate before relabeling is performed. Let N denote the number of test samples and $N_d$ denote the number of samples that receive a definite decision, i.e., either relabel or skip. The decision coverage is defined as

$$\mathrm{Coverage}={\displaystyle \frac{N_d}{N}}.$$

For the decided samples, let $TP$, $TN$, $FP$, and $FN$ denote true positives, true negatives, false positives, and false negatives, respectively. Here, the positive class corresponds to matrices that truly benefit from relabeling. We report

$$\mathrm{Accuracy}={\displaystyle \frac{TP+TN}{N_d}},$$

$$\mathrm{Precision}={\displaystyle \frac{TP}{TP+FP}},$$

and

$$\mathrm{Recall}={\displaystyle \frac{TP}{TP+FN}}.$$

Table 8 reports the band-gate performance on the SuiteSparse-origin test set under different threshold pairs. The results show a clear trade-off between decision coverage and decision reliability. When the uncertainty band is narrow, more samples receive definite decisions, but the decision accuracy is relatively lower. As the uncertainty band becomes wider, fewer samples are decided, while the reliability of the decided samples generally improves.

Table 8. Band-gate performance on the SuiteSparse-origin test set under the primary MERBIT backend.

Backend	$\mathbf{(}{\mathit{\tau }}_{\mathit{l}},{\mathit{\tau }}_{\mathit{h}}\mathbf{)}$	Coverage	Accuracy	Precision	Recall
MERBIT	(0.99, 1.01)	0.9111	0.7317	0.7955	0.7143
	(0.98, 1.02)	0.8556	0.7703	0.8500	0.7556
	(0.97, 1.03)	0.7556	0.7941	0.8462	0.8049
	(0.96, 1.04)	0.6444	0.8621	0.8684	0.9167
	(0.95, 1.05)	0.5889	0.8868	0.8649	0.9697
	(0.94, 1.06)	0.4111	0.8684	0.8649	1.0000
	(0.93, 1.07)	0.4000	0.8571	0.8571	1.0000

Under MERBIT, the threshold pair $({\tau }_l,{\tau }_h)=(0.95,1.05)$ provides a balanced operating point. It achieves 58.89% coverage, 88.68% accuracy, 86.49% precision, and 96.97% recall. In this case, 37 matrices are predicted as beneficial for relabeling, including 32 true positives and 5 false positives.

CSR gate results are omitted from the main discussion because CSR is used only as a reference backend for sensitivity analysis.

7.3. Evaluation of pGOrder

7.3.1. Comparison with Other Matrix Reordering Methods

We compare pGOrder with five representative matrix reordering methods: DegSort, DBG, RCM, RabbitOrder and GOrder. The comparison focuses on the order-generation overhead of each reordering method and the resulting SpMV speedup. We use $({\tau }_l,{\tau }_h)=(0.95,1.05)$ to select 37 matrices from the SuiteSparse-origin test set. All SpMV speedups in this subsection are measured using MERBIT and normalized to the runtime under the original labeling. In this comparison, order-generation time refers to the time required by each reordering method to generate the vertex order, excluding the RD-feature extraction and prediction overhead.

Let $T_p\left(\mathrm{ALG}\right)$ denote the order-generation time of a reordering algorithm and $T_s\left(\mathrm{ALG}\right)$ denote the SpMV runtime after applying that algorithm. We define the normalized order-generation time and SpMV speedup as

$$t_p\left(\mathrm{ALG}\right)={\displaystyle \frac{T_p\left(\mathrm{ALG}\right)}{T_p\left(\mathrm{pGOrder}\right)}},t_s\left(\mathrm{ALG}\right)={\displaystyle \frac{T_s\left(\mathrm{pGOrder}\right)}{T_s\left(\mathrm{ALG}\right)}},$$

respectively. Thus, a smaller $t_p(·)$ indicates lower order-generation cost, while a larger $t_s(·)$ indicates better SpMV performance. The SpMV speedup over the original labeling is defined as

$$t_o\left(\mathrm{ALG}\right)={\displaystyle \frac{T_s\left(\mathrm{origin}\right)}{T_s\left(\mathrm{ALG}\right)}}.$$

Figure 5 plots $\log \left(t_p\right)$ and $\log \left(t_s\right)$, with each marker representing one method–matrix pair. The vertical dashed line corresponds to $t_p=1$, meaning that the method has the same order-generation time as pGOrder, while the horizontal dashed line corresponds to $t_s=1$, meaning that the reordered matrix has the same SpMV runtime as pGOrder. Consequently, Quadrant I represents higher SpMV speedup at a higher order-generation cost relative to pGOrder; Quadrant II represents higher SpMV speedup at a lower generation cost; Quadrant III represents lower SpMV speedup at a lower generation cost; and Quadrant IV represents lower SpMV speedup at a higher generation cost. Table 9 reports the corresponding statistics.

Figure 5. Per-matrix trade-off between normalized order-generation time ($t_p$) and MERBIT SpMV performance ($t_s$). Each marker represents one method–matrix pair. The vertical dashed line denotes $t_p=1$, corresponding to the order-generation time of pGOrder, and the horizontal dashed line denotes $t_s=1$, corresponding to the SpMV performance of pGOrder. Roman numerals I–IV indicate the four quadrants separated by the dashed lines: I/IV have $t_p>1$, II/III have $t_p<1$, I/II have $t_s>1$, and III/IV have $t_s<1$.

Table 9. Statistics of order-generation time $t_p$ and SpMV speedup $t_o$ across algorithms. The best values are shown in bold.

ALG	${\mathbf{t}}_{\mathbf{p}}$				${\mathbf{t}}_{\mathbf{o}}$
	Min	Max	Median	Mean	Min	Max	Median	Mean
DegSort	<0.001	0.0045	$\mathbf{0.0016}$	$\mathbf{0.0018}$	0.6514	1.4589	0.9780	0.9879
DBG	0.0014	0.1253	0.0167	0.0249	0.7427	1.4712	1.0008	1.0359
RCM	1.2782	2204.5	7.0103	138.28	0.8309	3.3316	1.0891	1.2847
RabbitOrder	0.1258	8.2078	3.3756	3.0872	0.2215	1.0072	0.8793	0.7931
GOrder	2.4395	51.569	16.8703	20.156	0.9379	2.9068	1.2904	1.3182
pGOrder	1.0000	1.0000	1.0000	1.0000	0.4860	2.9243	1.2196	1.2636

The results show that DegSort and DBG have very low preprocessing overhead, but their median and mean SpMV speedups are close to $1.00\times$, indicating limited locality improvement. RabbitOrder introduces nontrivial preprocessing overhead but does not provide stable SpMV gains in this experiment. RCM can achieve substantial acceleration on some matrices, as shown by its maximum speedup, but its preprocessing overhead is highly variable and can be extremely large.

GOrder achieves the strongest average SpMV speedup, confirming the effectiveness of its reuse-oriented objective. However, this benefit comes with high preprocessing overhead: its mean order-generation time is $20.16\times$ that of pGOrder. In contrast, pGOrder achieves a mean SpMV speedup of $1.26\times$, close to GOrder’s $1.32\times$, while using pGOrder itself as the normalization baseline for order-generation time. On these 37 selected matrices, pGOrder retains approximately 95.8% of GOrder’s average SpMV speedup while requiring less than 5% of GOrder’s order-generation time.

It is worth noting that pGOrder can still degrade SpMV performance on a small number of matrices, as indicated by the minimum speedup of $0.4860\times$. This occurs because the current gating mechanism is trained to estimate the relabeling headroom of GOrder, rather than the exact speedup of pGOrder on every individual matrix. Although pGOrder is designed to preserve most of GOrder’s locality benefit, its batched approximation may lose ordering quality on matrices with unfavorable local structures. Therefore, the current gate should be interpreted as a headroom filter rather than a strict guarantee of per-matrix speedup.

7.3.2. Cache Profiling

To better understand the source of the MERBIT performance gain, we use NVIDIA Nsight Compute to profile the cache behavior of SpMV on the same 37 matrices. We consider five metrics: L1-Sectors, L1-Hit, L2-Sectors, L2-Hit, and DRAM traffic. L1-Sectors and L2-Sectors count the number of cache sectors requested at L1 and L2, respectively, and therefore reflect memory traffic at different cache levels. L1-Hit and L2-Hit measure the corresponding cache hit rates. DRAM measures the global memory traffic observed during SpMV execution.

Table 10 reports the geometric mean of these metrics, normalized to the original labeling. For sector counts and DRAM traffic, a value smaller than 1 indicates lower memory traffic. For hit-rate metrics, a value larger than 1 indicates a higher hit rate than the original labeling. Since hit rates are ratios whose denominators may also change after relabeling, we interpret them together with sector counts and DRAM traffic rather than in isolation.

Table 10. Geometric mean of cache profiling metrics.

ALG	L1-Sectors	L1-Hit	L2-Sectors	L2-Hit	DRAM
DegSort	0.9988	0.8838	1.0126	1.0550	0.9757
DBG	0.9865	1.0767	0.9826	1.0322	0.9733
RCM	0.8659	1.5578	0.8135	0.9574	0.9175
RabbitOrder	1.1126	0.7000	1.1443	1.0301	1.0970
GOrder	0.7958	2.1261	0.7083	0.8540	0.9329
pGOrder	0.8764	1.7998	0.8112	0.9949	0.9240

The results show that RCM, GOrder, and pGOrder reduce L1-Sectors, L2-Sectors, and DRAM traffic. In particular, GOrder reduces L2-Sectors to 0.7083, and pGOrder reduces L2-Sectors to 0.8112, while pGOrder also reduces DRAM traffic to 0.9240. These reductions are consistent with the expected effect of locality-oriented relabeling: more input-vector reuse is concentrated at shorter reuse distances, reducing the number of cache-sector requests and the amount of global memory traffic during SpMV.

In contrast, DegSort and RabbitOrder show weaker or degraded cache behavior. RabbitOrder increases L1-Sectors, L2-Sectors, and DRAM traffic, while its L1-Hit ratio decreases to 0.7000. This suggests that not all reordering methods improve effective SpMV locality. Some orderings may disturb existing short-range reuse and shift accesses toward longer reuse distances, thereby increasing memory traffic.

7.3.3. Ablation Study

To quantify the contribution of each phase in pGOrder, we compare the full pGOrder with two reduced variants. The first variant, Coarse_only, performs global coarse-grained batch generation without local fine-grained refinement. The second variant, Fine_only, first partitions vertices uniformly and then applies local fine-grained refinement within each partition.

Figure 6 and Table 11 report the SpMV speedups normalized to the original labeling. The full pGOrder achieves the best overall performance, with a mean speedup of 1.2636 and a median speedup of 1.2196. This confirms that the two phases are complementary: the global phase constructs reuse-aware batches, while the local phase further improves the ordering inside each batch.

Figure 6. Per-matrix distribution of SpMV speedup for full pGOrder, Phase 1 only, and Phase 2 only. In the boxplots, circles indicate outlier matrix-level observations.

Table 11. Ablation statistics of normalized SpMV speedup.

ALG	Min	Max	Median	Mean
pGOrder	0.4860	2.9243	1.2196	1.2636
Coarse_only	0.4531	1.9378	1.0692	1.1417
Fine_only	0.9848	1.2416	1.0183	1.0435

Compared with Fine_only, Coarse_only contributes the larger share of the performance gain. Coarse_only achieves a mean speedup of $1.1417\times$, while Fine_only achieves a mean speedup of $1.0435\times$. This indicates that global coarse-grained batch generation captures the dominant locality structure, whereas local fine-grained refinement mainly acts as a refinement step that improves the quality of already meaningful batches.

7.4. End-to-End Cost–Benefit Analysis

We finally evaluate the end-to-end cost of the locality-activated framework on the 90 SuiteSparse-origin test matrices under the MERBIT backend. The sampled-RD predictor applies the upper gate threshold ${\widehat{s}}_i>1.05$ and selects 37 matrices. Offline model training is excluded from the analysis. The online costs include sampled RD extraction, predictor inference, pGOrder generation, and matrix permutation.

7.4.1. Per-Matrix Cost Model

Let $\mathcal{U}$ denote the complete set of 90 matrices and $\mathcal{S}\subset \mathcal{U}$ denote the 37 matrices selected by the gate. Let $N_i$ be the number of subsequent SpMV executions involving matrix i. Without applying the framework, its lifecycle cost is

$$T_i^{\mathrm{orig}}\left(N_i\right)=N_i{t}_i^{\mathrm{orig}},$$

where $t_i^{\mathrm{orig}}$ is the SpMV time under the original labeling.

For a selected matrix $i\in \mathcal{S}$, the complete one-time online preprocessing cost is

$$C_i=t_i^{\mathrm{RD}}+t_i^{\mathrm{pred}}+t_i^{\mathrm{order}}+t_i^{\mathrm{perm}},$$

and its lifecycle cost becomes

$$T_i^{\mathrm{gate}}\left(N_i\right)=C_i+N_i{t}_i^{\mathrm{reordered}}.$$

Define the per-execution saving as

$${\Delta }_i=t_i^{\mathrm{orig}}-t_i^{\mathrm{reordered}}.$$

If ${\Delta }_i>0$, the matrix has a finite break-even point

$$N_{\mathrm{BE},i}=⌈{\displaystyle \frac{C_i}{{\Delta }_i}}⌉.$$

Otherwise, there exists no finite break-even point.

For a filtered matrix $i\notin \mathcal{S}$, the deployed framework incurs only sampled RD extraction and predictor inference, after which the original labeling is retained:

$$T_i^{\mathrm{filter}}\left(N_i\right)=t_i^{\mathrm{RD}}+t_i^{\mathrm{pred}}+N_i{t}_i^{\mathrm{orig}}.$$

7.4.2. Online Preprocessing Cost

Table 12 summarizes the per-matrix execution times of the online preprocessing components. Among the 37 selected matrices, pGOrder generation is the dominant source of overhead. At the mean level, pGOrder accounts for 12,799.22 ms of the mean total preprocessing cost of 13,288.54 ms. Note that the sampled-RD timing statistics in this subsection are obtained from an independent end-to-end run, thus the resulting mean differs slightly from that reported in Table 3.

Table 12. Summary statistics of per-matrix online preprocessing times (ms).

Component	Matrices	Min	Max	Median	Mean
Sampled RD extraction	90	40.20	5430.23	452.35	696.41
Predictor inference	90	0.011	0.039	0.020	0.019
pGOrder generation	37	323.05	248,707.00	1390.70	12,799.22
Matrix permutation	37	7.06	339.44	18.30	47.61
Total preprocessing cost	37	502.81	250,750.36	1864.54	13,288.54

The pGOrder and total preprocessing costs are strongly right-skewed. The mean pGOrder time is more than $9\times$ its median, and its maximum reaches 248,707.00 ms. This gap indicates that a small number of matrices incur exceptionally expensive order generation. The mean values can therefore be dominated by these large matrices, which motivates the following per-matrix break-even analysis.

7.4.3. Per-Matrix Break-Even

Among the 37 selected matrices, 30 obtain a lower SpMV time after pGOrder, whereas 7 are slowed down and consequently have no finite break-even point. We also measured pGOrder and reordered SpMV performance for the 53 filtered matrices, of which 32 would be slowed down by pGOrder, while 21 would obtain a positive SpMV speedup.

Because sampled RD extraction and predictor inference have already been incurred before the gate decision, overriding a rejection would introduce the additional cost

$${\tilde{C}}_i=t_i^{\mathrm{order}}+t_i^{\mathrm{perm}}.$$

For a filtered matrix with ${\Delta }_i>0$, we define the incremental counterfactual break-even point as

$${\tilde{N}}_{\mathrm{BE},i}=⌈{\displaystyle \frac{{\tilde{C}}_i}{{\Delta }_i}}⌉.$$

Figure 7 compares the break-even distributions of the 30 selected-and-accelerated matrices and the 21 filtered-but-hypothetically-accelerated matrices.

Figure 7. Per-matrix break-even distributions of the selected-and-accelerated and filtered-but-hypothetically-accelerated groups. Individual points represent matrices, where blue dots denote selected-and-accelerated matrices, and orange dots denote filtered-but-hypothetically-accelerated matrices.

Among the 30 selected-and-accelerated matrices, the median break-even point is 17,493 SpMV executions. Of these matrices, 17 of the 30 amortize their complete online preprocessing cost within 20,000 executions, and 23 do so within 50,000 executions. The upper tail nevertheless shows that a positive steady-state SpMV speedup does not necessarily imply rapid amortization.

The filtered matrices exhibit substantially weaker end-to-end potential. Their median break-even point is 221,300 executions, approximately $12.7\times$ that of the selected-and-accelerated group. Only 2 of the 21 filtered matrices with positive SpMV speedups would recover the additional reordering cost within 20,000 executions, and only 4 would do so within 50,000 executions.

These results clarify the role of the predictor. It should not be interpreted as a perfect classifier of whether pGOrder produces any positive SpMV speedup. Instead, its primary role is to avoid expensive reordering on matrices whose expected gains are insufficient to amortize the preprocessing cost within a practical reuse horizon. Several filtered matrices exhibit small positive speedups, but their counterfactual break-even points are generally much larger than those of the selected matrices.

8. Conclusions

In this paper, we proposed a locality-activated matrix reordering framework for SpMV. It combines an RD-based headroom predictor with a two-phase parallel reformulation of GOrder. From the graph perspective, the framework can be viewed as selective vertex relabeling guided by input-vector locality headroom. The predictor characterizes the cache-line locality of the input-vector access stream using a sampled RD distribution, allowing the framework to skip matrices with limited expected gain. For matrices selected by the gate, pGOrder performs low-cost relabeling through GPU-based global batch generation and CPU-based local refinement.

The experiments show that the sampled RD distribution closely approximates the exact distribution at substantially lower extraction cost. Under the primary MERBIT backend, pGOrder preserves most of the locality benefit of GOrder while greatly reducing the time required to generate the vertex order. On the selected matrices, pGOrder retains over 95% of GOrder’s SpMV speedup while requiring less than 5% of its order-generation time on average. Cache profiling confirms that the improvement is mainly associated with reduced cache-sector requests and lower memory traffic. The end-to-end results indicate that the predictor avoids expensive reordering on matrices whose expected gains are insufficient to amortize the preprocessing cost.

The CSR sensitivity analysis further shows that RD features capture input-vector locality headroom, but this locality signal alone is not sufficient to predict SpMV speedup when backend-specific workload imbalance dominates, as illustrated by the RMAT-CSR case. In future work, we plan to develop a graph neural network-based headroom predictor that directly learns structural information from sparse matrices to further improve prediction accuracy.

Appendix B.1. SuiteSparse

Table A1. Sparse matrices. In the Relabel column, Y indicates that the matrix is selected for relabeling, whereas N indicates that it is not selected.

Id	Dataset	n	m	Relabel	Id	Dataset	n	m	Relabel	Id	Dataset	n	m	Relabel
1	italy_osm	6,686,493	14,027,956	N	31	cage14	1,505,785	27,130,349	N	61	ljournal-2008	5,363,260	79,023,142	N
2	Freescale2	2,999,349	14,313,235	N	32	adaptive	6,815,744	27,248,640	N	62	Long_Coup_dt0	1,470,152	8,442,2970	N
3	circuit5M_dc	3,523,317	14,865,409	N	33	nlpkkt80	1,062,400	28,192,672	N	63	Long_Coup_dt6	1,470,152	84,422,970	N
4	web-hudong	1,984,484	14,869,484	Y	34	wiki-topcats	1,791,489	2,851,1807	Y	64	channel	4,802,000	85,362,744	N
5	patents	3,774,768	14,970,767	Y	35	rgg_n_2_21_s0	2,097,152	28,975,990	N	65	kron_g500-logn20	1,048,576	89,239,674	Y
6	soc-flixster	2,523,386	15,837,602	Y	36	soc-Pokec	1,632,803	30,622,564	Y	66	dielFilterV3real	1,102,824	89,306,020	N
7	venturiLevel3	4,026,819	16,108,474	N	37	soc-flickr-und	1,715,255	31,110,084	Y	67	nlpkkt120	3,542,400	95,117,792	N
8	great-britain_osm	7,733,822	16,313,034	N	38	road_central	14,081,816	33,866,826	Y	68	cage15	5,154,859	99,199,551	N
9	cit-Patents	3,774,768	16,518,948	Y	39	packing	2,145,852	34,976,486	N	69	delaunay_n24	16,777,216	100,663,202	N
10	in-2004	1,382,908	16,917,053	N	40	hugetrace-00010	12,057,441	36,164,358	Y	70	europe_osm	50,912,018	108,109,320	Y
11	Freescale1	3,428,755	17,052,626	N	41	wikipedia-20060925	2,983,494	37,269,096	Y	71	ML_Geer	1,504,002	110,686,677	N
12	hugetric-00000	5,824,554	17,467,046	N	42	wikipedia-20061104	3,148,440	39,383,235	Y	72	hollywood-2009	1,139,905	113,891,327	N
13	web-baidu-baike	2,141,300	17,794,840	Y	43	socfb-B-anon	2,937,612	41,919,708	Y	73	Flan_1565	1,564,794	114,165,372	N
14	soc-linkedin	6,726,289	19,360,690	Y	44	wikipedia-20070206	3,566,907	45,030,389	Y	74	kmer_V2a	55,042,369	117,217,600	Y
15	wikipedia-20051105	1,634,989	19,753,078	Y	45	socfb-A-anon	3,097,165	47,334,788	Y	75	Cube_Coup_dt0	2,164,760	124,406,070	N
16	hugetric-00010	6,592,765	19,771,708	Y	46	hugetrace-00020	16,002,413	4,799,7626	Y	76	Cube_Coup_dt6	2,164,760	124,406,070	N
17	rajat31	4,690,002	20,316,253	N	47	dielFilterV2real	1,157,456	48,538,952	N	77	rgg_n_2_23_s0	8,388,608	127,002,786	N
18	M6	3,501,776	21,003,872	Y	48	delaunay_n23	8,388,608	50,331,568	N	78	Bump_2911	2,911,419	127,729,899	N
19	StocF-1465	1,465,137	21,005,389	N	49	af_shell10	1,508,065	52,259,885	N	79	kron_g500-logn21	2,097,152	182,082,942	Y
20	hugetric-00020	7,122,792	21,361,554	Y	50	hugebubbles-00000	18,318,143	54,940,162	Y	80	socfb-uci-uni	58,790,782	184,416,390	Y
21	as-Skitter	1,696,415	22,190,596	N	51	wb-edu	9,845,725	57,156,537	N	81	socfb-konect	59,216,214	185,044,034	Y
22	333SP	3,712,815	22,217,266	Y	52	road_usa	23,947,347	57,708,624	N	82	indochina-2004	7,414,866	194,109,311	N
23	AS365	3,799,275	22,736,152	Y	53	hugebubbles-00010	19,458,087	58,359,528	Y	83	nlpkkt160	8,345,600	225,422,112	N
24	Transport	1,602,111	23,487,281	N	54	Hook_1498	1,498,023	59,374,451	N	84	com-Orkut	3,072,441	234,370,166	Y
25	germany_osm	11,548,845	24,738,362	N	55	circuit5M	5,558,326	59,524,291	N	85	rgg_n_2_24_s0	16,777,216	265,114,400	N
26	NLR	4,163,763	24,975,952	Y	56	Geo_1438	1,437,960	60,236,322	N	86	HV15R	2,017,169	283,073,458	N
27	delaunay_n22	4,194,304	25,165,738	N	57	rgg_n_2_22_s0	4,194,304	60,718,396	N	87	uk-2002	18,520,486	298,113,762	N
28	asia_osm	11,950,757	25,423,206	N	58	hugebubbles-00020	21,198,119	63,580,358	Y	88	soc-sinaweibo	58,655,849	522,642,142	Y
29	CurlCurl_4	2,380,515	26,515,867	N	59	Serena	1,391,349	64,131,971	N	89	soc-twitter-2010	21,297,772	530,051,618	Y
30	FullChip	2,987,012	26,621,983	N	60	soc-LiveJournal1	4,847,571	68,993,773	Y	90	arabic-2005	22,744,080	639,999,458	N

Table A1. Sparse matrices. In the Relabel column, Y indicates that the matrix is selected for relabeling, whereas N indicates that it is not selected.

Id	Dataset	n	m	Relabel	Id	Dataset	n	m	Relabel	Id	Dataset	n	m	Relabel
1	italy_osm	6,686,493	14,027,956	N	31	cage14	1,505,785	27,130,349	N	61	ljournal-2008	5,363,260	79,023,142	N
2	Freescale2	2,999,349	14,313,235	N	32	adaptive	6,815,744	27,248,640	N	62	Long_Coup_dt0	1,470,152	8,442,2970	N
3	circuit5M_dc	3,523,317	14,865,409	N	33	nlpkkt80	1,062,400	28,192,672	N	63	Long_Coup_dt6	1,470,152	84,422,970	N
4	web-hudong	1,984,484	14,869,484	Y	34	wiki-topcats	1,791,489	2,851,1807	Y	64	channel	4,802,000	85,362,744	N
5	patents	3,774,768	14,970,767	Y	35	rgg_n_2_21_s0	2,097,152	28,975,990	N	65	kron_g500-logn20	1,048,576	89,239,674	Y
6	soc-flixster	2,523,386	15,837,602	Y	36	soc-Pokec	1,632,803	30,622,564	Y	66	dielFilterV3real	1,102,824	89,306,020	N
7	venturiLevel3	4,026,819	16,108,474	N	37	soc-flickr-und	1,715,255	31,110,084	Y	67	nlpkkt120	3,542,400	95,117,792	N
8	great-britain_osm	7,733,822	16,313,034	N	38	road_central	14,081,816	33,866,826	Y	68	cage15	5,154,859	99,199,551	N
9	cit-Patents	3,774,768	16,518,948	Y	39	packing	2,145,852	34,976,486	N	69	delaunay_n24	16,777,216	100,663,202	N
10	in-2004	1,382,908	16,917,053	N	40	hugetrace-00010	12,057,441	36,164,358	Y	70	europe_osm	50,912,018	108,109,320	Y
11	Freescale1	3,428,755	17,052,626	N	41	wikipedia-20060925	2,983,494	37,269,096	Y	71	ML_Geer	1,504,002	110,686,677	N
12	hugetric-00000	5,824,554	17,467,046	N	42	wikipedia-20061104	3,148,440	39,383,235	Y	72	hollywood-2009	1,139,905	113,891,327	N
13	web-baidu-baike	2,141,300	17,794,840	Y	43	socfb-B-anon	2,937,612	41,919,708	Y	73	Flan_1565	1,564,794	114,165,372	N
14	soc-linkedin	6,726,289	19,360,690	Y	44	wikipedia-20070206	3,566,907	45,030,389	Y	74	kmer_V2a	55,042,369	117,217,600	Y
15	wikipedia-20051105	1,634,989	19,753,078	Y	45	socfb-A-anon	3,097,165	47,334,788	Y	75	Cube_Coup_dt0	2,164,760	124,406,070	N
16	hugetric-00010	6,592,765	19,771,708	Y	46	hugetrace-00020	16,002,413	4,799,7626	Y	76	Cube_Coup_dt6	2,164,760	124,406,070	N
17	rajat31	4,690,002	20,316,253	N	47	dielFilterV2real	1,157,456	48,538,952	N	77	rgg_n_2_23_s0	8,388,608	127,002,786	N
18	M6	3,501,776	21,003,872	Y	48	delaunay_n23	8,388,608	50,331,568	N	78	Bump_2911	2,911,419	127,729,899	N
19	StocF-1465	1,465,137	21,005,389	N	49	af_shell10	1,508,065	52,259,885	N	79	kron_g500-logn21	2,097,152	182,082,942	Y
20	hugetric-00020	7,122,792	21,361,554	Y	50	hugebubbles-00000	18,318,143	54,940,162	Y	80	socfb-uci-uni	58,790,782	184,416,390	Y
21	as-Skitter	1,696,415	22,190,596	N	51	wb-edu	9,845,725	57,156,537	N	81	socfb-konect	59,216,214	185,044,034	Y
22	333SP	3,712,815	22,217,266	Y	52	road_usa	23,947,347	57,708,624	N	82	indochina-2004	7,414,866	194,109,311	N
23	AS365	3,799,275	22,736,152	Y	53	hugebubbles-00010	19,458,087	58,359,528	Y	83	nlpkkt160	8,345,600	225,422,112	N
24	Transport	1,602,111	23,487,281	N	54	Hook_1498	1,498,023	59,374,451	N	84	com-Orkut	3,072,441	234,370,166	Y
25	germany_osm	11,548,845	24,738,362	N	55	circuit5M	5,558,326	59,524,291	N	85	rgg_n_2_24_s0	16,777,216	265,114,400	N
26	NLR	4,163,763	24,975,952	Y	56	Geo_1438	1,437,960	60,236,322	N	86	HV15R	2,017,169	283,073,458	N
27	delaunay_n22	4,194,304	25,165,738	N	57	rgg_n_2_22_s0	4,194,304	60,718,396	N	87	uk-2002	18,520,486	298,113,762	N
28	asia_osm	11,950,757	25,423,206	N	58	hugebubbles-00020	21,198,119	63,580,358	Y	88	soc-sinaweibo	58,655,849	522,642,142	Y
29	CurlCurl_4	2,380,515	26,515,867	N	59	Serena	1,391,349	64,131,971	N	89	soc-twitter-2010	21,297,772	530,051,618	Y
30	FullChip	2,987,012	26,621,983	N	60	soc-LiveJournal1	4,847,571	68,993,773	Y	90	arabic-2005	22,744,080	639,999,458	N

Appendix B.2. Local Swap

Algorithm A2 local_swap

Require:  S, n, $\rho$, l, u.  Ensure:  S.   1: for$i\in S$do   2:       p ← random(0,1);   3:       if p $<\rho$ then   4:            $l_1\leftarrow \mathtt{max}(0,i-u)$; $r_1\leftarrow \mathtt{min}(n-1,i-l)$;                                  ▹ Left zone.   5:            $l_2\leftarrow \mathtt{max}(0,i+l)$; $r_2\leftarrow \mathtt{min}(n-1,i+u)$;                                  ▹ Right zone.   6:            $j\leftarrow \mathtt{random}([l_1,r_1]\cup [l_2,r_2])$;   7:            $\mathtt{swap}(i,j)$;   8:       end if   9: end for

Table A2. Local Swap Parameters.

Id	$\mathit{\rho }$	l	u	Id	$\mathit{\rho }$	l	u	Id	$\mathit{\rho }$	l	u
para1	0.10	64	256	para4	0.30	4096	16,384	para7	0.50	262,144	1,048,576
para2	0.10	256	1024	para5	0.30	16384	65,536	para8	0.70	1,048,576	4,194,304
para3	0.20	1024	4096	para6	0.40	65,536	262,144	para9	0.90	0	10,000,000

Table A2. Local Swap Parameters.

Id	$\mathit{\rho }$	l	u	Id	$\mathit{\rho }$	l	u	Id	$\mathit{\rho }$	l	u
para1	0.10	64	256	para4	0.30	4096	16,384	para7	0.50	262,144	1,048,576
para2	0.10	256	1024	para5	0.30	16384	65,536	para8	0.70	1,048,576	4,194,304
para3	0.20	1024	4096	para6	0.40	65,536	262,144	para9	0.90	0	10,000,000

Appendix B.3. RMAT

Table A3. RMAT datasets used in the test set.

Id	n	m	a	b	c	d	Id	n	m	a	b	c	d	Id	n	m	a	b	c	d
1	16,777,216	67,101,731	0.43	0.26	0.26	0.05	26	16,777,216	129,887,242	0.59	0.18	0.18	0.05	51	16,777,216	108,634,307	0.75	0.09	0.09	0.05
2	16,777,216	134,188,884	0.43	0.26	0.26	0.05	27	16,777,216	192,987,496	0.59	0.18	0.18	0.05	52	16,777,216	35,332,197	0.77	0.09	0.09	0.05
3	16,777,216	201,261,426	0.43	0.26	0.26	0.05	28	16,777,216	64,737,893	0.61	0.17	0.17	0.05	53	16,777,216	63,341,599	0.77	0.09	0.09	0.05
4	16,777,216	67,096,343	0.45	0.25	0.25	0.05	29	16,777,216	127,143,072	0.61	0.17	0.17	0.05	54	16,777,216	88,695,911	0.77	0.09	0.09	0.05
5	16,777,216	134,167,910	0.45	0.25	0.25	0.05	30	16,777,216	188,121,274	0.61	0.17	0.17	0.05	55	16,777,216	29,626,389	0.79	0.08	0.08	0.05
6	16,777,216	201,214,455	0.45	0.25	0.25	0.05	31	16,777,216	63,254,567	0.63	0.16	0.16	0.05	56	16,777,216	52,321,541	0.79	0.08	0.08	0.05
7	16,777,216	67,085,776	0.47	0.24	0.24	0.05	32	16,777,216	123,289,084	0.63	0.16	0.16	0.05	57	16,777,216	72,732,046	0.79	0.08	0.08	0.05
8	16,777,216	134,126,329	0.47	0.24	0.24	0.05	33	16,777,216	181,506,527	0.63	0.16	0.16	0.05	58	16,777,216	24,000,709	0.81	0.07	0.07	0.05
9	16,777,216	201,121,603	0.47	0.24	0.24	0.05	34	16,777,216	61,178,869	0.65	0.15	0.15	0.05	59	16,777,216	41,669,827	0.81	0.07	0.07	0.05
10	16,777,216	67,063,778	0.49	0.23	0.23	0.05	35	16,777,216	118,170,607	0.65	0.15	0.15	0.05	60	16,777,216	57,516,172	0.81	0.07	0.07	0.05
11	16,777,216	134,040,423	0.49	0.23	0.23	0.05	36	16,777,216	172,957,284	0.65	0.15	0.15	0.05	61	16,777,216	18,685,659	0.83	0.06	0.06	0.05
12	16,777,216	200,932,753	0.49	0.23	0.23	0.05	37	16,777,216	58,438,033	0.67	0.14	0.14	0.05	62	16,777,216	31,758,474	0.83	0.06	0.06	0.05
13	16,777,216	67,016,812	0.51	0.22	0.22	0.05	38	16,777,216	111,714,838	0.67	0.14	0.14	0.05	63	16,777,216	43,458,187	0.83	0.06	0.06	0.05
14	16,777,216	133,862,993	0.51	0.22	0.22	0.05	39	16,777,216	162,450,336	0.67	0.14	0.14	0.05	64	16,777,216	13,878,702	0.85	0.05	0.05	0.05
15	16,777,216	200,552,899	0.51	0.22	0.22	0.05	40	16,777,216	54,997,994	0.69	0.13	0.13	0.05	65	16,777,216	13,878,702	0.85	0.05	0.05	0.05
16	16,777,216	66,918,913	0.53	0.21	0.21	0.05	41	16,777,216	103,937,241	0.69	0.13	0.13	0.05	66	16,777,216	31,049,026	0.85	0.05	0.05	0.05
17	16,777,216	133,512,118	0.53	0.21	0.21	0.05	42	16,777,216	150,085,635	0.69	0.13	0.13	0.05	67	16,777,216	9,672,065	0.87	0.04	0.04	0.05
18	16,777,216	199,826,522	0.53	0.21	0.21	0.05	43	16,777,216	50,876,452	0.71	0.12	0.12	0.05	68	16,777,216	15,698,201	0.87	0.04	0.04	0.05
19	16,777,216	66,722,704	0.55	0.20	0.20	0.05	44	16,777,216	94,967,845	0.71	0.12	0.12	0.05	69	16,777,216	20,797,415	0.87	0.04	0.04	0.05
20	16,777,216	132,856,528	0.55	0.20	0.20	0.05	45	16,777,216	136,111,428	0.71	0.12	0.12	0.05	70	16,777,216	6,095,567	0.89	0.03	0.03	0.05
21	16,777,216	198,523,227	0.55	0.20	0.20	0.05	46	16,777,216	47,410,829	0.73	0.10	0.10	0.05	71	16,777,216	9,819,374	0.89	0.03	0.03	0.05
22	16,777,216	66,359,551	0.57	0.19	0.19	0.05	47	16,777,216	87,753,284	0.73	0.10	0.10	0.05	72	16,777,216	12,845,083	0.89	0.03	0.03	0.05
23	16,777,216	131,716,711	0.57	0.19	0.19	0.05	48	16,777,216	125,268,859	0.73	0.10	0.10	0.05	73	16,777,216	3,268,641	0.91	0.02	0.02	0.05
24	16,777,216	196,348,239	0.57	0.19	0.19	0.05	49	16,777,216	42,028,945	0.75	0.09	0.09	0.05	74	16,777,216	5,209,791	0.91	0.02	0.02	0.05
25	16,777,216	65,733,611	0.59	0.18	0.18	0.05	50	16,777,216	76,686,805	0.75	0.09	0.09	0.05	75	16,777,216	6,790,484	0.91	0.02	0.02	0.05

Table A3. RMAT datasets used in the test set.

Id	n	m	a	b	c	d	Id	n	m	a	b	c	d	Id	n	m	a	b	c	d
1	16,777,216	67,101,731	0.43	0.26	0.26	0.05	26	16,777,216	129,887,242	0.59	0.18	0.18	0.05	51	16,777,216	108,634,307	0.75	0.09	0.09	0.05
2	16,777,216	134,188,884	0.43	0.26	0.26	0.05	27	16,777,216	192,987,496	0.59	0.18	0.18	0.05	52	16,777,216	35,332,197	0.77	0.09	0.09	0.05
3	16,777,216	201,261,426	0.43	0.26	0.26	0.05	28	16,777,216	64,737,893	0.61	0.17	0.17	0.05	53	16,777,216	63,341,599	0.77	0.09	0.09	0.05
4	16,777,216	67,096,343	0.45	0.25	0.25	0.05	29	16,777,216	127,143,072	0.61	0.17	0.17	0.05	54	16,777,216	88,695,911	0.77	0.09	0.09	0.05
5	16,777,216	134,167,910	0.45	0.25	0.25	0.05	30	16,777,216	188,121,274	0.61	0.17	0.17	0.05	55	16,777,216	29,626,389	0.79	0.08	0.08	0.05
6	16,777,216	201,214,455	0.45	0.25	0.25	0.05	31	16,777,216	63,254,567	0.63	0.16	0.16	0.05	56	16,777,216	52,321,541	0.79	0.08	0.08	0.05
7	16,777,216	67,085,776	0.47	0.24	0.24	0.05	32	16,777,216	123,289,084	0.63	0.16	0.16	0.05	57	16,777,216	72,732,046	0.79	0.08	0.08	0.05
8	16,777,216	134,126,329	0.47	0.24	0.24	0.05	33	16,777,216	181,506,527	0.63	0.16	0.16	0.05	58	16,777,216	24,000,709	0.81	0.07	0.07	0.05
9	16,777,216	201,121,603	0.47	0.24	0.24	0.05	34	16,777,216	61,178,869	0.65	0.15	0.15	0.05	59	16,777,216	41,669,827	0.81	0.07	0.07	0.05
10	16,777,216	67,063,778	0.49	0.23	0.23	0.05	35	16,777,216	118,170,607	0.65	0.15	0.15	0.05	60	16,777,216	57,516,172	0.81	0.07	0.07	0.05
11	16,777,216	134,040,423	0.49	0.23	0.23	0.05	36	16,777,216	172,957,284	0.65	0.15	0.15	0.05	61	16,777,216	18,685,659	0.83	0.06	0.06	0.05
12	16,777,216	200,932,753	0.49	0.23	0.23	0.05	37	16,777,216	58,438,033	0.67	0.14	0.14	0.05	62	16,777,216	31,758,474	0.83	0.06	0.06	0.05
13	16,777,216	67,016,812	0.51	0.22	0.22	0.05	38	16,777,216	111,714,838	0.67	0.14	0.14	0.05	63	16,777,216	43,458,187	0.83	0.06	0.06	0.05
14	16,777,216	133,862,993	0.51	0.22	0.22	0.05	39	16,777,216	162,450,336	0.67	0.14	0.14	0.05	64	16,777,216	13,878,702	0.85	0.05	0.05	0.05
15	16,777,216	200,552,899	0.51	0.22	0.22	0.05	40	16,777,216	54,997,994	0.69	0.13	0.13	0.05	65	16,777,216	13,878,702	0.85	0.05	0.05	0.05
16	16,777,216	66,918,913	0.53	0.21	0.21	0.05	41	16,777,216	103,937,241	0.69	0.13	0.13	0.05	66	16,777,216	31,049,026	0.85	0.05	0.05	0.05
17	16,777,216	133,512,118	0.53	0.21	0.21	0.05	42	16,777,216	150,085,635	0.69	0.13	0.13	0.05	67	16,777,216	9,672,065	0.87	0.04	0.04	0.05
18	16,777,216	199,826,522	0.53	0.21	0.21	0.05	43	16,777,216	50,876,452	0.71	0.12	0.12	0.05	68	16,777,216	15,698,201	0.87	0.04	0.04	0.05
19	16,777,216	66,722,704	0.55	0.20	0.20	0.05	44	16,777,216	94,967,845	0.71	0.12	0.12	0.05	69	16,777,216	20,797,415	0.87	0.04	0.04	0.05
20	16,777,216	132,856,528	0.55	0.20	0.20	0.05	45	16,777,216	136,111,428	0.71	0.12	0.12	0.05	70	16,777,216	6,095,567	0.89	0.03	0.03	0.05
21	16,777,216	198,523,227	0.55	0.20	0.20	0.05	46	16,777,216	47,410,829	0.73	0.10	0.10	0.05	71	16,777,216	9,819,374	0.89	0.03	0.03	0.05
22	16,777,216	66,359,551	0.57	0.19	0.19	0.05	47	16,777,216	87,753,284	0.73	0.10	0.10	0.05	72	16,777,216	12,845,083	0.89	0.03	0.03	0.05
23	16,777,216	131,716,711	0.57	0.19	0.19	0.05	48	16,777,216	125,268,859	0.73	0.10	0.10	0.05	73	16,777,216	3,268,641	0.91	0.02	0.02	0.05
24	16,777,216	196,348,239	0.57	0.19	0.19	0.05	49	16,777,216	42,028,945	0.75	0.09	0.09	0.05	74	16,777,216	5,209,791	0.91	0.02	0.02	0.05
25	16,777,216	65,733,611	0.59	0.18	0.18	0.05	50	16,777,216	76,686,805	0.75	0.09	0.09	0.05	75	16,777,216	6,790,484	0.91	0.02	0.02	0.05