4 ms·

Thank you for the detailed response. I'll try to allocate a weekend to port some of my usual scientific GPGPU test cases to Futhark and see how it goes. > Mos

Thank you for the detailed response. I'll try to allocate a weekend to port some of my usual scientific GPGPU test cases to Futhark and see how it goes. > Most low-level GPU languages (like OpenCL and CUDA) make it very hard to write code that is both fast and modular. That's absolutely true, which is why a frequent solution is to achieve modularity by using simple metaprogramming to generate kernel code from higher level constraints. I understand Futhark aims to obviate at least a subset of these issues, so there's value there. > Essentially, the Futhark compiler is not bound by the restriction that the optimised code should be maintainable by humans, so it is able to use inlining, duplication, fusion and a host of other transformations that are helpful for performance, but no sane programmer would write if they cared about the maintainability of their code. Am I correct in assuming that you can still (easily) obtain, inspect and profile the Futhark-generated OpenCL code using the usual tools? I suppose a sensible workflow could be using Futhark to get as far as you can and then hand optimize the bottleneck kernels further. > In practice, Futhark usually gets beat on single primitive operations (matrix multiplication, FFT, etc), but at an application level, it tends to do well. Do you happen to know of any scientific/engineering applications (lattice Boltzmann methods, molecular dynamics, etc.) using Futhark in the wild? From a quick glance at the website it seemed like all of the applications are focused on image/video processing, any reason for that?

Athas 8y ago
> Am I correct in assuming that you can still (easily) obtain, inspect and profile the Futhark-generated OpenCL code using the usual tools? I suppose a sensible workflow could be using Futhark to get as far as you can and then hand optimize the bottleneck kernels further. Sort of. Futhark generates pretty simple OpenCL host code, but there is not yet an obvious way to tie the generated kernels back to the original Futhark source code. As a result, it's easy enough to detect that some specific kernel is the bottleneck, and often also why, but it can be a bit of a puzzle to connect it to a part of the original program. While you can in principle edit the generated kernels yourself, it's not code that is at all nice to read or modify. > Do you happen to know of any scientific/engineering applications (lattice Boltzmann methods, molecular dynamics, etc.) using Futhark in the wild? No. Closest are simple things like nbody[0] simulations. [0]: https://github.com/diku-dk/futhark-benchmarks/tree/master/accelerate/nbody https://github.com/diku-dk/futhark-benchmarks/tree/master/ac... > From a quick glance at the website it seemed like all of the applications are focused on image/video processing, any reason for that? Not sure. Most of these are stencils, and while Futhark does alright with stencils, it doesn't do anything particularly clever (no hexagonal tiling, for example). Maybe it's just that they are easy and satisfying to write, because you trivially get something visual at the end. Futhark's design was originally inspired by nasty financial algorithms (the ones from the FinPar suite[1]), which tend to be a combination of Monte Carlo methods and differential equations. I'd say that is Futhark's main strength. [1]: https://dl.acm.org/citation.cfm?id=2898354 https://dl.acm.org/citation.cfm?id=2898354

Athas 8y ago

> Am I correct in assuming that you can still (easily) obtain, inspect and profile the Futhark-generated OpenCL code using the usual tools? I suppose a sensible workflow could be using Futhark to get as far as you can and then hand optimize the bottleneck kernels further. Sort of. Futhark generates pretty simple OpenCL host code, but there is not yet an obvious way to tie the generated kernels back to the original Futhark source code. As a result, it's easy enough to detect that some specific kernel is the bottleneck, and often also why, but it can be a bit of a puzzle to connect it to a part of the original program. While you can in principle edit the generated kernels yourself, it's not code that is at all nice to read or modify. > Do you happen to know of any scientific/engineering applications (lattice Boltzmann methods, molecular dynamics, etc.) using Futhark in the wild? No. Closest are simple things like nbody[0] simulations. [0]: https://github.com/diku-dk/futhark-benchmarks/tree/master/accelerate/nbody https://github.com/diku-dk/futhark-benchmarks/tree/master/ac... > From a quick glance at the website it seemed like all of the applications are focused on image/video processing, any reason for that? Not sure. Most of these are stencils, and while Futhark does alright with stencils, it doesn't do anything particularly clever (no hexagonal tiling, for example). Maybe it's just that they are easy and satisfying to write, because you trivially get something visual at the end. Futhark's design was originally inspired by nasty financial algorithms (the ones from the FinPar suite[1]), which tend to be a combination of Monte Carlo methods and differential equations. I'd say that is Futhark's main strength. [1]: https://dl.acm.org/citation.cfm?id=2898354 https://dl.acm.org/citation.cfm?id=2898354