GCC 5 Is Compiling Faster, But Still Falls Short Of Clang

[Michael_S]

you can force your views on your project or organization. language has nothing to do with it.

Someone can force their views on their project or organization. They can't force their views on the entire ecosystem. That's fine when you write your entire stack in-house, but as soon as you pull in third party code you still have a problem.

With Go and Python, you can grab open source code from anywhere and use snippets, hook into libraries, and so forth with the same idioms you'll have in your in-house or in-project code. And if your project is open source, other people in the same ecosystem can grab it and use it just as easily. I'd say that's essential reason that Python, which by most metrics is a pretty unremarkable language, is so popular.

Even the Perl community has come to recognize the value of having a smaller number of coding coventions: the complete language redesign for Perl6 - which admittedly may never get off the ground - abandons the famous Perl TIMTOWTDI motto ("There Is More Than One Way To Do It") because of this exact problem with Perl 5. Now again, Perl6 does not, as far as I know, have a full implementation or much adoption. But I think that's due to other problems, not the move towards fewer syntactic oddities than Perl 5.

[pal666]

I completely disagree. The awesome thing about Python's syntax rules is that it makes reading almost anybody's Python a simple thing to do.

Look at Perl and C++. Both are awesome languages. Both have tons of features. Both can do an incredible amount of things. Both can be written in clean, clear, easy-to-read ways. But to work professionally with Perl or C++, you have to be prepared to deal with outrageous abuses of Perl's implicit variables and syntax quirks and insane uses of the C++ preprocessor and a hundred other combinations of bizarre code.

Forcing one convention in a development language might be limiting for each individual but it's better for the community.

you can force your views on your project or organization. language has nothing to do with it.

[Michael_S]

I count "where to put the brace" as part of indent style, though maybe I should have said "GNU coding style" instead. Any language where the FAQ and interviews clearly show the designers' attitude to be "because fuck you, that's why" is a bad language. Compare with Stroustrup: "I felt I don't have the right to force my views on the developers". That right there is a huge, huge difference.

Incidentally, that is also why I hate Python.

I completely disagree. The awesome thing about Python's syntax rules is that it makes reading almost anybody's Python a simple thing to do.

Look at Perl and C++. Both are awesome languages. Both have tons of features. Both can do an incredible amount of things. Both can be written in clean, clear, easy-to-read ways. But to work professionally with Perl or C++, you have to be prepared to deal with outrageous abuses of Perl's implicit variables and syntax quirks and insane uses of the C++ preprocessor and a hundred other combinations of bizarre code.

Forcing one convention in a development language might be limiting for each individual but it's better for the community.

[curaga]

I count "where to put the brace" as part of indent style, though maybe I should have said "GNU coding style" instead. Any language where the FAQ and interviews clearly show the designers' attitude to be "because fuck you, that's why" is a bad language. Compare with Stroustrup: "I felt I don't have the right to force my views on the developers". That right there is a huge, huge difference.

Incidentally, that is also why I hate Python.

[Zan Lynx]

Go certainly compiles fast, but that evens out in developer convenience because writing it is a PITA. Imagine writing C++ where the compiler would only let it build if you used the GNU indent style.

Go doesn't care about the indent style. You may be thinking about some of the requirements it has because it doesn't use semicolons to end statements. It does need to know where the line ends and for that it requires that braces, commas, quotes, etc, be in the correct positions. This is no different than Python, but unlike Python you can indent however you want and use tabs or spaces in any combination.

Go does have an official indent style and if you run "go fmt" it will rewrite your code into the official style. I appreciate this because it ends forever any arguments about where to put the braces and how many spaces code should have. Just run "go fmt" and the argument is over.

So GCC is useless for development... But really... GCC is not THAT much faster than clang. Just a litte if you compile for one CPU...

I don't deny. I am aware Clang/LLVM has some advantages over GCC.

[Michael_S]

Go certainly compiles fast, but that evens out in developer convenience because writing it is a PITA. Imagine writing C++ where the compiler would only let it build if you used the GNU indent style.

I haven't used Go in anger. I only played with D, but so far I like it a lot.

