Accelerate: an embedded array language for Haskell on GPUs and CPUs

What problem Accelerate solves for Haskell programs

Accelerate addresses the problem of expressing high-performance parallel array computations in Haskell without leaving the language. Data.Array.Accelerate defines an embedded language of array computations for high-performance computing. Computations on multi-dimensional, regular arrays are expressed as parameterised collective operations such as maps, reductions, and permutations. These computations are online-compiled and executed on a range of architectures.

The intended audience is Haskell developers who need GPU or multicore performance but want to stay in a functional style. The README's dot product example shows how close the syntax stays to ordinary Haskell list code, differing mainly in types. The types indicate that the computation may be online-compiled for performance, for example using Data.Array.Accelerate.LLVM.PTX.run to off-load to a GPU on the fly.

How Accelerate compiles and runs array code

The mechanism is online compilation of an embedded array language. A computation is written with Acc types and collective operations, then executed by a backend that compiles it at runtime. The README names two backends among the supported add-ons: accelerate-llvm-native targets multicore CPUs, and accelerate-llvm-ptx targets CUDA-enabled NVIDIA GPUs, requiring a GPU with compute capability 3.0 or greater according to the linked table.

The README points to several papers for the underlying design, including Accelerating Haskell Array Codes with Multicore GPUs, Optimising Purely Functional GPU Programs, Embedding Foreign Code, Type-safe Runtime Code Generation, and Streaming Irregular Arrays. Chapter 6 of Simon Marlow's book Parallel and Concurrent Programming in Haskell contains a tutorial introduction. Trevor McDonell's PhD thesis details the design and implementation of frontend optimisations and the CUDA backend.

The front-end and backend split matters for adoption: the core package defines the language, while performance comes from a separate backend package. A project can depend on the core and choose a backend at build time.

A simple example from the README

The README gives a dot product of two vectors of single-precision floating-point numbers as the introductory example.

dotp :: Acc (Vector Float) -> Acc (Vector Float) -> Acc (Scalar Float)
dotp xs ys = fold (+) 0 (zipWith (*) xs ys)

Except for the type, this code is almost the same as the corresponding Haskell code on lists of floats. The Acc types mark the computation as one that may be online-compiled. With Data.Array.Accelerate.LLVM.PTX.run it may be off-loaded to a GPU on the fly.

The repository also ships computational kernels and applications in accelerate-examples, which serve as a regression test suite supporting function and performance testing.

Installing Accelerate and getting started

The package is available on Hackage as accelerate, and the README says to add it to your cabal file. The source is available on GitHub.

git clone https://github.com/AccelerateHS/accelerate.git

To install the Haskell toolchain, the README suggests GHCup at haskell.org. The repository includes Setup.hs, accelerate.cabal, cabal.project, and stack.yaml, so both Cabal and Stack workflows are supported by the repository layout.

The README also lists many conversion packages under accelerate-io, covering raw pointers, immutable arrays, BMP images, bytestrings, cereal serialisation, JuicyPixels images, repa arrays, serialise, and vectors. Further add-ons include accelerate-fft, accelerate-blas, accelerate-bignum, colour-accelerate, containers-accelerate, gloss-accelerate, gloss-raster-accelerate, hashable-accelerate, lens-accelerate, linear-accelerate, mwc-random-accelerate, numeric-prelude-accelerate, and wigner-ville-accelerate. All are available on Hackage.

Requirements and documentation

The repository layout shows Haskell sources under src, tests under test, example applications under app, and C bindings under cbits. Documentation is provided as Haddock, linked with individual packages.

Limitations and when Accelerate is the wrong tool

The most recent release listed is v1.3.0.0 on 2020-08-28, while the last push was on 2026-06-20. That gap between release and commit activity means a user depending on released packages may be behind the current code, and should verify which version a backend package expects.

The license is reported by GitHub as Other, a custom licence it cannot classify, with a pointer to the LICENSE file. That is a real adoption hurdle for organizations that require a standard classified license, and it must be reviewed before commercial use.

The PTX backend requires a CUDA-enabled NVIDIA GPU with compute capability 3.0 or greater, so Accelerate is the wrong tool for AMD or Intel GPU targets or older NVIDIA hardware. It is also the wrong tool if you need a simple drop-in array library without learning an embedded DSL and managing backend packages.

Alternatives and how the approach differs

The README names repa as another Haskell library for high-performance parallel arrays, and accelerate-io-repa exists to convert between Accelerate and repa arrays. Accelerate is an embedded language that is online-compiled to target GPUs and multicore CPUs through LLVM backends.

The difference in practice is target hardware and compilation strategy. Accelerate generates code for NVIDIA GPUs through the PTX backend and for multicore CPUs through the native backend, sharing one front-end DSL. A team already using repa for CPU arrays can bridge the two through accelerate-io-repa rather than replacing one with the other.

Maintenance, licensing and upgrade cost

The repository is not archived and the last push was on 2026-06-20. The only recent release listed is v1.3.0.0 on 2020-08-28. The license is a custom one that GitHub cannot classify, so the LICENSE file must be read directly.

Upgrade cost is shaped by the multi-package ecosystem. The core accelerate package is separate from accelerate-llvm-native, accelerate-llvm-ptx, accelerate-examples, and the accelerate-io conversion packages, each with its own version. Keeping them in sync is a manual task. A maintainer should pin backend versions to the core version and test GPU code on real hardware.

The license implications cannot be summarized as a standard SPDX identifier; this is not legal advice and a team should have counsel review the LICENSE file.

Editorial conclusion

Adopt Accelerate if you write Haskell and need GPU or multicore array computations with an embedded, type-safe DSL. Skip it if you need a stable release cadence or a classified open source license. Verify the GHC toolchain, the backend you intend to use, and the LICENSE file before depending on it.

Frequently asked questions

Official sources

1. AccelerateHS/accelerate on GitHub
2. Issues
3. Project website
4. README
5. Releases