# Thread: Fastest float to int conversion

1. ## Fastest float to int conversion

Hi guys,

This is probably more of an ASM question. Once again I am using ARM, no hardware floats (all software). Does anyone have a fast technique for converting float to int?

I don't mind if its the same as 'round' , 'ceil' or 'floor', as long as its consistant, and FAST

Cheers,
Pea

2. Code:
```float f = 10.0;
int i = 0;

i = (int)f;```
I doubt you'll find anything faster.

Quzah.

3. I believe some compilers sometimes use the ftol asm command which is a slow, rounding assembly call. There is a way to disable this and make it chop instead of round...*runs off to get book*

K, in Andre LaMothe's Tricks of the 3D Game Programming Gurus:
When assigning a float to and int, the compiler will many times call the internal function, _ftol(), which can slow things down to a crawl. For example:

float f=10.5;
int i=f;

To avoid this, use inline assembly and FPU instructions, such as fistp/fst:

_asm
{
fld f;
fistp i;
}

Or use the compiler flag /QIfist to force the rounding mode to chop, and no call to _ftol() will be made.

4. Code:
```union convert
{
int i;
float f;
};```
That'll beat your assembly method hands down for speed. This is found in the "Tips of the Wise-Ass Gurus".

Quzah.

5. Thanks guys. I'll give it a go. I'll have to look up some of those assembler instructions thought

I knew there was a faster way than a cast

BTW, whats 'union convert' ?

6. BTW, whats 'union convert' ?
It's a joke

7. Code:
```#include <stdio.h>
int main( void )
{
union convert
{
float f;
int i;
} data;

data.f = 10.0;
printf("Using a union to convert %f to an int is fun: %d!\n",
data.f, data.i );
return 0;
}

/*
Using a union to convert 10.000000 to an int is fun: 1092616192!
*/```
Nothing was ever said about accuracy. Just speed.

Quzah.

8. > no hardware floats (all software)
The speed of converting a float to an int is inconsequential to all the work which gets done as soon as you start using floating point.

Consider your need carefully, and consider whether fixed-point arithmetic will work just as well, because it can be a hell of a lot quicker than true floating point.

9. Yes, I would agree with Salem. Years ago I wrote a mandelbrot program in C (actuallly my first real C program) at college on a 386 (no coprocessor).It ran pretty slowly using the library float routines, so I recoded it to use fixed point integer, needless to say the performance difference was dramatic.

Remember too that that Doom /Doom2 is all integer, so you can do quite a lot this way.

10. Originally Posted by quzah
Nothing was ever said about accuracy. Just speed.
That's worse than my random milliseconds answer I gave awhile back! :P

11. No FPU eh? Gawd, that takes me back to the days when Intel FPUs were optional (8086-386). Back then, you had to spend serious time configuring the compiler otherwise your program would crash regardless of the code. (Those who are still using Borland/Turbo C 3 will know what I mean )

For FPU support then, you had 3 options:- Hardware (i.e. you knew that the x87 was installed on the motherboard), emulation or none. Am I right in thinking that FPU emulation was a fixed-point approximation (otherwise these 16 MHz boxes would've been there for hours)?

Perhaps there's a similar option on your ARM compiler.

12. Thanks guys, but the argument to float or not to float is a different one. Just after the quickest method...

13. > but the argument to float or not to float is a different one
Except you seem to consider tying your feet together to be a good start, then asking what's the best way to win a 100M race is.

> Just after the quickest method.
Hire someone with a clue would be my next suggestion, from reading your other "performance" post

14. Salem has a point. Although we could probably help more if we knew more about what the problem space is. What does your program actually do?