Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
We actually have a long-standing issue regarding WebGPU[0]. Long story short, we want to support it, and Athas did some exploratory work a couple of years ago and decided that WebGPU wasn't mature enough yet. We already have a WebAssembly backend, so as soon as it is possible to access WebGPU from WebAssembly it should be relatively straightforward.
[0]: https://github.com/diku-dk/futhark/issues/1403
Do you know if there is any work being done to support a Metal backend for Futhark? That would be interesting for local prototyping on macOS. I've found a fork[1], but it doesn't seem to have been updated since February.
[1]: https://github.com/MilesLitteral/futhark-metal
Compared to Halide:
* Futhark does not expose a scheduling language that gives you precise control over code generation. This is probably the main selling point of Halide.
* Futhark has a much broader focus than Halide, which is mainly oriented towards image processing. Futhark wants to support arbitrary data parallel computation. E.g. see this compiler written in Futhark: https://github.com/Snektron/pareas
Compared to Sycl:
* Futhark is a non-embedded language that is more high level than Sycl. The goals are similar in the sense that both systems to try make (data) parallel programming more accessible. The vision behind Futhark is that the conventional functional programming vocabulary is actually a pretty good fit for parallelism, and that an aggressively optimising compiler can reduce or eliminate the overhead of abstraction. I don't think Sycl is as focused on high levels of abstraction, but rather focuses on being a relatively low-level portable programming interface.
Related posts
- What downsides exist to Futhark? Seems almost too good to be true?
- Functional GPU programming: what are alternatives or generalizations of the idea of "number of cycles must be known at compile time"?
- The Futhark Programming Language: Functional Array Programming in CUDA
- Achieving High-Performance the Functional Way
- Package management woes