PaperlayerView exact revision on arXiv

Source-linked AI summary

GNNAdvisor: An Adaptive and Efficient Runtime System for GNN Acceleration on GPUs

Yuke Wang, Boyuan Feng, Gushu Li, Shuangchen Li, Lei Deng, Yuan Xie, Yufei Ding

arXiv:2006.06608v3cs.DC

TL;DR

Existing one-size-fits-all GNN implementations do not adequately handle evolving architectures, graph sizes, and embedding dimensionalities. GNNAdvisor uses runtime model and graph properties to adapt GPU workload, memory, and parameter choices, and reports broad speedups over established frameworks.

  • Problem

    Existing one-size-fits-all GNN frameworks do not adapt effectively to diverse architectures, graphs, and embedding dimensions.

  • Method

    GNNAdvisor uses model and graph input properties to drive parameterized 2D workload management, memory customization, and automatic parameter selection.

  • Results

    3.02× average speedup over Deep Graph Library and 4.36× average speedup over NeuGraph are reported across mainstream GNN architectures and varied datasets.

  • Takeaways & Limitations

    GNNAdvisor provides a systematic GPU tool for accelerating GNNs across a wide range of datasets and mainstream models.

  • Takeaways & Limitations

    The evaluation and design primarily target single-GPU GNN computing.

Abstract

from arXiv · show

As the emerging trend of graph-based deep learning, Graph Neural Networks (GNNs) excel for their capability to generate high-quality node feature vectors (embeddings). However, the existing one-size-fits-all GNN implementations are insufficient to catch up with the evolving GNN architectures, the ever-increasing graph sizes, and the diverse node embedding dimensionalities. To this end, we propose \textbf{GNNAdvisor}, an adaptive and efficient runtime system to accelerate various GNN workloads on GPU platforms. First, GNNAdvisor explores and identifies several performance-relevant features from both the GNN model and the input graph, and uses them as a new driving force for GNN acceleration. Second, GNNAdvisor implements a novel and highly-efficient 2D workload management, tailored for GNN computation to improve GPU utilization and performance under different application settings. Third, GNNAdvisor capitalizes on the GPU memory hierarchy for acceleration by gracefully coordinating the execution of GNNs according to the characteristics of the GPU memory structure and GNN workloads. Furthermore, to enable automatic runtime optimization, GNNAdvisor incorporates a lightweight analytical model for an effective design parameter search. Extensive experiments show that GNNAdvisor outperforms the state-of-the-art GNN computing frameworks, such as Deep Graph Library ($3.02\times$ faster on average) and NeuGraph (up to $4.10\times$ faster), on mainstream GNN architectures across various datasets.

1 Introduction

GNNAdvisor addresses the mismatch between diverse GNN workloads and one-size-fits-all GPU implementations by using runtime input information to guide adaptive optimization. It combines GNN-specific workload and memory techniques with automatic parameter selection, outperforming established frameworks in reported experiments.

  • Motivation: Existing GNN frameworks often perform poorly on complicated architectures and diverse graphs because their one-size-fits-all implementations do not exploit runtime input information.Relevant information includes model architecture, node degree, and embedding size; ignoring it can underutilize GPU resources and cause inefficient irregular memory access.
  • Scope: GNNAdvisor focuses primarily on single-GPU GNN computing, while larger graphs may require out-of-GPU-core or multi-GPU processing.The paper notes that graph partitioning can make large graphs suitable for single-GPU processing, but this remains the stated focus boundary.
  • Approach: GNNAdvisor explores GNN model and input-graph properties to guide GPU system optimizations.The paper identifies input properties as a basis for adapting optimization choices to application settings.
  • Approach: GNNAdvisor provides parameterized 2D workload management, specialized GPU memory customization, analytical modeling, and automatic parameter selection.The optimizations target GNN-specific computation and support design-space exploration.
  • Evaluation: 3.02× average speedup over Deep Graph Library and 4.36× average speedup over NeuGraph are reported across mainstream GNN architectures and diverse datasets.These are the comparative averages stated in the contribution summary.

