[ogg-dev] Ogg bitwise.c bit tracking
Timothy B. Terriberry
tterribe at email.unc.edu
Thu Feb 7 15:44:57 PST 2008
Ivo Emanuel Gonçalves wrote:
> And IF that kind of performance can be gained in libvorbis too, the
> question is, what are we waiting for?
I doubt the performance gain would be that large. Theora had the fun
little situation where it was thunking into the big endian version of
some bitpacker functions which were one-line calls to the little
endian version. Because gcc seemed to be concerned that some dynamic
library could override one and not the other, it went through the
routine of saving old registers and setting up the PIC register two
times, and then restoring everything on the way out two times. Hence
almost half the time spent in the hundreds of thousands of calls to
that function per frame was for mucking around with the stack in a
one-line call that should've been inlined away anyway. And on top of
that Theora had an additional wrapper to handle various problems with
the libogg1 API when reading past the end of a packet, which added
even more overhead.
Vorbis, on the other hand, calls the little endian versions of the
functions directly and decodes far fewer bits per second, typically.
Also, Ralph reported that x86-64 showed only a 7% speed-up in Theora
with the above patch (presumably because of the much saner ABI), so
architecture makes a big difference as well.
None of that means there aren't other very good reasons we should pull
the bitpacker out of libogg that have nothing to do with speed. People
seem to have a philosophical problem with linking to libogg when they
want to mux Vorbis in non-Ogg containers, even though the only
Ogg-specific parts of libogg are a single C file which compiles to a
single object file smaller than 30K. The only people who actually care
about something so small are embedded developers, who would use Tremor
(with its own built-in bitpacker) anyway.
More information about the ogg-dev