Author: Uri Blass
Date: 14:47:08 12/06/01
Go up one level in this thread
On December 06, 2001 at 17:17:25, Severi Salminen wrote: >>Crafty does not do the same job that I do when it makes move so comparison when >>I have to make the last ply is not fair. > >And it is not fair that you don't actually make those last moves - so you really >can't compare the times. But this is no surprise. And the same reasoning goes >for comparing nodes/sec figure: can't compare oranges and apples. > >>I can also add that I use only C and no assembler tricks so I am sure that it is >>possible to improve the speed of my program but the main improvenet can come out >>of other possible ideas(I can save most of the nodes that I generate by trying >>to see if I can change the order of moves after some plies. >> >>1.e4 e5 2.d4 d5 >>1.e4 d5 2.d4 e5 >>1.d4 e5 2.e4 d5 >>1.d4 d5 2.e4 e5 >>are leading to exactly the same position and >>it is possible to use this fact to save nodes. > >Yep, transposition tables are very helpful in normal search but they won't make >perft faster because the point in perft is to calculate all leaf nodes in search >tree, even if there are identical positions. The point of perft was/is to test >movegen and make/unmake routines. > >>I will not complain if another program is using it and is faster than mine. >> >>I think that the only fair comparison with other program is time. >>It is not my fault that other programs are not optimized to calculate perft. >> >>I believe that there is no free program that is faster than mine in the task >>that is well defined. > >Well, I have to say you have a strong faith :) But what is the task? If it is >"how many legal leaf nodes there are in a N ply tree from a certain position", >then you really have to add castling and other parts your code is still missing. castling is not missing. I have bugs that I have to correct that are not about castling but I expect that correcting the bugs is not going to make my program more than 0.1% slower. >It is possible that you have the fastest because you have not yet implemented >the searchin functions. It is much wiser to dump as much code as possible from >move generation to make()/unmake() - this is why I also don't check legality in >generation. I disagree that it is wiser. Chest that is the best mate solver when the target is to find the shortest mate also generates only legal moves. Like I said, I did a perft 5 in one second (on my Celeron300) if I >didn't actually make()/unmake() the last ply - so I also claim to be the fastest >free program :) This is because my movegen() is very fast for the cost of a >slower make(). Your movegen is very fast because you generate illegal move so you practically do not do perft 5 in one second. At one point I made a design choice about the Board structure: I >added many bitboard variables there to make mobvegen() a little faster. This of >course made the make()/unmake() slower but in normal search this results a lot >better overall performance - but a worse perft performance. So don't trust TOO >much the figures you'll get from perft testing. I do not say that I will use the fastest perft that I can get for a chess program. trying to calculate perft as fast as possible and trying to play chess well are 2 different tasks but knowing to do one better can also help to know to do the second better. I cannot do something that is better than the other programs in playing chess so at least I try to do something that is better than the others in another thing. 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.