Category Archives: FATE Server

Process of Confusion

I am working hard at designing a better FATE right now. But first thing’s first: I’m revisiting an old problem and hoping to conclusively determine certain process-related behavior.

I first described the problem in this post and claimed in this post that I had hacked around the problem. Here’s the thing: When I spin off a new process to run an FFmpeg command line, Python’s process object specifies a PID. Who does this PID belong to? The natural assumption would be that it belongs to FFmpeg. However, I learned empirically that it actually belongs to a shell interpreter that is launching the FFmpeg command line, which has a PID 1 greater than the shell interpreter. So my quick and dirty solution was to assume that the actual FFmpeg PID was 1 greater than the PID returned from Python’s subprocess.Popen() call.

Bad assumption. The above holds true for Linux but not for Mac OS X, where the FFmpeg command line has the returned PID. I’m not sure what Windows does.

This all matters for the timeout killer. FATE guards against the possibility of infinite loops by specifying a timeout for each test. Timeouts don’t do much good when they trigger TERM and KILL signals to the wrong PID. I tested my process runner carefully when first writing FATE (on Linux) and everything worked okay with using the same PID returned by the API. I think that was because I was testing the process runner using the built-in ‘sleep’ shell command. This time, I wrote a separate program called ‘hangaround’ that takes a number of seconds to hang around before exiting. This is my testing methodology:

From another command line:

$ ps ax|grep hangaround
21433 pts/2    S+     0:00 /bin/sh -c ./hangaround 30
21434 pts/2    S+     0:00 ./hangaround 30
21436 pts/0    R+     0:00 grep hangaround

That’s Linux; for Mac OS X:

>>> process.pid
82079

$ ps ax|grep hangaround
82079 s005  S+     0:00.01 ./hangaround 30
82084 s006  R+     0:00.00 grep hangaround

So, the upshot is that I’m a little confused about how I’m going to create a general solution to work around this problem– a problem that doesn’t occur very often but makes FATE fail hard when it does show up.

Followup:

State of the Art Compiler Optimization

Felix von Leitner delivered a talk at the 2009 Linux Kongress about the state of the art in compiler optimization (link to PDF slides). Presentation slides by themselves are not a good way to understand a talk and it would be better to learn if video for the actual talk is posted somewhere. Compiler optimization (or lack thereof) is fairly important to FFmpeg developers.

The talk analyzes how LLVM, icc, MSVC, Sun C, and gcc generate fast code in this day and age. One basic theme I gathered is that coders should forgo clever C optimizations as they tend to be counterproductive. I wish I could believe that, but there was that recent episode where I optimized FFmpeg’s Theora decoder by removing structure dereferences. I’m sure that other performance-minded multimedia hackers will have other nits to pick with the broad generalizations in the presentation. I call your attention to the fighting words (which I have taken out of context since it’s such a fun quote) on slide 41: “Note: gcc is smarter than the video codec programmer on all platforms.” Further, slides 53-55 specifically call out madplay for inline ASM that allegedly didn’t improve efficiency vs. what the compiler could achieve with the raw C code.

On the whole, the findings are probably quite accurate for the kind of C code that most people need to write (e.g., “No need to write a >> 2 when you mean a/4!”).

Speaking of compilers, FATE now covers Intel’s 11.1 series C compiler for both 32- and 64-bit icc. I have also updated the stale snapshots of the gcc-svn for my machines (I still need to write a tool to do that for me automatically and continuously).

iPhone Developments

Wikipedia’s knowledge of compilers credits the first compiler to Grace Hopper in 1952 (for a language called A-0). I suspect that if blogs existed in 1952, we would have been treated to rants such as:

I, personally, have a problem with a developer who feels entitled to be able to develop for a computer without investing the time to learn the machine opcodes or punch card formats that the machine was built around.

This is one of the arguments I have been hearing this past week after my employer announced an upcoming method for exporting Flash/AS3 projects as iPhone apps. It strikes me as an age-old argument between low vs. high level languages, that’s all. I chortle when recalling how certain people urged me to construct the FATE system in POSIX-complaint, ANSI C for maximum portability and speed instead of using a language like Python. Nowadays, that Python code is testing FFmpeg on a dozen different CPUs running 10 different operating systems. It makes me shudder to think of how much work it would have been to write the FATE script in straight C and how little benefit doing so would have brought.

In other groundbreaking iPhone news, Mans recently announced that FFmpeg can be built for the iPhone out of the SVN tree with only a minor modification to Apple’s iPhone toolchain (call the SDK police!). This is a feat that has thus far proved challenging, as Mans outlined here. I understand it will be a little difficult to continuously test FFmpeg on either a real iPhone or an emulator. However, I’m planning a revision to FATE’s architecture so that certain configurations can be marked “build-only” and forgo the test phase. This will also be useful for Hitachi SH-4 and perhaps other architectures that FFmpeg supports but for which we don’t have access to hardware for the sake of continuous testing.

Whenever the notion of compiling and running FFmpeg on the iPhone crops up, it prompts me to wonder why. Why do people care about this? Are they transcoding media on the iPhone? Are they republishing old games and using FFmpeg’s numerous game-oriented decoders for direct playback instead of doing the sensible thing and transcoding the original media to MP4/CAF/H.264/AAC for native playback through the platform’s frameworks and hardware acceleration? Is it just a point of academic curiosity thanks to the fact that FFmpeg is quickly becoming a standardized metric of compiler quality? Why?

13 Architectures

An impromptu query from the FATE database:

mysql> SELECT DISTINCT(architecture) 
  FROM web_config_cache 
  WHERE revision IS NOT NULL 
  ORDER BY architecture;

This yields 13 architectures currently being continuously tested in FATE:

+--------------+
| architecture |
+--------------+
| Alpha        | 
| ARMv5TE      | 
| ARMv7        | 
| AVR32        | 
| ia64         | 
| MIPS         | 
| PA-RISC      | 
| PowerPC      | 
| PowerPC 64   | 
| Sparc        | 
| Sparc64      | 
| x86_32       | 
| x86_64       | 
+--------------+

I suppose it’s questionable to treat ARMv5TE and ARMv7 as truly separate architectures. Still, it’s not a bad list of CPU coverage. It makes me wonder how it stacks up to the Linux kernel in terms of CPU support. According to Wikipedia, Linux still has the advantage.

One day I’ll figure out a way to continuously test FFmpeg on a Hitachi SH-4 using my old Sega Dreamcast. That’ll bring us closer.