Futhark: a data-parallel functional language that compiles to GPU code

What Futhark solves, and who it is for

Futhark is a purely functional data-parallel programming language in the ML family, developed at DIKU at the University of Copenhagen, originally as part of the HIPERFIT centre. The README states that it can be compiled to typically very efficient parallel code, running on either a CPU or a GPU. That single sentence is the whole pitch, and it is a narrow one. The language exists so that you describe a computation over whole arrays and let the compiler decide how to map it onto parallel hardware. You do not write a kernel per device, and you do not manage thread blocks by hand.

The audience follows from that. If your work is dense linear algebra, stencil codes, or any computation that reduces to map, reduce, scan and scatter over arrays, Futhark is aimed at you. If your program is a state machine with irregular branching, pointer chasing, or heavy host-side orchestration, the language is a poor fit and the compiler will not rescue you. The README describes the language as quite stable and suitable for practical programming, which is a stronger claim than most research languages make, but it is still a claim about the language, not about every workload you might want to express in it.

How the compiler turns array code into CPU or GPU programs

The repository layout tells you most of what you need to know about the architecture. There is src/ for the compiler itself, prelude/ for the built-in definitions that programs see by default, and rts/ for the runtime system that generated code links against. The compiler is written in Haskell, which is why the build goes through cabal. Documentation for the built-in prelude is published separately from the user guide.

The data flow is conventional for a compiler of this kind. A .fut source file is parsed and type-checked, then transformed through a series of internal representations before being handed to a backend. The topics list on the repository names cuda and opencl, so those are the two GPU targets the project advertises, with CPU code generation as the other path. The exact set of backends and their flags belongs in the user guide, not in this article, and the README does not enumerate them.

What matters for a decision is the contract this design imposes on you. Because the language is purely functional and data-parallel, the compiler can assume that array operations do not alias and that the order of independent elements does not matter. That assumption is what makes aggressive parallelisation possible. It is also why expressing sequential dependencies is awkward: the model has no place to put them, so you either restructure the algorithm or use a different tool.

Installing Futhark and compiling a first program

The README does not spell out installation steps. It points to an installation page at futhark.readthedocs.io and to a packaging status badge on repology.org, which is where you should look for a distribution package for your platform. The repository itself builds with cabal, and the Makefile wraps the longwinded commands. If you build from source, this is the sequence the Makefile abbreviates.

make configure
make build
make install

make configure runs cabal update followed by cabal configure. make build runs cabal build. make install copies the compiled binary to $(PREFIX)/bin/futhark, where PREFIX defaults to $(HOME)/.local, so the binary lands in ~/.local/bin/futhark unless you override it. The Makefile comment notes that it depends on cabal to do anything incrementally, so it is a convenience layer, not a separate build system.

Once the futhark binary is on your path, the usual workflow is to compile a .fut file to a binary that you then run. The README links to a collection of code examples and to Parallel Programming in Futhark, which it describes as an extensive introduction and guide. Those two links are the honest starting point for a first real program; the README itself does not walk through one. The Makefile also exposes a fast type-check target for test programs, which is useful while iterating on code that does not yet compile.

make test-t

That target runs futhark test tests -t, which type-checks the test programs without compiling them. The Makefile calls this much faster than compiling them, which is the right loop to be in while you are still getting the types right.

Testing GPU codegen without a GPU in the machine

One practical detail in the Makefile deserves attention because it removes a common blocker. The test-oclgrind target runs the GPU-relevant tests through oclgrind, a simulator, rather than on real hardware.

make test-oclgrind

That target invokes futhark test tests -c --backend=opencl, excluding the compiled and no_oclgrind test sets and using a cache extension. The Makefile explains that oclgrind dislikes some LLVM optimisations, hence the adjustments, and that it is a slow simulator, hence the exclusion of slow workloads. It also states plainly that this is normally the best way to test correctness of GPU code generation. For anyone evaluating Futhark on a machine without a discrete GPU, that is the path to verifying that OpenCL codegen produces correct results. It is not a performance measurement, and the Makefile does not pretend otherwise.

