bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Small cache changes


From: Joaquín Koifman
Subject: Re: [Bug-gnubg] Small cache changes
Date: Tue, 24 Feb 2009 12:04:51 -0200

I've done some checking with the -O3 version. Here are the results:
 
- lots of moves aren't highlighted -in red- in the hint window. Both when a match is loaded and analyzed, or simply played.
Even more, when you play a session, for example, none of them are highlighted.
 
- about the bug Massimiliano found, I couldn't reproduce it but it happened to me too in the position that's analyzed next. A 4-1 played 12/7 which was played and shown as 12/6 5/2.
 
- the cube is centered in 2. I suppose this is on purpose.
 
 
Now, concerning the cubeful bug and the cache:

- I couldn't find any analysis bug in a couple of matches I analyzed. Previously, the bug was present in every analyzed match.
I used as reference the analysis and rollouts with only one thread -which are obviously correct-. Although since the February builds the #QO bug had almost disappeared -it happened just once in a month when before this I couldn't finish the great majority of the rollouts-, any multi-threaded action was giving wrong results and always different ones.
Now using more than one thread and different cache sizes gives correct -exactly the same- results.

- Being solved the analysis bug, the rollout bug should had gone also.
This is correct at least in the position I used. I stored it because it was one of the fastest where the bug appeared -less than 10 seconds-.

 GNU Backgammon  Position ID: dgcAAL6dBQJAAA
                 Match ID   : cAmmASAAMAAA
 +13-14-15-16-17-18------19-20-21-22-23-24-+     O:
 |                  |   |       O  O  O  X | OO  2 points
 |                  |   |       O  O  O    | OO 
 |                  |   |       O  O       | O  
 |                  |   |                  | O  
 |                  |   |                  | O 
v|                  |BAR|                  |     13 point match (Cube: 1)
 |                  |   |                X |   
 |                  |   |                X |    
 |                  |   |          X     X |    
 |                  |   |    X     X  X  X |     Rolled 41
 | X                |   | X  X     X  X  X |     6 points
 +12-11-10--9--8--7-------6--5--4--3--2--1-+     X:

Every multi-threaded rollout in the new build gave the same results than the uni-threaded rollout in the old one.
The exception was the multi-threaded rollout in the previous build, where a play such as 24/19 showed a small chance of X winning the game, amongst all the other wrong values.


About speed and cache sizes, same position:

I imagine that being the position close to the end the cache is much more effective. So this speed improvements should be kind of optimal.
The 3 first candidates where rolled out with standard settings, 0-ply checker, 2-ply cube

Cores Build Cache  Time  Correct
  1   feb18   ?   7m  0s   OK
  4   feb18   ?   2m  0s  wrong

  4   feb24   0MB 6m  0s   OK
  4   feb24  22MB 0m 56s   OK
  1   feb24 176MB 1m 21s   OK   
  4   feb24 176MB 0m 22s   OK


Joaquin.


 
2009/2/24 Massimiliano Maini <address@hidden>

I've uploaded to gnubg.org the gui/cli exes wih the lates cache code (20090224) compiled with -O2
and -O3. If anyone wants to run a few tests on them, just download and unzip into your gnubg
installation directory (20090218), the new exes will not overwrite the old ones.

MaX.

bug-gnubg-bounces+massimiliano.maini=amadeus.com@gnu.org wrote on 23/02/2009 21:27:19:

> I've done some experimenting with the cache code and ended up changing very
> little o). I should have fixed the minor #Q.00 analysis output problem (so Max
> you should be able to build with -O3 if you changed that).
>
> The cache setting in the options dialog now tells you how much
> memory the cache
> is using, I found that my sample position got notable quicker as thecache was
> made larger, flattening out at about the 175mb level.
>
> There's every chance that I may have messed up things, so hopefully someone
> could give the code a quick go to see if it's ok (maybe we should
> have some unit
> test code to check the major things are ok?). If anyone is keen enough to try
> rolling out some positions with different cache sizes I'd like to
> know how that
> goes.
>
> Jon
>
>
>
> Windows Live Hotmail just got better. Find out more!
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-gnubg

_______________________________________________
Bug-gnubg mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-gnubg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]