Author: Dann Corbit
Date: 13:20:46 06/20/02
Go up one level in this thread
On June 20, 2002 at 16:02:04, Robert Hyatt wrote: >On June 20, 2002 at 15:58:29, Tom Kerrigan wrote: > >>On June 20, 2002 at 15:25:36, Sune Fischer wrote: >> >>>So what you are saying is that you can't just count the number of operation and >>>use that to pridict the speed? >> >>Counting the operations is difficult. You can't just go through the source code >>and count them because that doesn't tell you how often the code is run. >> >>>Now if Crafty is 50% 64 bit operations then we can expect a factor of two in >>>speedup on that 50%, right? >> >>I think Crafty must be << 50% 64 bit operations. Think about all the data that >>Crafty must operate on that isn't bitboards... >> >>-Tom > > >Which data is that? The top 80% in profiling depends on bitboards heavily. >generating moves, evaluating positions, updating the bitmaps in make/unmake, >detecting checks, evaluating Swap(). > >I doubt it is << 50% (where << typically means "much less than"). There are a large number of bitboard chess programs that I have run through the Intel profiler. For the majority of them, the bottom-line bottleneck is 64 bit shift right and shift left. The profiler identifies hot-spots in the code and draws thicker lines to the worst offenders. The real, bleeding problems are identified by thick red lines. Often, it is the shift routines at the bottom, holding up the show. With crafty, it is harder to see because the use of assembly functions removes some of the detail that is normally available in the profiler. Just for fun, here is the crafty profile map: ftp://cap.connx.com/pub/crafty.jpg
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.