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

Defending GCC considered futile

lists.gnu.org

Post reply on HN
Print view View original

21–30 of 209 posts

Re: Defending GCC considered futile

#21

Post by Tomte »

rayiner wrote: post #18
lultimouomo wrote: post #3

ESR seems a bit over the line with this mail, but what never ceases to amaze me is how RMS is disconnected with the present technology: >From its name, I guess that LLDB is a noncopylefted debugger and that some might intend it to replace GDB. But I don't know if that is so. This is just one of many, in the recent arguments he has stated several times that he doesn't understand how automated code refactoring works, h…

We're talking about a C compiler and debugger. Lots of very technically knowledgable people shun IDEs and automated refactoring in that space.

Sure, that's a valid choice.

But when you're implementing a language ecosystem, proud ignorance of other peoples' usage patterns is just embarassing.

Re: Defending GCC considered futile

#22

Post by gcp »

zanny wrote: post #11

So this was a discussion in /r/linux last week about LLVM and GCC et al, so I'm just reposting my statements on why a world where GCC is irrelevant is bad: It takes little effort on Apples or Googles or Microsofts part to take advantage of an LLVM dominated world to close off their own changes to it and try to force developers to use their own proprietary LLVM distributions on their own operating systems. It stops ev…

One of the big advantages of LLVM's license in this regard is that, unlike GCC, you don't risk leaking patents either even if you did open source it. Or did they fix that now?

Re: Defending GCC considered futile

#23

Post by sanxiyn »

This is a bit over the top. As the rest of the thread points out, GCC in general still generates faster code than LLVM.

"What does it take to get LLVM as performant as GCC" talk from 2014 LLVM Developers' Meeting discusses details.

http://llvm.org/devmtg/2014-10/Slides/Molloy-LLVM-Performant...

"GCC versus LLVM performance analysis reveals the LLVM inliner 1) does not inline certain hot functions unless a high threshold is provided at -O3 2) produces larger and slower code at -Os."

The problem of LLVM inliner has been known for a long time. One of the best discussion is "Optimization in LLVM" talk from 2013 European LLVM Conference.

http://www.irill.org/videos/euro-llvm-2013/carruth-hires

Re: Defending GCC considered futile

#24

Post by weenie »

lultimouomo wrote: post #3

ESR seems a bit over the line with this mail, but what never ceases to amaze me is how RMS is disconnected with the present technology: >From its name, I guess that LLDB is a noncopylefted debugger and that some might intend it to replace GDB. But I don't know if that is so. This is just one of many, in the recent arguments he has stated several times that he doesn't understand how automated code refactoring works, h…

You have to realize that RMS's goal isn't to "steer important projects", and you should give him more credit in that he probably could be "connected with the present technology" if he wanted to.

The fact that "he doesn't know enough anymore" doesn't say much about Stallman; instead it says a lot about how his goal of making sure software is libre has been shoved aside by everyone else for other priorities.

Also, RMS is one of the most humble people on the scene, and will freely admit to not knowing something until he lives and breathes it.

Re: Defending GCC considered futile

#25

Post by coldtea »

rayiner wrote: post #18
lultimouomo wrote: post #3

ESR seems a bit over the line with this mail, but what never ceases to amaze me is how RMS is disconnected with the present technology: >From its name, I guess that LLDB is a noncopylefted debugger and that some might intend it to replace GDB. But I don't know if that is so. This is just one of many, in the recent arguments he has stated several times that he doesn't understand how automated code refactoring works, h…

We're talking about a C compiler and debugger. Lots of very technically knowledgable people shun IDEs and automated refactoring in that space.

Not that many.

Except if Windows C++ developers (most of which use VS) don't qualify as "technically knowledgable people".

And who is doing the judging?

Re: Defending GCC considered futile

#26

Post by dragonwriter »

neindanke wrote: post #8
vezzy-fnord wrote: post #5

This is pretty much the perfect moment for two egos like RMS and ESR to clash. RMS is already getting a lot of flak for expressing his fear of GCC being displaced in such a manner, whereas ESR is well known for his disliking RMS, to put it mildly.

It is not clear that RMS is driven by ego. He's motivated by a very clear goal to keep free software free. Free as in freedom free. As for ESR, well, yup, that's an ego that is sufficient in size to have a gravitational pull. http://www.linuxtoday.com/infrastructure/2000082800620OPCYKN

