[vorbis-dev] optimizing float to int conversions

[Conrad Parker]

Hi all,

Erik de Castro Lopo (of libsndfile) wrote a report on this issue:

    http://www.mega-nerd.com/FPcast/

It turns out there's C99 functions to do the machine's preferred
conversion. He introduces that and also provides m4 macros for detecting
it, and inline versions to fall back on for legacy hosts (like Win32 ;)

The float_cast.h in current libsndfile also provides inlines for ppc; I'm
sure erik has some good reason for not using OS X's native lrint[f]?

btw. libsndfile also contains a bunch of macros for stuff like detecting
the cpu's clip mode; its aclocal.m4 is an interesting read.

Conrad.

On Wed, May 05, 2004 at 03:22:40PM -0400, Monty wrote:
> Hi folks,
> 
> The big losses in float to int (or int to float) conversion are
> usually due to context setup and tear-down.  For example, GCC doesn't
> have (or at least three years ago didn't have) a default FPU control
> flags convention, so every time a program does a cast, it has to set
> up rounding mode, move things to the stack, etc, because it is
> uncertain of current state...  Then tears it all back down after the
> cast.  In a tight loop, the optimizer often doesn't notice this is
> being done every time.  MSVC may well be doing something similarly
> 'stupid' in order to conform strictly to IEEE float spec or some such
> thing.
> 
> If you're benchmarking these optimizations without a full analysis of
> the actual assembly/opcodes being generated by the compiler, you're at
> best a blind man with a Braille copy of War & Peace you've mistaken
> for a map of Cleveland...
> 
> (float/int conversion on x86 is a little odd to start with.  The
> original x86 FPU was as much an afterthought as MMX was...)
> 
> > Hmmm.. fair enoughi can't find anything specific on C++ but my compiler
> > certainly doesn't just shift using the low 5-bits... I'll take your word for
> > it in C... i'd be interested to find out if it is undefined in C++ too.
> 
> The shift and rotate opcodes in x86 only have a five bit field for
> shift.  If the compiler is reliably right-shifting a 32 bit int to 0,
> it's generating extra code (not required by the C spec) to do so.  GCC
> does *not* do this; a 32 bit right shift of a 32 bit on x86 leaves the
> original number untouced because the opcode field overflows to zero.
> This is correct behavior under all revisions of the C spec.
> 
> > I did find this though... (C++ draft Standard 1996)
> > 
> > 3 The value of E1 >> E2 is E1 right-shifted E2 bit positions.  If E1 has
> >   an unsigned type or if E1 has a signed type and a  nonnegative  value,
> >   the  value  of  the  result is the integral part of the quotient of E1
> >   divided by the quantity 2 raised to the power E2.  If E1 has a  signed
> >   type  and  a  negative  value,  the resulting value is implementation-
> >   defined.
> > 
> > So if the number being shifted is signed and engative, this is
> > imlpementation dependant too :| Interesting !
> 
> Yes, this is the unrelated note that makes >>1 not the same as /2.
> 
> Monty
> --- >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.
--- >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.