Author: Dan Newman
Date: 01:49:31 04/18/00
Go up one level in this thread
On April 17, 2000 at 18:48:15, Dann Corbit wrote:
>On April 17, 2000 at 18:18:33, Andrew Dados wrote:
>
>>On April 17, 2000 at 17:05:55, Dann Corbit wrote:
>>
>>>On April 17, 2000 at 17:00:05, Andrew Dados wrote:
>>>
>>>>On April 17, 2000 at 16:21:09, Dann Corbit wrote:
>>>>
>>>>[snipped]
>>>>
>>>>>Fascinating approach that does not use 64 bit bitboards, and yet hits 100-300K
>>>>>NPS when analyzing on a wimpy PII 300 MHz.
>>>>
>>>>Should I understand you think bitmaps are faster then other approaches from the
>>>>above? IMO representation does not matter much (especially on 32bit processor).
>>>>
>>>>Implementation matters though...:)
>>>
>>>I only understand the implementations that I have seen. Of all that I have had
>>>a chance to peruse the source code, the 64 bit bitboard approaches have totally
>>>dominated the other methods in NPS (usually by a factor of 2-4 even for the best
>>>programs, Phalanx being the fastest Non-bitboard engine I had examined up till
>>>G2). I had pretty well bought into the idea that to make a really fast engine,
>>>64 bit bitboards would be a necessity.
>>
>>As far as I know, Ferret, Fritz, Junior don't use bitmaps (to name a few).
>>Any bitmap proggy I know of is far from latter 2 nps-wise...
>
>None of these does me any good at all, since I can't study the implementation.
>Therefore, I don't care much, because we don't really know what they are doing.
>I think it is also true that Chess Tiger does not use bitmaps, since I have seen
>Christophe Theron smirk at them.
>
>Without knowing the exact data structure and algorithm that is employed, just
>knowing that they supposedly do something different does not seem helpful to me.
>
>It could even be possible (though unlikely) that they actually use one technique
>and claim to use another. Without seeing the actual code, how will we ever know
>what is going on?
>
>On the other hand, a detailed description of the algorithms and data structures
>(even in an abstract sense) might be just as useful. However, I find that the
>commercial programmers are (understandably) very reluctant to part with this
>particular information.
I think it's very difficult to really see which is faster. If you work a
long time using one technique and then a short time with another, it's
likely the first will be faster and the second will seem like a loser...
OTOH, I found bitboards to be a good deal faster than the 0x88 that I had
been using, after a relatively short time. At a point when the bitboard
code hadn't diverged a great deal from the 0x88, I measured aproximately
a 40% speed boost. I was actually very surprised since I didn't expect
to see any performance improvement until I got around to using bitboards
to do more eval stuff. (I had experimented with bitboards once before and
thought that they might reduce the speed by half or so...)
I think several things made the bitboard engine faster:
1) Using the BSR/BSF instructions for getting the bit index (as
opposed to using C code).
2) Using MSVC instead of Watcom (I suspect MSVC knows more about
generating code for the P6, PIII, etc.)
3) Not using rotated bitboards (perhaps). I suspect that
(at least on a 32-bit PC) that certain things are faster if
you just scan the board--but I don't know for sure.)
4) Elimination of complicated piece list machinery.
5) A faster SEE (related to not having piece lists).
6) (As Bob points out) bitboard code supplies lots of pairs of
arithmetic operations to be done, so that integer pipes are
kept busy.
None of this is to say that there doesn't exist some other scheme that
would be even faster...
-Dan.
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.