5 ms·

I mean, Futhark certainly can. The whole point of Futhark is that it's a functional language that can run on GPUs. Futhark will beat the pants off of C for most

by OskarS 7y ago

I mean, Futhark certainly can. The whole point of Futhark is that it's a functional language that can run on GPUs. Futhark will beat the pants off of C for most any problem that is suitable for GPU computation, even if written in an entirely functional style. For CPUs, I'd like to introduce you to my good friend Fortran.

gridlockd 7y ago
That's an apples to oranges comparison, because Futhark needs to compete with C on the GPU (CUDA/OpenCL), not C on the CPU. That's what I'm missing from these benchmarks - how does it fare against a handwritten, competent implementation in those languages?
- gilmi 7y ago
  https://futhark-lang.org/performance.html https://futhark-lang.org/performance.html
  - gridlockd 7y ago
    This is comparing against a high-level library (Thrust) that offers a comparable level of convenience. That's fair, but it tells you nothing about the performance gap introduced by these high-level abstractions.
    - Athas 7y ago
      There is also a comparison against HotSpot, which is a hand-written GPU program (albeit imperfectly). Futhark does not outperform expertly hand-optimised GPU code, but most of the GPU code found in the wild is hardly expertly hand-optimised. Futhark comes out on top surprisingly often, but can be solidly beaten for complex algorithms or clever implementations. See figure 8 in this paper for examples: https://futhark-lang.org/publications/ppopp19.pdf https://futhark-lang.org/publications/ppopp19.pdf
- penagwin 7y ago
  Yeah this is what I'd like to see, Futhark vs Cuda. If your application is better suited for GPUs of course it'll be faster than C on the cpu. GPU mining and AI training are done on the GPU for a reason, and they of course beat "C" on the cpu.
- OskarS 7y ago
  In the linked post, the author tests Futhark running on the CPU without any parallelism or low-level optimizations, and it still beat GNU wc. Fair enough about apples to oranges, but it was really distasteful to me that the top comment on this post was about how C is “unbeatable”, when the article clearly showed that Futhark was faster. And since we’re at the dawn of a new age of parallel computing, statements like that are absurd in general.
  - mlyle 7y ago
    > In the linked post, the author tests Futhark running on the CPU without any parallelism or low-level optimizations, and it still beat GNU wc. Barely... It also mmaps in a whole 100 meg file. :P wc is not optimized to count as fast as possible, resource use be damned.
- Athas 7y ago
  You are right that it's interesting to compare Futhark-on-GPU with X-on-GPU for various values of X. In most of our academic work, that is what we do. However, in practice, X-on-GPU where X is not Futhark is rare, because GPU programming is notoriously difficult and time-consuming. Futhark's purpose is to make high-performance data-parallel programming more accessible, even if you could potentially write a faster program yourself. There are no empirical measurements that I know of, but I would not be surprised if it is a hundred times faster to write a Futhark program than the corresponding OpenCL program. CUDA fares a little better, but not by much. So even if your hand-written program might be twice as fast as Futhark, do you really have the time to write it in the first place? And if you later want to make a small change to its logic (say, adding another parallel loop on top), you may need to rework all of your optimisations from scratch.
