Perft

Archive of the old Parsimony forum. Some messages couldn't be restored. Limitations: Search for authors does not work, Parsimony specific formats do not work, threaded view does not work properly. Posting is disabled.

Re: Perft

Postby Fabio Cavicchio » 18 Feb 2003, 23:25

Geschrieben von: / Posted by: Fabio Cavicchio at 18 February 2003 23:25:44:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Claudio Della Corte at 18 February 2003 22:38:10:
I don't think these results are that important. Many engines use pseudomoves and later check the legality ONLY of the moves to be actually played. These engines are penalized in the perft because ALL the moves have to be checked. Many other engines, instead, just generate the legal moves and so their relative perft performance is swelled.
Let me disagree. A legal-moves generator (like the Delfi one) has to "play internally" the moves it generates to verify if they are legal or not, so it can be slower during the normal search.
During Perft these "internal" playmove/takebacks can be faster than the normal ones because they do not update the hashkey, etc. BTW they are "played" in any case (en passant too!).
It is possible to optimize every engine about Perft (Delfi not yet!) writing some special code (fast playmoves, etc..) I think that this is "legal", maybe in the future we will see some "Perft tournaments" ?!
Hello,
Fabio.
Fabio Cavicchio
 

Re: Perft

Postby Fabio Cavicchio » 18 Feb 2003, 23:36

Geschrieben von: / Posted by: Fabio Cavicchio at 18 February 2003 23:36:41:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Andreas Herrmann at 18 February 2003 23:14:44:
Hi Fabio,
thanks for your answer. Another question: Are you generating only legal moves or also the pseudolegal moves. If you generate only legal moves, this would explain me your second array board. Or has the second (8x8) array, another reason?
??? I thought that all legal-move generators create pseudo-legal moves and later discard the non-legal ones. Delfi does this. I cannot see a way to generate directly legal moves, this would be fantastic(!)
Legal-moves generators are usually slower, but I prefer them.
Fabio Cavicchio
 

Re: Perft

Postby Sune Fischer » 18 Feb 2003, 23:38

Geschrieben von: / Posted by: Sune Fischer at 18 February 2003 23:38:11:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Fabio Cavicchio at 18 February 2003 23:25:44:
I don't think these results are that important. Many engines use pseudomoves and later check the legality ONLY of the moves to be actually played. These engines are penalized in the perft because ALL the moves have to be checked. Many other engines, instead, just generate the legal moves and so their relative perft performance is swelled.
Let me disagree. A legal-moves generator (like the Delfi one) has to "play internally" the moves it generates to verify if they are legal or not, so it can be slower during the normal search.
During Perft these "internal" playmove/takebacks can be faster than the normal ones because they do not update the hashkey, etc. BTW they are "played" in any case (en passant too!).
It is possible to optimize every engine about Perft (Delfi not yet!) writing some special code (fast playmoves, etc..) I think that this is "legal", maybe in the future we will see some "Perft tournaments" ?!
Hello,
Fabio.
Right. And this is because checking for legality usually is quite expensive, so they don't want to waste time on moves that will be cutoff by an early fail high move.
This is what my engine does, I believe this is called a pseudo legal move generator. A legal move generator checks if the move is legal before putting it on the stack.
So you are not making and unmaking moves as you would in a normal search?
How much slower would it be if you used your regular makemove for perft?
-S.
Sune Fischer
 

Re: Perft

Postby Tim Foden » 18 Feb 2003, 23:43

Geschrieben von: / Posted by: Tim Foden at 18 February 2003 23:43:48:
Als Antwort auf: / In reply to: Perft geschrieben von: / posted by: Andreas Herrmann at 18 February 2003 20:55:10:
I have found a few more engines, which have perft implemented.
Green Light also has a perft command implemented... Maybe you would like to try it on your system and report the results? On my machine (AXP 1700+) it gives similar times to Yace 0.99.50 (times are best time from 3 consecutive runs):
perft 4 perft 5 perft 6
GLC 2.18 0.040 1.101 27.349
Yace 0.99.50 0.043 1.095 27.228
Cheers, Tim.
Tim Foden
 

