Comments on: Intel Beats Up GCC

By: ARM compiler shoot-out | Hardwarebug

ARM compiler shoot-out | Hardwarebug — Wed, 05 Aug 2009 00:06:16 +0000

[...] See also Mike’s test of x86 compilers. [...]

By: Carl Eugen Hoyos

Carl Eugen Hoyos — Sat, 07 Mar 2009 01:13:27 +0000

Just for the record: Until recently, I used to run icc compiled code (as long as that was possible with FFmpeg) only on AMD cpus and the code was always faster than with gcc.

icc defaults to something like –cpu=pentium3, so unfortunately, this test was not exactly fair, march=native would turn the advantage: Imo, –cpu=core2 would be fair.

By: Diego "Flameeyes" Pettenò

Diego "Flameeyes" Pettenò — Wed, 04 Mar 2009 13:00:57 +0000

Weeeell when a hardware manufacturer comes to me with a compiler that “magically” runs code faster on his chips, but doesn’t on the ones from a rival, it really sounds like mafia speaking ;)

But I agree that GCC needs improvement, especially in the heuristics. I’m afraid I’m not geek enough to know about compilers to the point of hacking at them though :(

By: Multimedia Mike

Multimedia Mike — Wed, 04 Mar 2009 01:24:25 +0000

@Flameeyes: From the discussions I’ve read, it all depends on whose side of the story you believe. Apparently, Intel said it was to protect against running magical, possibly volatile code on non-blessed chips.

So there, you anti-Intel zealot. :-)

By: Diego "Flameeyes" Pettenò

Diego "Flameeyes" Pettenò — Wed, 04 Mar 2009 00:46:39 +0000

I don’t have the reference at hand but I remember at least older Intel C Compiler versions used to have a killswitch for AMD.

Basically it produced much bigger code, branching depending on the runtime features found on the CPU (SSE, MMX, and so on), checked with cpuid. When cpuid reported a vendor different from GenuineIntel, it branched to “no extension available”.

Fun isn’t it?

By: Bobby

Bobby — Tue, 03 Mar 2009 21:05:04 +0000

And just for comparison, with the ffmpeg I had installed, which included all the hand-written asm, it only takes 6m13.722s

By: Bobby

Bobby — Tue, 03 Mar 2009 20:55:00 +0000

With an Athlon64 X2 3800:

Configure options common to all configurations: –disable-amd3dnow –disable-amd3dnowext –disable-mmx –disable-mmx2 –disable-sse –disable-ssse3 –disable-yasm

Input file was divx5 video (652×356), mp3 audio, 95 minutes

ICC 10.1 20080801:
- options: –cc=icc –extra-cflags=-O3
- best time: 7m57.379s

GCC 4.3.3:
- options: -O3 -march=athlon64
- best time: 8m17.021s

LLVM-GCC 2.4 (2.5 came out recently):
- options: -O3 -march=athlon64
- best time: 8m30.107s

By: Alex

Alex — Tue, 03 Mar 2009 18:44:52 +0000

@Mike:

ffmpeg llvm benchmarks: http://laurovenancio.wordpress.com/2007/08/07/llvm-perf-tests/

By: astrange

astrange — Tue, 03 Mar 2009 17:51:30 +0000

ffmpeg doesn’t compile under llvm-gcc with inline asm on, but should work with it off.

gcc should be able to do a little autovectorization with appropriate -march -mtune, but not as many movqs.

And can you try gcc svn?

By: Bobby

Bobby — Tue, 03 Mar 2009 17:49:44 +0000

@Multimedia Mike: I don’t know. That’s something else I’m curious to see. I’ll probably give it a try in the next couple days if somebody doesn’t beat me to it.