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

21–30 of 88 posts

Re: Beating C with Futhark Running on GPU

#21

Post by jacquesm »

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.

I don't think that's true. When I came of age in programming there were lots of choices already but none that offered the balance of control and speed that C gave. It was a very easy choice; do I invest my next two decades in Assembly, Pascal (in several flavors), Modula-2, Forth, LISP (which required unobtainable computers at the time), Basic (compiled or interpreted) or C?

UNIX had very little to do with it, only very few people were lucky enough to have access to UNIX machines but untold 100's of thousands had access to PCs or 8 bit micros. The first time I saw a UNIX machine it was an Acorn 'Unicorn' and it was so far ahead of what I could afford that it might as well not exist.

Re: Beating C with Futhark Running on GPU

#22

Post by glouwbug »

tom_mellior wrote: post #16
Athas wrote: 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

Most of -O3's performance is lost across translations units.

Compile and link with `-flto --march=native -O3` and you're good to go.

Re: Beating C with Futhark Running on GPU

#23

Post by pjmlp »

jacquesm wrote: post #18
pjmlp wrote: 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…

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…

The point being that generated code from C compilers being always the one to beat is an urban myth.

C compilers are only speed monsters thanks to almost 50 years of research in optimizing C and C++ compiler backends.

Re: Beating C with Futhark Running on GPU

#24

Post by jacquesm »

pjmlp wrote: post #23
jacquesm wrote: post #18

Earlier quoted context omitted.

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…

The point being that generated code from C compilers being always the one to beat is an urban myth. C compilers are only speed monsters thanks to almost 50 years of research in optimizing C and C++ compiler backends.

> The point being that generated code from C compilers being always the one to beat is an urban myth.

Ok.

> C compilers are only speed monsters thanks to almost 50 years of research in optimizing C and C++ compiler backends.

Lots of those optimizations apply in one form or another to other languages as well.

And... so which is it? Are C compilers fast and the thing to beat or did that research go nowhere?

C is the speed benchmark because 'beating C' is what will get you a foot in the door. Being 'slower than C' is going to get your pet language booted out the door because:

- companies tend to compete on speed of execution

- the speed of the compiler itself is a major factor in turnaround time for the typical edit-compile-test cycle

- nobody cares about security until they've been bitten hard.

This is all very frustrating but it seems to - in my experience - accurately reflect priorities in lots of corporations. It is up to us to change that.

See the title: it is about the speed of execution, and it uses one technology 'GPU' to challenge another 'CPU' and yet the accent is on which language was used.

Re: Beating C with Futhark Running on GPU

#25

Post by pjmlp »

jacquesm wrote: post #21
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.

I don't think that's true. When I came of age in programming there were lots of choices already but none that offered the balance of control and speed that C gave. It was a very easy choice; do I invest my next two decades in Assembly, Pascal (in several flavors), Modula-2, Forth, LISP (which required unobtainable computers at the time), Basic (compiled or interpreted) or C? UNIX had very little to do with it, only v…

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 and C++ support, PowerPlant C++ framework was the way to go.

Epoch, BeOS and Symbian were also C++ territory.

MS-DOS games were also adopting C++ via Watcom and its DOS extender.

UNIX and the rise of FOSS, based on UNIX culture, were definitely the only reason.

Re: Beating C with Futhark Running on GPU

#26

Post by popee »

_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.

C is Sparta! :-)

Re: Beating C with Futhark Running on GPU

#27

Post by reikonomusha »

_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’d call a language like Scheme simple. C—especially post ANSI—is veritably not simple.

Re: Beating C with Futhark Running on GPU

#28

Post by flohofwoe »

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 was (and still is) a fairly obvious choice for programming when you need full control over the memory layout of an application (which is becoming all the more important with the growing CPU/memory gap). I choose C 15 years before I got into contact with UNIX (first on the Amiga, after that on Windows, and only fairly recently macOS and Linux).

Re: Beating C with Futhark Running on GPU

#29

Post by flohofwoe »

pjmlp wrote: post #25
jacquesm wrote: post #21

Earlier quoted context omitted.

I don't think that's true. When I came of age in programming there were lots of choices already but none that offered the balance of control and speed that C gave. It was a very easy choice; do I invest my next two decades in Assembly, Pascal (in several flavors), Modula-2, Forth, LISP (which required unobtainable computers at the time), Basic (compiled or interpreted) or C? UNIX had very little to do with it, only v…

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).

Re: Beating C with Futhark Running on GPU

#30

Post by [deleted] »

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…

[deleted]
Post reply on HN