7 ms·

Designing a Programming Language for the Desert

163 points by Athas 8y ago

erikpukinskis 8y ago
Transcendant read. Bang on.
Nzen 8y ago
tl;dr futhark is a DSL for transpiling non-graphics parallel submodules for other programs. Which is to say, if one were to write a N-queens futhark program, it could create C, C#, or Python modules for use in a larger program that would leverage OpenCL for parallelizing the chess moves. This blog post declares some culture boundaries. Namely, the team intends to keep the dsl targeted at this domain, rather than expanding to general computation in some far future. This enables them to focus on common target language constructs and keep their documentation efforts toward similar experts. They acknowledge that this demands more of their users, for <example all> external imports must be in the same folder when compiled, but allows for simplicity and clarity all around. Hence, the author uses the analogy of a desert creature that survives in an environment of constrained resources.
earenndil 8y ago
Honestly, if it's not intended for general use, I don't think it's worth it to complicate the build process, and complicate the process of setting up a dev environment by installing a whole new compiler toolchain just for a couple of small functions.
- everdev 8y ago
  > 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.
- pjmlp 8y ago
  While I agree with your point of view regarding production code, it is this continuous ongoing effort of such language designers that eventually (with a bit of luck as well) turn a programming language from "yet another one" to something relevant.
dom96 8y ago
So futhark is designed to be small and specific to a single class of problems. Has the author considered implementing it in another language as a DSL?
- Athas 8y ago
  Yes, we considered that. There were two reasons we wrote a standalone language instead: * It gives more flexibility and simplicity, regarding both syntax and type system. The compiler can also more easily analyse the AST, because there are no artifacts of an embedding. * An embedded DSL is practically available only to users of the host language. In contrast, Futhark is equally accessible to many languages, either via direct code generation (such as for Python), or using a fairly simple C FFI. The best example of an embedded high performance DSL is, I believe, Accelerate[0] for Haskell. It is really good, but is ultimately only accessible to Haskell programmers, and the implementation has to solve non-trivial problems related to the embedding. [0]: http://hackage.haskell.org/package/accelerate http://hackage.haskell.org/package/accelerate
qazwsxedcrfv12 8y ago
this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa
qazwsxedcrfv123 8y ago
this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa
azwsxedcrfv12 8y ago
check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa
876735345345 8y ago
this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa
tehsauce 8y ago
These DSLs for high performance parallel computing based on purely functional algorithm descriptions are very exciting- halide and accelerate are similar projects. I can see as the demand for writing parallel, portable code increases technology like these becoming essential tools.
- mkirklions 8y ago
  What applications?
  - lou1306 8y ago
    Most algorithms related to computer vision and image processing come to mind. Of course there are efficient libraries written in general-purpose languages, but DSLs could lead to smaller, easily maintainable codebases.
