Re: Multi-thread Theora Decoder

Leonardo de Paula Rosa Piga wrote:
> I took a look at the the experimental multi-thread version and I think
> this approach could not be scalable. It just creates three threads and
> if you have more than 3 processors they will be idle.

Correct. Also, the Y thread generally has 4 times as much work as the Cb
and Cr threads, so the workload is not balanced well. However, it was
also very easy to implement.

> OpenMP could be a good choice, perhaps a mixed with pthread could be better.

One of the big things I like is that OpenMP allows you to compile
essentially the same code as either multi-threaded or single-threaded.
Of course, there's only so much parallelism you can achieve with such a
constraint. If it's seriously hampering the design, then it may not be
worth it.

> Do you have any other suggestion? Should I focus on maintainability
> code or on performance?

Both, of course. In all seriousness, if you're going to do something
that's hard to read, or hard to maintain, at least run some tests to
make sure it actually gives a noticeable benefit. Use your judgment.

For example, I often see people complain about things like run-time CPU
detection because it means you have to use function pointers to access
asm-accelerated routines, instead of static calls (that can potentially
be inlined). However, in practice these functions are called a few
hundred times a frame, for an overhead of at most a few thousand cycles,
which is difficult to even measure.

In contrast, we recently discovered that thunking into libogg to use the
bitpacker routines was adding more than 50% overhead to these calls
thanks to PIC register management, and they were invoked hundreds of
thousands of times per frame. Moving them into libtheoradec, where they
could in addition be inlined, improved x86-32 performance by 17%, and
x86-64 performance by 7%. So this is an example of where we sacrificed
maintainability for speed (there were other reasons to do this, so it
wasn't much of a sacrifice, but all the same).