Re: spring and -march=i686
People seem to be treating the SSE requirement as a performance
consideration, but I think it's really about getting the same rounding
errors on all hosts:
>From http://springrts.com/wiki/Build_from_source#Desync_in_game:
> Spring only send the commands and not the result over the network, so
> it needs to run all math in a repeatable manner, so all other clients
> in a multiplayer match get the same results. So some CPU specific
> features have to enabled/disabled. If you desync you either have a CPU
> that isn't SSE capable or you set the wrong -march /-mtune compiler
> flags.
The i387 FPU (or whatever emulation of it actually exists in a modern
CPU) normally works in 80-bit precision internally and truncates to 32-
or 64-bit when writing into memory, whereas SSE always works in IEEE
32-bit/64-bit precision (for float/double respectively), as far as I
understand it?
So, SSE and non-SSE Spring executables, when fed the same data, can
potentially get different rounding errors and hence different results;
compound that over a whole game and you'll find you and your opponent
disagree about where your squad of robots/goblins/whatever have ended up.
If this is the problem, then it might be sufficient to use gcc -mpc64 or
gcc -mpc32, possibly with -mno-fused-madd, on i386... or not. (I am not
a compiler ninja, those are just the options that info gcc said affected
rounding.) To be honest, it might be best to have spring/i386 require
SSE and check for it on startup.
In theory this shouldn't be a problem for most of Debian's architectures
because i386 is the unusual one here - I believe powerpc uses IEEE
32-bit floats and 64-bit doubles anyway - but I don't know whether there
are other subtle differences. -mfpmath=sse is probably a good idea on
amd64 as well as i386.
(To be honest this sounds like a recipe for portability disaster to
me... I wonder how well i686, amd64, ppc Spring interoperate, and I
wonder whether upstream could be persuaded to use fixed-point (i.e.
integer) mathematics for network-relevant calculations in future versions?)
Regards,
S
Reply to: