Author: Tom Kerrigan
Date: 18:13:49 08/22/04
Go up one level in this thread
On August 22, 2004 at 18:15:55, Robert Hyatt wrote: >On August 22, 2004 at 17:12:05, Tom Kerrigan wrote: > >>On August 22, 2004 at 11:10:33, Robert Hyatt wrote: >> >>>Simple. I access a batch of random attack entries. I then access a _lot_ of >>>other stuff before I come back to the attack entries. Your 256K cache has 4K >>>lines. I don't know what the set associativity is, as AMD has lots of options >>>there in recent history. But that further reduces the number of "buckets" to >>>stuff stuff in. My xeon claims 16-way set associativity, with 128 byte lines. >>>That turns into a paultry 256 sets. It is very easy to get a bad physical >>>memory layout where you don't even use all of those sets, and where some sets >>>get badly overloaded. >> >>This is a bunch of nonsense. You make it sound like associativity somehow >>decreases the amount of cache you have. Really, associativity has no place in >>this discussion, except maybe to note that it reduces the behavior that you're >>complaining about, namely random accesses evicting important data from the >>cache. > >Then you don't understand set associativity. It _does_ influence what goes >where. Physical memory maps directly to a set. A program doesn't necessarily >use _every_ set in cache due to poor physical memory layout decisions by the >O/S. The hardware textbooks I have say that the lower order bits of an address determine which set the cache line goes to, so if you use a certain amount of contiguous data (e.g., 64KB for an Opteron), it WILL make use of every set, regardless of where the OS has located your program. Do you have reason to believe this isn't the case for the processors in question? >>But let's say you do randomly access your working set. How about you explain how >>performance isn't increased going from 256k to 512k cache? > >I believe I already answered. I _can't_ explain it because I _can't_ reproduce >it. Why do you have to reproduce it to be able to explain it? How does reproducing it get you any closer to an explanation anyway? I didn't even produce the data in the first place (Anandtech did) and I explained it. >>large percentage of your maximum possible working set... Windows reports that it >>only allocates 5MB for Crafty, including hash tables, tables that never get > >Strange number. Linux reports 20M. >How can it use 5mb when the default hash sizes total 4 megs? >IE start crafty and type "hash" and "hashp". You get almost 4 megs for those. >There are 128 TREE blocks also, but they get malloc()'ed. That is way over a >meg total... >5mb has to be wrong... I have Volker Pittlik's build of Crafty 19.7. It's on the web. Download it, run it, bring up task manager, and look at the number in the column on the right. Declaring that it "has to be wrong" just makes you look more like an idiot when you figure out that it's actually right. -Tom
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.