Author: Vincent Diepeveen
Date: 06:58:23 08/08/03
Go up one level in this thread
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. 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] 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.