Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (805)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (868)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Question: Bit-exact floats on different computers?  (Read 17786 times)
0 Members and 1 Guest are viewing this topic.
Offline theagentd
« Posted 2016-06-15 20:21:21 »

Hey.

Has anyone successfully managed to get a perfectly synced up game client where all computers in a networked game did the exact same computations and got the exact same results regardless of hardware/OS/etc with Java? Is strictfp enough to get this? Is it possible to do this between x86 and ARM?

Myomyomyo.
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2016-06-15 21:31:43 »

strictfp will do this.

Cas Smiley

Offline theagentd
« Reply #2 - Posted 2016-06-15 21:55:01 »

Even on ARM and for both floats and doubles? Can I be 100% sure that if I run the exact same deterministic program on both the result will be bitwise exactly the same?

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Ninja


Medals: 73


falling into the abyss of reality


« Reply #3 - Posted 2016-06-15 22:13:48 »

Even on ARM and for both floats and doubles? Can I be 100% sure that if I run the exact same deterministic program on both the result will be bitwise exactly the same?

Short of a VM bug, hardware bug, or error in your own code, yes.

Java requires & utilizes only IEEE 754 floating point.
( https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.2.3 )
FP-strict forces all intermediate values to be constrained to the same precision as the operands.
( https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.4 )
Offline thedanisaur

JGO Knight


Medals: 59



« Reply #4 - Posted 2016-06-16 03:59:04 »

I have yet to run into any problems, but my engine game isn't super sophisticated yet.

Supreme commander utilized IEEE 754 to achieve determinism. If I recall correctly they had a couple outliers, but the vast majority of players had zero problems.

Every village needs an idiot Cool
Offline delt0r

JGO Wizard


Medals: 145
Exp: 18 years


Computers can do that?


« Reply #5 - Posted 2016-06-16 06:46:23 »

Yes i have tested this ages ago. It is one of the reasons the base java math class is fairly slow since IEEE 7 whatever  is fairly strict and java requires 2ulp accuracy (also Part of IEEE IIRC). It is *bit perfect*.

In fact we have also done this with C/C++ across quite a wide range of CPUs. But for that you got to get your compiler flags right for each target. It is def much easier to do in java.

People often think that floating point is somehow not deterministic. Not sure why. But outside bugs, it is.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2016-06-16 08:27:22 »

