[RESOLVED] Parallel condition evaluation

[cami]

Shoot! Did you remember we actually did foresee this problem and ignored it?
If I may make a recommendation and if you think it's realistic to expect more thread-specifics to be necessary in the future (external libraries often require them), once you add a new parameter maybe you might want to add a "thread context" instead of just an rng instance. You can then encapsulate any bookkeeping or message passing related to threading in there.

[Vezzra]

When running with a single Effects thread I don't seem to run into this variance. If anyone else tests this out and sees variance even then using a single Effects thread then please be sure to post about it.

Hm, well... I tried the following: I first started a single player game where I set the galaxy shape to Irregular2, monsters, specials and natives to None and AI players to 0. Started and immediately quitted a test game, exited FO. Effect threads in the options dialog has been set to 8, I checked that too.

Then I ran 5 tests with that command line:

Code: Select all

./freeorion --GameSetup.player-name RNG --quickstart --auto-advance-n-turns 10 --auto-quit

and copied the auto-saved game from turn 11 each time. Save games 1 and 5 where identical, as where 2, 3 and 4, but between these two groups there have been differences, as expected.

Then I ran 5 tests with that command line:

Code: Select all

./freeorion --effects-threads 1 --GameSetup.player-name RNG --quickstart --auto-advance-n-turns 10 --auto-quit

Assuming that that should override the setting in config.xml, and running FO with only one effects thread, now the resulting 5 save games from turn 11 should have been identical, right? Well, they weren't. Only 1 and 5 have been identical.

Archive with all five test games of this second batch of test runs attached.

[Dilvish]

Hm, well... I tried the following:

Your results made me try the same, and I initially got similar results, but it turns out the problem is just with trying to change the number of threads via the command line. Using the attached python script (which should probably also work on MacOSX), to run three tests of 20 trials each (requires slight manual edit between sets to specify test type), first with 8 threads, second with changing to single thread on command line, third done after having manually changed the thread option to one thread (with that saved to the config file), I got the results:

8 threads:

Code: Select all

Out of 20 tests, had 4 different savefile patterns, binned as [8, 3, 5, 4]

8 threads in config file but specifying single thread on command line:

Code: Select all

Out of 20 tests, had 4 different savefile patterns, binned as [3, 6, 4, 7]

1 thread specified in config file:

Code: Select all

Out of 20 tests, all had same savefile pattern

[Vezzra]

Ok, I just wanted to try your script, and ran into several issues: Apparently the "--auto-advance-n-turns" and "--auto-quit" command line options don't work on OSX. Can't tell if they ever did (don't remember if I ever tried), but with r7801 they definitely don't. Specifiying "--quickstart" and "--auto-advance-n-turns" do automatically start a game, but the game doesn't stop after the specified number of turns, it just keeps going. I also tried "--quickstart" and "--auto-quit" (to bypass the issue that "auto-advance-n-turns" does not stop) to test the auto-quit feature. This works up to the point where the game quits, but the app doesn't exit. All windows are closed, but the app remains active and has to be quitted manually. Which kind of defeats the purpose of auto-quit of course.

[Geoff the Medio]

...it just keeps going.

That's probably due to my attempts to fix the in-game manually set auto-advance, which was broken by the initial implementation of the command-line auto-advance.

Dunno about the quitting, though.

Edit: Try with this patch...

[Vezzra]

Try with this patch...

Yup, that did it - almost. I had to fix one glitch: When execution arrives at this code section:

Code: Select all

...
        } else if (once && GetOptionsDB().Get<int>("auto-advance-n-turns") > 0) {
            // if command-line auto-turn advance is set, set the target turn that many turns ahead
            once = false;
            target_turn = Client().CurrentTurn() + GetOptionsDB().Get<int>("auto-advance-n-turns");
        } else {
            // do not auto-advance turn
            target_turn = Client().CurrentTurn();
        }

...in the second turn, once is of course false and the else branch is executed, resulting in target_turn to be updated with the value of CurrentTurn(), which is not quite what we want in case target_turn has been set before by the auto-advance-n-turns option. So I added a check if target_turn is lesser than CurrentTurn(), and only in that case set target_turn to CurrentTurn():

Code: Select all

...
        } else if (once && GetOptionsDB().Get<int>("auto-advance-n-turns") > 0) {
            // if command-line auto-turn advance is set, set the target turn that many turns ahead
            once = false;
            target_turn = Client().CurrentTurn() + GetOptionsDB().Get<int>("auto-advance-n-turns");
        } else if (target_turn < Client().CurrentTurn()) {
            // do not auto-advance turn
            target_turn = Client().CurrentTurn();
        }

That did the trick. Now both the auto end turn button and the auto-advance-n-turns command line option seem to work fine. I've committed the edited patch.

Dunno about the quitting, though.

That issue of course remains. Unfortunately I've no idea what's the problem here, and I fear that issue only turns up on OSX. Somehow quitting the program like it's done when the auto-quit option is set must be different from what happens when the "Exit" button on the main menu is pressed...

[Vezzra]

Now both the auto end turn button and the auto-advance-n-turns command line option seem to work fine. I've committed the edited patch.

Or not. My attempt to fix the glitch in your patch introduced another issue, so I tried again. Hopefully the last time...