PaperlayerView exact revision on arXiv

Source-linked AI summary

HyGCN: A GCN Accelerator with Hybrid Architecture

Mingyu Yan, Lei Deng, Xing Hu, Ling Liang, Yujing Feng, Xiaochun Ye, Zhimin Zhang, Dongrui Fan, Yuan Xie

arXiv:2001.02514v1cs.DC

TL;DR

GCNs combine irregular Aggregation with regular Combination, motivating architectures that handle both execution patterns efficiently. The paper characterizes these patterns and introduces HyGCN, a hybrid accelerator with specialized engines, phase fusion, and coordinated memory access. HyGCN reports substantial speedup and energy reductions against CPU and GPU software baselines, while the evaluated design targets inference rather than the full training pipeline.

  • Problem

    GCN execution combines irregular Aggregation and regular Combination, requiring hardware to address distinct phase behaviors, parallelism, data reuse, and phase fusion.

  • Method

    HyGCN uses a hybrid architecture with an edge- and MVM-centric programming model, specialized Aggregation and Combination Engines, inter-engine pipelining, and priority-based memory coordination.

  • Results

    1509× speedup with 2500× energy reduction over PyTorch Geometric on Intel Xeon CPU, and 6.5× speedup with 10× energy reduction on NVIDIA V100 GPU.

  • Takeaways & Limitations

    HyGCN demonstrates that separate treatment of GCN phases can support efficient execution by exploiting their distinct parallelism, regularity, and data-reuse characteristics.

  • Takeaways & Limitations

    The work focuses on inference; training additionally requires specialized support for backward and update passes and an efficient memory hierarchy connecting them.

Abstract

from arXiv · show

In this work, we first characterize the hybrid execution patterns of GCNs on Intel Xeon CPU. Guided by the characterization, we design a GCN accelerator, HyGCN, using a hybrid architecture to efficiently perform GCNs. Specifically, first, we build a new programming model to exploit the fine-grained parallelism for our hardware design. Second, we propose a hardware design with two efficient processing engines to alleviate the irregularity of Aggregation phase and leverage the regularity of Combination phase. Besides, these engines can exploit various parallelism and reuse highly reusable data efficiently. Third, we optimize the overall system via inter-engine pipeline for inter-phase fusion and priority-based off-chip memory access coordination to improve off-chip bandwidth utilization. Compared to the state-of-the-art software framework running on Intel Xeon CPU and NVIDIA V100 GPU, our work achieves on average 1509$\times$ speedup with 2500$\times$ energy reduction and average 6.5$\times$ speedup with 10$\times$ energy reduction, respectively.

1. INTRODUCTION

GCNs combine irregular, graph-structure-dependent Aggregation with regular Combination, creating conflicting accelerator requirements. HyGCN addresses these patterns with a hybrid architecture, specialized programming model and engines, fused execution, and reported CPU/GPU gains.

  • Motivation: GCNs have become an important workload family for graph tasks including node classification, link prediction, clustering, and recommendation.They are increasingly used in data centers such as Google, Facebook, and Alibaba.
  • Execution patterns: Aggregation is dynamic and irregular because vertices have varying numbers and locations of source neighbors, while Combination is regular.These phases occupy most convolutional-layer execution time and exhibit contrasting computational and memory-access patterns.
  • Design requirements: GCN accelerators must alleviate Aggregation irregularity, exploit Combination regularity, support intra-vertex parallelism and reusable data, and fuse both phases efficiently.These requirements arise from GCN-specific execution and data-reuse characteristics.
  • HyGCN: HyGCN uses a programming model and two specialized processing engines to exploit fine-grained parallelism while separately addressing Aggregation and Combination.The Aggregation Engine targets irregularity; the Combination Engine leverages regularity and shared data reuse.
  • Evaluation: 1509× speedup with 2500× energy reduction over PyTorch Geometric on Intel Xeon CPU, and 6.5× speedup with 10× energy reduction on NVIDIA V100 GPU.The evaluation compares HyGCN with the state-of-the-art software framework using the stated CPU and GPU baselines.

