GPU Programming: When, Why and How?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  • futhark

    :boom::computer::boom: A data-parallel functional programming language

    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

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
  • futhark-metal

    :boom::computer::boom: A data-parallel functional programming language

    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

  • pareas

    GPU-accelerated compiler

    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.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • What downsides exist to Futhark? Seems almost too good to be true?

    1 project | /r/CUDA | 29 Jun 2023
  • Functional GPU programming: what are alternatives or generalizations of the idea of "number of cycles must be known at compile time"?

    1 project | /r/ProgrammingLanguages | 4 Apr 2023
  • The Futhark Programming Language: Functional Array Programming in CUDA

    1 project | news.ycombinator.com | 7 Mar 2023
  • Achieving High-Performance the Functional Way

    1 project | news.ycombinator.com | 5 Mar 2023
  • Package management woes

    1 project | /r/futhark | 7 Jan 2023

Did you konow that Haskell is
the 25th most popular programming language
based on number of metions?