Where Futhark is the wrong tool

The purity of the language is a real constraint, not a marketing detail. Algorithms that depend on sequential state, on mutable data structures with pointer identity, or on fine-grained irregular control flow do not map onto the data-parallel model without being rewritten, and some of them cannot be rewritten at all. If your inner loop is a graph traversal with unpredictable branching, Futhark will make you fight the language.

There is a second limitation that is less obvious. The README says the language is quite stable, and the release history shows both tagged releases and a nightly build. A nightly release that moves daily is a commitment: if you pin to it, you own the churn. The tagged releases, v0.27.1 and v0.26.4, are the ones to prefer unless you need something that only exists in the nightly. Nothing in the README describes a stability guarantee for the nightly channel, so treat it as what it is.

Finally, the repository does not document a rollback procedure for generated binaries or for the toolchain. If you need to pin a compiler version for reproducibility, you are relying on cabal and your package manager, not on guidance from the project.

How Futhark differs from writing CUDA or OpenCL directly

The obvious alternative is writing CUDA or OpenCL kernels by hand, and the difference is not cosmetic. With CUDA or OpenCL you control memory hierarchy, work-group sizes, and synchronisation explicitly. That control is exactly what you give up with Futhark. In exchange, the same source can target a CPU or a GPU backend, and you do not maintain two implementations of the same kernel. The repository's own topics list cuda and opencl together, which reflects that Futhark generates code for those platforms rather than replacing them.

A second alternative is a host language with array primitives, such as a numerical Python stack or an array library in a general-purpose language. Those keep you in a language you already know and integrate with the rest of your codebase. Futhark does not: it is a separate language with its own prelude, its own build tooling, and its own documentation set. The trade is that you get a compiler whose only job is parallel code generation, rather than a library bolted onto a general-purpose runtime.

Neither alternative is wrong. If your performance problem is already solved by a library call, Futhark adds a language boundary for no gain. If it is not solved, and the shape of the computation is regular, the compiler's assumptions about purity and array independence are worth more than the control you surrender.

Maintenance, licensing, and the cost of tracking the compiler

The repository is not archived, and the last push was on 2026-09-23. That is the relevant fact for maintenance: the project is being worked on now. The release history shows a nightly build dated 2026-09-23 alongside tagged releases v0.27.1 from 2026-08-19 and v0.26.4 from 2026-07-04, so both channels are live.

The upgrade cost depends on which channel you pick. Tagged releases arrive on a slower cadence and give you a version number to pin. The nightly channel gives you the newest fixes at the price of a moving target. The CHANGELOG.md at the repository root is where the project records what changed, and it is the file to read before moving between versions. The README does not describe a deprecation policy or a support window for older releases.

Futhark is licensed under the ISC licence, a permissive licence. The LICENSE file is at the repository root. ISC is short and permissive, similar in effect to the MIT licence, but this is not legal advice and the exact obligations depend on how you distribute the compiler or generated code. If you ship binaries built with Futhark, read the LICENSE file yourself rather than relying on a summary.

The build itself is a cost worth naming. The compiler is written in Haskell and builds through cabal, so a from-source build pulls in a Haskell toolchain. The Makefile comments that its commands are otherwise longwinded, which is a fair description of the underlying build. If your environment cannot host a Haskell toolchain, use a distribution package from the packaging status page instead.

Editorial conclusion

Use Futhark if your problem is a whole-array computation you can express without irregular control flow, and you want one source compiled to CPU or GPU backends. Do not use it if your workload is branch-heavy, pointer-chasing, or mostly host-side orchestration. Before adopting, verify the installation path for your platform in the official installation page, confirm which backend your target machine supports, and check that the nightly build you plan to track is the one you actually want rather than the tagged v0.27.1 release.

Frequently asked questions

Official sources

1. diku-dk/futhark on GitHub
2. License: ISC
3. Project website
4. README
5. Releases