
Streaming Combinators and Extracting Flat Parallelism - Athas
http://futhark-lang.org/blog/2017-06-25-futhark-at-pldi.html
======
purpleog
I'm curious to know how Futhark relates in performance to halide -- halide is
more specific to image processing, but uses a similar approach (domain-
specific language compiled to multiple target platforms): [http://halide-
lang.org](http://halide-lang.org)

------
tibbe
The Data Parallel Haskell work on flattening ran into problems with space
blow-up due to replicating arrays to perform flattening. Does Futhank avoid
those problems?

~~~
Athas
Yes. Since Futhark does not perform full flattening, replication is limited to
how much parallelism is _exploited_ , not how much parallelism is _available_.

(That said, memory explosion is still a common symptom when the compiler
misjudges how much parallelism should be exploited.)

------
fulafel
Has anyone here tried Futhark? Is it ready to use or mostly PL research?

~~~
DannyBee
These types of things are mostly PL research. Staring at their repo, Futhark
is better than most in terms of "readyness", but it's still probably not
something you'd want to start programming all your GPU code in :) It lacks a
lot of developer friendliness.

~~~
Athas
What would be a good starting point for adding more friendliness?

~~~
DannyBee
It doesn't even always produce sane error messages right now :)

It also misses a bunch of syntactic sugar that make programming inconsistent
from what one would expect in a bunch of cases (they acknowledge this up
front).

Past that, in part, getting people to adopt new languages is about either
providing them an ecosystem that is amazing to start and trying to convince
them to jump ... _OR_ meeting them where they are now (IE building integration
into existing editors, tooling, etc).

Usually people try to get people to jump. You'll note that this rarely works
and is a very long and slow burn when it does. This is true even when the new
ecosystem is huge. The successful jump cases are usually somewhere in the
middle, where they are leveraging existing ecosystems but providing something
better enough.

Futhark is neither providing a better ecosystem to jump to, _or_ meeting
people where they are.

~~~
Athas
Insightful and reasonable, thanks! In particular, I agree that the error
messages could probably do with a few hints of what to do next. I find Elm's
work on user-friendly error messages rather inspiring.

Editor integration would definitely also be interesting. I suspect the best
approach would be to implement the language server protocol, as there are too
many editors to handle all of them individually.

The hope for Futhark is that a "jump" will be much smaller than for other
languages, since it's not really supposed to replace any language, just to
augment existing ones. It should feel more like using a library than adding a
new language to a project. Of course, there is still a compilation step, but
if necessary, that can be crudely circumvented by simply adding the (portable)
code generated by the Futhark compiler to source control.

So, the strategy is definitely to meet people where they are - building an
entire ecosystem is not really feasible for such a small and specialised
language. Most people don't even have the problems that Futhark tries to
solve, which is certainly a nontrivial hindrance to usage.

