Bulk-Synchronous GPU Programming Model Compiler

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current GPU programming languages, such as those based on the stream processing model, are difficult to read, maintain, and reuse due to their data-centric approach, which leads to complex dataflow management and abstraction of parallel primitives, making general-purpose GPU programming challenging.

Innovation Solution

The Bulk-Synchronous GPU Programming (BSGP) model abstracts from low-level program structures using supersteps with barrier synchronization, allowing for easier code reuse and management through a compiler that converts BSGP programs into kernels and manages temporary streams efficiently.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Power

If stream processing model is used for GPU programming, then processing power is provided, but programming difficulty increases due to dataflow management complexity

Engineering Contradiction:

Improveprocessing powerVSAvoidprogramming difficulty

Core Design Contradiction:

PowerVSEase of operation

Solution Approach 1:

The program is divided into sequential supersteps with explicit barrier synchronizations, where each superstep processes a specific computational phase. This segmentation allows programmers to reason about each superstep independently while maintaining parallel execution within supersteps, reducing the cognitive load of managing complex dataflows across the entire program.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent introduces an intermediary layer (the barrier synchronization mechanism) between computational stages that automatically manages dataflow transitions. This intermediary abstracts the complexity of intermediate stream management from the programmer, as barriers automatically handle data transfer and synchronization between supersteps without requiring explicit stream management code.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Productivity

If kernels are partitioned according to data dependencies, then processing efficiency is maintained, but code readability and maintenance deteriorate

Engineering Contradiction:

Improveprocessing efficiencyVSAvoidcode readability

Core Design Contradiction:

ProductivityVSEase of operation

Solution Approach 1:

The patent makes the program structure dynamic by allowing computational logic to be organized functionally within supersteps while the compiler dynamically determines the optimal kernel partitioning based on data dependencies. This allows code to be written with functional organization for readability, while the system adapts to maintain processing efficiency through automatic kernel generation and optimization.

Inventive Principle:

Principle #15Dynamics

3Adaptability or versatility

If intermediate streams are used for dataflow management, then computation flexibility is achieved, but dataflow management becomes tedious and error prone

Engineering Contradiction:

Improvecomputation flexibilityVSAvoiddataflow management

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The barrier synchronization mechanism provides self-service by automatically managing intermediate data streams between supersteps. The system autonomously handles stream allocation, data transfer, and synchronization without requiring programmer intervention, thereby maintaining computation flexibility while eliminating the tedium and error-proneness of manual stream management.

Inventive Principle:

Principle #25Self-service

4Quantity of substance

If parallel primitives are bundled with callers to reduce intermediate stream size, then memory usage is optimized, but primitive integrity is broken making abstraction difficult

Engineering Contradiction:

Improveintermediate stream sizeVSAvoidprimitive abstraction

Core Design Contradiction:

Quantity of substanceVSDevice complexity

Solution Approach 1:

The patent resolves the conflict by operating in another dimension - the temporal dimension of supersteps. Primitives can be defined as self-contained supersteps with their own internal data streams, allowing them to be reused across different contexts without breaking integrity. The compiler optimizes memory usage by managing stream lifetimes across superstep boundaries while preserving primitive abstractions as reusable computational units.

Inventive Principle:

Principle #17Another dimension (Dimensionality change)

Data Source

PatentUS8866827B2Bulk-synchronous graphics processing unit programming

Publication Date: 2014.10.21 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

Described is a technology in a computing environment comprising a programming language for general purpose computation on a graphics processing unit (GPU), along with an associated compiler. A Bulk-Synchronous GPU Programming (BSGP) program is programmed to include barriers to describe parallel processing on GPUs. A BSGP compiler detects barriers corresponding to supersteps, converts BSGP programs to kernels based on the barriers, and combines them. During compilation, the compiler aligns barriers in the statements and bundles the corresponding supersteps together. A par construct is provided to allow the programmer to control aspects of bundling, e.g., by specifying a block independent statements. Thread manipulation emulation is provided to transparently emulate thread creation and destruction, with operations fork and kill. Also provided is remote variable access intrinsics for efficient communications between threads, and collective primitive operations.