Author: Chris Whittington
Date: 07:30:29 11/27/97
Go up one level in this thread
On November 27, 1997 at 09:20:53, Robert Hyatt wrote: >On November 27, 1997 at 04:43:04, Chris Whittington wrote: > >> >>On November 26, 1997 at 21:52:10, Robert Hyatt wrote: >> >>>On November 26, 1997 at 15:54:48, Tom Likens wrote: >>> >>>> >>>>How about "because Bob's a damn good programmer!!" :) >>>> >>>>Bob, you've gotta' love messages like this. So much more satisfying >>>>then >>>>why did Crafty X.XX lose to Mega-Chess 1E6 on such-and-such a date. >>>> >>>>To really address the question, from my perusal of Crafty's source code, >>>>it seems to do an excellent job of move ordering and intelligent move >>>>extensions. Both key components of a fast program. >>>> >>>>--Tom Likens >>> >>>while it's move ordering is not bad, it is not particularly exciting. >>>The >>>stuff I do here is the same stuff I did in Cray Blitz for many years. >>>That >>>part of the search is well-known... >>> >>>Part of the speed has been the direct result of bitmap development. >>>When I >>>started, I knew nothing about it. I made a promise to myself that I was >>>going >>>to stick with them for at *least* 3 years, to give myself a chance to >>>become >>>familiar with them, and get into the mode of "thinking bitmaps." It is >>>now >>>natural, thankfully, and they offer a lot. They *really* offer a lot >>>when it >>>comes to 64 bit architectures, because they are designed to work on such >>>machines efficiently... >> >>If I remember rightly, Crafty didn't get such a vast nps improvement on >>the alpha in Paris, certainly not as much as I'ld been expecting ..... >> >>What is Crafty nps on say a PP200, compared to an alpha 500 ? >> >>And could you factor out for us the nps change due to the architecture >>only ? (I know this is fraught with difficulties, but please take a shot >>at it). >> >>Chris Whittington > > >All I can respond with here is that Jason ran a suite of 6 test >positions, >two opening, two middlegame and two endgame positions. On the P6/200, >we >averaged 80K across them. On the alpha/500 we averaged 250K across >them, >which is roughly 3.1X faster. > >Bruce reported 1.7X improvement (P6/200 to 21164/533). So this is >probably >the "pure" mhz improvement expected here. Our machine was almost 10% >slower >(500mhz) but our improvement was almost 2x over what Bruce reported. >This is >likely attributed to the 64bit vs the 32bit architectural difference. >But it >is all speculation. > >One point here is that Crafty favors the P6/200 because I have tuned for >that, >particularly after studying the Intel manuals that explain the processor >architecture. We have done *no* tuning for the alpha. Joel Rivat >reports >that I crush him speed-wise on the PC platform, but he is much faster >than >me on the alpha. I'd bet we have another 50% lurking inside that we >could >(will) get later... > >Our opening NPS on a P6 is inn the 50K range, typical middlegame is >80-100K, >and endgames settle in around 100K and up (but not by much). The alpha >is >pretty much 3.1X faster. According to bruce the 767 machines scaled >pretty >well compared to the 500, so we could have probably searched at >somewhere >around 350-400K on one of those. Wait until next year. :) So, hacking your numbers around, you appear to suggest: 1. 32-bit P6 to 64 bit alpha architecture change gives Crafty about 80% 2. With some care and optimisation, you reckon you could get this to, say 125% But this doesn't imply 64 bitmap approach for chess is approx 100% faster than 32 bit for chess, does it ? Because the 32 bit Crafty code is an emulation of 64 bitness bitmaps, not code that is written in the 'previous' style, of say having a byte or a word or whatever per board square. The next interesting question, and one that is again semi-impossible to answer, is just how much better is it (as measured by nps) to be using bitmaps than not. Looks like the upper bound on 'better' is something less than your 125%. One wonders how much less .... ? Also of consequence is that these figures are dependant on working to the Crafty-design paradigm. Loosely, I seem to recollect that you (or was it a Bruce description of Ferret?) create piece movement bitmaps, and for sliding pieces, these bitmaps don't account for blocking pieces. Like, for example, if you want to know if a piece is attacked, you pick up the enemy movement bitmaps, test for a hit on the square in question, and, if its hit by a sliding piece, THEN test for a blocking piece. This seems fine, good and fast, if your program is not needing to do many piece attack queries; becuase if it is, there comes the point where it is probably better to preprocess all of these beforehand, and then not have to waste time over and over in doing block piece tests ........ ? Or, what I'm trying to say is that the Crafty results probably don't cover highly intensive evaluation functions ..... ? Chris Whittington > > > >> >>> >>>but you are right, it is more fun talking about why it is fast, or why >>>it >>>does (or doesn't) find a particular move, rather than why it loses to or >>>beats program "X". IE I'd suspect someone is going to want to know how >>>Rebel 9 lost to Rebel 7 in this last tournament going on. The answer is >>>simply "stuff happens." One game is interesting, but not informative.
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.