Author: Robert Hyatt
Date: 11:48:09 02/13/04
Go up one level in this thread
On February 13, 2004 at 11:35:50, martin fierz wrote:
>looking at some crafty source code, i noticed this huge tree structure:
>
>struct tree {
> POSITION pos;
> PAWN_HASH_ENTRY pawn_score;
> NEXT_MOVE next_status[MAXPLY];
> BITBOARD save_hash_key[MAXPLY+2];
> BITBOARD rep_list[256];
> int rep_game;
> BITBOARD all_pawns;
> BITBOARD nodes_searched;
> SEARCH_POSITION position[MAXPLY+2];
> BITBOARD save_pawn_hash_key[MAXPLY+2];
> int current_move[MAXPLY];
> int hash_move[MAXPLY];
> int *last[MAXPLY];
> PATH pv[MAXPLY];
> unsigned int fail_high;
> unsigned int fail_high_first;
> unsigned int evaluations;
> unsigned int transposition_probes;
> unsigned int transposition_hits;
> unsigned int transposition_good_hits;
> unsigned int transposition_uppers;
> unsigned int transposition_lowers;
> unsigned int transposition_exacts;
> unsigned int pawn_probes;
> unsigned int pawn_hits;
> unsigned int egtb_probes;
> unsigned int egtb_probes_successful;
> unsigned int check_extensions_done;
> unsigned int recapture_extensions_done;
> unsigned int passed_pawn_extensions_done;
> unsigned int one_reply_extensions_done;
> unsigned int mate_extensions_done;
> KILLER killers[MAXPLY];
> int move_list[5120];
> int sort_value[256];
> signed char in_check[MAXPLY];
> signed char phase[MAXPLY];
> int search_value;
> int w_safety, b_safety;
> int w_kingsq, b_kingsq;
> int endgame;
> int root_move;
> lock_t lock;
> int thread_id;
> volatile char stop;
> char root_move_text[16];
> char remaining_moves_text[16];
> struct tree *volatile siblings[CPUS], *parent;
> volatile int nprocs;
> int alpha;
> int beta;
> int value;
> int wtm;
> int depth;
> int ply;
> int mate_threat;
> int lp_recapture;
> volatile int used;
>};
>
>i have many of these things in my program too of course, but they are not
>grouped together as one huge structure. i have two questions about this:
>
>-> i guess this is designed to be faster than keeping all variables separately
>in memory - is this correct? and if yes, does this really make a significant
>difference?
That isn't the main reason. I group those together as they represent the
"search state" of the tree being searched. With multiple threads, each needs
its own copy of the bitboards, repetition list, all that stuff. Each thread
accesses the data above via tree-> references so that the threads don't interact
with each other in bad ways.
I didn't do the "tree" stuff until the first SMP version.
>
>-> i never lumped together my counters like this, because i thought that if i
>had one global struct with all counters in it, dereferencing the struct (to do
>something like
>
>counters->nodes++; or
>counters->hashlookups++;
>
>would take a little time, so i do
>
>nodes++; and
>hashlookups++;
That doesn't hurt a thing. If it is a static structure, then accessing a
variable within the structure is no more/less efficent than simply accessing a
global variable directly... There is a plus for the struct however, it does let
me guarantee that two variables are close together in memory so that when one is
referenced, both get sucked into cache if I need the other one soon.
int a,b doesn't guarantee that a and b are adjacent in memory unless they are in
a structure.
>
>obviously bob thinks otherwise :-)
>is dereferencing a struct essentially free, or is there a cost (in cycles) that
>can be assigned to it?
>
>cheers
> martin
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.