{"id":1225,"date":"2009-03-09T01:23:35","date_gmt":"2009-03-09T08:23:35","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=1225"},"modified":"2020-07-25T22:41:35","modified_gmt":"2020-07-26T05:41:35","slug":"icc-vs-gcc-smackdown-round-3","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/icc-vs-gcc-smackdown-round-3\/","title":{"rendered":"icc vs. gcc Smackdown, Round 3"},"content":{"rendered":"

How did I become the benchmark peon? Oh right, I actually dared to put forth some solid benchmarks and called for suggestions for possible improvements to the benchmark methodology. This is what I get.<\/p>\n

Doing these benchmarks per all the suggestions I have received is time-consuming and error-prone. But if you know anything about me by now, you should know that I like automating time-consuming and error-prone tasks<\/a>. This problem is looking more and more like a nail, so allow me to apply my new favorite hammer: Python<\/strong>!<\/p>\n

Here’s the pitch: Write a Python script that iterates through a sequence of compiler configurations, each with its own path and unique cflags, and compiles FFmpeg. For each resulting build, decode a long movie twice, tracking the execution time in milliseconds. Also, for good measure, follow Reimar’s advice<\/a> and validate that the builds are doing the right thing. To this end, transcode the first 10 seconds of the movie to a separate, unique file for later inspection. After each iteration, write the results to a CSV file for graphing.<\/p>\n

And here’s the graph:<\/p>\n


\n\"icc
\n<\/center><\/p>\n

Look at that!<\/em> gcc 4.3.2 still isn’t a contender but gcc 4.4-svn is putting up a fight.<\/p>\n

Here are the precise details of this run:<\/p>\n