@pepijndevos That is correct, but we'll soon be enabling a new compilation scheme in which multiple increasingly-flattened versions of the code are produced, and the best one picked at run-time. My idea is to employ full flattening as the final version that is picked if nothing else works.
While I want to have that to handle things that Futhark already permits (in particular irregular parallelism), it will not be particularly efficient.
For example, I think Harlan supports recursion by simply emulating a stack on the GPU. As I recall, the cost is that parallel operations inside recursive calls are simply sequentialised.
(Also, the stack operations will be incredibly slow.)
Full flattening turns the recursion inside out, so to speak, so you get full parallelisation and nice memory access patterns. The downside is that while the memory is accessed decently enough, it will be accessed a lot.
Hello. Very nice work. I was wondering if there was any plan to extend futhark to say multi threaded C (something like
The OpenCL currently generated by the Futhark compiler runs OK on a CPU OpenCL implementation too, although there are still some GPU-isms in the optimisation pipeline.
I do still want a multicore backend that does not depend on OpenCL, though.
You're welcome to chip in, but it's going to be real time-consuming to answer such questions.
Once the foundations are laid, hopefully smaller and more well-defined issues will open up.
@jakehehrlich it generates either C or Python, with embedded GPU kernels.
But then you won't get the source for the input parsing machinery. On the other hand, you'll get a
.h file!
I was under the impression that that produced a .so
It's too system-dependent, so the Futhark compiler doesn't even try.
(E.g. typically I don't compile to an .so, I compile to an .o and link directly.)
I certainly have opinions on how to compile and link lol
Only one translation unit is output, correct?