Author: Sune Fischer
Date: 13:07:25 04/09/04
Go up one level in this thread
On April 09, 2004 at 15:26:34, Christophe Theron wrote: >On April 09, 2004 at 14:27:48, Sune Fischer wrote: > >> >>>Clearly, nothing beats the ugliness of bitboards. >> >>This may not be the best example to judge by. >> >>-S. >>> Christophe > > > >In the contrary, I think it's fairly typical of bitboard code. > >Elegance is supposed to be the strong point of bitboards. > >The only thing I find elegant is the pseudo-great starting idea "64 squares <-> >64 bits". > >Passed this point everything becomes unreadable and ugly. I know what you mean by that of course. There are some macros for rotated which is very ugly and initializing the lookup tables isn't pretty either. When that is over and done with however, you never need to look at it again. The question is what do you get in return. What you get in return is a piece list which is very easy to work with. You get fast checks for a lot of simple stuff, ie. is the king in the corner could be something like (white_king & (H1|G1|H2|G2)) is there white rooks on 7th: (white_rooks & rank7) etc. So a lot of little things are easy. For the attacks I don't know if they is faster, they use a table so they are loopless and branch pridictionless, so it might be faster if cache is big enough. Another possibility is to do a hybrid approach to get the best of both worlds. This might be faster but for now I'm not interested in complicating my program. >I also see it often used to pre-compute attack tables and such, which is in my >opinion contrary to one of the most important things I have learned in computer >chess: do not compute anything in advance if you are not certain that you will >use it. Actually I'm on the same side as you in this, altough I'm not 100% convinced we are right :) Attack tables, if you need them at every node because you do a complicated eval every node, might actually save time. Of course we can then discuss if a full eval at every node shouldn't be avoided in the first place, but "evaluation based search" seems to be a hit with for some people. I think it sounds interesting too, I just wouldn't know what to do with it :) >This is not an intrinsic problem of bitboards, it's just that use of >bitboards often go along with this misuse of computing resources, is it just by >chance? Asside from the attack lookup table I don't think you need that much else. Crafty has a lot of stuff for detecting outposts and such, but a filler could do this just as well on the fly. It's just a matter of tuning which is faster in your program. >Bitboards are a great tool allowing you to compute very complex things in a >blink. The problem is that in a chess program you rarely need to do these >complex computations if you know what you are doing, and so you end up with ugly >and unreadable code and waste of resources (in particular of L1 and L2 caches). If you want to program to run within 64k I would not recommend bitboards. But this limit is from the early 90ties, today we have 256k minimum and soon 512k to 1024k and growing larger with each generation of CPUs. >That being said, I do not want to be too harsh: it is probably possible to write >a top-level chess program using bitboards, a program that would be not very far >behind the programs using more portable approaches like 0x88 and derivatives. > >Somebody will write one some day. I think it has already been done. Ruffian is said to be a bitboarder but since I'm not sure about that I will mention Crafty instead. Crafty isn't quite a "top" engine you might say, but I don't think that has got anything to do with bitboards, I think that is because 1. it is open source 2. its selective search isn't very advanced. > Christophe (setting up a shield for the upcoming flame) Haven't you noticed, I _never_ flame decent people. :) -S.
This page took 0.04 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.