What's the word on floating-point reproducibility?

Hi all,

I hear the problem with reproducibility is that different machines might have different ideas about rounding. In particular, it seems that Intel 64-bit may round differently than AMD 64-bit, and that using SSE instructions will produce yet another set of results.

And once you have a difference, it will likely cause larger differences in the next simulation cycle, until the differences get noticeable.

Does jMonkeyEngine have a policy for this?

1 Like

Java has, in java there is no such thing as different Machines, due to the JVM.

EDIT: I was posting an image but it didn’w work, nm…

@toolforger said:
Does jMonkeyEngine have a policy for this?

We don't have policies for things that have not shown to have any effect yet. These kinds of talks are pretty much a drag, come back when you got a nice test case and an actual problem case.

See http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/ for the problem case.

A test case would involve having different hardware with different floating-point implementations. E.g. AMD vs. Intel.

@EmpirePhoenix The JVM depends on the underlying hardware’s IEEE implementation, which can have differences. For example if inverse transcendental functions (arcsin etc.) are used, these aren’t defined very precisely. [EDIT: I know about strictfp, but it needs to be activated at a per-class level. IOW I’d need to fork jMonkeyEngine’s simulation-relevant classes to have strictfp.]

Or the compiler may keep intermediate results in an 80-bit register on an Intel CPU and in a 64-bit register on an AMD one, and that means different number of rounded digits. The difference will be minimal, but that will build up to wildly different simulation results very quickly - a handful of collisions in a frictionless billiard simulation, for example.

BTW is there such a simulation that uses jMonkeyEngine? It would help to perform actual tests; I’m currently going by reported industry experience, which is good but not as good as seeing the issue in action.

You could run jroockit jvm with global strictfp parameter if you are paranoid


I still don’t see the case…? I never heard of more snapping in games because of intel/amd hardware. This is a normal drift issue that can be handled with normal synchronization techniques…?

You could try experimenting with the canonball demo (one of the early test tutorials).

Add a script to fire off a number of canon balls, wait a set time then snapshot the state.

Then run that on a few different systems and compare the snapshots.

I’ve no idea how deterministic that would be even over multiple runs on the same machine though.

In general I’d say it is a bad idea to try and rely on synchronized simulations though, timing effects over the internet introduce all sorts of imprecisions that throw things out. It’s better to expect a certain amount of difference and correct for it over time either by having one server running the “real” situation and then everyone else correcting towards that or by having some sort of peer-to-peer negotiation.

1 Like
@zarch said:
I've no idea how deterministic that would be even over multiple runs on the same machine though.

None, bullet itself is not fully deterministic, as for some none solveable problems (imagine two solid boxes at the same position with same velocity and same rotation) you need random inputs to solve the problem (-> both boxes fly away in a somwwhat random direction)

Yes, you could synchronize the random seed though.

However I think we are all agreed, it’s essentially impossible to get identical simulations which is why very few games (and no modern ones I can think of off hand) try to do it…

Exactly, it is far easier to just repliate the positions every few ms per entwork (and also else cheating)