[vorbis-dev] integer pcm decode patch

[Monty]

> What are the plans for optimizing the codec, Monty? There is a a guy in
> France who loves to write assembly optimiztions for codecs and we could
> probably get him to help us out here. Question is when do we pull him in?

Plans for optimizing: when resources are available.  We're always running the
redline on programmer cycles available.

Strategy:  Optimization is good.  However, from an engineering/code complexity
standpoint, I fear implementing large swaths of libvorbis in hand-optimized
assembly for specific processors at this point.  As someone who had to deal
personally with the Linux libc5 assembly fiasco, the possible results of
unrestrained assembly optimization are fresh in my mind (and sore upon my
buttocks).

I'm not saying that I want to discourage *anyone* from aggressive optimization;
I simply want to be very careful about what optimization we initially choose to
put on the mainline. I'm psyched to have an 'aggressive' branch maintained in
xiph.org CVS.  

Even after 1.0, portability is still more important to the core than speed.  
And given the current state of the code, you won't need assembly for the first 
10x improvement ;-)

(the largest issue affecting conversion speed right now is actually the use of
rint() and other math.h functions while I have math inlining specifically
disabled.  Why do I have it disabled?  Because of bugs in the hand-rolled,
inline header assembly in glibc 2.0 and early 2.1.  Assembly is powerful, but
much more dangerous than C)

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/