Author: Gerd Isenberg
Date: 14:14:30 09/10/02
Go up one level in this thread
On September 10, 2002 at 13:51:02, Kim Roper Jensen wrote: >Hi > >I just got an idea or maybe just a brain meltdown, but how about this ? > >Assumption: >=========== >In a bitboard evaluation routine, some bitboards will be generated multiple >times for various > >evaluations. > >Idea for Optimization: >====================== >Make an editor where the evaluation routine is described in a meta-language. >Then let the editor/parser analyze the various subcomponents in the evaluation >routine and optimize > >/rearrange the code so there a minimum amount of duplicate generated bitboards. >Convert the code to a source file in C/C++/Java etc. and compile the chess >program. > >Shouldnt this give a improvement in execution of the evaluation routine ?? > >PS. I know it looks like the Che+ language of Nimzo, I dont have Nimzo so I dont >know if its the > >same, but it is the idea of the code rearranging that I wanted to ask about. > >PPS. My crappy(yes thats the name of the program if it isnt taken by someone >else) little program > >doesnt use bitboards(yet :) so maybe im way off here. nice idea, some aspects... First you have the incremental updated associated/embedded in your node object(4 rotated occupied, 6 for all kind of pieces, 2 for black/white). Quite often, not only during eval, you may need to "and" the piece bitboards with the color bitboards to get specific piece sets for one side. One idea is to precalculate these once after doMove or even incrementally, but that implies to enlarge your recursive node-structure with possible cache drawbacks. I prefere calculating them on the fly, doing some "and" here and there. Of course the are several often used recursive bitboards i initialize after incremental update like pinnedPieces, pawnAttacks[2], pawnTargets[2] and so on. Other bitboards, like GetAttackedBy(int otherThanKingSquare) are often called conditionally very rarely with specific squares, that it is too expensive to precalculate them all. Often used BitBoards for Evaluation are another issue. There is no need for recursive varibales. I put them in a class/structure, so that there are accessable in all eval functions and initialize them in sevaral phases. Most cheap ones at eval startup, but some expensive during specific piece evaluations, which implies a specific piece evaluation order. Some expensive bitboards are used conditonally very rarely here and there. I use some initial cleared flags in the eval class/struct, to avoid multiple calculation. But it occurs that i implement some (bitboard) pattern and i'm thinking "hadn't i done similar things a few month ago, but where?". Important to detect common subexpressions is abstraction level (inlines, templates) and common identifiers for locals with same semantic (attackedByQueenBB, rookAttacks). 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.