Comments on: Why You Should Never Cast Floats To Ints

By: GameCoder.it − Il cast floatint

GameCoder.it − Il cast floatint — Thu, 01 Jul 2010 09:20:28 +0000

[...] why-you-should-never-cast-floats-to-ints [1] fast-floating-point-to-integer-conversions [...]

By: Elan

Elan — Wed, 14 Jan 2009 01:02:39 +0000

Thanks for the clarification, cb! I’ve corrected that passage.

By: cb

cb — Wed, 14 Jan 2009 00:49:26 +0000

I’m a P3 and get numbers about the same as the stereopsis numbers (eg. the xs addition trick is slightly faster than fistp). My objection was to this part :

“Furthermore, most of the magic-number tricks involve an integer step on the floating-point number, which is disastrously slow because of the way the registers are partitioned”

which is true on consoles but not on x86. The big win of using the magic number trick on PC’s is that you can distribute code or put it in new projects and not worry about what compiler settings they’re using. Also the advantage over fistp is you don’t have to worry about how the FPU rounding mode is set.

Note that the magic number truncate is really slow, though, only the magic number round-to-int is fast.

By: Elan

Elan — Tue, 13 Jan 2009 19:43:43 +0000

Wow, MSVC fail:

error C3861: ‘lrint’: identifier not found

By: syskill

syskill — Tue, 13 Jan 2009 18:53:17 +0000

I did some digging into whether and how this is handled in my world; it seems that the trick to avoiding fldcw in GCC is to use the lrint() function from the C99 standard, and then compile with -ffast-math so that it will be inlined.

Maybe lrint() with /fp:fast will give the desired results in MSVC without resorting to deprecated switches?

By: Elan

Elan — Tue, 13 Jan 2009 00:00:01 +0000

What hardware are you running, cb? I just tried a test that converts an array of 1024 floats 100,000 times (ie, performs 1.024×10⁸ conversions while fitting in cache) and here are the results for my Intel Core2 @2.4ghz:

_ftol2_sse versus magic-number truncation
(4 trials)
_Ftol2_sse	magic number
313.932ms	182.816ms
319.619ms	181.992ms
311.646ms	178.677ms
310.179ms	177.646ms

fistp (via /QIfist) versus magic-number truncation
(4 trials)
`fistp`	magic number
185.479ms	179.934ms
180.314ms	182.722ms
183.951ms	179.802ms
178.270ms	178.007ms

It looks like the magic-number trick varies between 1% slower and 2% faster than native fistp, which is basically the same.

By: Elan

Elan — Mon, 12 Jan 2009 19:55:32 +0000

Hmm, let me test that again and if so I’ll revise the article. I tried it once on my Core2, but it’s possible the compiler may have actually optimized out my profile loop. Thanks for the note.

By: cb

cb — Mon, 12 Jan 2009 18:55:23 +0000

Good article, but this -

“It’s also possible to convert floats to ints by adding them to a certain magic number, but usually this isn’t a benefit. In times of yore the fistp op was slow, so there was an advantage to replacing the fist with a fadd, but this hasn’t been the case since the Pentium 3. Furthermore, most of the magic-number tricks involve an integer step on the floating-point number, which is disastrously slow because of the way the registers are partitioned.”

is just not true on x86 PC CPU’s. My measurements roughly match the Stereopsis XS measurements – the magic number based rounding is still faster than fist by a little bit, and it has the advantage of not relying on compiler settings or FPU rounding mode. (of course on Xenon and Cell it’s a different story)

note that’s only true for round-to-int, the XS truncs are a little bit slower than fist or cvtt2sse.

Also the big advantage of the sse instructions is that you have truncate & round both available at any time without changing modes.