Author: Johan de Koning
Date: 22:50:46 08/27/03
Go up one level in this thread
On August 27, 2003 at 12:25:51, Robert Hyatt wrote: >On August 26, 2003 at 21:12:45, Johan de Koning wrote: [snip] It seems we're finally back to where you and me started off. >>You keep saying that copy/make causes problems with cach to memory traffic. >>Here I was just saying it doesn't, if cache is plenty. > >Here is the problem: > >When you write to a line of cache, you _guarantee_ that entire line of cache >is going to be written back to memory. There is absolutely no exceptions to >that. So copying from one cache line to another means that "another line" is >going to generate memory traffic. Here is the solution: write-through caches were abondoned a long time ago. And for good reason, think of the frequency at wich data is written (eg just stack frame). Once CPU speed / RAM speed hits 10 or so, write-through cache will cause almost any program to run RAM bound. >>> I claimed that for _my_ program, >>>copy/make burned the bus up and getting rid of it made me go 25% faster. >> >>And I suspect this was because of a tiny cache that couldn't even hold the >>heavily used stuff. > >This was on a (originally) pentium pro, with (I believe) 256K of L2 cache. L2 is not a good place to keep your heavily used data. >However, I found the _same_ problem on other architectures, such as the Sparc >(super-sparc). However, I believe it would happen on my 1M L2 cache 700 >mhz xeons as well, because my "kernel data" is quite large and anything that >displaces it from cache will hurt. Anything could happen, but is it worth the debugging and the added complexity if you don't even know the hot spots? Or reversed: if under slightly different circumstances the gain would have seemed to be around 0, would you have kept the prepare_undo and unmake code? ... Johan
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.