Re: Perft

Postby Sune Fischer » 19 Feb 2003, 00:03

Geschrieben von: / Posted by: Sune Fischer at 19 February 2003 00:03:39:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Uri Blass at 18 February 2003 22:42:38:

Okay Uri, got your perft3 latest thingy, and you are right it is faster.

program perft 4 perft 5 perft 6 perft 7
movei *perft3* 0.01 0.21 5.08 132.62
movei *perft* 0.01 0.24 5.83 148.78
delphi 0.01 0.24 5.92 155.02
frenzee *hash* 0.09 1.28 16.02 207.10

I noticed the numbers fluctuated a little bit, so I ran them three times (perft 7 only once though) and used the fastest time.
-S.
Sune Fischer
 

Re: Perft

Postby Uri Blass » 19 Feb 2003, 00:14

Geschrieben von: / Posted by: Uri Blass at 19 February 2003 00:14:44:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Fabio Cavicchio at 18 February 2003 23:36:41:
Hi Fabio,
thanks for your answer. Another question: Are you generating only legal moves or also the pseudolegal moves. If you generate only legal moves, this would explain me your second array board. Or has the second (8x8) array, another reason?
??? I thought that all legal-move generators create pseudo-legal moves and later discard the non-legal ones. Delfi does this. I cannot see a way to generate directly legal moves, this would be fantastic(!)
Legal-moves generators are usually slower, but I prefer them.

I have an array that tell me about pin pieces.
If I have a knight that is pinned then I can save generating it's moves and check if they are legal.
Uri
Uri Blass
 

Re: Perft

Postby Uri Blass » 19 Feb 2003, 00:21

Geschrieben von: / Posted by: Uri Blass at 19 February 2003 00:21:46:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Uri Blass at 19 February 2003 00:14:44:
Hi Fabio,
thanks for your answer. Another question: Are you generating only legal moves or also the pseudolegal moves. If you generate only legal moves, this would explain me your second array board. Or has the second (8x8) array, another reason?
??? I thought that all legal-move generators create pseudo-legal moves and later discard the non-legal ones. Delfi does this. I cannot see a way to generate directly legal moves, this would be fantastic(!)
Legal-moves generators are usually slower, but I prefer them.

I have an array that tell me about pin pieces.
If I have a knight that is pinned then I can save generating it's moves and check if they are legal.
Uri
I can add that even moves that are not of pinned pieces are discarded based on the attack tables so they are not generated in the stack of the moves.
Uri
Uri Blass
 

Re: Perft

Postby Will Singleton » 19 Feb 2003, 00:42

Geschrieben von: / Posted by: Will Singleton at 19 February 2003 00:42:44:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Sune Fischer at 18 February 2003 22:17:33:
I have found a few more engines, which have perft implemented.
Very impressive is also Delfi 4.0 (written in Delphi). So it must be possible to write a fast move generator in Delphi too. I'm now thinking of rewriting Holmes completely from the scratch after the IPCCC. And i will do much more work on the move generator.
I just re-ran some of the faster ones on my system.
Apparently bitboards don't do much better here, actually a bit worse!
But Delfi really is fast, faster than Movei the normal chess engine version!

program perft 4 perft 5 perft 6
movei *perft* 0.01 0.24 5.90
delfi 0.0 0.23 5.97
movei 0.02 0.26 6.72
yace 0.02 0.59 13.45
pepito 0.05 0.93 22.22
sjeng 0.04 0.98 24.23
Greko 0.1 2.5 63.8
frenzee *hash* 0.09 1.20 17.90
frenzee 140 0.13 3.05 79.14

I would like to see Yace with hash, so if you read this Dieter, could you give us the numbers for Yace compared to Movei or Delfi? :)
Could you explain how you benefit with hash in movegen?
Will
Will Singleton
 

