Hacker News Reader

Comment by 10000truths | Hacker News Reader

Does this determinism extend to floating point computations? This has historically been a pain point with multiplayer games where the client state has to be periodically re-synced with the server state due to slowly accumulating drift in floating point calculations.

View on HN

When I implemented a WASM compiler, the only source of float-based non-determinism I found was in the exact byte representation of NaN. Floating point math is deterministic. See https://webassembly.org/docs/faq/#why-is-there-no-fast-math-... and https://github.com/WebAssembly/design/blob/main/Nondetermini....

> Floating point math is deterministic.

It is deterministic in a single machine, but it unfortunately is not deterministic across machines (and specially not across architectures)

... however, if you restrict yourself to a subset of floating point, it's straightforward to provide cross-platform determinism. That's what's the Rapier physics engine does

https://rapier.rs/docs/user_guides/rust/determinism/

On that note, Wasmtime has an option to enable NaN canonicalization, which should patch that hole, too: https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#...

It may also be thread nondeterminism, eg relying on the commutativity of addition etc.

The other common one is elementary functions from libm (i.e. exp/log etc)

Do note that sqrt should return the same results on all libm implementations, as well as functions like nextafter or scalbn.

That's probably more about GPUs cheating to be faster[1]. https://asawicki.info/news_1741_myths_about_floating-point_n...

[1]: Back in the day, CPU results could also vary based on path of execution; see tweet in article.

is one option to sync “bignum” structs instead of f64 or is that not realistic in terms of complexity/size?

Reply on news.ycombinator.com