Author: Christophe Theron
Date: 17:31:29 06/21/00
Go up one level in this thread
On June 21, 2000 at 14:44:10, Tom Kerrigan wrote:
>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
I see. Thanks for the explanation.
Christophe
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.