Author: Robert Hyatt
Date: 08:20:19 09/02/03
Go up one level in this thread
On September 02, 2003 at 00:26:00, Uri Blass wrote: >On September 01, 2003 at 23:45:45, Robert Hyatt wrote: > >>On August 29, 2003 at 18:26:46, Dave Gomboc wrote: >> >>>On August 29, 2003 at 08:53:50, Robert Hyatt wrote: >>> >>>>It isn't big enough to hold even the stuff I need to generate moves. I have >>>>multiple arrays of 64 X 256 X 8bytes, that I use repeatedly. One of those >>>>is enough to zap L1, although I don't need the entire table at one shot. But >>>>I do need parts of four of those, and that is just for starters... >>> >>>Well, it's either a software implementation issue or a software design issue, >>>then. Your call. :-) Blowing L1 cache just to generate moves seems >>>unreasonable. >>> >>>Dave >> >> >>It is easy to blow L1 with _many_ things. > >Like always I do not understand these discussions. >I read claims like >L2 is not a good place to keep your heavily used data. > >I do not understand how do you keep your heavily used data in L2. > >Maybe an example may help me. OK. First, you don't do _anything_ specifically to put data into L2. When you access _any_ memory address, the CPU passes that address out to "memory". The first stop is L1 cache, where the requested address might already be. If so, L1 returns the data to the CPU and you are done in one cycle. If L1 doesn't have that address, L2 is checked. If it has the data, you get it, but with a slightly longer delay (6 clocks is common.) If it isn't in L2, then you wait for real memory to supply the data, which is then copied to L2 _and_ to L1. This takes a bunch of clocks, adding up to 120-150ns total. Data stays in L1/L2 as long as possible, but they are not that big. IE L1 on the PIV has 16kb, L2 has 512kb, while main memory commonly is at least one gigabyte. Each time you reference something, the above hierarchy is used. Data is replaced in cache using a common LRU replacement policy (it is a bit more complicated due to 4-way to 16-way set associativity but that is not that important here). All you have to do to keep something in L1/L2 is use it _often_. > >I need Definition of the heavily used data in Crafty. That's not easy. But the move generation tables are good examples as they get beat on _every_ node when I generate moves. Of course, L1/L2 cache also contains instructions in addition to data, so instructions you execute frequently stick around there as well. Say your InCheck() function, or (in the case of Crafty) FirstOne() or LastOne() or PopCnt(). >I need to understand how do you decide that it is the heavily used data( a >profiler may tell me how much time I use for a function but I do not know if it >can tell me information about time that is used for a specific data structure) >and I need to understand how do you tell the computer to keep the heavily used >data in L2. That's the point. _I_ don't have to decide. The CPU discovers this by running the program and letting its cache line replacement policy hopefully end up with the important data stuck in cache. The most-used data should be in L1, with the L2 as a backup for that. Least-used data ends up being only in main memory which means it is much slower to fetch. > >Uri
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.