Author: Gerd Isenberg
Date: 05:47:05 01/07/05
Go up one level in this thread
On January 07, 2005 at 04:15:37, Daniel Shawul wrote: >On January 06, 2005 at 19:53:58, Dann Corbit wrote: > >>On January 06, 2005 at 19:15:58, Pallav Nawani wrote: >> >>>On January 06, 2005 at 18:18:40, David B Weller wrote: >>> >>>>Hi Geoff, >>>> >>>>The fact that you stumble over my code is probably a credit to your >>>>intellegence, and if I tried to explain: attack_mask[][], I would embarass >>>>myself. >>>> >>>>In fact, while thinking over how to best answer your question, I too became >>>>somewhat puzzled as to how what I did, actually improves GES performance. It >>>>really is inacurate. >>>> >>>>The part I added is at the end of control.cpp and 1 line in evaluate.cpp : >>>> >>>>s += count_ctrl() * 3; >>>> >>>> the '3' is pulled from memory - I think Prof Hyatt used it for Bishop mobility, >>>>but since what I am counting isnt the same, it is probably way off. WAY off. >>>> >>>>The basic idea of count_ctrl() is to detirmine who 'owns' each of the 64 >>>>squares. But it is very simple and naive. It makes assumptions which are >>>>probably true more often than not, but still wrong much of the time. eg., if >>>>white has a pawn attacking a square, but black doesnt have a pawn attacking that >>>>square - white owns the square. regardless of what else is attacking it. If both >>>>have pawns attacking [or, niether do] then the same idea is applied for knights. >>>>Then Bishops, then Rooks, then Queens. >>> >>>So what you are evaluating is board control. I had no idea it was that useful. >>>Maybe I will try implementing that (after I have implemented attack tables, that >>>is). >> >>A bitboard program will have a stupendous advantage here [considering again >>Fabian's code]. >> >>If you look at the eval function (where he calculates mobility) with a bitboard >>program you can precompute EVERYTHING and every single nested loop goes away. >> >>By a stupendous margin, all of his program's time is bottled up by eval(). >> >>If Fabian's program were converted to bitboard, it could run 5x faster. How's >>that for a scary thought? > Hi Dann > 5x faster is probably an exaggeration. I have my self a copy of evaluation >function without attack tables(ie using attack functions). When i use that one >it increases NPS by <=100000 which is 25% speed up. Besides if you are going to >use bitboards you loose all the nice evaluation you can do with the attack >tables. King Safety and Square control are some examples. >As demonstrated on Ed's page it is even possible to SEE. >With bitboards it is only possible to compute a fair mobility fucntion but no >more. >best >daniel > Hi Daniel, sorry if i don't aggree with you. With bitboards you can bild Ed like attack-tables rather effiecient. It is even possible to build several sets of taboos for all kinds of pieces even more effiecient. Bitboards have some advantages and disadvantages, other Board representations as well. Single or low populated bitboards are obviosly more inefficient than higher populated bitboards, because of lower data density and loss of immanent parallelism. Using bitboards or 0x88 or whatever is probably more a matter of taste, thinking patterns and paradigms. I like bitboards and believe that bitboards are fine and may gain more parallel speedup with future or current 64-bit and SIMD architetures. Possible examples are some kind of dynamic mobility, by passing sets of eg. Bishop attacks, intersected with some taboo complement, back to diagonal fill routines, to get set of squares reachable in two moves - eg. for looking for some attacking or defending trajectories like controlling far stopp squares of opposite passers, etc. Or such tiny things like bit[54]*byte[64] dot-products in 30 amd64 cycles. I agree that it is possible to write bad programs with both board representations - and that board representation is probably a minor aspect to get a superior branching factor. Cheers, Gerd
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.