Author: Uri Blass
Date: 06:46:24 08/08/03
Go up one level in this thread
On August 08, 2003 at 09:28:58, Joost Buijs wrote: >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! There is one thing that I do not understand. Is there a contradiction between bitboard and not using bitboard in move generation? I can continue to use my normal arrays for move generation and add bitboards that are updated in my make move and use them for evaluation. I do not understand why people assume that they need to choose between the 2 things. If the engine is a slow searcher then the time of updating both bitboard and the non botabord data structure is relatively small and the advantage from being able to choose between bitboard and non bitboard every time may be bigger. Uri
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.