Author: Johan de Koning
Date: 00:45:09 08/23/03
Go up one level in this thread
On August 22, 2003 at 10:45:11, Robert Hyatt wrote: >On August 22, 2003 at 02:53:06, Johan de Koning wrote: > >>On August 21, 2003 at 11:29:49, Robert Hyatt wrote: >> >>>On August 21, 2003 at 03:16:35, Johan de Koning wrote: [snip] >>>>Hence I dare to ask: 25% of what? >>> >>>NPS went _up_ by 25%+. So total engine speed. >>> >>>This was changed in Crafty version 9.16, which dates back many years. >> >>Whoah! This is *very* hard to believe. >>There must have been something severely wrong with 9.15 then (continuing chache >>trashing comes to mind, but that's just guessing). More likely, this number does >>not come from a clean comparison of copy/make versus make/unmake. > >The _only_ change made was to replace copy/make with make/unmake. Think about >the math. Thinking about the math is easy. Doing the math in order to get valid results is much harder since it requires facts to start with. > Copy/make copies 256 bytes+. Once _every_ node. On today's >hardware, my dual xeon 2.8, I search about 2.4M nodes per second. or about >400ns per node. Copying 256 bytes is certainly going to show up on the radar >in a significant way, when it gets done once every 400 ns. To start simple, at 2.4 MN/s the average node takes 833 ns, or 2333 cycles. That's a fact. :-) The next interesting fact is the time it takes to copy from cache to cache. Unfortunitaly, I don't know this fact, so doing the math stops here (while thinking about it continues :-). I just conducted a simple experiment on an Athlon Thunderbird 1333 MHz with my engine doing about 250 kN/s. Adding an unused copy (440 bytes) to the usual copy/make shows up as approx 3% in the sampling profiler (that is the single instruction repe movsd). Doing the math revealed that this 3% means about 180 cycles per copy of 110 ints. Since I've heared that Athlon reads take 3 cycles, and I've heared long ago that K6 allowed 2 reads and 2 writes at the same time it does make sense. So I'll venture to say it is *almost* a fact that AMDs do blockmoves at a rate of 64 bit in 3 cycles. I'm still pretty factless though about blockmove speed of P{I...IV}, not to mention the next generations. > Yes, when you do >a copy, it will start off cache-to-cache. But once you do that cache-to-cache >copy you are committed to eventually doing a cache-to-memory write-back. This is the final interesting fact. But also the most non-fact, since it depends almost everything. In my little experiment above, the extra copy took only 3%, but the actual run time went up 5.5%. This may not mean much because 1 extra line in main() can easily change the runtime by 1 or 2% (for reasons I haven't fathomed yet). It may also mean that data cache is actually getting trashed, and I'm lucky not to use large tables on a regular basis. ... 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.