PaperlayerView exact revision on arXiv

Source-linked AI summary

pocl: A Performance-Portable OpenCL Implementation

Pekka Jääskeläinen, Carlos Sánchez de La Lama, Erik Schnetter, Kalle Raiskila, Jarmo Takala, Heikki Berg

arXiv:1611.07083v1cs.DC

TL;DR

OpenCL provides platform portability, but performance portability remains difficult because programmers must adapt code to low-level, vendor-specific implementations. The paper introduces pocl, an LLVM-based OpenCL implementation that separates parallel-region formation from target-specific mapping, and reports that most benchmarked applications matched or exceeded the best proprietary implementation on each platform.

  • Problem

    OpenCL’s low-level standard and vendor-specific implementations require manual, platform-by-platform optimization to achieve performance portability.

  • Method

    pocl uses LLVM IR and metadata to separate target-independent parallel-region formation from target-specific mapping across different parallel hardware styles.

  • Results

    Most benchmarked applications compiled with pocl were faster than or close to the best proprietary OpenCL implementation for the platform.

  • Takeaways & Limitations

    pocl provides a modular OpenCL framework for porting applications across architectures and experimenting with parallel computing devices.

  • Takeaways & Limitations

    The authors state that current performance improvements to pocl’s kernel compiler are mostly language-generic LLVM improvements that could also benefit non-OpenCL programs.

Abstract

from arXiv · show

OpenCL is a standard for parallel programming of heterogeneous systems. The benefits of a common programming standard are clear; multiple vendors can provide support for application descriptions written according to the standard, thus reducing the program porting effort. While the standard brings the obvious benefits of platform portability, the performance portability aspects are largely left to the programmer. The situation is made worse due to multiple proprietary vendor implementations with different characteristics, and, thus, required optimization strategies. In this paper, we propose an OpenCL implementation that is both portable and performance portable. At its core is a kernel compiler that can be used to exploit the data parallelism of OpenCL programs on multiple platforms with different parallel hardware styles. The kernel compiler is modularized to perform target-independent parallel region formation separately from the target-specific parallel mapping of the regions to enable support for various styles of fine-grained parallel resources such as subword SIMD extensions, SIMD datapaths and static multi-issue. Unlike previous similar techniques that work on the source level, the parallel region formation retains the information of the data parallelism using the LLVM IR and its metadata infrastructure. This data can be exploited by the later generic compiler passes for efficient parallelization. The proposed open source implementation of OpenCL is also platform portable, enabling OpenCL on a wide range of architectures, both already commercialized and on those that are still under research. The paper describes how the portability of the implementation is achieved. Our results show that most of the benchmarked applications when compiled using pocl were faster or close to as fast as the best proprietary OpenCL implementation for the platform at hand.

1 Introduction

OpenCL reduces program porting effort, but its low-level, platform-specific performance tuning leaves programmers responsible for adapting and optimizing each application. The paper proposes pocl, whose LLVM-based compiler separates parallel-region formation from target-specific mapping across diverse hardware.

  • Motivation: OpenCL expresses multiple levels of parallelism through work-items, work-groups, and work-spaces while reducing software porting effort.Work-items execute the same kernel, work-groups may synchronize internally, and separate work-groups have no data dependencies.
  • Motivation: OpenCL 1.2 exposes platform details, requiring programmers to adapt and manually optimize applications for each vendor implementation.Different implementations have distinct characteristics and optimization strategies, limiting performance portability.
  • Approach: pocl separates target-independent parallel-region formation from target-specific parallel mapping of multi-work-item work-groups.The resulting compiler passes support different granularities and styles of parallel hardware.
  • Evaluation: The paper evaluates pocl across processor architectures with different parallelism capabilities and compares performance across platforms.The evaluation is presented as part of the paper’s applicability and performance comparison study.
  • Approach: The compiler operates on LLVM IR and metadata, supporting kernel languages beyond OpenCL C through SPIR.The implementation integrates these transformations into a modular LLVM-based compiler.

2 Open Computing Language

OpenCL 1.2 combines host-side control, device execution, runtime commands, and kernel-level parallelism for heterogeneous systems. Its model exposes work-item, work-group, vector, and instruction-level parallelism while leaving execution mapping to the target device.

  • OpenCL framework: OpenCL 1.2 comprises platform querying, runtime control, and compilation of OpenCL C kernels for targeted devices.The framework includes a platform layer, runtime APIs, and an OpenCL compiler.
  • Kernel example: A dot-product kernel indexes global work-items and computes one vector dot product per output element.The example uses vector inputs and writes each result through the work-item’s global identifier.
  • Execution model: OpenCL programs use a host device for top-level control and one or more devices for computation, with kernels compiled for targeted platforms.The runtime launches kernels and transfers data using event synchronization.
  • Parallelism: Kernel execution exposes work-item, work-group, vector, and compiler- or hardware-exploitable instruction-level parallelism.Programmers can express vector computations within work-items and use independent work-items within work-groups.
  • Parallelism: Multiple work-items in a work-group are independent by default, while explicit synchronization limits their parallel execution.Multiple work-groups are also assumed independent of one another.

