Hi, Le 10/02/2010 23:52, Florian Köberle a écrit : > Hello Matthieu > > first thank you for gathering the information together. > > I like option (b) most. It keeps the code simple and requires only a few > small steps to implement: > 1. Change the build process to use streflop > 2. Add the line "streflop_init<Double>" to the main.cpp file > 3. Replace all occurrences of "float" and "double" with Double > 4. Search for includes of<math.h> and replace it with a include > of"streflop.h" and declare that we use the streflop namespace. >
Unfortunately, it may be not that easy too according to the 'Notes' on streflop: "The compiler must not assume strict aliasing. For g++ optimization levels 2 and 3, this assumption is unfortunately the default.". At least, it gives which gcc flags should be used. But, I'm just reading the Notes deeper : "This also means you cannot reliably use this library with gcc on systems where only sse (but not sse2) is present, like some athlon-xp cores.". This is really sad, because I don't think we should drop support for such CPU. On the other point, I agree with you that is seems the best choice. I'm looking to find another similar library. > You have convinced me that option (a) is as good as impossible to > implement in C/C++. > I totally agree with that point :) > Option (c) seems to be quite tricky to me. The main problem is that > locally games stay synchronous for me and I guess it will be the same > for any other developer which doesn't own two machines. So how do you > want to find out that your resynchronization works? One idea to test it > locally would be VMs but I don't know if they are fast enough if they > simulate another architecture. > Yea, that's a problem :-/ > Another option (d), which can also be combined with (a) and (b) is to do > a calculation test which results in a hash of multiple calculation > results. That hash gets then used to determine if a player can play with > another player without a loss of synchronization. > > For example would then Wormux ask the index server for games which are > compatible to Wormux 0.9.1 and contain no player with a hash different > to 42251060023612167. Games hosted by headless servers are visible to > all players until a player joins with a specific hash. > > In theory option (d) should not be necessary if we implement option (b) > but to catch cases where people compile Wormux wrongly it would be a > nice to have. > I mostly agree with Kurosu. I'm pretty unsure that we can not find one particular computation that is able to really test the difference between compiler. Just because sometimes the rounding difference comes from an optimization such as a loop unrolling. Regards, Matt (gentildemon) > Best regards, > Florian > > > Matthieu Fertré wrote: > >> Hi, >> >> Floating points operations are not deterministic. That means that the >> same computation can give different results because it has been built >> with different compilers, with different options. But even running the >> same binary on a different CPU may give you different results : by >> default, x86 uses 80 bits internal precision while x86_64 uses 64 bits >> internal precision, there may have differences in the mathematic library >> installed on different systems. You can find some explanations here for >> instance [1]. >> >> There is no good way to make portable code (remember that Wormux runs on >> x86, x86_64, sparc, arm, ...) making deterministic computation. >> >> In fact, there are merely 3 solutions : >> a/ force operations precision in a portable way, but it is not that >> easy. [2] >> b/ do not use floating points operation at all. That means relying of >> fixed point integers or using a deterministic floating point library >> such as streflop [3] >> c/ support non deterministic computation. That means that we have to >> resync from times to times. This is how some other games do [4], of >> course, we are not the first to face the problem. This is how it works >> before Wormux 0.9.0 but it was far from perfect since it was hiding some >> bugs (mostly due to bad use of random generator). >> >> From my point of view, we have to re-add synchronizations, at least in >> release mode. Anyway, what has been done for 0.9.0 was useful and we >> must find way to not hide bugs with synchronization. >> >> Regards, >> >> Matt (gentildemon) >> >> >> [1] >> http://blogs.msdn.com/shawnhar/archive/2009/03/25/is-floating-point-math-deterministic.aspx >> [2] http://www.christian-seiler.de/projekte/fpmath/ >> [3] >> http://nicolas.brodu.numerimoire.net/en/programmation/streflop/index.html >> [4] http://springrts.com/wiki/Syncing_System >> _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
