[RESOLVED] Parallel condition evaluation
Moderator: Committer
Re: [RESOLVED] Parallel condition evaluation
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.
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.
Yesterday, we were still on the brink. Fortunately, today we have come one step further.
Re: [RESOLVED] Parallel condition evaluation
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.Dilvish wrote: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.
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
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
Archive with all five test games of this second batch of test runs attached.
- Attachments
-
- RNG-Test-Savegames.zip
- (448.72 KiB) Downloaded 100 times
Re: [RESOLVED] Parallel condition evaluation
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:Vezzra wrote:Hm, well... I tried the following:
8 threads:
Code: Select all
Out of 20 tests, had 4 different savefile patterns, binned as [8, 3, 5, 4]
Code: Select all
Out of 20 tests, had 4 different savefile patterns, binned as [3, 6, 4, 7]
Code: Select all
Out of 20 tests, all had same savefile pattern
- Attachments
-
- test_random.py.zip
- (1.21 KiB) Downloaded 106 times
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: [RESOLVED] Parallel condition evaluation
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
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: [RESOLVED] Parallel condition evaluation
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.Vezzra wrote:...it just keeps going.
Dunno about the quitting, though.
Edit: Try with this patch...
- Attachments
-
[The extension patch has been deactivated and can no longer be displayed.]
Re: [RESOLVED] Parallel condition evaluation
Yup, that did it - almost. I had to fix one glitch: When execution arrives at this code section:Geoff the Medio wrote:Try with this patch...
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();
}
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 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...Dunno about the quitting, though.
Re: [RESOLVED] Parallel condition evaluation
Or not. My attempt to fix the glitch in your patch introduced another issue, so I tried again. Hopefully the last time...Vezzra wrote: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.