I think because there were subtle differences in implementations on various processors over the last 20 years (f. ex. Intel using 80-bit internals for computation unless you use strictfp). That, and understanding exactly how floats work in all situations is very complicated (I don't really know myself) and there are better things to do with one's day.

Cas Smiley

Offline theagentd
« Reply #7 - Posted 2016-06-16 09:41:29 »

Yes i have tested this ages ago. It is one of the reasons the base java math class is fairly slow since IEEE 7 whatever  is fairly strict and java requires 2ulp accuracy (also Part of IEEE IIRC). It is *bit perfect*.
The reason why I thought it wasn't exact was the ULP requirement. If the result has to be within 2 ULP of the correct result, then technically there are up to 5 possible answers that are all deemed correct. Is there really a requirement that says that all hardware must round all results exactly the same way?

Thanks for all the info everyone!

Myomyomyo.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #8 - Posted 2016-06-16 09:57:59 »

I'd suggest to avoid the problem.  Make your life easier.  The server is always right.  Mostly send relative information and have client side smoothing.  Periodically send absolute information, but not in the same packet for every object.  Then you don't have to care about any compounding of errors due to FP results...it will go away at the next abs-update and it mostly will be unnoticed due to client side smoothing.  This also allows different versions of the game to work together as long as the net datamodel hasn't changed (barring other breaking changes of course).
Offline theagentd
« Reply #9 - Posted 2016-06-16 10:00:56 »

The problem is that this can lead to very weird situations. An error in one object's position can cascade out to all nearby object through physics etc, so a huge pile of AI could constantly be pushing each other into the wrong positions if not all of them are updated at once. That would require the server not updating random objects each update, but identifying all touching objects to resync the entire batch. At the same time, we can't afford to use lock-stepping either since it's not responsive enough. I'm just scouting my options here, and if floats are reliable enough, then that's another tool I can use if I need to.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2016-06-16 10:33:23 »

Model the world on the server; model the special effects on the client. If something is critical to the gameplay, the server should be the arbiter. If it's just eye-candy, let the client do whatever it likes.

Cas Smiley

Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #11 - Posted 2016-06-16 10:57:16 »

Seems to me that miniscule mathematical differences should not amount to significant differences in logic. If your world is made of perfectly spherical billiard balls rolling over perfectly flat, frictionless surfaces, the tiny differences quickly add up. But in a real world there is friction and nonrigidity.

Offline CommanderKeith
« Reply #12 - Posted 2016-06-16 11:19:16 »

KevGlass made a networked game using perfect determinism with strictfp that was a success. I forget which game that was but I found this old discussion about it on google:
http://www.java-gaming.org/index.php?topic=18183.0
[EDIT, found it]: http://www.java-gaming.org/topics/networking-a-dungeon-crawl/10516/msg/83159/view.html#msg83159

My little networked game used Roquen's approach where the server is always right. But I used a funny setup to update the clients where the server would send an old game world's state which was then updated to the present by the clients. This happened every few seconds.  
There's some detail about it here:
http://www.java-gaming.org/topics/multiplayer-top-down-view-shooter/18019/view.html

I wasn't happy with the end result since there was noticeable frame drop when the big update occurred to get the old server world up to date by applying all of the events and updates. But perhaps it could be refined some more.

I'll be interested to see how you deal with the networked game problem.

Offline ddyer
« Reply #13 - Posted 2016-06-16 16:38:54 »

It's unwise to depend on exact value floats.  Even if you believe everyone is doing the same
calculation, compilers can and do change the order of calculations in ways that are permitted by
the normal laws of arithmetic, but which no floating point implementation can actually follow.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #14 - Posted 2016-06-16 20:37:01 »

Although I generally agree with the first sentence, everything past that is incorrect.

"compilers can and do change the order of calculations":  with specifically known set of rules which are language specific and may depend on programmer specs in code and/or compiler settings.

"in ways that are permitted by the normal laws of arithmetic": if you mean Z/Zn integers and IEEE spec FP then okay, otherwise no.  The only tricky part is FP functions that are not required to be properly rounded.  You have to know what they are and not use them for exact computation everywhere.

"but which no floating point implementation can actually follow."  IEEE FP rules aren't black magic and if you don't use variable ULP functions and disallow any compiler transforms that change error bound then all computations are bit-exact.  That's one of the main points of the spec in the first place.
Offline princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2016-06-16 20:54:26 »

... which is exactly what strictfp does, at the occasional expense of a bit of performance here or there Smiley Even so it's probably going to be quite hard to find bugs in your client when they inexplicably diverge at some point.

Cas Smiley

Offline Roquen

JGO Kernel


Medals: 518



« Reply #16 - Posted 2016-06-17 11:34:59 »

yeap, but you have to take care with things like "java.Math" functions.
Offline theagentd
« Reply #17 - Posted 2016-06-17 11:46:18 »

yeap, but you have to take care with things like "java.Math" functions.
Which functions?

Myomyomyo.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #18 - Posted 2016-06-17 18:57:24 »

Looking quickly, the follow should all be good of the fp routines:
sqrt,ceil,floor,rint,round,abs,min,max,ulp,signum,copySign,next{Up,Down,After},scalb
Offline Abuse

JGO Ninja


Medals: 73


falling into the abyss of reality


« Reply #19 - Posted 2016-06-17 20:26:46 »

Why not just use StrictMath everywhere?

Do some of the Math methods with exactly defined results (e.g. Math.sqrt) get intrinsified?
Offline theagentd
« Reply #20 - Posted 2016-06-17 21:43:51 »

Looking quickly, the follow should all be good of the fp routines:
sqrt,ceil,floor,rint,round,abs,min,max,ulp,signum,copySign,next{Up,Down,After},scalb
Are all functions in StrictMath OK in that sense as well?

EDIT: Apparently that's the whole point of StrictMath. According to this: https://gist.github.com/ijuma/840120, the only things slower are sin, cos, tan, exp and log.

Myomyomyo.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #21 - Posted 2016-06-18 05:24:47 »

Yeah StrictMath is bit-exact, but so is rolling your own approx defed with strictfp.  The compiler is aware of many of these functions and sqrt is an intrinsic.  The rule is the function must be "properly rounded", "correctly rounded" isn't good enough to insure bit-exact.
Pages: [1]
  ignore  |  Print  
 
 

 
Riven (586 views)
2019-09-04 15:33:17

hadezbladez (5526 views)
2018-11-16 13:46:03

hadezbladez (2409 views)
2018-11-16 13:41:33

hadezbladez (5788 views)
2018-11-16 13:35:35

hadezbladez (1229 views)
2018-11-16 13:32:03

EgonOlsen (4667 views)
2018-06-10 19:43:48

EgonOlsen (5685 views)
2018-06-10 19:43:44

EgonOlsen (3204 views)
2018-06-10 19:43:20

DesertCoockie (4103 views)
2018-05-13 18:23:11

nelsongames (5121 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!