make and unmake stadistics

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
User avatar
Kempelen
Posts: 620
Joined: Fri Feb 08, 2008 9:44 am
Location: Madrid - Spain
Contact:

make and unmake stadistics

Post by Kempelen » Tue Feb 28, 2012 9:37 am

Hello,

I made a small investigation in orden to fast my makemove and unmakemoves routines. In my engine, this routines have switch statements that examines the moved pieced and the captured pieces if it exits. My statements are sorted following standard enumeration: no_piece, pawn, knight, bishop, root, queen and king.

What I did is examine four thousand chess games (that I think should be enough) counting how many times a piece is moved, so I can use that information to change the orden in which the switch statement examines pieces.

This where may findings:

Code: Select all

Numbers of time a pieze is moved:
Piece    For all the game    Only for opening + middle game
ROOK	       38.937	               24.322
PAWN	       31.243	               22.267
QUEEN	      23.606                  20.855
BISHOP        25.865                  18.095
KNIGHT        20.810                  16.609
KING          25.587                   8.554
		
Numbers of captures
Piece   Captures
PAWN     10.640	
KINGHT    5.165	
BISHOP    4.777	
ROOK      3.382	
QUEEN     2.133	
KING          0	
So I changed my routines to the above order. As you can see I had not to change captures order, as it is the usual, only I changed the moved piece. It is curious that rooks is the more often moved piece, even over pawns.

For my surprise, my engines scored 15 Elo points worse for that little change. This makes me things that maybe is not the same the moves stadistics doing in a game, than stadistics doing in the search over all games. Any opinions here?

I post this findings for it somebody find they usefull.

Regards
Fermin
Fermin Serrano
Author of 'Rodin' engine
http://sites.google.com/site/clonfsp/

Daniel Shawul
Posts: 3819
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:

Re: make and unmake stadistics

Post by Daniel Shawul » Tue Feb 28, 2012 12:07 pm

Your measurements are for how many times a piece moved , not how good it turned out to be. Indeed it should perform worse if you put the rook before the pawns. Consider SEE or MVV/LVA order than overall movement statistics. The pawns easily refute many silly moves that one can make. Your statistics are more appropriate for mobility changes.

Also if you want to optimize things like order of switch by playing games, use profile guided optimization. Play as many games as you want and it should be able to pick up that and much more from the statistics it collects.

User avatar
pocopito
Posts: 238
Joined: Tue Jul 12, 2011 11:31 am
Contact:

Re: make and unmake stadistics

Post by pocopito » Tue Feb 28, 2012 12:40 pm

Hi Fermin

Tell me if I've understood properly your idea: in order to make you moves generator faster, you want to put first in the switch the pieces that are moved more often, because that way you have to check less conditions.

If that's the idea, then I guess you shouldn't take statistics from played games, but from moves generated by the moves generator itself. I mean: generate all the moves to, for example, ply 8. Count how many of the generated moves were made by each type of piece, and then use this info to order the cases of the switch of your move generator.


Cheers

E Diaz
Two first meanings of the dutch word "leren":
1. leren [vc] (learn, larn, acquire) acquire or gain knowledge or skills.
2. leren [v] (teach, learn, instruct) impart skills or knowledge to.

Pablo Vazquez
Posts: 154
Joined: Thu May 31, 2007 7:05 pm
Location: Madrid, Spain
Contact:

Re: make and unmake stadistics

Post by Pablo Vazquez » Tue Feb 28, 2012 3:19 pm

Hi Fermín,

If you are only touching make and unmake, you probably won't be changing functional equivalence, so you don't need to play games, just check the speed before and after the change.

If you define the pieces as consecutive ints starting at 0 (or with and enum), the compiler will probably create a jump table to make it constant time, so the order of the switch cases won't matter and you will get the same speed as before.

Regards

kbhearn
Posts: 411
Joined: Thu Dec 30, 2010 3:48 am

Re: make and unmake stadistics

Post by kbhearn » Tue Feb 28, 2012 4:16 pm

changing the order of the switch should not result in a speedup anyways, since the switch should be compiled as a jump table instead of a chain of if statements since it uses (presumably) contiguous values (0, 1, 2, 3, 4, 5, 6) - perhaps changing the order from that resulted in it compiling as not a jump table but i'd assume the compiler should rearrange them unless some of your case statements are not seperated by a break;

User avatar
Evert
Posts: 2924
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: make and unmake stadistics

Post by Evert » Tue Feb 28, 2012 6:36 pm

Kempelen wrote: For my surprise, my engines scored 15 Elo points worse for that little change.
How did you measure this? What is the error bar?

User avatar
Kempelen
Posts: 620
Joined: Fri Feb 08, 2008 9:44 am
Location: Madrid - Spain
Contact:

Re: make and unmake stadistics

Post by Kempelen » Wed Feb 29, 2012 12:45 pm

Evert wrote:
Kempelen wrote: For my surprise, my engines scored 15 Elo points worse for that little change.
How did you measure this? What is the error bar?
Comparing result of 4.000 games before change and 4000 games after the change, +- 10 elo error bar.
Fermin Serrano
Author of 'Rodin' engine
http://sites.google.com/site/clonfsp/

Post Reply