Crinus 7y ago
Also for CPUs there is ispc (https://ispc.github.io/ https://ispc.github.io/) which provides a language that takes advantage of modern CPU's parallel friendly features with a C-like syntax. From the site: > ispc compiles a C-based SPMD programming language to run on the SIMD units of CPUs and the Intel Xeon Phi™ architecture; it frequently provides a 3x or more speedup on CPUs with 4-wide vector SSE units and 5x-6x on CPUs with 8-wide AVX vector units, without any of the difficulty of writing intrinsics code. Parallelization across multiple cores is also supported by ispc, making it possible to write programs that achieve performance improvement that scales by both number of cores and vector unit size. There is also an interesting story of its development (full with office politics drama :-P) written by its -then- main developer: https://pharr.org/matt/blog/2018/04/18/ispc-origins.html https://pharr.org/matt/blog/2018/04/18/ispc-origins.html
yiyus 7y ago
> For CPUs, I'd like to introduce you to my good friend Fortran. Fortran scares people because it is often identified with FORTRAN77. I find very unfortunate that the concept of F (a modern simplified Fortran without the legacy features [1]) never took off, although I understand the reasons. [1] https://www.fortran.com/F/index.html https://www.fortran.com/F/index.html

by OskarS 7y ago

gridlockd 7y ago

That's an apples to oranges comparison, because Futhark needs to compete with C on the GPU (CUDA/OpenCL), not C on the CPU. That's what I'm missing from these benchmarks - how does it fare against a handwritten, competent implementation in those languages?

gilmi 7y ago
https://futhark-lang.org/performance.html https://futhark-lang.org/performance.html
- gridlockd 7y ago
  This is comparing against a high-level library (Thrust) that offers a comparable level of convenience. That's fair, but it tells you nothing about the performance gap introduced by these high-level abstractions.
  - Athas 7y ago
    There is also a comparison against HotSpot, which is a hand-written GPU program (albeit imperfectly). Futhark does not outperform expertly hand-optimised GPU code, but most of the GPU code found in the wild is hardly expertly hand-optimised. Futhark comes out on top surprisingly often, but can be solidly beaten for complex algorithms or clever implementations. See figure 8 in this paper for examples: https://futhark-lang.org/publications/ppopp19.pdf https://futhark-lang.org/publications/ppopp19.pdf
penagwin 7y ago
Yeah this is what I'd like to see, Futhark vs Cuda. If your application is better suited for GPUs of course it'll be faster than C on the cpu. GPU mining and AI training are done on the GPU for a reason, and they of course beat "C" on the cpu.
OskarS 7y ago
In the linked post, the author tests Futhark running on the CPU without any parallelism or low-level optimizations, and it still beat GNU wc. Fair enough about apples to oranges, but it was really distasteful to me that the top comment on this post was about how C is “unbeatable”, when the article clearly showed that Futhark was faster. And since we’re at the dawn of a new age of parallel computing, statements like that are absurd in general.
- mlyle 7y ago
  > In the linked post, the author tests Futhark running on the CPU without any parallelism or low-level optimizations, and it still beat GNU wc. Barely... It also mmaps in a whole 100 meg file. :P wc is not optimized to count as fast as possible, resource use be damned.
Athas 7y ago
You are right that it's interesting to compare Futhark-on-GPU with X-on-GPU for various values of X. In most of our academic work, that is what we do. However, in practice, X-on-GPU where X is not Futhark is rare, because GPU programming is notoriously difficult and time-consuming. Futhark's purpose is to make high-performance data-parallel programming more accessible, even if you could potentially write a faster program yourself. There are no empirical measurements that I know of, but I would not be surprised if it is a hundred times faster to write a Futhark program than the corresponding OpenCL program. CUDA fares a little better, but not by much. So even if your hand-written program might be twice as fast as Futhark, do you really have the time to write it in the first place? And if you later want to make a small change to its logic (say, adding another parallel loop on top), you may need to rework all of your optimisations from scratch.

Crinus 7y ago

Also for CPUs there is ispc (https://ispc.github.io/ https://ispc.github.io/) which provides a language that takes advantage of modern CPU's parallel friendly features with a C-like syntax. From the site: > ispc compiles a C-based SPMD programming language to run on the SIMD units of CPUs and the Intel Xeon Phi™ architecture; it frequently provides a 3x or more speedup on CPUs with 4-wide vector SSE units and 5x-6x on CPUs with 8-wide AVX vector units, without any of the difficulty of writing intrinsics code. Parallelization across multiple cores is also supported by ispc, making it possible to write programs that achieve performance improvement that scales by both number of cores and vector unit size. There is also an interesting story of its development (full with office politics drama :-P) written by its -then- main developer: https://pharr.org/matt/blog/2018/04/18/ispc-origins.html https://pharr.org/matt/blog/2018/04/18/ispc-origins.html

yiyus 7y ago

> For CPUs, I'd like to introduce you to my good friend Fortran. Fortran scares people because it is often identified with FORTRAN77. I find very unfortunate that the concept of F (a modern simplified Fortran without the legacy features [1]) never took off, although I understand the reasons. [1] https://www.fortran.com/F/index.html https://www.fortran.com/F/index.html