Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beating C with Futhark Running on GPU

futhark-lang.org

Post reply on HN
Print view View original

61–70 of 88 posts

Re: Beating C with Futhark Running on GPU

#61

Post by Athas »

mjaniczek wrote: post #56
Herrin wrote: post #51

I found this more readable and understandable than the Haskell post, although I can't quite say why. It might simply be the repetition. I'm really interested in Futhark, though I haven't found a project where it would be make sense to use it. But I feel like it has the same potential to make GPU programming not feel overwhelming the same way Elm did with frontend work for me.

Since Futhark has sum types, I wonder whether we could transpile Elm syntax to Futhark. I'll have to dig into what's possible with Futhark and how well it would map...

The biggest problem would be the absence of recursion, but a recursion-free subset of Elm (with a different standard library) would be straightforward.

Re: Beating C with Futhark Running on GPU

#62

Post by Athas »

gridlockd wrote: post #45
gilmi wrote: post #42

Earlier quoted context omitted.

https://futhark-lang.org/performance.html

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.

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

Re: Beating C with Futhark Running on GPU

#63

Post by Athas »

gridlockd wrote: post #36
OskarS wrote: post #10

Earlier quoted context omitted.

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.

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?

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.

Re: Beating C with Futhark Running on GPU

#64

Post by com »

shrubble wrote: post #33
_wldu wrote: post #3

C is the Mike Tyson of programming languages. There will never be another like it. It's simple, dangerous and fast. You can't beat C, but everyone will keep trying. It may beat itself in the end though as it's too rough for the modern world.

Both lovers of C and its detractors should read the Turing award speech of Tony Hoare http://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf

I found this an interesting and illuminating read, partially for how some of the basic concerns that we have for language tools like compilers were imagined into being and later internalised by us all, but also for the “fear and horror” around bounds checks.

Re: Beating C with Futhark Running on GPU

#67

Post by earth_walker »

mjaniczek wrote: post #56
Herrin wrote: post #51

I found this more readable and understandable than the Haskell post, although I can't quite say why. It might simply be the repetition. I'm really interested in Futhark, though I haven't found a project where it would be make sense to use it. But I feel like it has the same potential to make GPU programming not feel overwhelming the same way Elm did with frontend work for me.

Since Futhark has sum types, I wonder whether we could transpile Elm syntax to Futhark. I'll have to dig into what's possible with Futhark and how well it would map...

James Carson gave a talk at this year's Elm Conf on using Elm to talk to Futhark:

https://www.youtube.com/watch?v=FVP8zxpZKV8

Re: Beating C with Futhark Running on GPU

#68

Post by nickpsecurity »

namirez wrote: post #37
pjmlp wrote: post #17

Earlier quoted context omitted.

The same reason people got to choose JavaScript or PHP years later, the platform's adoption, in this case UNIX.

C is not a fad; it's an outlier among languages in the sense that basically it's a portable assembler very close to the metal. If you change the basic architecture of the machine, you can create a better language. For now however it's unlikely to beat C.

They did change the architecture of the machine. C didn't have concurrency and SIMD built-in.

Re: Beating C with Futhark Running on GPU

#69

Post by hellofunk »

A lot of the Futhark demos you see are rather basic algorithms like matrix multiplication, and the documentation for Futhark does say that it is not well-suited to complex kernels, so that to me puts a big limiting factor on how useful it could be to invest in it.

I really like technologies like this and Sycl which aim to greatly simplify the process of writing GPU code. The important thing is that it can handle what you'd throw at it as if you were writing directly in Metal, Cuda, OpenCL, and I don't think that is the case (yet?) with Futhark.

Re: Beating C with Futhark Running on GPU

#70

Post by Athas »

hellofunk wrote: post #69

A lot of the Futhark demos you see are rather basic algorithms like matrix multiplication, and the documentation for Futhark does say that it is not well-suited to complex kernels, so that to me puts a big limiting factor on how useful it could be to invest in it. I really like technologies like this and Sycl which aim to greatly simplify the process of writing GPU code. The important thing is that it can handle what…

It depends on what you consider a "complex kernel". Futhark is only for regular non-recursive data parallelism, but I'll argue that something like a genetic algorithm that does calibration of market parameters in the Heston model[0] is pretty complex. It comprises multiple levels of parallelism and several kernels (last I checked, the core work is done in four kernels which are invoked in a loop).

But more importably, this benchmark is written as a composition of two reusable parts (a genetic algorithm that is parametric in its objective function, and a specific objective function that does option pricing) that are then put together in an efficient and automatic way by the compiler. You literally could not write it this way in OpenCL or CUDA (modulo extreme amounts of template metaprogramming in the latter). While you could certainly write a specialised GPU program that did exactly this calibration, and probably outperform Futhark, you would not be able to structure it as reusable components without significant performance loss. This, I think, is the main advantage of using a high-level language together with an optimising compiler.

[0]: https://github.com/diku-dk/futhark-benchmarks/tree/master/mi...

Post reply on HN