Re: Perft

Postby Uri Blass » 19 Feb 2003, 01:13

Geschrieben von: / Posted by: Uri Blass at 19 February 2003 01:13:23:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Will Singleton at 19 February 2003 00:42:44:
I have found a few more engines, which have perft implemented.
Very impressive is also Delfi 4.0 (written in Delphi). So it must be possible to write a fast move generator in Delphi too. I'm now thinking of rewriting Holmes completely from the scratch after the IPCCC. And i will do much more work on the move generator.
I just re-ran some of the faster ones on my system.
Apparently bitboards don't do much better here, actually a bit worse!
But Delfi really is fast, faster than Movei the normal chess engine version!

program perft 4 perft 5 perft 6
movei *perft* 0.01 0.24 5.90
delfi 0.0 0.23 5.97
movei 0.02 0.26 6.72
yace 0.02 0.59 13.45
pepito 0.05 0.93 22.22
sjeng 0.04 0.98 24.23
Greko 0.1 2.5 63.8
frenzee *hash* 0.09 1.20 17.90
frenzee 140 0.13 3.05 79.14

I would like to see Yace with hash, so if you read this Dieter, could you give us the numbers for Yace compared to Movei or Delfi? :)
Could you explain how you benefit with hash in movegen?
Will
The idea is simple.
You can look at perft 6 as a sum of a lot perft 3.
if you remember perft 3 from the position after the moves 1.e4 d6 2.d4 then you do not have to clauclate perft 3 again after the moves 1.d4 e6 2.e4
Uri
Uri Blass
 

Re: Perft

Postby Claudio Della Corte » 19 Feb 2003, 01:20

Geschrieben von: / Posted by: Claudio Della Corte at 19 February 2003 01:20:13:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Fabio Cavicchio at 18 February 2003 23:25:44:
I don't think these results are that important. Many engines use pseudomoves and later check the legality ONLY of the moves to be actually played. These engines are penalized in the perft because ALL the moves have to be checked. Many other engines, instead, just generate the legal moves and so their relative perft performance is swelled.
Let me disagree. A legal-moves generator (like the Delfi one) has to "play internally" the moves it generates to verify if they are legal or not, so it can be slower during the normal search.
During Perft these "internal" playmove/takebacks can be faster than the normal ones because they do not update the hashkey, etc. BTW they are "played" in any case (en passant too!).
It is possible to optimize every engine about Perft (Delfi not yet!) writing some special code (fast playmoves, etc..) I think that this is "legal", maybe in the future we will see some "Perft tournaments" ?!
Hello Fabio,
I think that there was a misunderstanding.
All I wanted to say is that most of the engines make use of pseudolegal move generators, so they are supposed to perform horribly when you have a full branching factor of 30-35 (like in the perft case). So I believe that is insignificant to make speed challenges in the perft case, because the perft is supposed only to return a certain number of nodes for a given depth and not to use the speed capabilities of the engine. All this, of course, unless everybody gets building its own very specific move generator for perft, but that's another thing, and in my opinion, not so interesting... :)
ciao,
Claudio
Claudio Della Corte
 

Re: Perft

Postby Will Singleton » 19 Feb 2003, 01:42

Geschrieben von: / Posted by: Will Singleton at 19 February 2003 01:42:28:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Uri Blass at 19 February 2003 01:13:23:
I have found a few more engines, which have perft implemented.
Very impressive is also Delfi 4.0 (written in Delphi). So it must be possible to write a fast move generator in Delphi too. I'm now thinking of rewriting Holmes completely from the scratch after the IPCCC. And i will do much more work on the move generator.
I just re-ran some of the faster ones on my system.
Apparently bitboards don't do much better here, actually a bit worse!
But Delfi really is fast, faster than Movei the normal chess engine version!

