Author: Robert Hyatt
Date: 15:04:31 08/22/04
Go up one level in this thread
On August 22, 2004 at 13:20:08, Sune Fischer wrote: >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. No, I gave a simple example of why his test didn't prove _anything_ about the working set size of Crafty. > >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? > No idea. Remember that I didn't start the discussion, and I really don't care about the answer, since I'm not making decisions based on cache footprint at the moment. All I attempted to do was point out that testing on X and 2X cache, and getting no speed improvement does _not_ mean working set is <= X. It _could_ mean that is the case. But it does _not_ prove that it is. That was my point. My _only_ point. All the other stuff has been random noise... >-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.