title: Floating point determinism for gamedev in .NET Core
body: <h2>Background</h2>
  
  <p>We're working on an <a href="https://github.com/OpenSAGE/OpenSAGE" rel="nofollow noreferrer">RTS game engine</a> using C# and .NET Core. Unlike most other real-time multiplayer games, RTS games tend to work by synchronizing player inputs to other players, and running the game simulation in lockstep on all clients at the same time. This requires game logic to be deterministic so that games don't get out of sync.</p>
  
  <p>One potential source of non-determinism are floating point operations. From what I've gathered the primary issue is with the old x87 FPU instructions - they use an internal 80-bit register, while IEEE-754 floating point values are 32-bit or 64-bit, so values are truncated when moved from registers to memory. Small changes to code and/or the compiler can result in truncation happening at different times, resulting in slightly different results. Non-determinism can also be caused by accidentally using different FP rounding modes, though if I understood correctly this is mostly a solved issue.</p>
  
  <p>I've also <a href="https://stackoverflow.com/questions/15147174/is-sse-floating-point-arithmetic-reproducible">gotten the impression</a> that SSE(2) instructions do not suffer from the truncation issue, as they perform all floating point arithmetic in 32- or 64-bit without a higher precision register.</p>
  
  <p>Finally, as far as I know the CLR uses x87 FPU instructions on x86 (or that was at least the case before RyuJIT), and SSE instructions on x86-64. I'm not sure if that means for all or most operations.</p>
  
  <p>Support for accurate <a href="https://docs.microsoft.com/en-us/dotnet/api/system.mathf?view=netcore-2.2" rel="nofollow noreferrer">single precision math</a> has recently been added to .NET Core, if that matters.</p>
  
  <p>But when researching whether or not floating point can be used deterministically in .NET there are a lot of answers that say no, although they mostly concern older versions of the runtime.</p>
  
  <ul>
  <li>In a <a href="https://stackoverflow.com/a/14864871/486974">StackOverflow answer</a> from 2013 Eric Lippert said that if you want to guarantee reproducible arithmetic in .NET, you should "Use integers".</li>
  <li>In a is discussion about the subject on Roslyn's GitHub page a game developer <a href="https://github.com/dotnet/roslyn/issues/7333#issuecomment-334266148" rel="nofollow noreferrer">said in a comment</a> in 2017 that they were unable to reach repeatable floating point operations in C#, though he did not specify which runtime(s) they used.</li>
  <li>In a 2011 Game Development Stack Exchange <a href="https://gamedev.stackexchange.com/a/14909">answer</a> the author concludes that he was unable to attain reliable FP arithmetic in .NET. He provides a software-based floating point implementation for .NET, which is binary compatible with IEEE754 floating point.</li>
  </ul>
  
  <h2>The question</h2>
  
  <p>So, if CoreCLR uses SSE FP instructions on x86-64, does that mean that it doesn't suffer from the truncation issues, and/or any other FP-related non-determinism? We are shipping .NET Core with the engine so every client would use the same runtime, and we would require that the players use exactly the same version of the game client. Limiting the engine to only work on x86-64 (on PC) is also an acceptable limitation.</p>
  
  <p>If the runtime still uses x87 instructions with unreliable results, would it make sense to use a software float implementation (like the one linked in an answer above) for computations concerning single values, and accelerate vector operations with SSE using the new <a href="https://blogs.msdn.microsoft.com/dotnet/2018/10/10/using-net-hardware-intrinsics-api-to-accelerate-machine-learning-scenarios/" rel="nofollow noreferrer">hardware intrinsics</a>? I've prototyped this and it seems to be work, but is it unnecessary?</p>
  
  <p>If we can just use normal floating point operations, is there anything we should avoid, like trigonometric functions?</p>
  
  <p>Finally, if everything is OK so far how would this work when different clients use different operating systems or even different CPU architectures? Do modern ARM CPUs suffer from the 80-bit truncation issue, or would the same code run identically to x86 (if we exclude trickier stuff like trigonometry), assuming the implementation has no bugs?</p>