program perft 4 perft 5 perft 6
movei *perft* 0.01 0.24 5.90
delfi 0.0 0.23 5.97
movei 0.02 0.26 6.72
yace 0.02 0.59 13.45
pepito 0.05 0.93 22.22
sjeng 0.04 0.98 24.23
Greko 0.1 2.5 63.8
frenzee *hash* 0.09 1.20 17.90
frenzee 140 0.13 3.05 79.14

I would like to see Yace with hash, so if you read this Dieter, could you give us the numbers for Yace compared to Movei or Delfi? :)
Could you explain how you benefit with hash in movegen?
Will
The idea is simple.
You can look at perft 6 as a sum of a lot perft 3.
if you remember perft 3 from the position after the moves 1.e4 d6 2.d4 then you do not have to clauclate perft 3 again after the moves 1.d4 e6 2.e4
Uri
Oh, so it's a special perft hash, not useful in gameplay. I wonder how you can compare the quoted perft scores above, without knowing which progs use a perft hash?
Will
Will Singleton
 

Re: Perft

Postby Uri Blass » 19 Feb 2003, 07:25

Geschrieben von: / Posted by: Uri Blass at 19 February 2003 07:25:56:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Will Singleton at 19 February 2003 01:42:28:
I have found a few more engines, which have perft implemented.
Very impressive is also Delfi 4.0 (written in Delphi). So it must be possible to write a fast move generator in Delphi too. I'm now thinking of rewriting Holmes completely from the scratch after the IPCCC. And i will do much more work on the move generator.
I just re-ran some of the faster ones on my system.
Apparently bitboards don't do much better here, actually a bit worse!
But Delfi really is fast, faster than Movei the normal chess engine version!

program perft 4 perft 5 perft 6
movei *perft* 0.01 0.24 5.90
delfi 0.0 0.23 5.97
movei 0.02 0.26 6.72
yace 0.02 0.59 13.45
pepito 0.05 0.93 22.22
sjeng 0.04 0.98 24.23
Greko 0.1 2.5 63.8
frenzee *hash* 0.09 1.20 17.90
frenzee 140 0.13 3.05 79.14

I would like to see Yace with hash, so if you read this Dieter, could you give us the numbers for Yace compared to Movei or Delfi? :)
Could you explain how you benefit with hash in movegen?
Will
The idea is simple.
You can look at perft 6 as a sum of a lot perft 3.
if you remember perft 3 from the position after the moves 1.e4 d6 2.d4 then you do not have to clauclate perft 3 again after the moves 1.d4 e6 2.e4
Uri
Oh, so it's a special perft hash, not useful in gameplay. I wonder how you can compare the quoted perft scores above, without knowing which progs use a perft hash?
Will
look at the branching factor.
If it is less than 20 then it is clear that the program use hash.
Here only Frenzee *hash* use hash.
Yace has also a version that use hash based on Dieter's post but it is not public.
Uri
Uri Blass
 

Re: Perft

Postby Sune Fischer » 19 Feb 2003, 10:44

Geschrieben von: / Posted by: Sune Fischer at 19 February 2003 10:44:56:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Will Singleton at 19 February 2003 01:42:28:

Oh, so it's a special perft hash, not useful in gameplay.
I wonder how you can compare the quoted perft scores above, without knowing which progs use a perft hash?
Will
Right, it is perft cheating - just for fun :)
There is that, but another key point is we don't know who has optimized for perft. Obviously if Bob wanted he could double the speed of perft in crafty by making a special makemove for it. If some engine has been tuned for perft we can't use its score to say anything about its move making and generation speed.
But even if all engines did as Crafty, no "cheats", it would still be a bad test for the speed in a real program, where most use incremental move generators.
In short, anything that isn't real chess is a bad test for real chess :)
-S.
Sune Fischer
 

Re: Perft

Postby Peter Fendrich » 19 Feb 2003, 10:59

