Author: Bas Hamstra
Date: 08:02:39 10/19/00
Go up one level in this thread
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 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.
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.