LLVM Clang vs. GCC Compiler Benchmarks On FreeBSD 11.0

[carewolf]

hu?? where was the compile time measurement?

The timed Apache and PHP compile time benchmarks on page 3.

[Brane215]

Of course will you have to be fair. Nobody will take benchmarks serious where one compiler uses -O2 and another gets to use -O3.

But one bench with default -O2 and other with -O3 for all compiler might be useful. LTO likewise, where available.

The problem with the options is that when you start using all available options then you are doing it wrong, because realistically would you select options for each compiler and every single benchmark individually. Only to find the best options for one compiler with a particular benchmark on a given hardware is time consuming, the result will only be meaningful to each particular case, but not be of much use for a general comparison.

Wrong again. Many packages are compiled with ustom CFLAGS ( otherwise e.g. gentoo wouldn't have whole flag-o-matic class within its infrastructure) and compilers tend to vary quite significantly even with sasme flags on package to package case. So, if you don't care about CFLAGS, you are less likely to care about compiler either and vice versa - if you care about compiler, you are less likely to just leave CFLAGS at default.

The point of the benchmarks is to give the compilers something to do and to see how these compare with default settings, but not to find out how well one can optimize each benchmark. That's a completely different task.

I see things differently. I don't need such benchmarks for so trivial information I can have myself. I need info about their peculiarities, how they perform with different type of arch and code and optimizations etc.

Compilers are also meant to be smart enough to make most optimization decisions for you and not to demand of you to do these for the compiler. Another reason not to delve further into the massive amount of options (and parameters) that are available.

Fine. If they are smart for you, then you don't need this benchmark - just choose one of main choices. If they are not smart enough then that benchmark is meaningless for you.

BTW, dod you know that for example, gcc-6.x has option "-fdefault-null-pointer-checks" by default and it miscompiles quite a few packages,, because it can't determine when that option should not be used ?

[sdack]

But one bench with default -O2 and other with -O3 for all compiler might be useful. LTO likewise, where available.

Wrong again. Many packages are compiled with ustom CFLAGS ( otherwise e.g. gentoo wouldn't have whole flag-o-matic class within its infrastructure) and compilers tend to vary quite significantly even with sasme flags on package to package case. So, if you don't care about CFLAGS, you are less likely to care about compiler either and vice versa - if you care about compiler, you are less likely to just leave CFLAGS at default.

I see things differently. I don't need such benchmarks for so trivial information I can have myself. I need info about their peculiarities, how they perform with different type of arch and code and optimizations etc.

Fine. If they are smart for you, then you don't need this benchmark - just choose one of main choices. If they are not smart enough then that benchmark is meaningless for you.

BTW, dod you know that for example, gcc-6.x has option "-fdefault-null-pointer-checks" by default and it miscompiles quite a few packages,, because it can't determine when that option should not be used ?

It is not useful when the point is to be a general comparison.

Some packages are compiled with custom CFLAGS, sure, but most of the time because the plain defaults cause problems and a package needs additional arguments in order to compile at all. Most distributions however compile their packages with default -O2 and only generic architecture tuning. This then affects the majority of users, who don't recompile their distros.

And of course can you see things differently, but try to see the intentions of the article. The point was to replace FreeBSD's default compiler, which is clang, and to show what difference this makes. Many FreeBSD users aren't too happy about it. Tell them you didn't like the article, because you can't be bothered with any of this!!

[SaucyJack]

Compilers are also meant to be smart enough to make most optimization decisions for you and not to demand of you to do these for the compiler. Another reason not to delve further into the massive amount of options (and parameters) that are available.

Dafuq?

'-march=xxxx -O3'

If two flags are too much for you, you're using the wrong OS.

[sdack]

Dafuq?

'-march=xxxx -O3'

If two flags are too much for you, you're using the wrong OS.

You don't need "-march=xxx". You only need it once during the installation of gcc and it will use it as default from there on. Distros often default to something more generic. So you actually would want to install gcc yourself tailored to your hardware and with further options (i.e. "--with-fpmath=avx").

Still, this wasn't the point of the article, which was to simply replace the default compiler (clang) with a version of gcc and to see how it compares.

[jf33]

Clang tends to have better warnings, though. Anyway, I use both compilers to get all their warnings and I think this is what every good dev should do.

[VikingGe]

Maybe now we'll stop hearing all the bragging about compile times on Clang

Non-optimized builds are still faster than with GCC at least for my own C++ code. (1m59s vs 3m11s for a full rebuild). That's... *significant*.