3 ms·

> Thus, even were Futhark to become the indisputably best language in its area - which is certainly the goal! - the user base would still be small, and so would

> Thus, even were Futhark to become the indisputably best language in its area - which is certainly the goal! - the user base would still be small, and so would the development resources. Exactly. If I'm selecting a language for any critical components, it's going to be one with a strong community, not something obscure that might be a little less verbose or a little more performant.

Athas 8y ago
What if it's a lot more performant? It's of course always a risk to incorporate another language, but sometimes performance is a critical feature, yet you have no time or inclination to write (say) low-level GPU code by hand. Futhark is more of an alternative to CUDA or OpenCL than to high-level languages. Also, there is the important property that Futhark programs tend to be fairly small, and are semantically close to ordinary functional programming. Thus, even in a worst case situation where the Futhark compiler is abandoned, it is a reasonable task to simply rewrite all the code in another high-level language.
- earenndil 8y ago
  > sometimes performance is a critical feature, yet you have no time or inclination to write (say) low-level GPU code by hand I also have no time or inclination to integrate an entirely new tool into my build chain, complicate and lengthen the build process, and increase the cognitive load required to begin working on the project.
  - Athas 8y ago
    Sure, that's a fine judgment for most applications. That's exactly why high-performance languages (of any kind) necessarily must remain somewhat niche. Although I will point out that the point of this post is exactly to try to minimise the build system complication and cognitive load as much as possible, so Futhark will be useful to just slightly more projects.
  - crummy 8y ago
    That's probably why they focussed on making the compiler as simple and straightforward to use as possible, so it does not significantly increase the complexity of your build process.
    - orbifold 8y ago
      You would still need to wrap it in some form for it to be useable from most other build systems except make. For build systems such as bazel this is quite some work for little immediate benefit.
  - RasmusWL 8y ago
    That's totally fine. Futhark is an offer for people that need high performance code, but could spend their time on better things than writing CUDA/OpenCL code by hand. Clearly that's not everyone. Maybe you don't need high performance code. Maybe you need to squeeze every last bit of performance out of your GPUs, so you actually need to spend time writing your own CUDA/OpenCL code. So while it might not be worth it for you, it might be worth it for people trying to solve other kinds of problems :)

Athas 8y ago

What if it's a lot more performant? It's of course always a risk to incorporate another language, but sometimes performance is a critical feature, yet you have no time or inclination to write (say) low-level GPU code by hand. Futhark is more of an alternative to CUDA or OpenCL than to high-level languages. Also, there is the important property that Futhark programs tend to be fairly small, and are semantically close to ordinary functional programming. Thus, even in a worst case situation where the Futhark compiler is abandoned, it is a reasonable task to simply rewrite all the code in another high-level language.

earenndil 8y ago
> sometimes performance is a critical feature, yet you have no time or inclination to write (say) low-level GPU code by hand I also have no time or inclination to integrate an entirely new tool into my build chain, complicate and lengthen the build process, and increase the cognitive load required to begin working on the project.
- Athas 8y ago
  Sure, that's a fine judgment for most applications. That's exactly why high-performance languages (of any kind) necessarily must remain somewhat niche. Although I will point out that the point of this post is exactly to try to minimise the build system complication and cognitive load as much as possible, so Futhark will be useful to just slightly more projects.
- crummy 8y ago
  That's probably why they focussed on making the compiler as simple and straightforward to use as possible, so it does not significantly increase the complexity of your build process.
  - orbifold 8y ago
    You would still need to wrap it in some form for it to be useable from most other build systems except make. For build systems such as bazel this is quite some work for little immediate benefit.
- RasmusWL 8y ago
  That's totally fine. Futhark is an offer for people that need high performance code, but could spend their time on better things than writing CUDA/OpenCL code by hand. Clearly that's not everyone. Maybe you don't need high performance code. Maybe you need to squeeze every last bit of performance out of your GPUs, so you actually need to spend time writing your own CUDA/OpenCL code. So while it might not be worth it for you, it might be worth it for people trying to solve other kinds of problems :)