Author: Eugene Nalimov
Date: 10:35:56 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?
>
>-> 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++;
>
>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
Your program is not multiprocessor-aware, right? :-)
Thanks,
Eugene
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.