[curaga]

Go certainly compiles fast, but that evens out in developer convenience because writing it is a PITA. Imagine writing C++ where the compiler would only let it build if you used the GNU indent style.

[Michael_S]

And honestly, it doesn't matter what project I'm working on, or even the language I'm doing it in. When trying to develop software that requires iterating repeatedly through the compile/deploy/test process, you ALWAYS want a faster compiler. Faster built binaries is nice when you want to send something to a user/customer, but until then, speed of compilation is always more important than the performance of the produced binaries. Really.

I do this 40+ hours a week during my day job, and then some more for fun in the evenings, and that's one of the major lessons that I learned very early on. Time is money, and a developer having to wait on a compile to finish is a waste of both.

This is the selling point of Google's Go language and Walter Bright's D language - they're in the same family as C or C++, but they both compile substantially faster. Of course, Go has garbage collection so if you need manual memory management it won't work. D has garbage collection by default but you can use malloc and free if you want. Right now the D standard library uses garbage collection, but the main language designers are exploring changing that so that you can switch between garbage collection and manual memory management as you wish for the standard libary.

I don't know how Rust fares on compilation speed.

... of course, none of this is useful to you if you've got a colossal existing codebase in C or C++.

[Veerappan]

don't enable optimizations during development ffs

stop using macos then. linuxes have modern gcc versions, which have better error reporting and better intergation with their dev environment

Stop using MacOS? What does that have to do with my use case?

For the people who are saying, "Don't use optimizations", I just ran a full rebuild of LLVM using both GCC (4.9.1) and Clang (3.6svn)... Guess what, not only does GCC get faster without optimizations, but SO DOES LLVM.

Un-optimized Configuration: CFLAGS=-O0 ../llvm/configure --enable-assertions=no --with-python=/usr/bin/python2 --enable-shared --enable-targets=x86,r600 --prefix=/usr/local --with-optimize-option=-O0

Followed by: time CFLAGS=-O0 make -j6

And then I did one with the default optimization level. Note: These are with debug symbols/assertions in the build binaries DISABLED. The compile times get proportionally longer with those enabled.

LLVM/Clang 3.6svn	-O0	Default Optimization Level
real	10m36.558s	13m36.660s
user	54m21.323s	68m40.130s
sys	2m39.728s	3m58.685s
GCC 4.9.1
real	16m40.785s	20m36.600
user	86m35.194s	104m15.452
sys	6m10.038s	8m7.835s

So 10m32s for an -O0 clang-based build vs 16m40s for GCC -O0. That's a significant time savings by just swapping out the compiler. Keep in mind that debug builds with assertions intact can be significantly slower, and that time savings can grow.

For reference, the hobby project that I'm working on is the OpenCL built-in library implementation for Clover and the r600g/radeonsi gallium drivers in my GNU/Linux distro of choice.

In order to get meaningful work done, I often end up pulling changes from upstream llvm and then have to compile those changes so that I can then rebuild libclc and then fairly often I end up rebuilding mesa. Those upstream llvm changes often include new instructions that have been implemented for the Evergreen or SI architectures (i.e. necessary updates in order to then use those instructions in the library functions). And given that I only have an hour or so maybe 1 or 2 nights a week, spending 20+ minutes rebuilding software before I can really get started has a large impact on the amount I can get done, and 20 minutes is usually on the short end. Adding in assertions and full debugging capabilities to the built binaries does not help compile times at all.

All of this is done on machines running some variant of GNU/Linux, usually running the latest kernel/X/mesa/llvm (most built from git/svn).

And honestly, it doesn't matter what project I'm working on, or even the language I'm doing it in. When trying to develop software that requires iterating repeatedly through the compile/deploy/test process, you ALWAYS want a faster compiler. Faster built binaries is nice when you want to send something to a user/customer, but until then, speed of compilation is always more important than the performance of the produced binaries. Really.

I do this 40+ hours a week during my day job, and then some more for fun in the evenings, and that's one of the major lessons that I learned very early on. Time is money, and a developer having to wait on a compile to finish is a waste of both.