How to speed up floating-point to integer number conversion? [duplicate]

Answer 1

If you do not care very much about the rounding semantics, you can use the lrint() function. This allows for more freedom in rounding and it can be much faster.

Technically, it's a C99 function, but your compiler probably exposes it in C++. A good compiler will also inline it to one instruction (a modern G++ will).

lrint documentation

Answer 2

I'm surprised by your result. What compiler are you using? Are you compiling with optimization turned all the way up? Have you confirmed using valgrind and Kcachegrind that this is where the bottleneck is? What processor are you using? What does the assembly code look like?

The conversion itself should be compiled to a single instruction. A good optimizing compiler should unroll the loop so that several conversions are done per test-and-branch. If that's not happening, you can unroll the loop by hand:

for(int i = 0; i < HUGE_NUMBER-3; i += 4) {
     int_array[i]   = float_array[i];
     int_array[i+1] = float_array[i+1];
     int_array[i+2] = float_array[i+2];
     int_array[i+3] = float_array[i+3];
}
for(; i < HUGE_NUMBER; i++)
     int_array[i]   = float_array[i];

If your compiler is really pathetic, you might need to help it with the common subexpressions, e.g.,

int *ip = int_array+i;
float *fp = float_array+i;
ip[0] = fp[0];
ip[1] = fp[1];
ip[2] = fp[2];
ip[3] = fp[3];

Do report back with more info!

Answer 3

Most of the other answers here just try to eliminate loop overhead.

Only deft_code's answer gets to the heart of what is likely the real problem -- that converting floating point to integers is shockingly expensive on an x86 processor. deft_code's solution is correct, though he gives no citation or explanation.

Here is the source of the trick, with some explanation and also versions specific to whether you want to round up, down, or toward zero: Know your FPU

Sorry to provide a link, but really anything written here, short of reproducing that excellent article, is not going to make things clear.

Answer 4

See this Intel article for speeding up integer conversions:

http://software.intel.com/en-us/articles/latency-of-floating-point-to-integer-conversions/

According to Microsoft, the /QIfist compiler option is deprecated in VS 2005 because integer conversion has been sped up. They neglect to say how it has been sped up, but looking at the disassembly listing might give a clue.

http://msdn.microsoft.com/en-us/library/z8dh4h17(vs.80).aspx

Answer 5

rounding only excellent trick, only the use 6755399441055743.5 (0.5 less) to do rounding won't work.

6755399441055744 = 2^52 + 2^51 overflowing decimals off the end of the mantissa leaving the integer that you want in bits 51 - 0 of the fpu register.

In IEEE 754
6755399441055744.0 =

sign exponent mantissa
0 10000110011 1000000000000000000000000000000000000000000000000000

6755399441055743.5 will also however compile to 0100001100111000000000000000000000000000000000000000000000000000

the 0.5 overflows off the end (rounding up) which is why this works in the first place.

to do truncation you would have to add 0.5 to your double then do this the guard digits should take care of rounding to the correct result done this way. also watch out for 64 bit gcc linux where long rather annoyingly means a 64 bit integer.

Answer 6

There's an FISTTP instruction in the SSE3 instruction set which does what you want, but as to whether or not it could be utilized and produce faster results than libc, I have no idea.