This is getting arduous. I think this will be my last performance smackdown for awhile. First off, I put the latest in the icc 10.1 series — 10.1.022 — into FATE for both x86_32 and x86_64. It seems to work quite well with the 32-bit version having a little trouble with the regression suite; 64-bit version passes all of our tests.
For this test, I decided to use a much shorter video. The file in question has ~10700 frames of MPEG-4 part 2 video at 704×400, along with MP3 audio. The x86_32 performance trend shapes up precisely as we have seen in previous tests, and with a file that takes 1/10 the time to decode. FFmpeg SVN revision is 18737.

As usual, all handcrafted ASM optimizations are disabled. The x86_32 configurations were built with –march/–cpu equal to core2 where available, else pentium4 where available.
Here is the 64-bit chart. It must be noted that FFmpeg compiled with 11.0.083 did not decode the file correctly.

Update: I finally got the dark horse contender — LLVM — to compile at SVN 70961 for x86_64. Out of 2 runs with this same file, it posts a best time of 33.6 seconds.
The differences look severe, but they are actually within a few seconds of each other. And notice that all 64-bit configurations are demonstrably speedier than all 32-bit configurations.
Somehow, it’s only now as I prepare to publish this entry that I realize something amiss– how did my current gcc-svn build manage to build FFmpeg when FATE can’t do the same? It must be the configure options.
See Also: