Author: Vincent Diepeveen
Date: 07:22:32 08/08/03
Go up one level in this thread
On August 08, 2003 at 10:14:02, Joost Buijs wrote:
>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?
Don, James etc.
>
>>
>>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.