Author: Robert Hyatt
Date: 11:41:16 10/17/02
Go up one level in this thread
On October 17, 2002 at 14:03:10, Uri Blass wrote: >On October 17, 2002 at 11:51:30, Robert Hyatt wrote: > >>On October 17, 2002 at 10:54:15, Uri Blass wrote: >> >>>On October 17, 2002 at 10:12:26, Robert Hyatt wrote: >>> >>>>On October 17, 2002 at 06:20:11, Uri Blass wrote: >>>> >>>>>Today my repetition detection is not done based on hash tables and I plan to do >>>>>it faster by hash tables. >>>>> >>>>>After every makemove I calculate the new hash key for the hash tables >>>>>but I do not have an array of all the hash keys and I use a global varaible >>>>>__int64 zob to have the hash key. >>>>> >>>>> >>>>> >>>>>I plan to add an array zobkey[max_plies_of_game] for hash keys >>>>>My question is what is faster: >>>>> >>>>>1)Doing all the calculation on zob and after finishing them to do >>>>>zobkey[hply]=zob; >>>>>2)Doing all the calculations on zobkey[hply] >>>> >>>>I can't imagine it would matter at all, if zob is a local variable. >>> >>>In movei zob is a global varaible because I use it both in makemove >>>and in the search for order of moves that is in another file of the project. >>> >>>I did not have the array zobkey[hply] and had to use zob in both files. >>> >>>I do not see a reason that I need to change it to a local varaible. >> >>You need to study compilers and optimization a bit. If you update a global >>variable, then the compiler is _forced_ to write the result to that global >>variable >>before that procedure exits. If you write to a local variable, the compiler can >>notice >>that after you write to it, you don't read it again before the procedure exits, >>and it can >>avoid doing that store completely. > >Ok > >I understand but the problem is that zob is changed not only after doing regular >moves but also after doing null move or undoing null move. > >Do you suggest to use local varaible for zob only when I make and unmake normal >moves(in this case there are some changes in zob) or do you suggest to use it >also when I do or undo nullmove(usually one change but there are cases when >there are 2 changes because of the en passant rule)? No... what you _really_ want is a global hash signature, so you are probably doing it correctly. The question I was addressing was "should I do it twice, once in a scalar variable, once in an array?" The answer is "do it once and be done with it." The main point becomes "how do I undo the hash signature updates as I back out of the tree?" This is more difficult to understand and probably will require some testing. It might be better to just xor things again, or it might be better to put the original into an array (not bad when you are doing repetitions anyway if you do them that way) so that you just copy the saved value back over the thing... > >Here is my code after I know that I am going to do null move with R=3 with some >comments after it and questions > >j=ep[0]; >j1=ep[1]; >j2=ep[2]; >donullmove(); >null[ply]=1; >gen(); >val=-alphabeta(depth-4,-beta,-beta+1); >null[ply]=0; >undonullmove(); >ep[0]=j; >ep[1]=j1; >ep[2]=j2; >if (ep[0]>=0) > zob=zob^zobrist[0][1][fil0(ep[1])]; > > OK... > >The problem is that my code is the following >(ep[0],ep[1],ep[2] is information about the enpassant options in global >varaibles and when I make moves I calculate this information for generating >moves. My ep stuff is in a struct that is indexed by ply. There is an advantage to doing it that way in that when you reference any subscripted element of the array (a struct) the entire struct gets sucked into cache in one cycle because the struct is very short. If you use parallel arrays, you don't get this efficiency. For speed, the rule is "put variables that are used close to each other with respect to time, close to each other with respect to consecutive memory addresses." >j,j1,j2 are local varaibles in one file that does the search when I update >zob mainly in another file of making moves but not only in that file >but you can see that it can be changed also in another file > >I consider 2 options: >1)Changing the order of ep[0]=,ep[1]=,ep[2]= and undonullmove() so I can use >the last if in undonullmove. >2)using the global varaible zobkey[hply] > >Another note: > >When I do nullmove I increase ply that is the ply of the search but not hply >that is the ply of the history of the game. >When I take back moves I know that is is not a null move >if and only if null[ply]=0 I have a current_move[ply] value that always contains the current move being searched at this ply, so that I can peek into the engine if I need to and see what is happening, where. If current_move[ply] == 0, I am searching a null-move... > > > > >Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.