Author: Robert Hyatt
Date: 07:52:23 08/25/04
Go up one level in this thread
On August 25, 2004 at 06:06:24, Tom Kerrigan wrote: >Here's your first experiment, cache misses per node: > > === cache misses per node === >size inst data total >128K 0.36 7.66 8.05 >256K 0.21 3.33 3.54 >512K 0.04 2.00 2.04 >1M 0.04 1.28 1.32 >2M 0.04 1.05 1.09 > >Now here's your new data, same thing: > > === cache misses per node === >size inst data total >128K 0.71 4.33 5.04 >256K 0.68 1.92 2.60 >512K 0.00 0.46 0.46 >1M 0.00 0.15 0.15 >2M 0.00 0.00 0.00 > >Let's go back to your little wager: > >>I can do that and will report the results later. Want to wager whether it >>changes things or not with respect to my working set size estimations??? >>Think about it before you answer. > >Too bad you posted the data before I answered, because I would have taken this >bet and won. As you can see from the tables, your first set of data completely >misrepresents the number of cache misses that occur during search once the cache >is warmed up. > My issue was _never_ "cache misses". It was _always_ "how big does cache have to be to contain enough of Crafty to not have many misses?" The answer is obvious from _either_ set of data. There are definite "points" where cache size increases for either instructions or data stop reducing the misses. That is the cache size that contains nearly everything, and it gives a pretty good benchmark for the instruction or data working set sizes. If you can't follow that, it isn't my problem. I _knew_ that you would be unable to see the forest for the trees. And that posting the numbers would only serve to divert the conversation to a _different_ topic, which it has. But if you just look at the numbers, there are distinct sizes where cache misses drop to a nearly constant point. You _can_ draw conclusions from that. If you want to... >If you plot the total misses, your 1st experiment showed a gradual decline in >misses as cache size increased, so it's easy to conclude that your working set >is "big." Thankfully we have this new data, which shows a huge dropoff between >the 256k and 512k numbers. So yes, this should definitely change your working >set size esimations. It surprises me that it hasn't, but then again, I >understand that you have your fragile ego to protect. Nope. I believe I reached the same conclusion, which is _definitely_ that cache footprint is > 512K which was _not_ what you were claiming. Instruction footprint is between 128K and 256K. Data footprint seems to be between 512K and 1024K. So I suppose I completely miss your point since your original claim does not fit this data. And this data shows why I continued to get better performance with larger L2 on my tests. > >BTW, I estimate that Crafty does around 400 data memory accesses per node: > >(2GHz / 1.2M NPS) * 25% (conventional wisdom) 2.4ghz opteron == 2.4M nodes per second, for reference. My Intel box is 2.8ghz producing about 1.0M nodes per second. > >So even if you have the relatively high number of 4 misses per node, you're >still getting a 99% hit rate. I'd hardly call that thrashing the cache with all >sorts of random accesses, which is what you've been claiming Crafty does. Look at the smaller cache sizes. And remember that the _number_ of misses is irrelevant, it doesn't deal with pre-fetching since my line size was 16 bytes. It isn't the _number_ it is the scale of the number that is important here, in trying to estimate cache footprint. > >-Tom
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.