{"id":1179,"date":"2009-03-03T02:15:17","date_gmt":"2009-03-03T10:15:17","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=1179"},"modified":"2010-01-22T14:42:45","modified_gmt":"2010-01-22T22:42:45","slug":"intel-beats-up-gcc","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/intel-beats-up-gcc\/","title":{"rendered":"Intel Beats Up GCC"},"content":{"rendered":"

Executive Summary:<\/strong> Showcased by FFmpeg, Intel’s C Compiler beats gcc’s C compiler. Handily. Decisively. I stop just short of brutal dismemberment metaphors because that just seems so tasteless, and because I know there must be options to explore in order to improve gcc’s numbers.<\/p>\n

Pursuant to my last post where I found results all over the map<\/a> when comparing FFmpeg<\/a>‘s performance when built with different compilers, with Intel’s C compiler (icc) barely edging out gcc 4.1.2, David Conrad recommended<\/a> that I try building FFmpeg with all ASM and manual SIMD optimizations disabled. In doing so, the compilers would have a chance to really shine in optimizing plain C code for a computationally intensive — not to mention commonplace — task. And so I repeated the same test, only I configured the builds with these options:<\/p>\n

\r\n.\/configure --disable-yasm --disable-mmx \\ \r\n--disable-mmx2 --disable-sse --disable-ssse3\r\n<\/pre>\n
I also built static binaries with no swscale, if that makes any difference. After each build, I manually audited the resulting binary using the command:<\/p>\n
objdump -d ffmpeg_g | grep movq<\/p>\n
This method is predicated on the observation that x86 SIMD code blocks nearly always involve at least a movq (move quadword) instruction.<\/p>\n
Then I did 2 runs back to back with each build. The results are thus:<\/p>\n

\n\"icc
\n<\/center><\/p>\n
It’s interesting to note that icc’s build tested positive for movq instructions– they appear to be generated by the compiler, not present due to FFmpeg code. If the compiler was smart enough to build a binary that uses SIMD where appropriate, I count that as fair game for this exercise. Note that I didn’t specify any specific CPU type to icc. Meanwhile, the optimization level for the gcc builds is cranked up to -O3 (same with icc).<\/p>\n
I’m eager to hear how gcc’s numbers might be improved in this case (especially for the latest gcc versions). For reference, every one of these gcc compiler versions was built from source by me. Did I neglect to configure with some –turbo option? Also, fairness dictates that I field suggestions about how to coax icc into building an FFmpeg binary that further embarrasses gcc — and, by extension, free software — in this matter.<\/p>\n
Hey, wanna hear something really creepy? Just<\/em> as I was finishing this post, an apparently<\/em> automated email arrived from Intel, asking for my feedback on icc.<\/p>\n
See Also:<\/strong><\/p>\n