Ryzen Compiler Performance: Clang 4/5 vs. GCC 6/7/8 Benchmarks

[sdack]

Oh was it? That isn't good. Benchmarking doesn't combine well with anything but "performance" and even then modern systems screw with it. Ryzen X CPU's do dynamic clock boosting. Intel chips all do various Turbo modes... It can be locked down to constant clock speeds but is tricky to get set correctly.

Yes, it's listed in the second box on the first page ("Scaling Governor: acpi-cpufreq ondemand").

gcc 6.3 was then configured with PIE/PIC enabled by default whereas gcc 7.1 and gcc 8.0 don't show this option as listed. This alone can often makes as much of a difference as 2%-3% in performance.

[Zan Lynx]

I'm only aware of PIC/PIE performance issues with 32 bit code. As far as I know 64 bit has no slowdown.

[sdack]

I'm only aware of PIC/PIE performance issues with 32 bit code. As far as I know 64 bit has no slowdown.

It depends on the code itself and the difference is often within the deviation. A single cpu migration or context switch more or less can have a bigger effect on the result. It also has an effect on the code size, which is much easier to measure. The difference is there though.

[eva2000]

Thanks for sharing these benchmarks. They're of much interest to me as I am working on Clang 4 and 5 compilation support for my CentOS based LEMP stack as I already have native CentOS GCC support along with GCC 5.3 and GCC 6.2/6.3 and working on GCC 7.1 as well.

Do these compiler benchmarks on Ryzen 5 equally translater to Ryzen 7 cpus ?

+1 to also seeing compilation with -O2 vs -O3 results as well

[Steffo]

Well, can we call Clang already superior to GCC?!

[stormcrow]

Well, can we call Clang already superior to GCC?!

No. According to this rebuttal the optimization options for GCC vs. Clang are not the same. -O on GCC aliases to -O1 which is a hybrid debug/optimization setting while on Clang -O is an alias for -O2 which is the typical release optimization setting. So Michael is comparing apples to oranges in this case. The CPU being benchmarked in this case is irrelevant as the optimization options are not equivalent to begin with.

Rebuttal reference:

https://kristerw.blogspot.com/2017/07/phoronix-scimark-benchmarking-results.html

[sdack]

No. According to this rebuttal the optimization options for GCC vs. Clang are not the same. -O on GCC aliases to -O1 which is a hybrid debug/optimization setting while on Clang -O is an alias for -O2 which is the typical release optimization setting. So Michael is comparing apples to oranges in this case. The CPU being benchmarked in this case is irrelevant as the optimization options are not equivalent to begin with.

Rebuttal reference:
https://kristerw.blogspot.com/2017/0...g-results.html

He used -O3 -march=... for both compilers as you can see listed in the second box and on each chart.

[Ansla]

You didn't even bother to open the link before replying, did you? It explains there why the -O3 level set in CFLAGS is ignored.

[sdack]

You didn't even bother to open the link before replying, did you? It explains there why the -O3 level set in CFLAGS is ignored.

No, I don't read trash.

[el0j]

No, I don't read trash.

The only thing that's garbage is people not taking feedback seriously.

The published test results are made running scripts available at OpenBenchmarking.org, and looking at the build script for SciMark shows that it is built as
cc $CFLAGS -o scimark2 -O *.c -lm Note the -O – this overrides the optimization level set by $CFLAGS and explains at least some of the discrepancies in the test results.

So instead of calling it 'garbage', show that it's wrong and that the -O (which does not map to the same optimization levels on GCC and clang) does not override earlier CFLAGS.

I would have frankly expected the article to be updated by now, but perhaps its author doesn't read the comments. Maybe s/he think they're garbage, who knows.