Geschrieben von: / Posted by: Peter Fendrich at 19 February 2003 10:59:55:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Sune Fischer at 19 February 2003 10:44:56:
Oh, so it's a special perft hash, not useful in gameplay.
I wonder how you can compare the quoted perft scores above, without knowing which progs use a perft hash?
Will
Right, it is perft cheating - just for fun :)
There is that, but another key point is we don't know who has optimized for perft. Obviously if Bob wanted he could double the speed of perft in crafty by making a special makemove for it. If some engine has been tuned for perft we can't use its score to say anything about its move making and generation speed.
But even if all engines did as Crafty, no "cheats", it would still be a bad test for the speed in a real program, where most use incremental move generators.
In short, anything that isn't real chess is a bad test for real chess :)
-S.
I can see only one "useful" function of perft, namely to check that I haven't messed up my move-generation code. In order to do that one should stick as close as possible to the normal move generation procedure.
Other uses of perft is just fun, but OTOH chess programming is just for fun and isn't life just for fun? Our creator was probably more laughing than crying when all that mess was invented... :-)
/Peter
Peter Fendrich
 

Re: Perft

Postby Sune Fischer » 19 Feb 2003, 11:15

Geschrieben von: / Posted by: Sune Fischer at 19 February 2003 11:15:57:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Peter Fendrich at 19 February 2003 10:59:55:

I can see only one "useful" function of perft, namely to check that I haven't messed up my move-generation code. In order to do that one should stick as close as possible to the normal move generation procedure.
Other uses of perft is just fun, but OTOH chess programming is just for fun and isn't life just for fun? Our creator was probably more laughing than crying when all that mess was invented... :-)
/Peter
I agree. I just get slightly irritated when people go "wow that is a fast move generator" because it is fast at perft.
It is apples and oranges if you don't implement using the same scheme, it's like when laymen see the knps of the new fritz being lower than the old, they conclude something is wrong, that the old must be better...
I always shake my head in disbelief. ;)
-S.
Sune Fischer
 

Re: Perft

Postby Leen Ammeraal » 19 Feb 2003, 11:54

Geschrieben von: / Posted by: Leen Ammeraal at 19 February 2003 11:54:18:
Als Antwort auf: / In reply to: Perft geschrieben von: / posted by: Andreas Herrmann at 18 February 2003 20:55:10:
Queen 2.37 0,260 6,529 145,339
Thanks for this list. I could not resist trying
to improve Queen with regard to perft once again, and
I managed to get it about 2% faster.
Perhaps a strength increase of 2 Elo points? -:)
But at least no risk of actually making the program worse,
as is always the case with eval or search modifications!
Leen
Leen Ammeraal
 

Re: Perft

Postby Uri Blass » 19 Feb 2003, 12:13

Geschrieben von: / Posted by: Uri Blass at 19 February 2003 12:13:57:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Sune Fischer at 19 February 2003 11:15:57:
I can see only one "useful" function of perft, namely to check that I haven't messed up my move-generation code. In order to do that one should stick as close as possible to the normal move generation procedure.
Other uses of perft is just fun, but OTOH chess programming is just for fun and isn't life just for fun? Our creator was probably more laughing than crying when all that mess was invented... :-)
/Peter
I agree. I just get slightly irritated when people go "wow that is a fast move generator" because it is fast at perft.
It is apples and oranges if you don't implement using the same scheme, it's like when laymen see the knps of the new fritz being lower than the old, they conclude something is wrong, that the old must be better...
I always shake my head in disbelief. ;)
-S.
There is a difference
Nps mean nothing when perft is a specific defined task.
Uri
Uri Blass
 

Re: Perft

Postby Sune Fischer » 19 Feb 2003, 12:32