2 Background and Related Work

GNNs alternate neighbor aggregation with neural-network updates to generate node embeddings, but traditional graph systems and deep-learning frameworks lack important GNN-specific capabilities. Their limitations include insufficient support for embedding-dimensional parallelism, irregular aggregation, flexible kernels, and GNN training functionality.

  • GNN Computation: Each GNN iteration aggregates information from neighboring nodes and then applies a neural-network update to produce the next-layer node embedding.Aggregation may use node or edge properties, and embedding dimensions can vary across layers.
  • Graph Systems: Traditional graph-processing optimizations do not directly transfer to GNNs because GNNs maintain fixed neighbor frontiers and operate on high-dimensional embeddings.Embedding dimensions introduce an additional axis of data parallelism beyond node and edge processing.
  • Graph Systems: Graph systems lack essential GNN functionality, including neural-network node updates and automatic differentiation for forward and backward propagation.Supporting GNN computation therefore requires more than extending graph-processing operators.
  • Deep-Learning Frameworks: Deep-learning extensions such as PyG and DGL provide programmability but can scale poorly on large sparse graphs with high-dimensional embeddings.The cited issue is linked to excessive atomic operations or off-the-shelf sparse-matrix multiplication designs.
  • Deep-Learning Frameworks: Hard-coded kernels prevent users from customizing internal execution for differing graph sizes, embedding dimensions, model architectures, and GPU characteristics.Users can compose kernels externally but cannot adapt their internals to known workload properties.

3 Input Analysis of GNN Applications

GNNAdvisor treats GNN model and graph properties as runtime inputs for selecting optimization strategies. In particular, aggregation type, node degree, embedding dimensionality, graph communities, and the two-dimensional workload shape determine useful memory and parallelization choices.

  • GNN Model Information: Different GNN aggregation types favor different optimizations because GCNs can reduce embedding dimensions before aggregation, whereas GINs aggregate full-dimensional embeddings with edge features.The paper contrasts locality-oriented optimization for reduced-dimensional GCN aggregation with parallelization-oriented optimization for full-dimensional GIN aggregation.
  • GNN Model Information: GNNAdvisor can parse the aggregation type to guide system-level optimization.The paper identifies aggregation type as model information available to the runtime.
  • Graph Information: Node degree and embedding dimensionality reveal the workload composition, indicating whether parallelism should emphasize neighbors or embedding dimensions.Large degrees favor concurrent neighbor processing, while high-dimensional embeddings favor parallelism along the embedding dimension.
  • Graph Information: Graph communities can improve locality when node-level locality is mapped onto GPU thread, warp, and block organization.The approach seeks to exploit locality among threads through GPU L1-cache behavior.

4 2D Workload Management

GNNAdvisor manages GNN work along neighbor and embedding dimensions, then maps balanced work to warps to improve utilization, synchronization, and memory access.

  • Overview: GNNAdvisor uses 2D workload management spanning neighbor count and embedding dimension, with neighbor partitioning, dimension partitioning, and warp-based alignment.These techniques target GNNs’ two workload dimensions: the number of neighbors and embedding size.
  • 4.1 Coarse-grained Neighbor Partitioning: Coarse-grained neighbor partitioning divides each node’s neighbors into equal-sized groups and schedules each group as a workload unit.This reduces workload-size irregularity compared with node-centric partitioning and targets redundant atomic operations.
  • 4.2 Fine-grained Dimension Partitioning: Fine-grained dimension partitioning distributes each neighbor-group workload across consecutive threads, with each thread accumulating along one embedding dimension.Additional iterations handle embedding dimensions larger than the available workers.
  • 4.3 Warp-based Thread Alignment: Warp-aligned mapping assigns each warp to one neighbor group, parallelizing groups without the warp divergence caused by mixed group assignments.Threads within a warp process different dimensions of the same group, reducing synchronization conflicts.
  • 4.3 Warp-based Thread Alignment: Warp-based mapping also balances smaller workloads, increases scheduling flexibility and occupancy, and coalesces accesses to consecutive embedding addresses.These benefits address both execution divergence and irregular global-memory behavior.

