Comment by smabie | Hacker News Reader

Comment by smabie | Hacker News Reader

Honest question: what value does GCC have in 2020? It seems like llvm is the better designed compiler, more commercial support, more permissive license, etc. Pretty much everyone designing new languages today is using LLVM for backend codegen; and the people who aren't sure as hell are not using GCC.

GCC has the same value that LLVM had when it was first released: healthy competition for the market leader. The need to compete with LLVM was the best thing that ever happened to the GCC project. A world with only LLVM could easily lead back to a stagnant monoculture.

Therefore, it's in everyone's selfish interest to promote and use both toolchains.

See also:

- firefox and chrome

- ios and android

- mysql and postgres

- AMD and Intel

- C# and Java

More generally of course, healthy competition is good. There are more than 2 serious Java IDEs, for instance.

A few things off the top of my head, influenced by both trying to build Rust code for the Linux kernel as a hobby and maintaining compilers in my day job:

- GCC still supports more architectures/platforms than LLVM does. Apart from various rare/obscure/embedded platforms, one notable one (I think) is x86-16: .code16gcc pretty much works, LLVM only kinda supports it.

- GCC has its own plugin interface. If you already have GCC plugins, you probably want to stick with GCC.

- If you have a large legacy codebase that's probably got some UB somewhere because that's the nature of having large codebases written by fallible humans, it's probably less likely that a new versions of the same compiler will misinterpret your intentions than a new compiler would. (But this is a weak argument, since new versions could still change their interpretation/behavior.)

I think GCC often still outperforms LLVM for many people's workloads. Not sure why that is - haven't we gotten to the point where any missing optimisations can just be added to LLVM? Are some optimisations very hard to add given LLVM's architecture? There must be enough people and companies working on it by now to fix anything?

But if you're really serious about performance presumably you're using Intel.

> But if you're really serious about performance presumably you're using Intel.

Or a GPU?

We (as an industry) just don't know how to put some programs onto the GPU yet.

Agreed, true!

Or an FPGA or an ASIC, but this is obviously.in the context of CPUs.

How's LLVM's code coverage performance?

Starting with GCC 9, you can stream gcov straight to stdout in json format, which allowed me to write a multi-core coverage aggregation/analysis tool[1] to replace lcov (and is over 100x faster than lcov, in my case - ymmv):

[1] https://github.com/RPGillespie6/fastcov

Aaaah if only I could do this to a runtime defined fd or pipe... Live coverage information! Have to use Intel PT for this but sometimes feels like a big hammer :-)

At the very least GCC is keeping llvm permissively licensed.

llvm is partly a product of Apple's dislike of copyleft licenses. Without gcc there is no reason for llvm's large proprietary contributors to stick to the "more permissive license" and simply close it down and distribute it as "value added" binaries.

Competition and less permissive license (the license kind of ensures gcc can not be 'closed' and therefore ensure that llvm's license stays 'more permissive').

It's still the "de facto" compiler on most flavors of Linux and still tends to produce faster binaries in practice than Clang. That gap, however, continues to narrow.

I always viewed Clang as faster, and perceived GCC as catching up.

Clang has faster compilation, but (depending on the actual case) optimized binary built by gcc run faster; as mentioned above, both gaps are narrowing.

As of May 2019, Phoronix showed them being roughly equal, with the winner depending on the application. https://www.phoronix.com/scan.php?page=article&item=gcc9-cla...

We should expect them to both continue to improve. It's not a sure thing that Clang will end up the clear winner.

The perception of Apple's Midas Touch has never been dependent on banal things like objective comparisons.

GCC is bad for anything related to big integer arithmetic or cryptography unfortunately. Something like 20 to 40% slower than Clang.

Example of GCC awful codegen on add with carry: https://gcc.godbolt.org/z/2h768y

Right now, or last I checked, GCC supports more architectures. So while I realize that the Intel/ARM monoculture (or duoculture?) plus occasional emergence of things like risc-v will continue to absorb the world's new devices, there will probably be niche uses of GCC to target obscure hardware for a long time.

I use it because it outperforms both Intel and Clang on my code by significant margin. Open MP support in Clang on Windows comes and goes and no one cares (I don't blame them, it's a niche use case but still). I don't see any reason to switch tbh. GCC does the job, is around for much longer, supports more stuff and generates more efficient code (at least in my case).

Here's a key paragraph from Anandtech's recent article on ARM in AWS:

> Overall, I checked three different compiler setups: A freshly compiled GCC 9.2.0 release, Arm’s Allinea Studio Compiler 20 package which comes with both Arm’s closed source LLVM and Flang variants as well as a pre-compiled version of GCC 9.2.0, and Marvell’s branch of LLVM and Flang.

Note the phrases "ARM's closed source LLVM" and "Marvell's branch of LLVM". That's why GCC is still critical. Because LLVM is already suffering from the fragmentation and proprietary forks that BSD has always suffered from.

I'm having trouble finding whether this is still true, but for a long time gcc was the only supported option for building Linux (the kernel). I know there's been work to make it build with clang, but it at least used to be that you needed some patches.

That isn’t true anymore, not even for x86_64 (https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNote...)

Oh, excellent:) Thanks for sharing an official source for that.

