Author: Uri Blass
Date: 04:59:03 12/17/02
Go up one level in this thread
On December 17, 2002 at 07:53:15, Uri Blass wrote: >On December 17, 2002 at 07:30:02, JW de Kort wrote: > >>On December 17, 2002 at 07:07:46, Uri Blass wrote: >> >>>On December 17, 2002 at 06:31:50, JW de Kort wrote: >>> >>>>On December 17, 2002 at 05:45:28, Uri Blass wrote: >>>> >>>>>On December 17, 2002 at 05:34:31, JW de Kort wrote: >>>>> >>>>>>On December 17, 2002 at 05:09:31, Gian-Carlo Pascutto wrote: >>>>>> >>>>>>>On December 17, 2002 at 04:15:26, JW de Kort wrote: >>>>>>> >>>>>>>>Hi, >>>>>>>> >>>>>>>>Currently i'am using a piecelist to keep track of the locations of the pieces in >>>>>>>>my 0x88 based program. Iám thinking about removing this list and replacing it by >>>>>>>>a bitboard to keep track of the piecelocations of white pieces and black pieces. >>>>>>>>I'am wondering of anybody else does this (i think some one will) and if this is >>>>>>>>a good improvement to spees up my engine which is terrably slow. I have good >>>>>>>>expierences with other bitboards in my program. I already use bitboard to do the >>>>>>>>pawn evaluations and i'am thinkin about gradually removing the 0x88 stuff to >>>>>>>>replace it with bitboards >>>>>>>> >>>>>>>>any help appreciated >>>>>>> >>>>>>>Have you used a profiler to check where the program is spending most of its >>>>>>>time? >>>>>>> >>>>>>>-- >>>>>>>GCP >>>>>> >>>>>>Indeed i did. Most of its time is pend in the evualation code but that is nomal. >>>>> >>>>>I do not think that this is normal >>>>>Amir ban said that only 20% of the time is spent on the evaluation code of >>>>>Junior. >>>>> >>>>>The question is also what you define as evaluation code. >>>>> >>>>>I have arrays that are used in the evaluation and I update them when I make >>>>>moves. >>>>> >>>>>Should I include the time that I update the array as part of my evaluation code. >>>>>even if the arrays are used not only for evaluation but also for extension >>>>>rules? >>>>> >>>>>Uri >>>> >>>>Dear Uri, >>>> >>>>I do not dream of comparing my program to Junior. I managed to cut the time >>>>spend evaluating by using lazy evaluation. No my program does not do a full >>>>evaluation in a large number of positions. >>>> >>>>If i would do what you did i would not include the time spend updating as part >>>>of the time spend evaluating. >>>> >>>>Regards >>>> >>>>JWK >>> >>>By that definition today I use less than 5% of the time in evaluation. >>>My evaluation includes only the following factors: >>>1)piece square table >>>2)mobility when I use only the number of moves that both sides have(this >>>evaluation can be improved but it clearly help my program and I believe that it >>>is more important than knowledge about pawn structure). >>>3)double pawns(I use special arrays that are updated during making move for it) >>>4)some secret factor that is easy to evaluate for my program. >> >>I have no exact percentage but i estimate about 50% is spend evaluating. I use >>1) also, 2) i do not because i am afraid it is to costly to calculate but i will >>try it soon, 3( i also have plus a number of other pawn factors, en 4) i also >>have some extra features like devolpment etc. >> >> >> >> >> >> >>> >>>I believe that secret 4 is something that no program or almost no program knows >>>to evaluate and I do not want to lose my relative advantage. >> >>You are right about this. >> >> >> >> >> >> >> >> >>> >>>I have also secrets in my search algorithm but at the same time I also do stupid >>>things that no top program does(for example I do not use hash table efficientely >>>and I do not have some productive extensions that crafty have) so my search is >>>still clearly inferior to the search of the top programs. >>> >> >>The same goes for my program. My hashtable is not used efficiently but iam happy >>that is does work at all. >> >> >> >> >> >> >>>My program can often beat crafty in tactics but I am not going to say that >>>it is better than crafty in tactics inspite of the fact that it may be better >>>than crafty in the GCP test suite(comparison in the gcp test suite is unfair >>>because movei trains on this suite and I decided about changes in my search >>>algorithm in some cases from learning the reason that movei failed). >> >>I have not jet matches up my program agains Crafty. > >I also do not play games with it against crafty and I meant to say that it often >is better than crafty in test positions. > >> >> >> >> >> >> >> >>> >>>My target is of course to do it playing better but if I have some trick to make >>>it clearly faster in some positions without making it slower in other positions >>>then this trick is probably productive trick also in games(I also test in games >>>to verify that I did not do something bad in my search rules). >> >>Can you be more specific? > >I can give one example > >I have an array that tell me if a piece is pinned(I use that array in my move >generator that generates only legal moves) so there is no problem for me to >check if the queen of the side to move is pinned. > >I found that movei could solve some problems faster after extending >in the first ply of the qsearch when the queen is pinned(it almost does not >change the speed of it when pins are not relevant) . > >I believe that this change help also in games but it is possible that it helps >more in the gcp test suite than in other cases. > >Uri To be more correct it is not only in the first ply of the qsearch but I do not do it everywhere in the qsearch because I am afraid that if I extend too much the qsearch may explode(I did not test if doing it at all plies of the qsearch is productive and I prefer to test other ideas because I guess that there cannot be a big improvement from changes not in the first plies of the qsearch). 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.