Author: Joost Buijs
Date: 07:14:02 08/08/03
Go up one level in this thread
On August 08, 2003 at 09:58:23, Vincent Diepeveen wrote:
>On August 08, 2003 at 09:28:58, Joost Buijs wrote:
>
>If evaluation is only thing you care for, you
>should really use a different concept that you previously used.
>
>Please talk to some very strong ex-bitboard programmers who
>did pretty well in world champs and they all threw out the
>bitboard code for evaluation.
Who was that if I may ask?
>
>As i already said 5 years ago, i can only see the use of a
>bitboard for pawns. And then not the crafty definition which uses
>
>whitepawns and blackpawns
>
>but a
>
>pawns[2]
I use two structures containing the pieces for white and for black.
Adressing them goes like side[white].pawns or side[wtm].pawns, this is easier
then some other progs use and I even found it is somewhat faster with most
compilers. I can also adress them with a pointer like own = &side[wtm]; and then
own->pawns or opp->pawns works very convenient. This is better then the stuff
like if (wtm) then {...} else {...}.
>
>which is a better form of programming than writing out everything for
>black and white.
>
>Also is better for trace cache.
>
>So it is no mystery why each new CPU diep speeds up more relatively than other
>programs. Itanium2 i get more out of than crafty, despite that it goes from 32
>bits to 64 bits for crafty. opteron i profit more than crafty from and so on.
>
>Not to mention when the prescott gets released. of course P4 was first 2 steps
>back before moving a bit forward, but just consider the posted code here.
>
>Very P4 friendly!
>
>>On August 08, 2003 at 07:38:41, Vincent Diepeveen wrote:
>>
>>>On August 08, 2003 at 02:35:00, Joost Buijs wrote:
>>>
>>>>Vincent,
>>>>
>>>>Have you ever tried bitboards?
>>>
>>>why don't you try this code and find out it is 2.2 times faster than what crafty
>>
>>I really think it doesn't matter much because move generation takes only a very
>>small fraction of the total time involved. Speeding up your move generator by
>>100% gives you an overall gain of maybe 1.5%. Why on earth do you want to
>>generate 70 million moves/sec. If you can only evaluate at a rate of lets say 50
>>thousand moves/sec.??? I've been making this mistake for years, trying to speed
>>things up more and more. But in the end the most important thing is the
>>evaluation function. 10 or 20% difference in speed is hardly noticeable in
>>playing strength.
>>
>>>has. i measured this against crafty.
>>>
>>>please don't complain about L2 cache needs of crafty's move generator
>>>because when you generate semi legal move list for a few million times then
>>>crafty's move generator is within L1 cache even.
>>>
>>>In fact this is 0.6% system time so you would save out 2.4% directly.
>>>
>>>But if you remove the 'if' condition to put the move in the movelist,
>>>then you will notice that this is completely branchless code for 1 piece with
>>>exception of the loop.
>>>
>>>So where 0.6% system time in move generator already saves me out 0.6% system
>>>time which is worth the effort of some months of fulltime programming as you
>>>know, even more important is that all scans in my evaluation that involve semi
>>>legal moves, is completely branchless.
>>>
>>>And there you have a major winner in system time as you already noticed.
>>>
>>>I can scan more and i can scan it faster than most other software.
>>>
>>>And there is your answer.
>>>
>>>Such code like this is a lot cleaner. Bitboards is not easier to evaluate. It is
>>>much harder. Also my code is trace cache friendly so to speak. If i evaluate a
>>>pattern i prefer general code which works both for white and black.
>>>
>>
>>Evaluation is a lot easier with bitboards. I went really crazy about al these
>>'if then else' constructs in my old engine. Now things can be done very easely
>>with just a few shift and mask operations.
>>
>>>That is not always easy to write and in not all cases it gets done, but which
>>>single bitboard program is using such general code?
>>>
>>>the only use i see in bitboards is a pawn bitboard so that complex pawn patterns
>>>require just one 'if' instead of a bunch.
>>
>>Here you already begin seeing the light!
>>
>>>
>>>I feel your decision was wrong. With this code you can get 2 times faster in 32
>>>bits.
>>
>>I agree on this, but soon everything will be 64 bits, one or two years from now
>>32 bit machines will be history.
>>
>>>
>>>Also the advantage is you might get again interested in improving the evaluation
>>>function.
>>
>>Since I've impemented bitboards i'm more interested in the evaluation function
>>than ever before. So beware!
>>
>>>
>>>Best regards,
>>>Vincent
>>>
>>>>I agree that on a 32 bit machine it takes a tiny bit longer to generate all the
>>>>moves with a bitboard engine. The whole move generation process takes ~3% from
>>>>the time the engine needs to determine a move, so thats is not important at all.
>>>>
>>>>The evaluation fuction is much cleaner and more convenient to handle when using
>>>>bitboards, probably you can gain a lot here.
>>>>
>>>>About two years ago I rewrote my old engine completely, and since that time it
>>>>is using bitboards. I still think I made a good decision by doing so.
>>>
>>>>In fact my program runs even faster after the conversion to bitboards. All other
>>>>things like the search and evaluation parameters are exactly the same as in the
>>>>old 1991 engine, so I am really comparing apples to apples here.
>>>>
>>>>B.T.W. I think the move generation is not that slow at all, for instance a perft
>>>>6 from the starting position takes here 6.24 sec. on a fast Athlon-XP, that's
>>>>about 8.5 million moves/s. Can you tell me what your numbers are with respect to
>>>>this? I'm really curious about this.
>>>>
>>>>Next year I will certainly get a dual or quad Opteron, I think my bitboard
>>>>engine will really scream on such a machine.
>>>>
>>>>The development of my engine has been frozen for 10 year or so, simply because I
>>>>was very busy doing other things. But recently I decided to start developing it
>>>>further. This year I won't attend the CSVN tourney, but I certainly want to be
>>>>there next spring.
>>>>
>>>>Groetjes,
>>>>Joost
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.