[vorbis-dev] optimizing float to int conversions

[Tal]

1. I don't think that converting int to float is a problem.
2. For converting float to int, do we want to be depended upon the
compiler optimizations? 
    Why do we need a genious compiler when there is a simple macro that
does the trick?
    Moreover, I think that using the FPU for conversions even when you
are not "blind" is slower then this simple integer algorithm.

About the shifting problem, I can write it in assembly but then it
suffer for platform dependency...

Tal.

-----Original Message-----
From: owner-vorbis-dev at xiph.org [mailto:owner-vorbis-dev at xiph.org] On
Behalf Of Monty
Sent: Wednesday, May 05, 2004 9:23 PM
To: vorbis-dev at xiph.org
Subject: Re: [vorbis-dev] optimizing float to int conversions

<p>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.