> more permissive license

Not everyone favors a more permissive license.

There's permissive and then there's exploitable. People who benefit (financially) from being able use other people's work without contributing their own changes would prefer us to call it "permissive" instead of "exploitive".

It's sad that the movement which originally democratized computing (by placing development tools into the hands of ordinary users) is slowly being changed into a pyramid scheme that fleeces volunteers.

So, to echo other comments in this thread; GCC keeps the corporate BSD crowd honest, and postpones the day when they lock up their code.

It produces faster binaries than clang, sometimes significantly so.

ICC produces faster binaries than GCC, but ICC is expensive and GCC is free.

MSVC is garbage.

Desktop and Game developers happen to share a different opinion.

Does ICC have any traction in the gaming world?

It does on Windows shops that care about the ultimate performance optimization on Intel CPUs and vtune integration.

Doesn't that describe all high-budget games?

Would the average Unreal-based game be built with ICC?

Depends on the studio. Here is an overview and some testimonials,

https://software.intel.com/en-us/gamedev/tools

At a glance it seems the answer is No.

Unreal Engine 4 doesn't officially support icc, for instance. Neither does the Source Engine. I believe the same goes for CryEngine.

Going back to my initial reply, I did not say that everyone was using ICC, rather that desktop and game developers did not share the same opinion regarding ICC and Visual C++.

Specially given the lack of tooling that is only matched by C++ Builder, although I did not refer this point on my original reply.

So if you are reducing the world to just what Unreal, Source and CryEngine officially support, I wonder how many AAA games have been released on Windows using GCC or clang with those engines.

> I did not say that everyone was using ICC, rather that desktop and game developers did not share the same opinion regarding ICC and Visual C++

Yes, sure. MSVC is garbage clearly isn't right.

I presume (in the absence of any real data of course) that ICC doesn't result in significant performance advantages over MSVC, for games, or it would have been worth these developer's time to support it.

> if you are reducing the world to just what Unreal, Source and CryEngine officially support

It's a reduction sure enough, but I think that's a reasonable set of engines to consider.

> I wonder how many AAA games have been released on Windows using GCC or clang with those engines

I imagine it's none.

According to the (quite possibly stale) official wiki, Source does not support Clang, and only supports GCC for building Linux dedicated servers. [0]

It looks like Unreal Engine supports Clang for Linux builds [1], but for Windows it seems they really only support MSVC, although Clang can be made to work [2][3]

CryEngine supports Clang for Linux builds [4], but not for Windows where it seems to be MSVC-only [5][6]

[0] https://developer.valvesoftware.com/wiki/Compiler_Choices

[1] https://wiki.unrealengine.com/Compiling_For_Linux

[2] https://docs.unrealengine.com/en-US/Programming/Development/...

[3] https://forums.unrealengine.com/development-discussion/engin...

[4] https://docs.cryengine.com/display/SDKDOC4/CRYENGINE+on+Linu...

[5] https://github.com/CRYTEK/CRYENGINE/issues/381

[6] https://docs.cryengine.com/display/CEPROG/Building+the+Engin...

Reply on news.ycombinator.com