Remove "fast FPU" build targets

rogerborg · Post by **rogerborg** » Thu Dec 18, 2008 6:26 pm

We currently have 3 build targets in the Visual Studio and Code::Blocks projects:

Debug
Release (precise)
Release (fast FPU)

The difference between release and release fast FPU is that the "fast" build adds flags to allow less accurate but (ostensibly) faster floating point operations.

However, the difference is (reportedly) marginal, the distinction is not clear, and maintaining these builds takes up time that could be used for other things.

I propose to remove the "fast FPU" targets from all builds, and only maintain debug and release targets. Anyone who wants a "fast" build (and who understands the issues involved) can trivially enable that locally.

Seek your say in the poll, or hereunder.

joshcryer · Post by **joshcryer** » Thu Dec 18, 2008 7:09 pm

I voted no just because I'm lame (see my joke on IRC), but since it requires you to use up time maintaining them you can consider my vote a yes.

Sorry for messing up your poll, heh.

bitplane · Post by **bitplane** » Thu Dec 18, 2008 7:49 pm

Have you found FPU inaccuracies that cause irr::core bugs? If so then I'll vote yes, if not it depends how much of a difference to Burning's renderer the fast FPU mode makes, because I guess this is where such optimizations would really make a difference.

Mel · Post by **Mel** » Thu Dec 18, 2008 8:29 pm

I wouldn't remove an optimization which allowed faster operation of the engine. Not obstant, if it is a source of troubles go ahead, as fas as i know, in GCC compilers is pretty easy to re-enable them if the need arises.

If you have the doubt, it must mean that it really doesn't matter at all to have it there or not, so remove it.

Mirror · Post by **Mirror** » Thu Dec 18, 2008 8:59 pm

i vote for removing it. we don't live in 3742BC when we had ancient hardware. there is no need to try milking a fly.

MasterGod · Post by **MasterGod** » Thu Dec 18, 2008 9:33 pm

Mirror wrote:i vote for removing it. we don't live in 3742BC when we had ancient hardware. there is no need to try milking a fly.

You can never know which target platform would an Irrlicht application run on. It could be a 100 MHZ CPU, integrated graphic card with low mem and 64 MB RAM.
Don't you think such target platform (for example) would need that 'little' optimization?
And what if it doesn't have some cool floating point calculation device (or how ever it's called - like ALU for floating points, I think its FPU -whatever..), in such case floating point optimization would be exactly what it needs.

I guess because Irrlicht isn't just for the current high-end PCs it should not abandon such things.

Unless of course as bitplane said if those optimizations cause bugs and unexpected behaviors, it should be, in my opinion, fixed instead of removed, if possible.

rogerborg · Post by **rogerborg** » Thu Dec 18, 2008 10:19 pm

MasterGod wrote:You can never know which target platform would an Irrlicht application run on. It could be a 100 MHZ CPU, integrated graphic card with low mem and 64 MB RAM.
Don't you think such target platform (for example) would need that 'little' optimization?

The builds under discussion are Windows MSVC and Linux gcc Code::Blocks builds. What 100MHZ devices are those builds currently being run on?

hybrid · Post by **hybrid** » Thu Dec 18, 2008 10:22 pm

My settop box, 80MHz PPC, and an FPGA board, with 300MHz PPC. I won't use the project files, though, and the Makefile has -fast-math on by default

joshcryer · Post by **joshcryer** » Thu Dec 18, 2008 11:22 pm

Just out of curosity hybrid do you run Irrlicht on the 80Mhz computer? If so how does it do?

Dorth · Post by **Dorth** » Fri Dec 19, 2008 12:07 am

How about we remove them and mention in the doc how one could re-enable them? If it's well written in the doc, no one's got an excuse for not reading it and acting on it... ^^

hybrid · Post by **hybrid** » Fri Dec 19, 2008 12:30 am

Well, it seems to be 66MHz actually, but it renders something (SW renderer, tutorial 4, I made a photo some month ago and posted it somewhere on the forum)

wyrmmage · Post by **wyrmmage** » Fri Dec 19, 2008 1:56 am

I vote to remove them. Really, there's no reason to have them there...it's like having separate build targets for -O1, -O2, and -O3 flags: if you know the benefits of one over the other, you're going to know how to enable them

-wyrmmage

BlindSide · Post by **BlindSide** » Fri Dec 19, 2008 7:56 am

You can remove the build target, but please keep the configuration define, there are some very interesting tweaks in there, stuff like fast sqrt, etc. (Tbh that particular example doesn't show any practical improvement, but it IS interesting.)

Also, I would recommend transferring some of the functions over, as some of them are infact faster and cause no inaccuracies, such as the fast floating point rounding which just invokes the fp rounding instruction present on all processors. (It's actually faster and more accurate to round to the nearest integer on modern cpus then to floor). Note I'm talking about cases where you need rounding, not flooring.

Cheers

PS: I voted I am currently using them before I realised you were just talking about the build target which I don't really care about personally.

hybrid · Post by **hybrid** » Fri Dec 19, 2008 8:55 am

Removing the build target would never mean to remove the code optimizations. While those could be better encapsulated, there's good reason to keep them and also develop more of them

Dorth · Post by **Dorth** » Fri Dec 19, 2008 4:37 pm

if f = 0.999f would ever give me (int)(f) == 1, it would screw up lots of the logic behind my apps. This is a guarantee of the language, when you convert a float to int, it truncates whatever's after the dot. and floor wouldn't work either, because f = -0.999f gives you (int)(f) == 0, not -1. If I want (int) to round, I'll use the function that does it or write it myself. I don't expect my legacy c or my c++ cast to round.

Irrlicht Engine

Remove "fast FPU" build targets

Should we remove the "fast FPU" build targets?

Remove "fast FPU" build targets