2. BACKGROUND

GCNs iteratively aggregate neighbor features and transform each vertex representation, with optional sampling, pooling, and readout operations. The background introduces representative GCN models and the notation underlying these computations.

  • GCN computation: GCNs compute each vertex feature by recursively aggregating neighbor representations and transforming the result across iterations.The resulting representation captures structural information within the vertex’s k-hop neighborhood.
  • Core operations: Aggregation combines multiple source-neighbor feature vectors into one vertex vector, while Combination transforms each vertex vector using an MLP with shared weights and biases.Combination is typically a single- or multi-layer MLP whose parameters are shared across vertices.
  • Sampling: Sampling selects a subset of neighbors before Aggregation to reduce computational complexity.Sampling may occur during preprocessing or through random runtime selection.
  • Pooling and readout: Pooling can follow Combination to transform the original graph into a smaller graph, while Readout aggregates final vertex representations for graph-level classification.DiffPool uses additional GCNs to produce a new feature matrix and adjacency matrix for hierarchical graph transformation.
  • Representative models: GCN, GraphSage, and GINConv provide representative model variants, with GraphSage using uniform neighbor sampling and GINConv matching Weisfeiler-Lehman discriminative power.These models support tasks such as node classification, link prediction, and graph classification.

3. MOTIVATION

GCN workloads exhibit complementary execution patterns: Aggregation is dynamic, irregular, and memory-bound, while Combination is static, regular, and computation-bound. These characteristics expose limitations in CPUs, GPUs, and phase-by-phase frameworks, motivating a hybrid accelerator.

  • Aggregation incurs irregular neighbor accesses, high cache misses, ineffective prefetching, and greater DRAM access than Combination.
  • Combination performs compute-intensive MVMs with shared MLP weights, but shared-data copying and synchronization consume up to 36% of execution time.
  • GCN execution contains hybrid patterns: Aggregation is dynamic and irregular, whereas Combination is static and regular.
  • CPUs struggle with unpredictable Aggregation accesses and parameter reuse, while GPUs inefficiently handle irregular memory accesses and costly Combination synchronization.

4. ARCHITECTURE DESIGN

HyGCN uses an edge- and MVM-centric programming model to expose fine-grained parallelism across GCN Aggregation and Combination. The model processes sampled neighbor edges before applying MVM-based transformations at each vertex.

  • The programming model represents Aggregation as edge-centric processing and Combination as a series of MVMs.
  • For each vertex, sampled neighbor indices identify edges whose source features are aggregated before the Combine function begins.
  • The model exposes edge-level and MVM-level parallelism for hardware execution.
  • Pool and Readout are omitted because Pool can be expressed through GCNs and matrix operations, while Readout can use an additional connected vertex.

4.2 Architecture Overview

HyGCN combines an Aggregation Engine, a Combination Engine, and a memory access handler connected by a Coordinator. The design uses specialized buffering, systolic computation, prefetching, and an inter-engine pipeline.

  • HyGCN contains Aggregation and Combination Engines plus a memory access handler, with a Coordinator bridging the engines.
  • The Coordinator mitigates inter-engine interference and establishes an execution pipeline between the phases.
  • The Aggregation Engine uses eSched for edge workloads, a Sampler for selected edges, and buffers for edges, input features, and intermediate results.
  • The Combination Engine uses modified systolic arrays, a Weight Buffer for shared weights, and an Output Buffer for coalesced writes.
  • A prefetcher follows current vertices’ edges, obtains neighbor indices, and immediately prefetches their feature vectors.

4.3 Aggregation Engine

