AMD AOCC 1.3 Compiler Benchmarks vs. GCC 8.2 vs. LLVM Clang 7.0

[AndyChow]

I'm not sure I get the point of AOCC. Wouldn`t their effort be more productive by contributing to GCC with the -march flag? I know a lot of hipsters believed clang was the next big thing, and it improved so quick, of course it was going to soon surpass GCC. But that didn't happen, and the last few percentages of optimization are always the hardest. I've yet to see usage stats or marketshare, but I'd wager GCC has more users 10:1 vs clang.

[AsuMagic]

I'm not sure I get the point of AOCC. Wouldn`t their effort be more productive by contributing to GCC with the -march flag? I know a lot of hipsters believed clang was the next big thing, and it improved so quick, of course it was going to soon surpass GCC. But that didn't happen, and the last few percentages of optimization are always the hardest. I've yet to see usage stats or marketshare, but I'd wager GCC has more users 10:1 vs clang.

Maybe it's because clang has an actually proper codebase?

[ms178]

I'm not sure I get the point of AOCC. Wouldn`t their effort be more productive by contributing to GCC with the -march flag? I know a lot of hipsters believed clang was the next big thing, and it improved so quick, of course it was going to soon surpass GCC. But that didn't happen, and the last few percentages of optimization are always the hardest. I've yet to see usage stats or marketshare, but I'd wager GCC has more users 10:1 vs clang.

I guess it serves them as a testbed for multiple ZEN-optimizations. As you see, some drive up the compile time in certain benchmarks for modest gains. That might be a decision they can take with their own fork of LLVM/Clang to maximize performance for a certain workload elsewhere but would not be acceptable upstream.

[mlau]

Maybe it's because clang has an actually proper codebase?

What makes a "proper" codebase in your opinion?

[partizann]

I have the same experience: I try icc every few years on my code only to find it brings no speed improvement. OTOH my code is mostly integer code, for vectorizable FP code I guess the outcome wouldn't be the same.

Also to note is that icc is good at cheating at SPEC 2006 and that's why all entries in spec.org use it. I expect SPEC 2017 is the same, though they didn't break any of the subtests... yet

Thats most likely because Intel basically help write the SPEC benchmarks - thats why I totally ignore those results, especially vs other manufacturer CPUs.

[B]Intel contributes to the development of benchmarks[/B] in various ways.
Intel is a member of or participant in various benchmarking
organizations and consortia such as BAPCo* and SPEC*, and its employees
often serve in various leadership roles. [B]Intel also contributes[/B]
[B]programming resources, technical support, and/or funding to groups that[/B]
[B]develop benchmarks.[/B]
Principled Technologies Benchmark Disclosure:  [B]Intel is a sponsor and[/B]
[B]member of the BenchmarkXPRT* Development Community, and was the major[/B]
[B]developer of the XPRT* family of benchmarks[/B]. Principled Technologies is
the publisher of the XPRT* family of benchmarks. You should consult
other information and performance tests to assist you in fully
evaluating your contemplated purchases.

https://www.intel.com/content/www/us/en/benchmarks/benchmark.html

[ldesnogu]

Thats most likely because Intel basically help write the SPEC benchmarks - thats why I totally ignore those results, especially vs other manufacturer CPUs.

No that's not related. Intel did not write the benchmarks, they come from the community. Intel helps selecting them, just as ARM or other large CPU companies. Some of them also are cheating with their compilers, but ARM doesn't for instance. It's an open process for those involved, something very different from Intel sponsoring Principled Technologies.

OTOH being on the selection board helps them get early access and get ready to add "tweaks" to their compiler. But I don't think there's any evidence this has happened on SPEC 2017 (yet?).

[partizann]

No that's not related. Intel did not write the benchmarks, they come from the community. Intel helps selecting them, just as ARM or other large CPU companies. Some of them also are cheating with their compilers, but ARM doesn't for instance. It's an open process for those involved, something very different from Intel sponsoring Principled Technologies.

Well Intel is also just a member of BAPCo same as the SPEC group, but here is a document which proves how SYSmark 2002 and on clearly favored Intels CPUs:

http://www.vanshardware.com/reviews/2002/08/020822_AthlonXP2600/SYSmark%202002%20Analysis%20Presentation%20FINAL.pdf

Thats why after SYSmark 2012 AMD and VIA resigned from BAPCo and denounced SYSmark...

And thats why I simply dont trust any tool/benchmark/software touched by Intel in any way.

[ldesnogu]

Well Intel is also just a member of BAPCo same as the SPEC group, but here is a document which proves how SYSmark 2002 and on clearly favored Intels CPUs:
http://www.vanshardware.com/reviews/...on%20FINAL.pdf

Thats why after SYSmark 2012 AMD and VIA resigned from BAPCo and denounced SYSmark...

And thats why I simply dont trust any tool/benchmark/software touched by Intel in any way.

So because something stinks at BAPCo, it also stinks at SPEC? Are you a conspiracy theorist or what?

My company is involved in SPEC, and I have access to it. It's fine. Really. Well unless of course you think I'm part of the evil conspiracy.

BTW I hope you don't use Linux, Intel actually does a lot of work on it.

[partizann]

So because something stinks at BAPCo, it also stinks at SPEC? Are you a conspiracy theorist or what?

My company is involved in SPEC, and I have access to it. It's fine. Really. Well unless of course you think I'm part of the evil conspiracy.

BTW I hope you don't use Linux, Intel actually does a lot of work on it.

You have also access to the source code of the benchmark ?

The Linux kernel first of all is open to all to see, so you cant really hide things which would hurt other manufacturers and sooner or later such practices would be uncovered and rectified.
This is not so in case of closed source benchmarks.
Regarding conspiracies, well I know of at least 3 cases, where Intel influenced benchmarks/benchmark providers, so its not so far fetched to assume, there are more of such cases, which were not yet uncovered. Thats why I trust PTS much more as for example SPEC, as its based on all open source, and you can always check what the test does, you even have the info, with what compiler and flags was those results obtained.

[mlau]

A few years back I read that someone found the intel compiler (icc) was very very good at identifying SPEC benchmark sources,
and generating the most optimal code for these benchmarks on intel cpus. ICC seemed very well optimized for SPEC
As with all microbenchmarks, take them with a large grain of salt or consider them compiler optimizer benchmarks first and foremost.