3 Portable OpenCL Implementation

pocl uses a modular host/device architecture to isolate device-specific behavior while reusing generic OpenCL functionality. Its device layers support CPUs, threads, simulated accelerators, and heterogeneous hardware, with Bufalloc providing tailored buffer management.

  • Architecture: pocl separates portable host-layer functionality from device-specific implementations through a generic host-device interface.The architecture isolates target-specific behavior and encourages code reuse.
  • Device layers: The basic device executes one work-group at a time without multithreading, while the pthread device executes multiple work-groups in parallel.The pthread layer uses the POSIX threads library and can support SMP systems across CPU architectures.
  • Device layers: The ttasim driver simulates customizable TTA-based accelerators using explicit messages and DMA buffer transfers.It uses an instruction-set simulator and manages device memory from the host side.
  • Device layers: The cellspu device layer targets a Synergistic Processing Element in the heterogeneous Cell architecture through libspe.It runs on a Linux-based operating system.
  • Memory management: Bufalloc manages large OpenCL buffers using pooled regions and chunk-based allocation to reduce fragmentation and support devices without operating systems.Its linked-list structure tracks free and allocated chunks and splits a suitable free chunk for each request.

4 Performance Portable Kernel Compiler

pocl exposes OpenCL work-item parallelism in LLVM IR so target-specific passes can map it across diverse hardware. Its compiler handles work-group execution, barriers, and target-dependent generation while retaining platform portability.

  • Compiler architecture: pocl’s kernel compiler exposes parallelism so work-group regions can be mapped to diverse device resources, including SIMD and VLIW-style hardware.The approach separates reusable parallel-region formation from target-specific mapping and scheduling.
  • Compilation chain: Clang converts OpenCL C into single-work-item LLVM IR, while SPIR can bypass the frontend before built-ins are linked and later compilation proceeds.The resulting IR may be converted into a work-group function for non-SPMD targets.
  • Target execution models: SPMD-capable targets can execute the single-work-item description directly, whereas MIMD and SIMD targets require compiler-generated multi-work-item semantics.Direct generation is skipped for suitable SPMD targets or local size one; otherwise work-group functions execute all work-items statically.
  • Work-group functions: Work-group functions use parallel work-item loops to expose independent regions while preserving synchronization at barriers.A simple loop around the entire kernel is insufficient because regions between barriers must be parallelized separately.
  • Compilation trade-offs: Known local sizes enable constant work-item-loop trip counts, but require generating a separate work-group function for each local size.The fixed trip counts can simplify later static vectorization.
  • Scope: At the paper’s writing, pocl did not support popular commercial GPU targets, although its SPMD/GPU path had been tested with research targets.This bounds the implementation’s demonstrated commercial GPU coverage.
  • Compilation trade-offs: The compiler retains target-dependent optimization choices, including whether uniform values should be merged or replicated to avoid SIMD-lane broadcasts.Choosing replication based on machine-specific communication costs remains future work.

5 Vectorized Mathematical Library Functions

Vecmathlib provides portable vectorized mathematical functions for pocl across SIMD vectors, accelerators, and scalar CPUs. Its implementations combine architecture-specific vector types with numerical algorithms such as iterative approximation and range-reduced polynomial expansion.

  • Library design: Vecmathlib supplies efficient, accurate, tunable, vectorized mathematical functions as a pocl subsystem for computationally bound kernels.It is designed for vector arguments and supports multiple hardware styles.
  • Library design: The library combines type traits, SIMD vector templates, generic mathematical algorithms, and architecture-specific vector definitions.Available intrinsics are used when supported; otherwise generic algorithms provide fallbacks.
  • Vector portability: Unsupported vector sizes are implemented transparently through larger hardware-supported vectors or by splitting operations into smaller vectors.This preserves expected OpenCL types such as float2 and float8.
  • Numerical implementation: Low-level functions such as fabs, isnan, and signbit use bit manipulation and assume IEEE floating-point layout.For example, fabs clears the sign bit.
  • Numerical implementation: Inverse-based functions begin with an initial guess and iterate toward the result; sqrt uses Newton’s method after halving the exponent.The Newton iteration doubles the number of accurate digits at each step.
  • Numerical implementation: Most other functions use range reduction followed by polynomial expansion, with sin reduced by periodicity and symmetry before Chebyshev approximation.The polynomial minimizes maximum error over the reduced range.
  • Design limitation: Automatic compiler vectorization of scalar functions is not currently sufficient because low-level operations may require architecture-dependent implementations.The paper suggests LLVM could eventually incorporate logic already present in Vecmathlib.

