Floating-point contractions with Visual Studio 2019

[mihe]

This is way above my head, so I have no idea if this is even an issue, but I figured I should at least ask...

I was looking at the compiler options for Jolt and noticed that you set /fp:precise when enabling CROSS_PLATFORM_DETERMINISTIC on MSVC. I was curious how this differs from /fp:strict so I took a look at their documentation and took notice to this part in their description of /fp:precise:

Floating-point contractions aren't generated by default under /fp:precise. This behavior is new in Visual Studio 2022. Previous compiler versions could generate contractions by default under /fp:precise.

Does that mean that there can be problems, from a determinism standpoint, when compiling with Visual Studio 2019?

[jrouwe]

I think you're right. I've only tested cross platform determinism under (Windows, VS2022, x64) vs (Linux, Clang, x64) vs (Linux, Clang, ARM), but if VS2019 allows floating point contractions with /fp:precise then it won't deliver the same result as say (Linux, Clang, x64).

If you only need determinism within 1 platform, you don't need this define though and it won't matter if float contractions are enabled or not.

[mihe]

Would it be viable to use /fp:strict instead on Visual Studio versions pre-2022?

[jrouwe]

Yes, I'm not sure how much performance it will cost though, as /fp:strict will generate extra instructions to preserve/restore the floating point environment (and my guess is that that will cause a stall on the FPU).

[mihe]

I just ran PerformanceTest on (Windows, VS2019, x64), (Windows, VS2022, x64) and (Linux, Clang, x64) and they all generated the same hashes, regardless if the Windows ones were set to /fp:precise or /fp:strict. As far as performance difference it showed a pretty consistent 3-4% fewer steps per second with /fp:strict enabled.

I assume that means there's no immediate need to switch to /fp:strict for pre-VS2022? Although the wording in their documentation, saying "could generate contractions", makes me wonder if this could become a problem under some very specific conditions perhaps.

[jrouwe]

Yes, it looks like we don't need /fp:strict on VS2019 for now, but it could trigger a difference in the future as code changes. I think we should keep things the way they are, but if you ever run into inconsistencies then this will be the first thing to try.

Note that there's also __pragma(fp_contract(off)) which we could add to e.g. JPH_NAMESPACE_BEGIN/END when JPH_CROSS_PLATFORM_DETERMINISTIC is defined (although I think that's quite ugly).