> It is not clear that RMS is driven by ego. He's motivated by a very clear goal to keep free software free.

No, he's driven by a very clear goal to prevent non-free software, even if that means preventing free software that might, potentially, in the future, be used by someone, somewhere, to create non-free software.

And I think there is a certain amount of ego in there that gets in the way of good judgement on means, in that he tends to take actions which will naturally result in the free software he protects from being involved in producing non-free software losing mindshare to either non-free software or free software not wrapped around with his preferred restrictions, which is contradictory to his purpose -- since it means that not only does software that isn't crippled in features to prevent its utility in contributing non-free software wins, but that that software is also itself either non-free software, or non-copyleft free software that can more readily directly contribute to non-free software as well as being used by people who might build non-free software through use of the features of the software.

Re: Defending GCC considered futile

#27

Post by hga »

weenie wrote: post #24
lultimouomo wrote: post #3

ESR seems a bit over the line with this mail, but what never ceases to amaze me is how RMS is disconnected with the present technology: >From its name, I guess that LLDB is a noncopylefted debugger and that some might intend it to replace GDB. But I don't know if that is so. This is just one of many, in the recent arguments he has stated several times that he doesn't understand how automated code refactoring works, h…

You have to realize that RMS's goal isn't to "steer important projects", and you should give him more credit in that he probably could be "connected with the present technology" if he wanted to. The fact that "he doesn't know enough anymore" doesn't say much about Stallman; instead it says a lot about how his goal of making sure software is libre has been shoved aside by everyone else for other priorities. Also, RMS…

"You have to realize that RMS's goal isn't to 'steer important projects'"

Not as such, but as long as he's doing it for so many marque GNU/FSF projects....

Re: Defending GCC considered futile

#28

Post by Tomte »

michaelhoffman wrote: post #4

Thankfully, Emacs maintainer Stefan Monnier is being sensible about this: > As mentioned earlier, in any case I will happily accept and install LLDB support into gud.el. So as long as I'm Emacs maintainer, your opinion on whether this might ruin the FSF's goals are not relevant. https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...

I had never expected RMS to let go of his child, but the moment he handed over maintainership of Emacs was really a new starting point. A lot of bickering just went away, and pragmatism played at least some role from then on.

(Obviously not at any cost, he chose his successor(s) very well, so they are trusted and are committed to Free Software)

In the linked thread RMS is a bit detached from reality, IMO, but still very reasonable. In the other thread where this whole LLDB drama started he was simply obnoxious and a bully, even insulting and driving out a contributor.

Re: Defending GCC considered futile

#29

Post by jeremiep »

rayiner wrote: post #18
lultimouomo wrote: post #3

ESR seems a bit over the line with this mail, but what never ceases to amaze me is how RMS is disconnected with the present technology: >From its name, I guess that LLDB is a noncopylefted debugger and that some might intend it to replace GDB. But I don't know if that is so. This is just one of many, in the recent arguments he has stated several times that he doesn't understand how automated code refactoring works, h…

We're talking about a C compiler and debugger. Lots of very technically knowledgable people shun IDEs and automated refactoring in that space.

The SDK I'm working with at the moment has been entirely coded in VIM and is the only layer between our code and the hardware.

The fact that ESR doesn't use an IDE or automated refactoring is perfectly normal. It's those not able to work without using these tools who scare me.

Re: Defending GCC considered futile

#30

Post by ykl »

gcp wrote: post #15
hywel wrote: post #6

> Already my own experiments suggest that LLVM is a superior compiler, by every metric I know of Except that it isn't copyleft, which is one of the most important metrics to Stallman, FSF et al, and is why they're unlikely to stop defending it.

If clang/LLVM caught up in generated code performance to GCC then I must admit that is news to me.

Since clang 3.5 (or possibly even earlier), clang has basically been neck-in-neck with GCC. Most benchmarks seem to show the two basically equal to each other, and then there's a handful where clang wins outright and a handful where GCC wins outright. [1]

For my own use-case (a high-performance photorealistic renderer threaded using TBB), my clang builds outperform my gcc builds, but of course that's completely anecdotal and based on just my own use-case.

[1] http://www.phoronix.com/scan.php?page=article&item=gcc49_com...

Post reply on HN