Author: Christophe Theron
Date: 09:47:38 09/25/99
Go up one level in this thread
On September 25, 1999 at 09:44:45, Robert Hyatt wrote:
>On September 24, 1999 at 19:06:53, Christophe Theron wrote:
>
>>On September 24, 1999 at 01:36:19, Dann Corbit wrote:
>>
>>>On September 24, 1999 at 01:12:06, Christophe Theron wrote:
>>>[snip]
>>>>If somebody tells you bitboards are the way to go, don't believe him.
>>>Now that's what I call a beautiful tease.
>>>
>>>What is the way to go?
>>>;-)
>>
>>Bitboards give no real advantage, except that the author feels very proud of
>>itself when it works (and he thinks it's so elegant!).
>>
>>There are simpler data structures that work very well for chess, are very easy
>>to understand and program, and work on any computer, not just expensive 64 bits
>>processors.
>>
>>Oh yes! I know, these 64 bits processors will be cheap in the future. Be
>>prepared to throw your current computer into the nearest trash can if you want
>>to use these bright bitboard programs!
>>
>>It's the general trend, isn't it? The computer industry wants you to believe
>>that the word processor you have bought last year is now completely obsolete.
>>You'll have to buy another one as soon as possible. And as it will be sooooo
>>sloooooooow on your computer, you'll have to change your computer too.
>>
>>
>>
>> Christophe
>
>
>You can obviously have any opinion on this subject. But I have tried _all_
>the usual approaches. Each has advantages and disadvantages. Bitboards have
>no particular problems on _any_ computer. Modern computers are super-scalar
>in design already, issuing 3-4 instructions every clock cycle when possible.
>Bitboards help feed this multiple-pipeline approach, even on a 32 bit
>machine. If you run a good analysis program, you discover that only rarely do
>normal programs manage to keep 3 pipes busy all the time. So even though the
>bitboard programs must execute extra instructions (extra is a misnomer as non-
>bitboard programs have their own set of identifiable problems) these
>instructions just happen to fit the multiple pipes just fine.
>
>On the other hand, move generation is only _one_ part of a chess engine.
>Bitboards. But move generation fitx bitboards just fine... the sliding
>pieces are much easier to generate moves for... and captures are much
>easier/more efficient to generate moves for, since non-captures don't have
>to be skipped over. But the real benefit of bitmaps is the ability to do
>clever evaluation things. Very efficiently. IE my recently added candidate
>passed pawn / pawn majority code didn't slow me down a bit, because of the way
>it is done using bitmaps rather than loops.
>
>I'm not going to begin to claim that they are better than offset board
>approaches today. I do claim that they are absolutely _no worse_ than
>using an array.
I think we agree here. That's why I prefer not to use them, as they require 64
processors. I like the idea that my program can take advantage of any processor
I compile for, even if it's not a 64 bits one.
There are hundreds of millions of 16 and 32 bits PCs in the world today. How
many 64 bits PCs? NONE, ZERO, NIL, NADA.
It will take several years (maybe 10) before the number of 64 bits PCs becomes
larger than the number of 16 and 32 bits ones.
>And whether you like/believe it or not, 64 bit machines
>are coming.
The problem is not if I like it or not.
It's crazy to ask millions of people to change their computers to exploit a 64
bits chess program, when they already have a superb 300 or 400MHz PC that in
many countries costs much more than a month of salary, and that is able to give
them master-level analysis...
And it is misleading to tell them that they will have better chess programs when
64 bits processors are out just because bitboard programs will exploit it. Non
bitboard programs will be stronger too on this architecture and you won't make
the difference just with bitboards.
>And they will be the standard PC in a few more years. 10 years
>ago, people were using your same words, with the target divided by 2: "Why
>would I ever throw away my 16 bit 286 cpu? Those 32 bit machines are only
>useful for high-end applications..."
You live in a country where only a fraction of your monthly salary is enough to
buy a new powerful personal computer.
Of course you know it's not the case everywhere in the world.
So maybe you can easily erase 16 and 32 bits computers from your memory as soon
as Intel produces a 64 bits processor, but there are many people in the world
who will stick to 16 and 32 bits for 10 years or more.
I'm not saying that we should target the smallest platform available just
because of this.
I'm saying that my data structure works on the most recent computer as well as
the older PCs, and that's why I think it is much more elegant than bitboards.
By far.
> 64 bits are here to stay. Programs
>that use such architectures will gain more from them than those that don't.
>Just look at all the programs and programmers that had to convert to "32 bit
>programming" to avoid the less efficient 16 bit stuff on new processors. Do
>you think that won't happen _again_ soon? :)
Funny you mention this. I was recently thinking that I could produce a 16 bits
version of Chess Tiger.
In 1997 I rewrote everything to port from 16 to 32 bits. In fact, the rewrite
was essentially optmizing my algorithms for efficiency. I have used my older 16
bits version as a laboratory. I was very flexible, so I could try many different
things, but because of this was not optimized.
So I rewrote everything with the algorithm I was targetting for in mind.
Additionnaly, I thought I would take advantage of 32 bits processing where it
would make sense.
Recently I realized that I needed 32 bits integer very unfrequently. In fact I
could use 16 bits integer in 99% of my program. The 32 bits integer processing
is needed only for hash keys calculations and hash table access, and a 16 bits
processor can emulate them with only a very small speed penalty.
I think a 16 bits version of my program would be as efficient as the current 32
bits one. If the processor itself is not lousy at executing 16 bits code, it
could even be faster because of less L1 cache overloading.
And so I don't expect to have any kind of trouble in porting to 64 bits anyway.
>I think (my opinion) that 'evaluation-heavy' programs will like bitmaps better
>than just fast searchers will... because the bitboard approach makes a lot of
>evaluation pattern matching turn into a single AND or OR instruction. But
>until you try it for at least a couple of years, you won't ever see the
>advantages (and learn how to work around the occasional problem). It requires
>a new type of thinking. But not necessarily a bad type of thinking.
I understand the advantages and I agree that you can more easily evaluate
complex things with bitboards.
The question is:
1) do you really need these more complex terms?
2) would it be really slower to evaluate them without bitboards?
And you know what I think about it.
>I don't recommend this as a first approach to computer chess, because it is a
>good bit more complex to get off the ground quickly. However, I used to think
>it was an unworkable idea until I tried it. And stuck with it long enough to
>start thinking in bitmaps. It took time. And it works just fine. When I
>made the big step to convert to bitboards, I made a mental committment to stick
>with them for at least 3 years to give them a chance, because at first, they are
>'different' feeling. And it takes time to "think bitmaps". But once you get
>there, they work just as well as any other approach, and if you intend on doing
>a lot of eval work, they become _very_ efficient...
Maybe.
Christophe
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.