Running GCC 4.9 On AMD's AM1 Kabini With Jaguar Cores

[phoronix]

Phoronix: Running GCC 4.9 On AMD's AM1 Kabini With Jaguar Cores

Using the AMD Athlon 5350 AM1 APU with its four "Jaguar" cores operating at 2.05GHz, I ran some benchmarks from Ubuntu 14.04 Linux comparing the performance of binaries compiled under GCC 4.8.2 and this week's GCC 4.9.0 RC1. Is GCC 4.9 better able to exploit the potential out of AMD's Jaguar microarchitecture?..

http://www.phoronix.com/vr.php?view=MTY2MjI

[Spittie]

Well, seems that it got a nice boost compared to yesterday: http://openbenchmarking.org/result/1...=GCC+4.8+Tuned

[mmstick]

Well, seems that it got a nice boost compared to yesterday: http://openbenchmarking.org/result/1...=GCC+4.8+Tuned

Certainly, why are these scores 300-700% faster than previous benchmarks?

[Spittie]

Certainly, why are these scores 300-700% faster than previous benchmarks?

I'd love to ear an answer from Michael, anyway the only difference I can see is the kernel version (3.13 vs 3.14). There are also some different gcc flags, but I doubt those would give such a boost.

[Luke_Wolf]

I'd love to ear an answer from Michael, anyway the only difference I can see is the kernel version (3.13 vs 3.14). There are also some different gcc flags, but I doubt those would give such a boost.

Actually yes, yes the involved GCC flags would, why? well first off because march=native means that the binary itself is tuned towards the architecture it's running on, allowing things like SIMD extensions, whereas the previous tests were tune=generic which means that the binary isn't built for any of the quirks of the architecture and only has up to SSE2 available, but has the advantage of being a portable binary. Futher these binaries are built with Optimization level 3 whereas the previous article's binaries were built without any optimization level at all.

So yeah, those flags do make a big difference

[mmstick]

Actually yes, yes the involved GCC flags would, why? well first off because march=native means that the binary itself is tuned towards the architecture it's running on, allowing things like SIMD extensions, whereas the previous tests were tune=generic which means that the binary isn't built for any of the quirks of the architecture and only has up to SSE2 available, but has the advantage of being a portable binary. Futher these binaries are built with Optimization level 3 whereas the previous article's binaries were built without any optimization level at all.

So yeah, those flags do make a big difference

Nope, it shouldn't make the difference that big. 15%, maybe, but this is 200-700% faster in every benchmark.

[Luke_Wolf]

Nope, it shouldn't make the difference that big. 15%, maybe, but this is 200-700% faster in every benchmark.

Quite possible

http://www.phoronix.com/scan.php?page=article&item=gcc_47_optimizations&num=1

on GCC 4.7 O0 vs O3 doubles the performance, march=native will be more dependent upon the software involved but will give it's own boost. Note that most production software is built with O2, but that O0 is the default optimization level.

[carewolf]

Nope, it shouldn't make the difference that big. 15%, maybe, but this is 200-700% faster in every benchmark.

-O3 enables auto vectorization. Normally that isn't a big deal because real programs have custom code for inner loops like that, but in a benchmark where everything is written in generic C or C++, well the compiler gets to do vectorization that can give good 4-8x speed-up (though unless it is really clean examples you tend to only get 2-3x speed up with automatic which is why real application write important vectorizable loops in assembler or instrinsics).

[Ansla]

The change in CFLAGS would explain app benchmarks getting faster, but not also the compile time benchmark getting faster, it should have had the opposite effect.