Author: Keith Evans
Date: 13:41:30 07/18/03
Go up one level in this thread
On July 18, 2003 at 15:21:35, J. Wesley Cleveland wrote: >On July 17, 2003 at 18:25:51, Robert Hyatt wrote: > >>On July 17, 2003 at 17:35:33, Dieter Buerssner wrote: >> >[snip] >>> >>>I cannot find any randomness in the reads of lm-bench (I downloaded latest >>>stable source today, not the experimental version, available, too). If it would >>>do random reads, it would have no way to avoid the problem with the TLBs you >>>explained. >> >>4M pages solves it for at least 250mb worth of RAM. But then again, _no_ chess >>program depends on purely random memory accesses to blow out the TLB. The only >>truly random accesses I do are the regular hashing and pawn hashing, which >>both total to significantly less than the total nodes I search. Which means >>the TLB penalty is not even 1% of my total run time. Probably closer to >>.01% - .05%. >> >>I ignore that. > >Why do you think it is that low? I get ~20-30% of nodes have hash probes with >crafty. If you are getting 1m nodes/sec, then this is a probe every 3-5 usec. >With a very large hash table and 4K pages, the large majority of these will >cause a TLB miss. At 200 nsec each (a guess), this could be up to 5% of your >total run time. > >[snip] Also from "AMD Athlon™ Processor x86 Code Optimization Guide" "The L1 data cache has an associated two-level TLB structure. The first-level TLB is fully associative and contains 32 entries (24 that map 4-Kbyte pages and eight that map 2-Mbyte or 4-Mbyte pages). The second-level TLB is four-way set associative and contains 256 entries, which can map 4-Kbyte pages." So I don't think that "4M pages solves it for at least 250mb worth of RAM" on the Athlons. It would be interesting to hear what steps, if any, can be taken to minimize this problem. Both from a user's and a programmer's perspective.
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.