Author: Bruce Moreland
Date: 15:12:58 01/14/03
Go up one level in this thread
On January 14, 2003 at 05:47:51, Rémi Coulom wrote: >On January 13, 2003 at 13:16:33, Bruce Moreland wrote: > >... >> >>Checking specifically for pawns is probably right. Looking at two squares on >>the board is probably faster than spinning through 8 pawns. > >I agree with you. I first suggested that testing for pawns first might not be a >good idea, but I had not noticed that the piece list was sorted. The question is >now: is it a good idea to keep the piece list sorted? I suppose it adds >complexity to the make/unmake functions. Bas says it helps MVV/MVA move >ordering, but I tend to believe that ordering moves based on MVV/LVA only is not >very good. I posit without hard evidence MVV/LVA is bad. The reason it is bad is that it is difficult to prune out any captures. The classic use of a SEE is to disallow losing captures in quiescence. This is tremendously better than allowing all captures in MVV/LVA. If you want to be harsher, you can disallow winning captures that don't raise the score above alpha. This is easy to do with a SEE. You can try to do it with MVV/LVA, but some bad ones creep in. For example, let's say that you are four pawns below alpha. QxR, winning a rook, would be allowed by both MVV/LVA and SEE "harsh" pruning systems. But if QxR PxQ, QxR would be pruned out by the SEE, because rather than winning five pawns, it loses four. >>I think that the problem here is that he has a loop in the first place, which is >>just an aspect of 0x88. > >> >>I don't know how the bitboard "attacked" function works, but if it does less >>work, it's going to be faster. > >I agree too. 0x88 might slower on attack detection, but the speed of >makemove/unmakemove compensates so that perft should be faster on a 0x88 >implementation than with crafty. Move generations schemes have side-effects that affect attack detection (also SEE), make/unmake, move sorting, evaluation, and various things like easy of doing history heuristic, killer moves, etc. If one system generates moves fastest, it is not the best system if you can't sort the moves properly. You can go 1,000,000 nps and be out-searched by someone going 200,000 nps, if you are searching variations in spectacularly wrong order. >Also, my general advice to anobody starting to write a chess programs is that >spending huge amounts of time optimizing the low-level functions is probably not >an efficient way to obtain a good level of play. I suppose most top-level >programs could have their basic functions (make/unmake, genmoves, attacks) twice >slower without very significant losses in strength. Here is how it should work: Make a program by hook or crook, and get it playing chess automatically on a server, preferably ICC. Do this as quickly as possible. Either throw it away and start over, or fix it. Having gained practical experience will help immensely. I agree that most good programs could have their main functions slowed down and still play very well. bruce
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.