543543543543 8y ago
http://bit.ly/2K1FL3T http://bit.ly/2K1FL3T
876768868 8y ago
good forum https://bit.ly/2ygdgLt https://bit.ly/2ygdgLt
keldaris 8y ago
How close is Futhark to being considered production-ready? How close is the generated code to hand-optimized OpenCL for real problems (I did look at the benchmarks, but only the Rodinia suite had comparison numbers, and those are trivial to beat)? OpenCL is easy to write for anyone who knows C (far more people than fans of functional programming) and moderately difficult to write decently well. What's the value proposition of Futhark? Is it just that some people prefer writing in a functional DSL rather than C, or does it purport to enable some optimizations that are hard to write well manually?
- TomMarius 8y ago
  Is it true that more people know OpenCL than functional programming? To me it seems like functional programming is a lot more prevalent in domains where this would be used, but I don't have any numbers. Do you by any chance have a source?
  - keldaris 8y ago
    I didn't assert that more people know OpenCL than functional programming, I said far more people know C than functional programming. Anyone who knows C can write (bad) OpenCL after a trivial tutorial, so the initial barrier to entry is low. Writing decently optimized OpenCL is, as I said, moderately difficult and requires some domain specific knowledge, and it scales up from there if you want to get close to optimal.
    - deleted 8y ago
      [deleted]
    - TomMarius 8y ago
      Sorry, I also meant C. Let me correct my sentence: Do more people in verticals that would make use of this know more C or functional programming?
      - keldaris 8y ago
        Unequivocally, C. Futhark is clearly meant for reasonably high performance computing and I don't know of a single person in that domain that isn't a competent C programmer even if they spend a lot of time writing code in other languages (C++ mostly, also Fortran, Julia, Python with Cython/Numba, etc.). Functional programming, on the other hand, is something many (most, I'd contend) people in this domain consciously stay away from, myself included.
taneq 8y ago
> Fairly sure you don’t have to watch out for sandworms in a real desert. Doesn't that map rather well to being acquired by $bigcorp?

163 points by Athas 8y ago

Transcendant read. Bang on.

Nzen 8y ago

tl;dr futhark is a DSL for transpiling non-graphics parallel submodules for other programs. Which is to say, if one were to write a N-queens futhark program, it could create C, C#, or Python modules for use in a larger program that would leverage OpenCL for parallelizing the chess moves. This blog post declares some culture boundaries. Namely, the team intends to keep the dsl targeted at this domain, rather than expanding to general computation in some far future. This enables them to focus on common target language constructs and keep their documentation efforts toward similar experts. They acknowledge that this demands more of their users, for <example all> external imports must be in the same folder when compiled, but allows for simplicity and clarity all around. Hence, the author uses the analogy of a desert creature that survives in an environment of constrained resources.

earenndil 8y ago

Honestly, if it's not intended for general use, I don't think it's worth it to complicate the build process, and complicate the process of setting up a dev environment by installing a whole new compiler toolchain just for a couple of small functions.

everdev 8y ago
> 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.
pjmlp 8y ago
While I agree with your point of view regarding production code, it is this continuous ongoing effort of such language designers that eventually (with a bit of luck as well) turn a programming language from "yet another one" to something relevant.

dom96 8y ago

So futhark is designed to be small and specific to a single class of problems. Has the author considered implementing it in another language as a DSL?

Athas 8y ago
Yes, we considered that. There were two reasons we wrote a standalone language instead: * It gives more flexibility and simplicity, regarding both syntax and type system. The compiler can also more easily analyse the AST, because there are no artifacts of an embedding. * An embedded DSL is practically available only to users of the host language. In contrast, Futhark is equally accessible to many languages, either via direct code generation (such as for Python), or using a fairly simple C FFI. The best example of an embedded high performance DSL is, I believe, Accelerate[0] for Haskell. It is really good, but is ultimately only accessible to Haskell programmers, and the implementation has to solve non-trivial problems related to the embedding. [0]: http://hackage.haskell.org/package/accelerate http://hackage.haskell.org/package/accelerate

qazwsxedcrfv12 8y ago

this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa

qazwsxedcrfv123 8y ago

this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa

azwsxedcrfv12 8y ago

check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa

876735345345 8y ago

this is a very nice forum,check it out https://www.bit.ly/2M0hqJa https://www.bit.ly/2M0hqJa

tehsauce 8y ago

These DSLs for high performance parallel computing based on purely functional algorithm descriptions are very exciting- halide and accelerate are similar projects. I can see as the demand for writing parallel, portable code increases technology like these becoming essential tools.

mkirklions 8y ago
What applications?
- lou1306 8y ago
  Most algorithms related to computer vision and image processing come to mind. Of course there are efficient libraries written in general-purpose languages, but DSLs could lead to smaller, easily maintainable codebases.

543543543543 8y ago

http://bit.ly/2K1FL3T http://bit.ly/2K1FL3T

876768868 8y ago

good forum https://bit.ly/2ygdgLt https://bit.ly/2ygdgLt

keldaris 8y ago

How close is Futhark to being considered production-ready? How close is the generated code to hand-optimized OpenCL for real problems (I did look at the benchmarks, but only the Rodinia suite had comparison numbers, and those are trivial to beat)? OpenCL is easy to write for anyone who knows C (far more people than fans of functional programming) and moderately difficult to write decently well. What's the value proposition of Futhark? Is it just that some people prefer writing in a functional DSL rather than C, or does it purport to enable some optimizations that are hard to write well manually?

TomMarius 8y ago
Is it true that more people know OpenCL than functional programming? To me it seems like functional programming is a lot more prevalent in domains where this would be used, but I don't have any numbers. Do you by any chance have a source?
- keldaris 8y ago
  I didn't assert that more people know OpenCL than functional programming, I said far more people know C than functional programming. Anyone who knows C can write (bad) OpenCL after a trivial tutorial, so the initial barrier to entry is low. Writing decently optimized OpenCL is, as I said, moderately difficult and requires some domain specific knowledge, and it scales up from there if you want to get close to optimal.
  - deleted 8y ago
    [deleted]
  - TomMarius 8y ago
    Sorry, I also meant C. Let me correct my sentence: Do more people in verticals that would make use of this know more C or functional programming?
    - keldaris 8y ago
      Unequivocally, C. Futhark is clearly meant for reasonably high performance computing and I don't know of a single person in that domain that isn't a competent C programmer even if they spend a lot of time writing code in other languages (C++ mostly, also Fortran, Julia, Python with Cython/Numba, etc.). Functional programming, on the other hand, is something many (most, I'd contend) people in this domain consciously stay away from, myself included.

taneq 8y ago

> Fairly sure you don’t have to watch out for sandworms in a real desert. Doesn't that map rather well to being acquired by $bigcorp?