Author: Robert Hyatt
Date: 12:05:56 10/19/00
Go up one level in this thread
On October 19, 2000 at 11:02:39, Bas Hamstra wrote: >On October 18, 2000 at 10:26:47, Robert Hyatt wrote: > >>On October 18, 2000 at 09:31:56, Bas Hamstra wrote: >> >>>On October 17, 2000 at 10:02:54, Robert Hyatt wrote: >>> >>>>On October 17, 2000 at 05:14:14, Bas Hamstra wrote: >>>> >>>>>On October 16, 2000 at 10:18:31, Robert Hyatt wrote: >>>>> >>>>>>On October 16, 2000 at 06:32:53, Pham Minh Tri wrote: >>>>>> >>>>>>>I know that Bitboard makes move generation the fastest, but this structure is >>>>>>>also one of the most complicated. However, an old post said that the generation >>>>>>>function is not the key of success to chess program and the author illustrated >>>>>>>that after his optimality (which made that function work much faster), the speed >>>>>>>of system increased only 1 percent. >>>>>>> >>>>>>>As a result, my question is: is bitboard really worthy for implementation when >>>>>>>it takes a long time to program and more time to fix all bugs (maybe several >>>>>>>times bigger than the rest of program)? Or is it better if we use this time to >>>>>>>concentrate on hash table, null move threshold and so on? I plan that I will >>>>>>>forget the bitboard (at least in the first period) if it help me only few >>>>>>>percent. >>>>>>> >>>>>>>Pham >>>>>> >>>>>> >>>>>>I see nothing that makes them harder to use than an array. Nor nothing that >>>>>>makes them particularly easier to use either. >>>>>> >>>>>>They have certain advantages on new architectures that move 64 bits of data >>>>>>around in one cycle, and they have some advantages in evaluation where you can >>>>>>answer lots of questions in one AND or OR operation. On current machines, I >>>>>>would say they are no faster nor slower than any other approach. On 64 bit >>>>>>architectures, they begin to look better. >>>>> >>>>>Well if you wanted to build attacked-from tables I would not be so sure. Some >>>>>programs use that kind of info extensively. If you wanted to make such a >>>>>program, BB certainly wouldn't be the first option. >>>>> >>>>>However I know at least 1 program that builds attacks-to tables with BB and that >>>>>seems to work fine. >>>>> >>>>> >>>>>Bas Hamstra. >>>> >>>> >>>>Attacks_from works fine in bitboards. Just read the chess 4.x article in >>>>"Chess Skill in Man and Machine". I did them until I decided I didn't really >>>>need that often enough to tolerate the overhead. I _still_ get that information >>>>very quickly if I want it... but I could get it even quicker. Early versions >>>>of crafty had attacks_from and attacks_to that were incrementally updated as the >>>>board was modified. I changed to rotated bitmaps to eliminate the overhead of >>>>the incremental update and turn attacks into a simple table lookup. And I got >>>>rid of attacks_from almost everywhere except for a couple of places where I >>>> compute "in check". >>> >>>I know you don't use them. So it is logical you leave them out. But not all >>>program's work like Crafty. There are a couple of programs that use >>>attacked-from info heavily. They want to know not only that a square is >>>attacked, but exactly by what. For many squares. >>> >>>Now I personally think that if you wanted to do this, you better not use the >>>rotated BB approach. >>> >>> >>>Regards, >>>Bas. >> >> >>Why? I used both for a good while. rotated bitmaps help with the attacks_from >>stuff (move generation/mobility). incremental updates work for the attacks_to >>stuff (which pieces attack this square). >> >>But in any case, I use _both_ in crafty. The attacks_to is required for my >>Swap() function which is used to order moves and is called a huge number of >>times. > >Do you remember what keeping Attack info incrementally costed Crafty speedwise? >Did it slow you down much? I am interested. Visual C can handle plain bitboards >really well. The slowdown is in the "on the fly" stuff. For my program, that is. I really don't remember. I was primarily using this for an instant "am I in check" test. When I removed it all and used the simple InCheck() function I now use, things got significantly faster, because the incremental stuff is doing a lot of work that will never be used, yet it has a definite cost. > >I can do 5M AttacksTo's a sec. Not bad. Also not exactly free. If you do MANY of >them it will seriously affect NPS. > > > >Regards, >Bas. I only use it for check detection, and the check detection code hardly shows up in my profile runs... MakeMove/UnMakeMove are still significant as there are lots of bitmaps to update if you keep rotated copies around. But these are far less significant than Search() and Evaluate().
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.