Geschrieben von: / Posted by: Sune Fischer at 19 February 2003 12:32:13:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Uri Blass at 19 February 2003 12:13:57:
I can see only one "useful" function of perft, namely to check that I haven't messed up my move-generation code. In order to do that one should stick as close as possible to the normal move generation procedure.
Other uses of perft is just fun, but OTOH chess programming is just for fun and isn't life just for fun? Our creator was probably more laughing than crying when all that mess was invented... :-)
/Peter
I agree. I just get slightly irritated when people go "wow that is a fast move generator" because it is fast at perft.
It is apples and oranges if you don't implement using the same scheme, it's like when laymen see the knps of the new fritz being lower than the old, they conclude something is wrong, that the old must be better...
I always shake my head in disbelief. ;)
-S.
There is a difference
Nps mean nothing when perft is a specific defined task.
Uri
Perft is a defined task yes, but then what? What conclusions can you draw from a perft number other than the speed at which it calculates perft?

The more you modify in order to achieve great perft speeds the less of a relation is there to the move gen performance of the engine, it is simply not the same code being executed.
We could make a slightly modified test, to see which programs search the fastest to ply 12. This means you need to make and unmake at the last ply, so Movei would be slowest here (assuming we disabled all pruning and such).
Would such a test be wastly more unrealistic than perft? I don't think so, but the results would certain be completely different (for some programs).
-S.
Sune Fischer
 

Re: Perft

Postby Uri Blass » 19 Feb 2003, 12:47

Geschrieben von: / Posted by: Uri Blass at 19 February 2003 12:47:57:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Sune Fischer at 19 February 2003 12:32:13:
I can see only one "useful" function of perft, namely to check that I haven't messed up my move-generation code. In order to do that one should stick as close as possible to the normal move generation procedure.
Other uses of perft is just fun, but OTOH chess programming is just for fun and isn't life just for fun? Our creator was probably more laughing than crying when all that mess was invented... :-)
/Peter
I agree. I just get slightly irritated when people go "wow that is a fast move generator" because it is fast at perft.
It is apples and oranges if you don't implement using the same scheme, it's like when laymen see the knps of the new fritz being lower than the old, they conclude something is wrong, that the old must be better...
I always shake my head in disbelief. ;)
-S.
There is a difference
Nps mean nothing when perft is a specific defined task.
Perft is a defined task yes, but then what? What conclusions can you draw from a perft number other than the speed at which it calculates perft?

The more you modify in order to achieve great perft speeds the less of a relation is there to the move gen performance of the engine, it is simply not the same code being executed.
We could make a slightly modified test, to see which programs search the fastest to ply 12. This means you need to make and unmake at the last ply, so Movei would be slowest here (assuming we disabled all pruning and such).
Would such a test be wastly more unrealistic than perft? I don't think so, but the results would certain be completely different (for some programs).
-S.
You need to define evaluation for that test otherwise the test is not fair.
I think that in that case I can know the last ply and use different make move for the last ply(today part of the knowledge in the last ply is used for faster move generation).
Today I have not different make move for the last ply and one of the problem is that I do not know that a ply is the last ply before I make it.
If I disable pruning and extensions there is no problem to know the last ply.
Uri
Uri Blass
 

Re: Perft

Postby Sune Fischer » 19 Feb 2003, 13:02

Geschrieben von: / Posted by: Sune Fischer at 19 February 2003 13:02:03:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Uri Blass at 19 February 2003 12:47:57:
You need to define evaluation for that test otherwise the test is not fair.
I think that in that case I can know the last ply and use different make move for the last ply(today part of the knowledge in the last ply is used for faster move generation).
Today I have not different make move for the last ply and one of the problem is that I do not know that a ply is the last ply before I make it.
If I disable pruning and extensions there is no problem to know the last ply.
Uri
I don't see how you can make an evaluation or go into quiescent search without making the move at the last ply.
If you do it differently I would say that your definition of ply is different from mine. Nothing wrong with that, but again it is hard to compare apples and oranges.
-S.
Sune Fischer
 

PreviousNext

Return to Archive (Old Parsimony Forum)

Who is online

Users browsing this forum: Google [Bot] and 17 guests

cron