5 Specialized Memory Optimization

GNNAdvisor exploits graph communities and warp organization to improve locality and reduce aggregation overhead, while using AES to decide when graph reordering is worthwhile.

  • Overview: GNNAdvisor combines community-aware node renumbering with warp-aware memory customization as specialized optimizations for its 2D workload management.The two techniques target locality and the memory costs of aggregation.
  • 5.1 Community-aware Node Renumbering: Community-aware renumbering reorders node IDs so computationally adjacent groups can obtain improved temporal and spatial locality during aggregation.The mapping relies on consecutive warps processing neighbor groups according to node IDs.
  • 5.1 Community-aware Node Renumbering: Graphs with irregular edge-connection patterns can gain up to 2× speedup from reordering, whereas already block-diagonal graphs offer little additional locality benefit.AES is introduced to determine whether reordering is beneficial.
  • 5.1 Community-aware Node Renumbering: Rabbit Reordering hierarchically captures communities, matching smaller sub-communities to L1 locality and larger communities to L2 locality.It is described as fully parallelized and low-cost, with node order generated within clusters by DFS traversal.
  • 5.2 Warp-aware Memory Customization: Warp-centric shared memory customization reduces aggregation from O(k · ngs · Dim) atomic operations and global accesses to O(Dim) of each.The design reserves shared memory per neighbor-group warp and uses leader warps to flush intermediate results globally.

6 Design Optimization

GNNAdvisor automatically tunes GPU kernel parameters with a lightweight analytical model based on workload, shared memory, hardware limits, and input embedding dimensions.

  • Overview: GNNAdvisor’s kernel configurations expose parameters that can be tuned across GNN models and graph datasets, motivating automatic selection.The Decider combines analytical modeling with parameter search.
  • Warp-aware Memory Customization: The implementation organizes neighbor groups into warps and thread blocks, tracking leaders and shared-memory addresses during warp-aware execution.The pseudocode computes warps per block and assigns leader status as groups are processed.
  • Analytical Modeling: The analytical model uses workload per thread (WPT) and shared memory usage per block (SMEM) as its two variables.These variables summarize execution work and resource consumption.
  • Parameter Auto Selection: The Decider first selects dimension-worker size dw from warp size and embedding dimension, using a profiled rule.The selection accounts for the hardware constraint tpw and the input property Dim.
  • Parameter Auto Selection: It then selects neighbor-group size ngs using the chosen dw and user-specified threads per block, targeting WPT ≈1024 while respecting shared-memory capacity.Modern GPUs provide approximately 48KB to 96KB of shared memory per block.

7 Evaluation

GNNAdvisor is evaluated across representative GCN and GIN workloads, dataset types, training and inference, kernel metrics, and comparisons with several GPU GNN frameworks. It consistently improves performance, while benefits vary with model structure, graph characteristics, and optimization settings.

  • Experiment setup: GNNAdvisor evaluates GCN and GIN, covering different aggregation types with 2-layer 16-dimensional GCN and 5-layer 64-dimensional GIN configurations.These models are evaluated on node-classification workloads across three dataset types.
  • Compared with DGL: 4.03× and 2.02× average inference speedups over DGL are achieved for GCN and GIN, respectively, across three dataset types.The comparison covers GNN inference on all three dataset categories.
  • Compared with DGL: 6.45× versus 1.17× average speedup is observed for GCN and GIN on Type I graphs, respectively, because GCN reduces node dimensions before aggregation.This ordering reduces aggregation data movement and synchronization overhead, benefiting GNNAdvisor’s workload and memory optimizations.
  • Compared with DGL: 2.10× and 1.70× average speedups are achieved for GCN and GIN on large Type III graphs, respectively.The reported gains are attributed to reduced synchronization and global-memory overhead, plus community-aware node renumbering; artist benefits less for GIN because community sizes vary substantially.
  • Kernel metrics: 24.47% and 12.02% higher SM efficiency, plus 75.55% and 126.20% better cache hit rate, are reported versus DGL for GCN and GIN, respectively.The metrics associate workload management with SM efficiency and specialized memory optimization with cache behavior.
  • Training support: 1.61× and 2.00× average training speedups over DGL are achieved for GCN and GIN, respectively, across all three dataset types.Training benefits from the same forward-oriented improvements, while also incurring activation-storage and data-movement overheads for backpropagation.
  • Compared with other frameworks: 1.78× and 2.13× average speedups over PyG are achieved for GCN and GIN, respectively, while NeuGraph comparisons report 1.3×–7.2× speedups in computation and memory performance.Against PyG, the gains are linked to workload sharing, dimension-aware processing, and improved thread management; NeuGraph uses fixed optimizations that largely ignore input information.
  • Compared with other frameworks: 2.89×–8.41× speedups over Gunrock are achieved on the SpMM neighbor-aggregation kernel for Type III graphs.The comparison highlights GNNAdvisor’s handling of high-dimensional node embeddings and input-dependent optimization relative to Gunrock’s generic graph-oriented optimizations.