The Aggregation Engine combines vertex-disperse SIMD execution with static graph partitioning and dynamic sparsity elimination. These techniques exploit parallelism and locality while reducing redundant feature accesses.

  • 4.3.1 Execution Mode: Vertex-disperse processing assigns each vertex’s feature-element aggregation across all SIMD cores, exploiting intra-vertex parallelism.
  • 4.3.1 Execution Mode: Free cores process other vertices, keeping cores busy and reducing workload imbalance and single-vertex latency.
  • 4.3.1 Execution Mode: The vertex-disperse mode enables each completed vertex to enter the Combination Engine immediately.
  • 4.3.2 Graph Partitioning (Static): Graph data are partitioned into disjoint vertex intervals and edge shards directly from compressed sparse column input.
  • 4.3.2 Graph Partitioning (Static): Interval-wise processing merges feature accesses and reuses loaded neighbor features across vertices sharing overlapping neighbors.
  • 4.3.3 Data-Aware Sparsity Elimination (Dynamic): Window sliding and shrinking identify effectual shards and retain only remaining neighbor vertices, eliminating redundant feature accesses.
  • 4.3.3 Data-Aware Sparsity Elimination (Dynamic): These optimizations are especially valuable for GCNs because vertex features contain thousands of elements and sampling increases sparsity.

4.4 Combination Engine

The Combination Engine uses multiple systolic modules with independent and cooperative working modes to match different aggregation-output patterns while reusing weights across vertices.

  • Multiple systolic arrays form modules that support multigranular Combination Engine operation.The design integrates multiple arrays rather than one to accommodate the two Aggregation Engine processing modes.
  • Independent Working Mode: In independent mode, modules process small vertex groups separately, lowering vertex latency through immediate combination after aggregation results arrive.This mode matches vertex-disperse aggregation, which produces aggregated features quickly but sequentially.
  • Cooperative Working Mode: In cooperative mode, modules assemble aggregated features from a large vertex group before processing them together.The mode enables weight parameters to flow across merged systolic modules.
  • Weights are inherently reused in the Weight Buffer across vertices, unlike traditional neural networks that generally require batching for weight sharing.The multigranular systolic-array design is specific to HyGCN’s application needs.

4.5 Inter-Engine Optimization

HyGCN fuses Aggregation and Combination through a buffered inter-engine pipeline and coordinates shared off-chip memory accesses to balance latency, energy, and bandwidth utilization.

  • Inter-Engine Pipeline: A ping-pong Aggregation Buffer decouples the two engines by storing partial and final aggregation results for inter-engine reuse.The buffer can be written by the Aggregation Engine and read by the Combination Engine, enabling inter-engine pipelining.
  • Latency- or Energy-Aware Pipeline: The latency-aware pipeline processes small vertex groups immediately, reducing average per-vertex latency.It uses independent systolic-module operation and vertex-by-vertex aggregation output.
  • Latency- or Energy-Aware Pipeline: The energy-aware pipeline processes large vertex bursts together, reducing energy through weight propagation but increasing vertex latency.It uses cooperative systolic-module operation to avoid redundant weight accesses.
  • Coordination of Off-chip Memory Access: A single shared off-chip memory avoids difficult bandwidth-ratio configuration and bandwidth waste between engines.Workloads vary in their relative Aggregation and Combination demands, making fixed memory separation impractical.
  • Coordination of Off-chip Memory Access: Priority-based batching orders discontinuous requests as edges > input features > weights > output features to improve access continuity.Requests are executed batch-by-batch rather than always serving the highest-priority class first.

5. EVALUATION RESULTS

