[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Making lua execution results reproducible across architectures
- From: hollyrosella@...
- Date: Thu, 15 Dec 2011 00:33:54 +0000
Thanks, Eike. That link was extremely interesting, particularly the
part about Croquet.
> But I want to amend that it helps to work out code that checks if
> everything is running fine, e.g. making a test run beforehand that
> involves calculations and hash table iterations etc that should yield
> a certain value in the end.
This is a good idea. The intent is to include code from end-users, so I
want to minimize the responsibility to write reproducible code. But I
will definitely want tests for the reproducibility of the language
features I need to modify.
Holly.
On 12/14/2011 at 10:25 PM, Eike Decker <zet23t@googlemail.com> wrote:
2011/12/14 <hollyrosella@hushmail.com>:
> I would like to make a version of lua with perfectly reproducible results on
> all machines which run it. I think the main difficulty is reproducibility
> of floating-point calculations, but if there are other possible snags, I
> would be happy to learn of them. My plan is to replace the arithmetic
> macros in luaconf.h and the function calls lmathlib.c with calls to the
> relevant functions in the MPFR library, which should make atomic
> floating-point operations reproducible. I am also concerned about ensuring
> reproducible order of execution. If I compile with gcc using -O0, will that
> suffice?
>
> Holly
>
As some pointed out
- make sure that floating point unit is operating in strict IEEE mode
- avoid unsorted hash traversions (for i,v in pairs(...))
But I want to amend that it helps to work out code that checks if
everything is running fine, e.g. making a test run beforehand that
involves calculations and hash table iterations etc that should yield
a certain value in the end.
You could also calculate hashes of your states (e.g. in a physical
simulation the summed up coordinates / averages etc) and compare them
to known results. Supreme commander is synchronizing a game that
involves thousands of units over the network. Basically, the game is a
physic engine and only player interactions are exchanged. The clients
run their simulations and check via hashing against the server
simulation if they are in sync. They also had to make sure that they
are operating in correct FPU modes etc. etc. [1]
There might be one or two things described there that might be
interesting to you.
Hope it helps,
Eike
[1] - http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/