Author: Sune Fischer
Date: 10:20:08 08/22/04
Go up one level in this thread
On August 22, 2004 at 11:14:40, Robert Hyatt wrote: >On August 22, 2004 at 04:57:56, Sune Fischer wrote: > >>On August 21, 2004 at 21:14:57, Russell Reagan wrote: >> >>>On August 21, 2004 at 12:18:15, Sune Fischer wrote: >>> >>>>What you're saying here is basicly that Crafty has a working set that is much >>>>larger than 3 MB... >>> >>>You are not understanding what Bob is saying. He is not saying that Tom's >>>conclusion is wrong. He is saying that Tom's experiment does not *prove* Tom's >>>claim. Tom's conclusion may be correct. Tom's experiment may *support* his >>>conclusion. However, it doesn't *prove* his conclusion to be correct. >> >>Ehh Russel, what he says he is saying and what he is actually saying is two >>different things, IMO. >> >>If you read again you'll soon discover he seems very sure that he is blowing the >>cache continually and hence seems to claim there is no way it can fit in 256 kB. > > >So? That was the departure point for my original post. I presented data that >showed improved performance for bigger cache. Eugene did as well. If given the choice I prefer fresh data. You probably tested a different version back then and Eugene's test was not with identical systems "Unfortunately that did not answer original question, as CPUs have not only different cache size, but also different cache associativity. 1.5Mb was 6-way associative. 3Mb was 12-way associative." > By any >definition you care to use, if you increase cache size, and the program runs >faster, then its working set was larger than the _smaller_ cache size. Like I wrote above... > Cache >size > working set will _not_ make the program go faster. It can't. I think that this is kind of moot, there probably isn't a razor sharp limit on the working set. I do not see the main hash ever becomming part of the "working set" yet it is obvious how this could benefit from a larger cache. >So I suppose I _still_ miss the point here somewhere... > Oh? :) > >> >>Calling it badly flawed is an unnecessary exaggeration too IMO, it would have >>been more diplomatic to say something like "well your data is very interesting >>and certainly calls for further testing, at this stage however I'm not fully >>convinced you have sufficient data to make any solid conclusions....". >>Of course that's _not_ how we discuss things on this board ;) >> >>I certainly agree that it would appear that Crafty has a much bigger working >>set. Exactly how big this set is and in what way it gets used and re-used inside >>the program is very non-trivial to figure out IMO. >>I have a lot of tables too, but many of them are used scaresly like e.g. the >>king-pawn race table is only used in the far endgame, so I would not consider >>that as part of the working set under normal circumstances. >> >>Although Bob says he has "serialized" everything I'd rather not make too many >>assumptions about it but simply run a few tests. > > >Bob didn't say "he had serialized everything". He said "he had serialized some >important things." Just run a pre-CCT6 version against the current version on a >MOESI cache box to see what happens with parallel search NPS. Let's not split hairs here, I'm pretty sure you threw this argument into the mix about the time we discussed why in the world there wasn't a performance increase from 256 to 512 if the working set was larger than 256. You said something like it has been serialized and gave a very oddball example with looping through an array as though that was the way Crafty searched. But back to something interesting now. I think not getting any speed up at all from increasing cache is kind of strange in fact. I guess either the HT caching doesn't matter all or Crafty really is looping though a huge working set and trashing so extremely bad that 512 isn't any better. I'm not sure which is the most likely, or perhaps there is a third and more plausible explanation? -S.
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.