Author: Robert Hyatt
Date: 18:36:57 08/20/04
Go up one level in this thread
On August 20, 2004 at 19:09:20, Sune Fischer wrote: >On August 20, 2004 at 13:03:28, Robert Hyatt wrote: > >>On August 20, 2004 at 12:05:59, Tom Kerrigan wrote: >> >>>On August 20, 2004 at 05:10:10, Tony Werten wrote: >>> >>>>On August 20, 2004 at 04:33:07, Tom Kerrigan wrote: >>>> >>>>>Now that AMD is selling two processors that are identical other than L2 cache >>>>>size (Sempron has 256k, Athlon 64 has 512k) we have proof of Crafty's working >>>>>set size: >>>> >>>>Or that it's >> 512 >>>> >>>>Basicly, this only proves that it's not between 256 and 512. >>> >>>That's not how cache works. By that rationale, you might as well not have any >>>cache at all. See my reply to Bob above. >>> >>>-Tom >> >> >>Tom, that is _exactly_ how cache works for some reference patterns. > >I don't believe this pattern is an accurate model for a chess engine. Believe what you want. I spent a fair amount of time making this so for Crafty to improve cache utilization. IE I _want_ to access memory serially to take advantage of pre-fetching through cache line fills. And I re-ordered chunks of data to make this happen. > >> See my >>reply to you above. You don't yet have enough data to conclude anything about >>the working set size. you might be right. You could definitely be wrong. At >>present, there is no valid way to say, based on running on two small cache >>processors. > >Then let's design a way :) > >For instance, say Crafty has a working set of 200 kB, try and add a dummy table >of 1 kB to your working set by looping through this at every node. > >Now run the test again with increasing table sizes until you get hit with a big >slowdown. That's when you start serious trash caching. > >Of course it assumes there's no trashing to begin with, but since Crafty is a >pretty fast searcher I don't think there are any big cache issues. "You don't think there are any big issues..." "I _know_ there are". I've actually measured it, analyzed it, and worked on it both with folks at Microsoft through Eugene, and through folks at AMD... > >Granted there are a lot of small tables and they probably add to more than 256 >kB, but I bet most of those are used only sparsely. move generation tables extern signed char directions[64][64]; extern BITBOARD w_pawn_attacks[64]; extern BITBOARD b_pawn_attacks[64]; extern BITBOARD knight_attacks[64]; extern BITBOARD bishop_attacks[64]; extern BITBOARD bishop_attacks_rl45[64][64]; extern BITBOARD bishop_attacks_rr45[64][64]; extern BITBOARD rook_attacks_r0[64][64]; extern BITBOARD rook_attacks_rl90[64][64]; extern int bishop_mobility_rl45[64][64]; extern int bishop_mobility_rr45[64][64]; extern unsigned char bishop_shift_rl45[64]; extern unsigned char bishop_shift_rr45[64]; extern int rook_mobility_r0[64][64]; extern int rook_mobility_rl90[64][64]; extern BITBOARD rook_attacks[64]; extern POSITION display; extern BITBOARD queen_attacks[64]; extern BITBOARD king_attacks[64]; extern BITBOARD king_attacks_1[64]; extern BITBOARD king_attacks_2[64]; extern BITBOARD obstructed[64][64]; extern BITBOARD w_pawn_random[64]; extern BITBOARD b_pawn_random[64]; extern BITBOARD w_knight_random[64]; extern BITBOARD b_knight_random[64]; extern BITBOARD w_bishop_random[64]; extern BITBOARD b_bishop_random[64]; extern BITBOARD w_rook_random[64]; extern BITBOARD b_rook_random[64]; extern BITBOARD w_queen_random[64]; extern BITBOARD b_queen_random[64]; extern BITBOARD w_king_random[64]; extern BITBOARD b_king_random[64]; extern BITBOARD stalemate_sqs[64]; extern BITBOARD edge_moves[64]; extern BITBOARD enpassant_random[65]; extern BITBOARD castle_random_w[2]; extern BITBOARD castle_random_b[2]; extern BITBOARD wtm_random[2]; extern BITBOARD clear_mask[65]; extern BITBOARD clear_mask_rl90[65]; extern BITBOARD clear_mask_rl45[65]; extern BITBOARD clear_mask_rr45[65]; extern BITBOARD set_mask[65]; extern BITBOARD set_mask_rl90[65]; extern BITBOARD set_mask_rl45[65]; extern BITBOARD set_mask_rr45[65]; Those are just a few random tables, not counting the actual stuff in my TREE structure that gets "swept over" many times in a search.. bitboard programs are not very small. But the disadvantages of size are offset in other ways, particularly as cache gets bigger and bigger. This ignores hashing and repetitions and everything else. testing says bigger hashes help. At least for the testing I reported, and for the test results Eugene reported. I can't say more but I can say what I have actually _measured_. > >-S.
This page took 0.01 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.