[Bug-gnubg] Rollouts: Multithreaded Build and 1 thread vs Non-Multithreaded.

[Michael Petch]

There appears to be a discrepancy between rollout data between the Multithreaded variants (Using 1 thread) and a Non-Multithreaded variant.
In built both variants without SSE support of any kind and Optimizations at all (No O2 or O3 flags).

In the Multithreaded/1 thread configuration when I run a rollout with Neil’s settings (as described in previous posts) and this position: hucZAxDYzmDABg:8AmmAAAAIAAA (Number trials 2592, JSD Limit of 3.1; stop after best move found; min trial 217; Full rollout; Cubeful (Truncate at exact bearoff database); variance reduction and Mersenne twister (Seed 359697340) I notice during the rollout that when a move exceeds  the JSD limit (The rank goes from “# r” to “# s”) to indicate a stop on the move. The trial count also stops for that move. If the JSD falls below 3.1 then the rollout is restarted for the move at the point where the JSD originally exceeded 3.1 and the trial count increases from there (And will stop again when JSD exceeds 3.1). This is what I would expect.

If I do the exact same test with the Non-Multithreaded code the Trial number never stops even when the JSD is exceeded, although the rank goes from “# r” to “# s”). So without threading support all rollouts will end with a trial count for each move of 2592. If the JSD for a move falls back below the 3.1 it does properly restart the rollout afrom the point where it originally stopped on a move.  The other curiousity is that although the trial count continues to rise for all the moves, even ones that are apparently stopped rollouts are not occurring for the ones that are stopped (And the  estimated time left will drop accordingly)

I would expect (I may be wrong) that if  a move in a rollout doesn’t go the full trial then the output should reflect the real trial number that the move was ended on.