I’m trying to come to terms with the reality that is XML. I may not like the format but that won’t change the fact that I have to interoperate with various XML data formats already in the wild. In other words, treat it like any random multimedia format. For example, suppose I want to write software to interpret the various comics that I’ve created with Taco Bell’s series of Comics Constructors CD-ROMs.
I saw Terminator Salvation recently. Observers enjoy dissecting the many ways that the entire Terminator franchise fails to add up, logically. I’m certainly not here to defend it.
However, none of the reviews or analyses I have read so far have mentioned the opening credit sequence for Salvation. Every actor’s name is ensconsed in some nonsensical computer code construct. The average programmer finds himself unable to avoid guessing what language the movie could have been hinting at– C, C++, Objective-C, XML, Python. They looked something like this:
/**Christian Bale; >> Sam Worthington < > [ Helena Bonham Carter ] Moon Bloodgood++ <Anton> <Yelchin>
I’m surprised that this hasn’t merited a mention in IMDb’s Crazy Credits section for the movie. Maybe Skynet (the master computer of the Terminator franchise) uses a proprietary language which is a mish-mash of all the computer languages the humans developed.
Some anonymous hacker recently made a name for himself (wait, can you make a name for yourself anonymously?) by ranting against the difficulty of working with certain Adobe file formats. It got me wondering if we could draw more attention to the FFmpeg program by littering the code with rants against the file formats we’re trying to re-implement. I’d like to think we’re above that, if only because the average FFmpeg hacker intuitively understands that no one ever meant for us to be able to re-implement these formats, at least not the proprietary formats.
Ironically, I think you’ll hear the most complaints from the crew where free, open formats are concerned.
You can look at a seemingly bizarre format and generally experience 1 of 2 reactions:
Over the years, I’ve trained myself to have reaction #2. I’m not saying I’m superior; on the contrary, the philosophy leads me down the wrong path sometimes when it turns out that the format’s originator honestly didn’t know what they were doing. In that case, I end up giving them too much credit.
Along these same lines, Joel Spolsky’s take is absolutely fascinating: He describes how the Microsoft Office formats evolved to their present complexity — not out of spite for third party programmers, but to meet the needs of the applications’ features.
Actually, an impromptu and unscientific audit of the FFmpeg code (grep’ing for certain keywords) does seem to indicate a high level of animosity towards Microsoft.
Suddenly, I feel revitalized regarding the MultimediaWiki and its charter. Someday, someone somewhere is going to want to know about that UMV format on Orpheo’s Curse.
Executive Summary: 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.
Pursuant to my last post where I found results all over the map when comparing FFmpeg‘s performance when built with different compilers, with Intel’s C compiler (icc) barely edging out gcc 4.1.2, David Conrad recommended 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:
./configure --disable-yasm --disable-mmx \ --disable-mmx2 --disable-sse --disable-ssse3
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:
objdump -d ffmpeg_g | grep movq
This method is predicated on the observation that x86 SIMD code blocks nearly always involve at least a movq (move quadword) instruction.
Then I did 2 runs back to back with each build. The results are thus:
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).
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.
Hey, wanna hear something really creepy? Just as I was finishing this post, an apparently automated email arrived from Intel, asking for my feedback on icc.
See Also: