Author: Uri Blass
Date: 04:53:15 12/17/02
Go up one level in this thread
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
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.