Live data from Hacker News

Beating C with Futhark Running on GPU

futhark-lang.org

11–20 of 88 posts

Re: Beating C with Futhark Running on GPU

#11

I'm starting to sound like a broken record on this, but if you're going to compare to your system wc without trying to figure out if it was compiled with -O3 [EDIT: and what source code it was compiled from], you haven't shown anything in the sequential case. What this article does show is that Futhark really does allow one to express this in a much simpler way than Haskell.

That's a good point, but the -O3 doesn't actually do a whole lot here. I recompiled the Futhark-generated C code with just -O and performance was unchanged. If you look at the generated C code, there isn't really a lot to do either: https://gist.github.com/athas/7c8ffc2620a9406e4bbb0df89f2fc9...

I hope I can assume that RHEL compiles their wc with at least -O.

Re: Beating C with Futhark Running on GPU

#12
post #5
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.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a…

I wonder if Allen considered that there might be a reason people chose to use C, it's not as if they were forced into it. "Something where experts can really fine-tune without big bottlenecks" is not a requirement specific to operating systems. It's a bit ironic to think that the inability to run fancy optimizations is considered a problem with C when one of the most widely recognized flaws in the C ecosystem is the way mainstream compilers will exploit behavior that was labeled "undefined" just to support old obscure architectures, to run all kinds of crazy transformations.

Re: Beating C with Futhark Running on GPU

#13
post #2

Very honest discussion of the results. I liked it. Would it be possible to use Futhark to rewrite the APL implementation instead of the Haskell one? That would make an interesting comparison.

> Would it be possible to use Futhark to rewrite the APL implementation instead of the Haskell one? That would make an interesting comparison.

Sadly, from what I can see, the APL version makes use of so-called nested arrays in the 'words' function, specifically arrays of strings (this is different from multidimensional arrays). Futhark does not directly support nested arrays. A rewrite of the APL implementation would require using a quite different algorithm (or a nontrivial encoding).

But my APL is a bit rusty, so I may be wrong.

Re: Beating C with Futhark Running on GPU

#14

I'm starting to sound like a broken record on this, but if you're going to compare to your system wc without trying to figure out if it was compiled with -O3 [EDIT: and what source code it was compiled from], you haven't shown anything in the sequential case. What this article does show is that Futhark really does allow one to express this in a much simpler way than Haskell.

Fair enough, but I'm honestly really enjoying this little round of programming language bragging. It's fun to see these smallish (well, Haskell is pretty big) languages all duke it out over how to solve this problem. Like: yeah, nobody's ACTUALLY going to replace their system wc with these implementations, but the articles themselves are nevertheless very fun. A very clever little case study!

Re: Beating C with Futhark Running on GPU

#16
post #11

I'm starting to sound like a broken record on this, but if you're going to compare to your system wc without trying to figure out if it was compiled with -O3 [EDIT: and what source code it was compiled from], you haven't shown anything in the sequential case. What this article does show is that Futhark really does allow one to express this in a much simpler way than Haskell.

That's a good point, but the -O3 doesn't actually do a whole lot here. I recompiled the Futhark-generated C code with just -O and performance was unchanged. If you look at the generated C code, there isn't really a lot to do either: https://gist.github.com/athas/7c8ffc2620a9406e4bbb0df89f2fc9... I hope I can assume that RHEL compiles their wc with at least -O.

> That's a good point, but the -O3 doesn't actually do a whole lot here.

True, maybe it's not about -O3 but about some factor in the unknown source code of the system wc. I did compile one version of wc with -O3 and it beat my system wc (Ubuntu) by 2x: https://news.ycombinator.com/item?id=21271951

Re: Beating C with Futhark Running on GPU

#17
post #5

Earlier quoted context omitted.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a…

I wonder if Allen considered that there might be a reason people chose to use C, it's not as if they were forced into it. "Something where experts can really fine-tune without big bottlenecks" is not a requirement specific to operating systems. It's a bit ironic to think that the inability to run fancy optimizations is considered a problem with C when one of the most widely recognized flaws in the C ecosystem is the…

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

Re: Beating C with Futhark Running on GPU

#18
post #5
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.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a…

That's a nice quote but it is also a bit nonsensical in that there has been plenty of work on optimizing compilers, also for C/C++ and a whole bunch of other languages.

That quote was true for some time but running into the limits of CPU clock gains for single threaded tasks all those optimizations are more than valid once more, and as you've no doubt noticed there is a veritable run on multi-core solutions embedded deeply in the languages, of which this article illustrates one special case using a co-processor.

Re: Beating C with Futhark Running on GPU

#19
post #8

Earlier quoted context omitted.

Which university? :)

Chalmers University of Technology, in Gothenburg. Though Futhark is developed in Copenhagen I think. We had a guest lecture with one of the developers of the language. Was a really interesting lecture together with some exercise for us to play with the Lang. Though it has gotten even better since then from what I've seen in their blog.

I wonder if this language has spread beyond Europe yet. Do any Americans use it?

Re: Beating C with Futhark Running on GPU

#20
post #11

Earlier quoted context omitted.

That's a good point, but the -O3 doesn't actually do a whole lot here. I recompiled the Futhark-generated C code with just -O and performance was unchanged. If you look at the generated C code, there isn't really a lot to do either: https://gist.github.com/athas/7c8ffc2620a9406e4bbb0df89f2fc9... I hope I can assume that RHEL compiles their wc with at least -O.

> That's a good point, but the -O3 doesn't actually do a whole lot here. True, maybe it's not about -O3 but about some factor in the unknown source code of the system wc. I did compile one version of wc with -O3 and it beat my system wc (Ubuntu) by 2x: https://news.ycombinator.com/item?id=21271951

Honestly, I would expect the main reason my wc is faster is that mmap()ing the file and then reading it in a huge chunk is about as fast as the kernel's IO can go. GNU wc cannot do this in general because it's supposed to work on pipes as well, and I doubt anyone cared enough about the tiny performance difference to exploit the case where the input file is mmap()able.

(I had actually hoped Futhark would be slower sequentially, just so this wouldn't be the focus of the discussion!)

Post reply on HN