Implementing FastMath

[Jonanin]

Well, FastMath got added, but not much has come of it, so I decided to go through the source and replace Normalize()'s with ANormalize.

However, one question: is it alright to use ANormalize() in SyncedFloat? It seems like it would be okay, and we did tests on multiple OS's to make sure the results where exactly the same - it checked out okay.

If so, that's what I did. If not, I'll remove that...

Here is a patch to do it - I've only tested it single-player though. No measures of the speed increase, those have already been done, and the speed increase was pretty significant. Especially, I believe, for older CPUs.

I was told that there aren't really any parts of spring which require any accuracy better than the basic isqrt function in FastMath, so pretty much every Normalize() was replaced.

Is this alright to do? I've included a link to a patch, though I have a feeling I'll get told to remove it from SyncedFloat3

patch: http://jonanin.com/spring/fsqrt/FastMathImplement.patch

[lurker]

Don't touch flankingbonus; that needs unparalleled accuracy!

[imbaczek]

If you could split it into synced/unsynced patch, the unsynced one should go in ASAP IMHO; synced will require some discussion.

[Jonanin]

http://jonanin.com/spring/fsqrt/FastMat ... nced.patch

Patch for only unsynced parts.

[HAARP]

Don't touch flankingbonus; that needs unparalleled accuracy!

Discussions on the GCC mailing list revealed different perceptions about the implications of the -ffast-math option. For the tests shown here, I included -ffast-math in the evolutionary mix. I've performed experiments that show how -ffast-math does not reduce (and in some cases, improves) accuracy when used with industry-standard benchmarks like Paranoia. The "floating-point accuracy" story is very complicated, but it deserves its own, to-be-written-when-I-have-time article. And no, I haven't had time in the year since I last wrote that sentence!

from http://www.coyotegulch.com/products/aco ... gcc40.html

[lurker]

1. That was a joke. FlankingBonus doesn't need better than say... 10% accuracy.
2. This is completely unrelated to -ffast-math

[REVENGE]

1. That was a joke. FlankingBonus doesn't need better than say... 10% accuracy.

BE CAREFUL WHATFUCK YOU DO TO FLANKINGBONUS >_<

[HAARP]

2. This is completely unrelated to -ffast-math

I am no developer myself, but as far as I can see, this thread is about replacing math functions with faster but possibly less-accurate implementations. This also also one of the, if not the main thing that -ffast-math does aswell. Ergo, the possible increase in accuracy with -ffast-math may also affect this thread's topic.

[lurker]

It's about replacing sqrt in certain contexts with quake's fast invsqrt. It's far less accurate, but far cheaper.

And from what I went looking at -ffast-math mostly has the effect of removing safeguards and some rearrangement of terms, nothing that affects accuracy more than a tiny tiny amount. If that's wrong can you link me to a proper explanation of -ffast-math?

[SinbadEV]

I think that as long as inaccuracies are synced with other simulations reaching the same inaccuracies, nothing will go wrong. Of course I'm neither a mathematician, physicist or programmer so...

[Tobi]

Yes, even if you make all operations return 0, as long as it happens on all clients Spring will run synchronized.

Problems will occur when e.g. in -ffast-math code in GCC the GCC people change the accuracy more often then they change the accuracy of "normal" floating point calculations, because then it willl mean that Spring will need to be compiled with even smaller range of compilers (particular version of GCC, for example).

[imbaczek]

yeah, we don't care that much about accuracy; what we need is perfect consistency.