{"id":1427,"date":"2009-05-04T22:38:32","date_gmt":"2009-05-05T05:38:32","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=1427"},"modified":"2010-01-24T10:00:49","modified_gmt":"2010-01-24T18:00:49","slug":"last-performance-smackdown-for-awhile","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/last-performance-smackdown-for-awhile\/","title":{"rendered":"Last Performance Smackdown For Awhile"},"content":{"rendered":"

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<\/a> 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.<\/p>\n

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<\/a> SVN revision is 18737.<\/p>\n


\n\"32-bit
\n<\/center><\/p>\n

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.<\/p>\n

Here is the 64-bit chart. It must be noted that FFmpeg compiled with 11.0.083 did not decode the file correctly.<\/p>\n


\n\"64-bit
\n<\/center><\/p>\n

Update:<\/strong> I finally got the dark horse contender — LLVM<\/a> — 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

See Also:<\/strong><\/p>\n