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

41–50 of 88 posts

Re: Beating C with Futhark Running on GPU

#41

Post by gmueckl »

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.

I'm not sure that this high level assembler assumption still holds for SIMD-capable CPUs. C compilers are asked to do quite drastic code transformations like autovectorization on these architectures. With these, the tight relationship between the high level code C code and the generated machine code is removed.

Re: Beating C with Futhark Running on GPU

#42

Post by gilmi »

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?

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

Re: Beating C with Futhark Running on GPU

#43

Post by penagwin »

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?

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.

Re: Beating C with Futhark Running on GPU

#44

Post by zabzonk »

flohofwoe wrote: post #29
pjmlp wrote: post #25

Earlier quoted context omitted.

Sure it was, there were zero reasons to use C on CP/M, MS-DOS, Atari, Amiga, Mac. It was just another programming language fighting for developer eyes. On Windows and OS/2, although IBM and Microsoft decided to go with C for the underlying low level layers, C++ was the way to go for high level coding, C Set++, MFC. With Borland having Turbo Vision, OWL and VCL. Macs were Object Pascal territory, and when MPW got C an…

IME C++ wasn't really a mainstream option until the second half of the 90's. BeOS choosing C++ for its operating system APIs was an extremely exotic choice at the time (same level of "exotic" as NeXT choosing Objective-C). And IMHO, at that time, before or around C++98, C++ didn't fix a single problem of C, but instead just added a lot of new ones (one could argue that this is still the case even today).

> IME C++ wasn't really a mainstream option until the second half of the 90's

I was getting paid for teaching C++ on commercial training courses in 1990 - the C++ courses were probably the most popular after C and UNIX

> before or around C++98, C++ didn't fix a single problem of C

Of course it did, or why would people like me have transferred wholesale from C to C++?

Re: Beating C with Futhark Running on GPU

#45

Post by gridlockd »

gilmi wrote: post #42
gridlockd wrote: post #36

Earlier quoted context omitted.

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?

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.

Re: Beating C with Futhark Running on GPU

#46

Post by megous »

gmueckl wrote: post #41
namirez wrote: post #37

Earlier quoted context omitted.

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.

I'm not sure that this high level assembler assumption still holds for SIMD-capable CPUs. C compilers are asked to do quite drastic code transformations like autovectorization on these architectures. With these, the tight relationship between the high level code C code and the generated machine code is removed.

You can still treat it that way even with SIMD. I quite enjoy using NEON (ARM SIMD) intrinsics in C, and the like.

Re: Beating C with Futhark Running on GPU

#47

Post by e12e »

> Word counting is primarily IO-bound, and it is much too expensive to ferry the file contents all the way to the GPU over the (relatively) slow PCI Express bus just to do a relatively meagre amount of computation.

After seeing that it's possible to play crysis using software rendering on an AMD Rome cpu with 128 hw threads [1] - might this lead to some vindication for AMD sticking with opencl (assuming exposing such a cpu via opencl) - or is it just simpler to ignore that (in general and for futark) and just use regular threads for parallelizing aacross many cpu cores?

[1] https://news.ycombinator.com/item?id=21339652

Re: Beating C with Futhark Running on GPU

#48

Post by megous »

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…

My experience is that memory mapping the file is not faster than reading it in big chunks into an already mapped, pre-allocated buffer.

You're going to be intially page faulting every 4096 bytes if you mmap the file. The fact that you're accessing the mapped range sequentially in this case may help, I guess.

Re: Beating C with Futhark Running on GPU

#49

Post by yiyus »

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.

> 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

Post reply on HN