3 ms·
> This turned out to be because the rounding behavior on the 360 was different and the algorithm is fundamentally unstable using floats. That sounds like a bug
by pedrocr 8y ago
> This turned out to be because the rounding behavior on the 360 was different and the algorithm is fundamentally unstable using floats.
That sounds like a bug though but I guess that's the point. Unless you're bug for bug compatible a reasonable amount of code will fail a significant amount of time...
- unwind 8y agoPerformance is often a critical feature in games. Nobody will play a janky game and go "yeah, it's a bit rough but I'm sure the floating-point operations are done sensibly if it were to run under emulation, two console generations in the future". Console games are not like ordinary/business applications where being 15 ms late is almost always better than tying the code to the hardware.
- toast0 8y agoThere's not really a bug here. Some algorithms based on floating point numbers require floating point operations to work in certain ways. x86 floating point operates differently than most other floating point systems, in large part because of when it was developed, and that it can't change because it needs to remain compatible with existing code. It would be a bug to release code that required x86 floating point behavior on a non-x86 system, but in this case, it was easily caught during early testing.
- brucedawson 8y agoThat may have been a case where the FMA instructions on Xbox 360 gave different results. Or maybe the code was relying on the x86's odd x87 floating-point unit, or maybe the compilers were rearranging the instructions slightly in one of the ways that is legal. Lots of reasons why floating-point math code might behave differently without it being a CPU or compiler bug.