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

31–40 of 88 posts

Re: Beating C with Futhark Running on GPU

#31

Post by tom_mellior »

Athas wrote: post #20
tom_mellior wrote: post #16

Earlier quoted context omitted.

> 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 seq…

> GNU wc cannot do this in general because it's supposed to work on pipes as well

I used the "reference" source code linked from the original Haskell post, a BSD version hosted by Apple: https://opensource.apple.com/source/text_cmds/text_cmds-68/w...

It uses raw read() from a file descriptor and works with pipes as well. I think the only special handling for stdin vs. an actual file it has is calling fstat() if only the number of characters is requested, which shouldn't apply here.

So yes, this version does need to do more complicated I/O than a simple mmap(). And (broken record, but I'll stop after this) it's 2x as fast as my system's GNU wc (when compiled with -O3 vs. however the system wc was compiled).

> I had actually hoped Futhark would be slower sequentially

It might still turn out to be, if you see if you can get a faster C version of wc.

Re: Beating C with Futhark Running on GPU

#33

Post by shrubble »

_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

Re: Beating C with Futhark Running on GPU

#34

Post by YSFEJ4SWJUVU6 »

tom_mellior wrote: post #31
Athas wrote: post #20

Earlier quoted context omitted.

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 seq…

> GNU wc cannot do this in general because it's supposed to work on pipes as well I used the "reference" source code linked from the original Haskell post, a BSD version hosted by Apple: https://opensource.apple.com/source/text_cmds/text_cmds-68/w... It uses raw read() from a file descriptor and works with pipes as well. I think the only special handling for stdin vs. an actual file it has is calling fstat() if only…

>It might still turn out to be, if you see if you can get a faster C version of wc.

You definitely can, at least if you allow manually vectorized code.

On my system, with a 1.661GB file (256 times big.txt from the original Haskell post) GNU wc takes about 6.5s (real time), a stripped down version of Apple's implementation about 4.1s, and a single-threaded vectorized wc (written in C) only 0.27s. (These times are of course only with a hot cache. For reference, catting the same file to /dev/null takes about 0.18s.)

edit: corrected the time for the BSD-derived implementation

Re: Beating C with Futhark Running on GPU

#35

Post by raphlinus »

Monoid homomorphisms for the win. I discussed a very similar approach for computing the length of the longest line in a "rope science" article[1], as well as unquoting strings[2]. In this case, it was very nice to see actual code, and Futhark looks like a good language. For the string unescaping, I used Nvidia's Thrust, which is a templated C++ library; generally pretty similar to the Futhark code, and generally similar results.

[1]: https://xi-editor.io/docs/rope_science_01.html

[2]: https://raphlinus.github.io/personal/2018/04/25/gpu-unescapi...

Re: Beating C with Futhark Running on GPU

#36

Post by gridlockd »

OskarS wrote: post #10
_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.

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?

Re: Beating C with Futhark Running on GPU

#37

Post by namirez »

pjmlp wrote: post #17
dooglius wrote: post #12

Earlier quoted context omitted.

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.

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.

Re: Beating C with Futhark Running on GPU

#38

Post by Crinus »

OskarS wrote: post #10
_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.

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.

Also for CPUs there is ispc (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

Re: Beating C with Futhark Running on GPU

#39

Post by jstimpfle »

pjmlp wrote: post #17
dooglius wrote: post #12

Earlier quoted context omitted.

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.

It's funny, when I'm not on Unix, C is still my go to language which lets me get shit done. I won't have to deal with performance problems or painful FFIs. Yesterday I was dealing with Webassembly, and having it interoperate with WebGL made me pull out the last few hairs I still had on my head. Go figure.

Re: Beating C with Futhark Running on GPU

#40

Post by jsd1982 »

One could easily amortize the startup cost by putting the backend logic into a background service where it only starts up once and continues running. A frontend program like `wc` would just forward requests to the backend service.
Post reply on HN