Author: Sune Fischer
Date: 09:18:15 08/21/04
Go up one level in this thread
On August 21, 2004 at 10:46:13, Robert Hyatt wrote: >>>extern BITBOARD set_mask_rr45[65]; >>> >>> >>>Those are just a few random tables, >> >>They aren't random at all, that's my point. > >That has been _my_ point. I run through a _lot_ of such tables. And that tends >to flush cache before something gets reused. A random probe into anything >replaces N bytes (a cache line). IE on my PIV that is a 1 byte access replaces >128 bytes of cache in one chunk. On my dual xeons, that is 4096 cache lines. >IE 4096 random accesses can completely flush cache. I think 4096 _random_ accesses is a lot. It's going to take you quite a few nodes to hit that number of accesses and most those accesses will not be random. >Who is ignoring that fact? I reported that when I first looked into buying my >first quad xeon, I benchmarked Crafty on the PII xeon with 512kb, 1024kb, and >2048kb of L2 cache. 1024K was 10% faster. 2048 was another 7% faster. Eugene >ran crafty on IA64 with 1.5mb L2 and 3.0mb L2 and found 3.0mb was 10% faster. > >Who is ignoring what? > >Tom ran on 256 and 512K and concluded the working set for crafty was < 256K. I >simply said the data doesn't support the conclusion. The conclusion _may_ be >right. But two of us ran on larger L2 boxes and got better performance. One >did not. Two of us ran up to 2048K, one only tried 256 and 512k. What you're saying here is basicly that Crafty has a working set that is much larger than 3 MB, for sure it is so much larger that no improvement can even be measured when going from 256 to 512 kB. I don't believe that. What I do believe however, is that to measure the influence of cache size you should run on identical machines (Eugene did not, I don't know about you). Secondly, consider we have other factors that would benefit from larger caches, things like the hash. Even if the cache could only store the last 1000 hash entries, those 1000 would also be the most interesting and most likely to be used next. How big is this effect? You don't know, so how do you know this is not what you're seeing when going from 1.5 to 3 MB cache? >What "problem" did I not isolate? I simply ran exactly the same program, on >exactly the same processors, but with three different cache sizes. I measured >the difference in speed and since the only difference was cache size, the speed >difference had to be attributed to that.. Correct, but how big a hash did you use? Suppose the cache was able to store half your hash. >Give me a break. There is but _one_ interpretation of the data I presented. >Bigger cache improves performance measurably for Crafty. What other >interpretation is possible from the data either I or Eugene have observed? There is a discrepancy with what others have seen, this must be explained somehow or your theory is not viable. I've aired a hypothesis that fits the data, further experiments are required to confirm it however. Two experiments I could think of: 1) do the same tests again, only this time with 0 kB main+pawn hash 2) add a "blow-out" table to be looped at every node and let it grow to see where the barrier is. -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.