Re: Problems converting Float to Integer efficiently

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

Jeff C, wrote:
> If you can use a more up to date gcc (a 3.X series) and have a pentium 4
> (maybe ok on III)
> then you can try this little thing I made
...
 > Asm ("cvttss2si %1, %0",inputs  => float'asm_input("m", y),
 >                          Outputs => integer'asm_output("=r",temp));

This works great!

I have had no problems on my Athlon (1100MHz clock speed) and GNAT 3.15p

My experiments show the following:
-- X is integer, Y is float
X := X + Truncate(Y);               -- 0.029us    1x
X := X + Integer (Y);               -- 0.360us   12x
X := X + Integer (Float'Floor (Y)); -- 1.196us   41x

This is timed in a  tight loop.  Optimisation "-O3", Checks suppressed, inlined where possible.
I checked carefully that the "right" code was being generated, and the test was fair.
These lines are not exactly equivalent in function - I wanted "floor", but "Truncate" is OK

As you can see, the "obvious" Ada code for converting to integer is at least 12x slower
than Jeff's version. This has the potential to be quite significant in my code which
implements interpolation of five dimensional arrays for function approximation.

I also had a look at the "stereopsis" and "gems" web site.  It seems the deficiency of compiler in
getting integers from floats has caused other people difficulties too.  I'm slightly worried that
the "Truncate" function will fail if the FPU/SSE mode is changed.  I'll try to cross that hurdle
if I encounter it.

Quoting the stereopsis site : "I've seen quite well-written code get 8 TIMES FASTER after
fixing conversion problems. Fix yours! And here's how.."

This whole situation illustrates one of the things which frustrates me about coding in Ada/GNAT:
performance and reliability of Ada code is often very good, but you need to be eternally
vigilant that you are getting out the code that you think you should be getting.  The speed
of the compiled code is sometimes critically dependent on apparently inocuous choices.
Things like enumerated types, use of generics under certain circumstances etc. can cause
apparently good source code to crawl.  Is this a necessary price for ditching low-level HLLs
like 'C'?  Perhaps someone should create a web site highlighting the problem areas and
explaining the solutions? Volunteers anybody?

Thanks guys for the help on this!
--
Adrian Wrigley, Cambridge, England.