Author: Tom Kerrigan
Date: 11:44:10 06/21/00
Go up one level in this thread
On June 21, 2000 at 13:56:02, Christophe Theron wrote: >On June 21, 2000 at 13:30:25, Tom Kerrigan wrote: > >>On June 20, 2000 at 21:02:15, Christophe Theron wrote: >> >>>On June 20, 2000 at 14:51:25, Tom Kerrigan wrote: >>> >>>>On June 20, 2000 at 14:21:23, Christophe Theron wrote: >>>> >>>>>On June 20, 2000 at 11:17:48, Andrew Williams wrote: >>>>> >>>>>>On June 20, 2000 at 09:02:26, Robert Hyatt wrote: >>>>>> >>>>>>>On June 20, 2000 at 04:55:22, Dann Corbit wrote: >>>>>>> >>>>>>>>On June 20, 2000 at 04:41:47, James Robertson wrote: >>>>>>>> >>>>>>>>>Ignore all results from my previous post "Rough comparison between ro....". I >>>>>>>>>made some stupid coding errors in my test rotated bitboard code. Once fixed the >>>>>>>>>rotated bitboards look very competitive against 0x88. :) I also found flaws in >>>>>>>>>my 0x88 code, but they were very minor and I think I caught all of them (correct >>>>>>>>>move lists are generated in all my test positions). >>>>>>>>> >>>>>>>>>I am very happy to continue to use rotated bitboards. Thanks Robert for >>>>>>>>>inventing them, and thanks Tim for showing me how to use them! >>>>>>>> >>>>>>>>What was the timing ratio for various operations between the two methods? >>>>>>>> >>>>>>>>For the 0x88, what board size did you use? >>>>>>> >>>>>>> >>>>>>>For 0x88 you don't have much choice... it has to be 128, where you use the left >>>>>>>half for the board, the right half (64 squares) are off the board. There is >>>>>>>really a top half of 128 words also, but 0x88 eliminates references to them >>>>>>>due to the 0x80 bit not being allowed. >>>>>> >>>>>>Christophe Theron posted a few interesting pointers to using 16x16 instead of >>>>>>16x8 last week (I think). >>>>>> >>>>>>Andrew >>>>> >>>>> >>>>>Yes. I think that comparing 0x88 and bitboards is not totally relevant, as 0x88 >>>>>is in my opinion suboptimal. I explained why in last week's posts. >>>>> >>>>>There are also many smart tricks you can use that are derived from the >>>>>properties of a 16x16 (or 16x12) board, and they have never been published. >>>>> >>>>>I don't believe it is possible to compare 0x88, 16x and bitboards in one day or >>>>>two. Once you start to use one system, you discover smart ways to optimize it >>>>>even months after you start using it. >>>>> >>>>>I think that 16x and bitboards just break even, even on 64 processors, but it >>>>>would probably be very difficult to demonstrate this... >>>> >>>>But with bitboards, there is more memory overhead. Sometimes you have to take >>>>that into consideration. With modern desktop PC processors, it's probably not a >>>>big deal. But I'd like my program to run on smaller computers (specifically >>>>palmtops) so I'm going with 0x88. >>>> >>>>-Tom >>> >>> >>>That's a good reason indeed, and could even be the ultimate argument to say that >>>bitboards are not the best way to go. >>> >>>Some people are not afraid to allocate a bunch of 64 bits (=8 bytes) integers. I >>>am. I don't want to blow out the cache of my processor. >>> >>>Some will say that in a few years from now L1 caches will be much bigger. >> >>I doubt it. Big L1 caches can only slow a chip down. >> >>-Tom > > >I did not expect that. Can you explain why? I know you have more knowledge about >hardware than I have. A big cache has big dimensions. So it takes longer for data to travel from the far end of the cache. Because chip timing is based on worst-case scenarios, the entire cache runs slower. The Athlon can have its 128k L1 cache because it has an "extra" pipeline stage for cache load. But who knows, the chip might have been significantly faster if it only had a 32k L1 cache and a shorter pipeline, like the P3. -Tom
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.