8 Conclusion

GNNAdvisor is presented as an adaptive GPU runtime that uses GNN input information and tailored optimizations to improve performance across diverse workloads.

  • GNNAdvisor uses GNN input-level information to guide system-level optimizations.
  • Its design combines 2D workload management and specialized memory optimizations in parameterized, adaptable implementations.
  • Experiments across diverse datasets and mainstream GNN models demonstrate the effectiveness of the design.

Abstract Summary

GNNAdvisor combines host-side runtime configuration with GPU-side execution for sparse aggregation and dense node updates. Its configurable workload management and specialized memory design target performance and adaptability across input settings.

  • GNNAdvisor has host-side and device-side components that jointly manage runtime configuration and GNN computation.The host loads datasets, generates configurations, and invokes GPU execution; the device performs the major GNN computations.
  • The GPU program handles sparse neighbor aggregation and dense node-update phases.
  • Highly configurable 2D workload management and specialized memory design improve GNN computing performance.
  • Runtime configuration generation makes GNNAdvisor more adaptive to varied input settings.

Artifact Checklist

The artifact requires a Linux-compatible development environment, an Intel x86_64 host with substantial memory, and an NVIDIA GPU with at least 16GB of device memory.

  • The host platform requires an Intel x86_64 CPU and at least 32GB of host memory.
  • The tested host uses an Intel Xeon Silver 4110 with 8 cores, 16 threads, and 64GB of host memory.
  • The GPU requirement is NVIDIA architecture sm_60 or newer with at least 16GB of device memory.
  • Evaluation used NVIDIA Quadro P6000, Tesla V100, and RTX3090 GPUs, mainly reporting results from RTX3090.Execution time can differ across devices, while the overall speedup trend is reported as similar.
  • The software environment requires Ubuntu 16.04 or newer, GCC 7.5 or newer, CMAKE 3.14 or newer, and CUDA 10.2 or newer.

Environment Setup

The artifact setup proceeds from environment installation to binding installation, dataset download, and execution of baseline and GNNAdvisor experiments. The evaluation scripts cover GCN, GIN, PyG, Gunrock, and additional studies.

  • Environment setup: The basic environment can be installed through Docker or through conda and pip, with details in README.md.
  • Module installation: GNNAdvisor’s PyTorch and rabbit reordering modules are installed with separate setup.py commands in their respective directories.
  • Dataset preparation: Preprocessed graph datasets are downloaded as an archive, while node initial embeddings are generated at runtime from the requested dimension.
  • Experiment execution: The artifact provides scripts for running DGL, PyG, Gunrock, and GNNAdvisor experiments, including GCN and GIN training and a single SpMM kernel.
  • Experiment execution: Additional studies are associated with Figures 11(a,b,c) and 12(a), with complete commands documented in README.md.
  • Evaluation scope: Training evaluation omits accuracy, data loading, and some preprocessing, reporting only per-epoch GNN forward and backward computation time.The comparison focuses on the latest DGL version available for the artifact.
Loading 2006.06608v3…