hgm wrote:But qperft is not an engine at all. Who wants an engine? It is evaluation that is completely useless. It does not help you at all to count move paths...
As usual you ar arguing from the tunnel vision of your own limited interests.
I am arguing from the perspective of the person that _created_ this idea, and why it is useful. I wanted to check correctness when I started the Crafty project, because the basic move generator and make/unmake changed dramatically month to month. I also wanted a way to compare approaches in terms of speed.
The hashing idea is nonsensical. Why add something to perft that requires _more_ debugging (the hashing stuff) when the primary purpose is to evaluate correctness and compare performance between two versions of some function.
I released this code, and others adopted the idea for testing, debugging and development. Then it turned into a "speed race" for a few. Best speed test is to compare time to depth for two programs, not compare some silly perft times where there is absolutely no incentive to make that efficient since it has little to do wtth playing chess, other than for the speed/correctness issues I mentioned. Comparing perft numbers between two programs is useful if you compare the node counts to detect errors. Comparing the speeds is about as pointless as comparing lines of code, or number of procedures, or whatever.
No tunnel-vision on my end at all. Simply a practical observation. Your comment, on the other hand.....
The target of a fast reliable perft function is to help other people to test if there is a bug in their program faster.
You can simply take epd file of a lot of position and calculate perft(5) in all the position and compare results with another program.
If you want this process to be as fast as possible then you will prefer faster program so speed is clearly relevant.
Uri
This argument makes no sense. How often does this happen? How many new programs are developed in a single year? How many of those even know about perft? And how many of those need deep perft's? I've developed two major programs, completely different in their architecture, I used perft during the development of both, and back in the 70's I did not find it necessary to have a perft 8, 9 or 10. I haven't done any of those for my own use even in Crafty. 3-4-5 has been more than enough to find any errors I have had, and those run so quickly that optimization is a complete waste of time.
This is clearly a violation of the principle behind Amdahl's law, which guides where we spend our time optimizing a program. Optimizing perft is simply an idea that makes no sense. Once your engine is done, you won't use it again for years. While writing your engine, you will barely use it. Most of the time is not spent on the move generator code. So why optimize something that will represent less than .0001% of your total compute cycles used to develop a program?
Now if you want to take the "anal approach" and simply say "but I just wanted to develop the fastest implementation of perft possible..." then that's up to you or anyone else that wants to use this as a speed comparison. But when a program can win a perft comparison and then get crushed on the chess board, it makes that effort to optimize perft seem somewhat foolishly spent.
An ultra fast hashed perft won't make a program play better than one with no hash at all.
Still, it's fun. Look at all the effort Steven J. Edwards put into perft calculations. Was it wasted? Not at all. It answers interesting questions. I also found the distributed perft project to be very interesting.
I think that lots of things people do with their chess engines won't make them play any better at all. But the experiments are interesting none the less.
Writing a fast and correct perft is a nice thing to have in a chess program. I can't even tell you why, but I really like it when a chess program has a really fast perft available.
P.S.
I think that *every* chess engine ought to at least expose their perft function, fast or not. Useful for debugging but also entertaining at times to those of us who are a little bent.
hgm wrote:But qperft is not an engine at all. Who wants an engine? It is evaluation that is completely useless. It does not help you at all to count move paths...
As usual you ar arguing from the tunnel vision of your own limited interests.
I am arguing from the perspective of the person that _created_ this idea, and why it is useful. I wanted to check correctness when I started the Crafty project, because the basic move generator and make/unmake changed dramatically month to month. I also wanted a way to compare approaches in terms of speed.
The hashing idea is nonsensical. Why add something to perft that requires _more_ debugging (the hashing stuff) when the primary purpose is to evaluate correctness and compare performance between two versions of some function.
I released this code, and others adopted the idea for testing, debugging and development. Then it turned into a "speed race" for a few. Best speed test is to compare time to depth for two programs, not compare some silly perft times where there is absolutely no incentive to make that efficient since it has little to do wtth playing chess, other than for the speed/correctness issues I mentioned. Comparing perft numbers between two programs is useful if you compare the node counts to detect errors. Comparing the speeds is about as pointless as comparing lines of code, or number of procedures, or whatever.
No tunnel-vision on my end at all. Simply a practical observation. Your comment, on the other hand.....
The target of a fast reliable perft function is to help other people to test if there is a bug in their program faster.
You can simply take epd file of a lot of position and calculate perft(5) in all the position and compare results with another program.
If you want this process to be as fast as possible then you will prefer faster program so speed is clearly relevant.
Uri
This argument makes no sense. How often does this happen? How many new programs are developed in a single year? How many of those even know about perft? And how many of those need deep perft's? I've developed two major programs, completely different in their architecture, I used perft during the development of both, and back in the 70's I did not find it necessary to have a perft 8, 9 or 10. I haven't done any of those for my own use even in Crafty. 3-4-5 has been more than enough to find any errors I have had, and those run so quickly that optimization is a complete waste of time.
This is clearly a violation of the principle behind Amdahl's law, which guides where we spend our time optimizing a program. Optimizing perft is simply an idea that makes no sense. Once your engine is done, you won't use it again for years. While writing your engine, you will barely use it. Most of the time is not spent on the move generator code. So why optimize something that will represent less than .0001% of your total compute cycles used to develop a program?
Now if you want to take the "anal approach" and simply say "but I just wanted to develop the fastest implementation of perft possible..." then that's up to you or anyone else that wants to use this as a speed comparison. But when a program can win a perft comparison and then get crushed on the chess board, it makes that effort to optimize perft seem somewhat foolishly spent.
My point is not that you need to have fast perft in your program but that fast perft without bugs by another person can be useful to detect bugs in your move generator faster.
The fast perft by another person may be useless for writing a chess engine but the point of the fast perft is not to have the best chess program but to help other people (that do not care about the speed of their perft) to debug their program to see that their perft has no error.
My experience is that perft 8 on a single position is less useful relarive to perft 3 on a big pgn because often a program may have some bug that happens only in rare cases.
For example in another thread somebody reported about a bug that his program did not consider promotion as a reply to block check.
You are not going to discover it in the opening position even with perft 8 and you may miss it even in part of the position when promotion is possible but if you calculate perft of a big pgn file and compare with a reliable fast perft then you can be practically sure of discovering this bug or similiar bugs.