[theora] Theora, liboil and Cell processors

David Schleef ds at schleef.org
Tue Jul 18 15:52:50 PDT 2006


On Tue, Jul 18, 2006 at 09:55:37AM -0700, Ralph Giles wrote:
> Someone has to write that code either way.

This is, of course, the most important point.

> Mike Smith had another complaint, which I will probably mangle, along 
> the lines of liboil's brittleness. It takes the approach of trying to 
> compile every possibly applicable version for a given architecture
> and then doing run-time profiling to choose between them. This is a 
> great idea for some applications, but it takes too long to get accurate 
> results with data streams the size of what we see in video, and in
> practice seems to make the build brittle since any bit-rotted code
> path can make somebody's executable go boom.

I'm not sure I understand this argument.  Liboil code is likely to
be in the top 0.0001% on the scale of "most heavily tested code on
the planet".  Code doesn't get "bitrotten" in the normal sense, since
code either passes the tests in the test suite or doesn't.  If it
doesn't pass, the code is deleted from the source tree.[1]  The tests
are quite rigorous -- I haven't seen other projects that use assembly
code routinely test their assembly against a reference function using
random data.  And that's just the beginning -- there are tests to make
sure functions don't read/write outside their array borders, tests
using different array alignments, and the latest, tests for different
stack alignments caused by using the Mono runtime.

The testing done by liboil is merely a bar, and functions must be
above that bar to be in liboil.  I don't know of another package that
uses assembly code that has such a bar, much less one as rigorous as
liboil.

Also note that just because code is developed in the context of
liboil doesn't mean that it can't be pulled out and used elsewhere.
It may turn out to be most appropriate in the theora context to
develop assembly as part of liboil (in order to take advantage of
liboil's testing and various other tools), and then copy the code
from liboil to libtheora.  Or maybe something else would be more
appropriate.

In one sense, liboil is a tool for writing great SIMD code that
happens to be in the shape of a library, instead of just a SIMD
library.  I would prefer people to view it as a tool, and then
decide later whether to use it as a library.



dave...

[1] Actually, there's a lot of marginal code that is hidden behind
#define ENABLE_BROKEN_IMPLS.

-- 
David Schleef
Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux


More information about the theora mailing list