6 Performance Evaluation

The evaluation tests pocl across CPUs and a simulated VLIW-style platform, comparing execution with vendor or reference implementations where available. Results show strong performance on Intel and substantial gains from horizontal parallelization, while some platforms and benchmark cases remain constrained by implementation maturity or benchmark characteristics.

  • Evaluation setup: The benchmark suite was run across platforms supported by pocl and compared with the best available vendor implementation for each platform.Repeated executions reduce cache effects and amortize kernel compilation time.
  • Intel x86-64: On Intel Core i7, pocl outperformed available AMD or Intel implementations for several applications, although BinarySearch and NBody remained poor cases.The tested workstation used an Intel Core i7-4770 at 3.4 GHz with Ubuntu Linux 12.04.
  • ARM Cortex-A9: ARM Cortex-A9 results were compared with FreeOCL because no ARM CPU OpenCL implementation was available; BinomialOption failed with FreeOCL.The PandaBoard used a 1 GHz Cortex-A9 with NEON SIMD and 1 GB RAM.
  • Cell Broadband Engine: The Cell evaluation was limited to the PowerPC because most SPU cases failed with compiler errors and LLVM removed the SPU backend after version 3.2.The PowerPC benchmarks used Debian sid and compared pocl with IBM’s OpenCL Development Kit.
  • Static multi-issue: 53.5 ms without horizontal inner-loop parallelization fell to 10.2 ms at 100 MHz with it, indicating roughly five-fold greater exploitable instruction-level parallelism on the TTA benchmark.The test used the unmodified AMD SDK DCT benchmark on a simulated TTA datapath.
  • Vector math: Vecmathlib was at least as efficient as libm for scalar mathematical functions and significantly more efficient for vector types, where scalarization incurs vector-shuffle overhead.The comparison covered exp, sin, and sqrt on Intel Core i7 and PlayStation 3 vector hardware.

7 Related work

Related work includes SPMD vectorization, source-to-source work-item coalescing, fiber-based OpenCL implementations, and portable runtimes. Pocl distinguishes itself by preserving parallelism in LLVM IR and separating resource-independent region formation from target-specific mapping.

  • Prior kernel transformations: Whole Function Vectorization and Intel’s implicit vectorization target SPMD descriptions but rely on particular parallel resources during kernel compilation.These approaches are related to compiling OpenCL work-group functions for vector hardware.
  • Work-item coalescing: Prior work applies work-item coalescing through source-to-source transformations, but converting parallel regions into serial loops loses parallelism information and complicates alias analysis.LLVM IR metadata lets pocl preserve parallel-loop information for later compilation passes.
  • Portable OpenCL implementations: Fiber-based implementations such as Clover and Twin Peaks have limited performance portability and scaling because independent work-item threads cannot expose fine-grained SIMD or VLIW parallelism.Fiber context switches also introduce overhead.
  • Portable OpenCL implementations: FreeOCL provides a platform-portable OpenCL implementation but does not provide a kernel compiler for static work-item parallelization.It relies on an external C++ compiler and a fiber-based approach for multi-work-group execution.
  • Pocl’s distinction: Pocl separates parallel-region exposure from target-specific parallelization, allowing parallel operations to map to the device resources available on each platform.Unlike vectorization-specific approaches, its kernel compilation does not depend on one particular parallel resource type.
  • Pocl’s distinction: Static analysis avoids independent-control-flow threads for barriered multi-work-item kernels, while a C host API broadens portability to embedded platforms.This addresses both performance portability and platform portability relative to fiber-based and C++-based alternatives.

8 Conclusions and Future Work

pocl combines a modular, LLVM-based kernel compiler with a portable OpenCL implementation that maps extracted parallelism onto diverse hardware. Experiments showed efficient porting and performance close to or exceeding proprietary implementations, while future work targets language-generic optimization and LLVM limitations.

  • Contributions: pocl separates parallelism analysis from target-specific static parallelization for SIMD, VLIW, and superscalar hardware.LLVM IR metadata carries multiple-work-item parallelism into later compilation phases.
  • Evaluation: Experiments on different processor architectures showed efficient OpenCL application porting and exploitation of varied underlying hardware parallelism.
  • Evaluation: Most benchmarked applications were faster or close to as fast as the best proprietary OpenCL implementation for each platform.
  • Future work: Current kernel-compiler performance improvements are largely language-generic and can benefit non-OpenCL programs through LLVM.
  • Future work: Planned work includes selective vector-code scalarization and more selective inlining to reduce instruction-cache costs when vectorization or static parallelization does not improve.
  • Future work: Limited LLVM if-conversion support constrains predication of statically parallelizable work-item loops and slows the worst-performing benchmark cases.
Loading 1611.07083v1…