[vorbis-dev] optimizing float to int conversions

[Monty]

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.