Source linked

GPU Peeling Is the Cure for Billion-Node Bipartite Core Queries

A new index-free GPU algorithm eliminates the massive index structures that bottleneck (α,β)-core computation, enabling real-time on-the-fly queries at billion-edge scale.

gpu computinggraph algorithmsbipartite graphscore decompositionon the fly queriesscalable systems

State-of-the-art CPU methods for (α,β)-core decomposition on bipartite graphs build an index for every possible α and β combination — a combinatorial explosion that strangles graphs beyond a few million edges.

An (α,β)-core is a maximal subgraph where every upper-layer vertex has degree ≥ α and every lower-layer vertex has degree ≥ β. Useful for fraud detection, recommendation systems, and community mining. But the index-first approach (decompose all α,β pairs once, then answer queries against the precomputed structure) produces space costs that can exceed the graph itself by orders of magnitude. That doesn't fly at billion-edge scale.

Why CPU Indexes Break at Scale

Every (α,β) pair potentially defines a distinct core. Building a full index means materializing all of them. CPU-based solutions like the state-of-the-art algorithms cited in the paper spend enormous time and memory on this precomputation — and they still fail to support on-the-fly queries (e.g., “does this edge update belong to a target core?”) without expensive re-indexing. Real-time applications like fraud monitoring can't wait for that.

GCC and GCC+: Index-Free Peeling on GPU

The authors tackle this by dumping the index entirely. GCC is an index-free GPU peeling algorithm: it iteratively removes vertices that don't meet the degree thresholds, using a warp-centric processing model that keeps GPU warps busy peeling in parallel. No index construction, no precomputation. For queries, you just run the peeling on demand.

GCC+ adds a nested-property optimization: if you know the core for a given (α,β), you can skip peeling for (α+1,β) because the cores are nested. A core-based early pruning strategy further cuts work. The result is a scalable peeling engine that fits within GPU memory limits — the main reason previous GPU graph systems avoided this class of problems.

GFQ: On-the-Fly Queries Without Full Graph Peeling

On-the-fly queries — “is this new edge part of the (α,β)-core?” — are the real killer for real-time systems. Existing methods either re-run the full decomposition or maintain an index that's expensive to update. GFQ instead uses connected component information to narrow the computation scope to only the relevant subgraph. Practically, this means you only peel the component that could possibly contain the updated edge, not the entire billion-node graph.

Experiments across 11 datasets (the paper doesn't name them in the abstract, but the benchmarks cover varied bipartite graphs) show that GCC, GCC+, and GFQ “outperform existing CPU-based solutions in terms of both space and time efficiency.” The index-free approach avoids the memory wall that kills CPU methods at scale, and warp-centric peeling keeps GPU utilization high.

What This Enables Next

For any system that needs real-time answers about edge updates in a bipartite graph — think fraud detection on a user-transaction graph or real-time content recommendations — this work makes (α,β)-core queries practical at the scale those systems operate. The next step is integrating GFQ into streaming graph processors so that live edge updates trigger only local peeling, not global recomputation.


Source: Efficient $(\alpha,\beta)$-core Computation and On-the-fly Query at Billion Scale with GPUs
Domain: arxiv.org

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.