[vorbis-dev] Optimisations

[Michael Smith]

>>In fact, floating point multiplication accuracy is independent of the 
>>relative order of magnitude of the operands (except in limit cases). This 
>>is one of the advantages of floating point over fixed point (not to say 
>>fixed point is never appropriate).
>
>Still, has any analysis been given to the required precision and dynamic 
>range of the numbers used within, rather than assuming floats would be 
>doing the right thing all the time?  If you use integer (fixed point) maths 
>you can have very good control over the precision and efficiency of 
>arithmetic operations.  Are artifacts that various other MP3 encoders 
>suffer from the result of poor maths and precision accounting?

In fact, when vorbis changed to using floats (it originally used doubles.
That makes things easier, but uses a lot of memory, and puts much more
pressure on caches), there were several things that failed due to
insufficient precision. 

Of course, this wasn't good - everything that didn't work has now been
replaced with things that don't rely on extremely high precision. Remember
that we're typically working with data that came from 16 bit samples - so
really high precision tends to be unneccesary in much of the code. Most of
the code is specifically designed so that floating point rounding errors,
etc. are irrelevent. This has been thought about.

That said, there are reasons to use fixed point arithmetic. With modern
processors, it's usually only a good idea to do fixed point if the
processor doesn't have a FPU (many/most dsps (including the C6201) are good
examples here, as you mentioned.) - fixed point is actually typically
slower these days if the cpu does have a FPU.

There are parts of vorbis that already have integer only implementations
(the LSP->LPC conversion code, I think, is an example). That particular one
actually ISN'T fixed point, because the dynamic range of the input data is
too great. 

In certain cases, poor accounting of precision issues will (in mp3
encoders/decoders, for instance) cause problems. However, these almost
always are either not important (i.e. they give off-by-one errors in the
final output - and with 16 bit samples, that's not really significant), or
are really critical, and so get found really quickly, when the output is
completely wrong.

At the current time, there aren't any such issues known in vorbis - they
got cleaned out between beta2 and the current source, along with the change
to floats.

Michael

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.