Author: Severi Salminen
Date: 14:17:25 12/06/01
Go up one level in this thread
>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. 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. 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(). 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. Severi
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.