HyGCN is evaluated with cycle-accurate simulation, synthesized RTL components, memory estimates, four GCN models, and six graph datasets. It substantially improves speed, energy, bandwidth use, and off-chip-data movement over software baselines, while its optimizations provide measurable component-level gains.

  • Methodology: The evaluation combines cycle-accurate microarchitectural simulation, HBM modeling, RTL synthesis, and memory-energy estimation.The architecture simulator models module behavior and HBM accesses, while CAD tools estimate area, power, and timing.
  • Overall Results: Average speedup reaches 1509× versus PyG-CPU and 6.5× versus PyG-GPU.The optimized PyG-CPU and naive PyG-GPU are the evaluation baselines.
  • Overall Results: HyGCN consumes only 0.04% and 10% of the average energy of PyG-CPU and PyG-GPU, respectively.Reported platform energy includes off-chip memory energy.
  • Overall Results: HyGCN improves average DRAM bandwidth utilization by 16× versus PyG-CPU and 1.5× versus PyG-GPU.Its lower bandwidth on the CL dataset is attributed to greater data reuse from denser connections.
  • Overall Results: HyGCN accesses only 21% and 33% of the off-chip data accessed by PyG-CPU and PyG-GPU, respectively.The reduction is attributed to data reuse, sparsity elimination, and immediate inter-engine processing.
  • Optimization Analysis: Sparsity elimination provides 1.1–3× speedup in Aggregation Engine experiments.The gain comes from eliminating redundant DRAM accesses associated with sparsity.
  • Inter-Engine Pipeline Optimization: Inter-engine pipelining reduces GCN execution time by 27%–53% and total DRAM accesses to 50%–73%.The engines overlap execution while avoiding intermediate aggregation-result transfers.
  • Pipeline Modes: The latency-aware pipeline reduces vertex latency by 7%–29%, whereas the energy-aware pipeline saves 35% energy.The two modes trade immediate small-group processing against large-group weight reuse.

6. DISCUSSION

The discussion identifies scope and integration challenges for applying the proposed programming model and architecture beyond inference-oriented evaluation. Training introduces more complex dependencies and propagation patterns, while software integration requires substantial framework changes and still misses hardware-optimized operations.

  • Programming-model integration: PyG requires significant modification to stream Aggregation and Combination for each vertex under the proposed programming model.Its coarse-grain message-passing mechanism does not directly support the required streaming execution.
  • Programming-model integration: The modified PyG execution still misses hardware-optimized operations such as matrix multiplication.
  • Training scope: Training is unsuitable as the starting point because it requires forward, backward, and update passes with data dependencies.Inference has only the forward pass, making its compute and memory patterns less complex than training.
  • Training scope: Graph training also requires specialized support for complex gradient propagation, additional blocks, and an efficient connecting memory hierarchy.The proposed architecture can support the forward pass, but other passes require further design.

7. RELATED WORK

Related work spans software frameworks, scalability exploration, and specialized hardware, but GCNs combine graph-processing and neural-network execution patterns. This hybrid behavior creates requirements that single-pattern frameworks and specialized architectures do not directly address.

  • Software frameworks: Software frameworks for graph analytics and neural networks generally work well only for single-pattern workloads.Hybrid-pattern GCNs therefore motivate dedicated software frameworks, including PyTorch Geometric's message-passing approach.
  • Scalability exploration: Figure 18 explores scalability through sampling-factor sparsity elimination, Aggregation Buffer capacity, and systolic-module size.The figure reports execution time, DRAM access, sparsity reduction, vertex latency, and Combination Engine energy across these explorations.
  • Hardware architectures: Existing specialized architectures target graph analytics or neural networks, whereas GCNs require support for both Aggregation and Combination behavior.This hybrid workload creates an intrinsic hybrid design requirement.

8. CONCLUSION

The conclusion presents HyGCN as a hybrid accelerator for GCNs whose distinct Aggregation and Combination patterns require separate but coordinated optimizations. It combines phase-specific engines with programming, pipeline, and memory-access techniques to improve performance and energy efficiency.

  • Execution patterns: GCNs exhibit distinct, nearly opposite execution patterns in Aggregation and Combination, requiring separate design requirements.
  • Architecture: HyGCN uses an edge- and MVM-centric programming model to expose parallelism while preserving hardware transparency.
  • Architecture: Two specialized engines optimize Aggregation and Combination correspondingly, exploiting high intra-vertex parallelism and reusable inter-vertex data.
  • System optimization: Latency- and energy-aware inter-engine pipelines and coordinated off-chip accesses improve system efficiency according to system needs.
Loading 2001.02514v1…