Perft

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 19 February 2003 13:23:47:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Sune Fischer at 19 February 2003 13:02:03:

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.

I did not say not to make the move of the last ply but to do less work in the last ply by a different make move.
The question what information I need in the last ply is dependent on the evaluation so without definition of evaluation we cannot compare and say that movei is slower.
Uri

[Sune Fischer]

Geschrieben von: / Posted by: Sune Fischer at 19 February 2003 17:05:52:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Uri Blass at 19 February 2003 13:23:47:

I did not say not to make the move of the last ply but to do less work in the last ply by a different make move.
The question what information I need in the last ply is dependent on the evaluation so without definition of evaluation we cannot compare and say that movei is slower.
Uri

Yeah maybe, but if we are talking pure nps Movei is not known to be one of the fastest. That kindof classes with the notion that perft should be some kind of indicator for that, in fact I dare say it disproves it to some degree.
You say yourself that Movei doens't have a lot of evaluation, so there is another thing that will be slowing it down, eventually.
all I say is that one cannot compare these things, the only way to compare is to have them play it out. Speeds makes no sense without some guidelines for proper implementation standards. I will bet you that I have one of the fastest SEE rutines known to man, but my makemove is slow, I made a choice.
My philosophy is that you can't build a house with sticks and stones, you need proper powertools to do the job, attack tables are such powertools, but carrying them around is a heavy burden...
Actually the I did some quick math on it too, I will leave it to the reader to figure out the answer
"Person X has a program that is spending 10% time making moves, 10% time generating moves and 50% time in the evaluation. Now Person X is given a choice, he can add some code to his structures to speed up his evalutation by a factor 2. The only downside is that it will slow down his makemove by a factor 2 also. Should he go ahead with the implementation?"

-S.

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 19 February 2003 17:25:16:
Als Antwort auf: / In reply to: Re: Perft geschrieben von: / posted by: Sune Fischer at 19 February 2003 17:05:52:

I did not say not to make the move of the last ply but to do less work in the last ply by a different make move.
The question what information I need in the last ply is dependent on the evaluation so without definition of evaluation we cannot compare and say that movei is slower.
Uri

Yeah maybe, but if we are talking pure nps Movei is not known to be one of the fastest. That kindof classes with the notion that perft should be some kind of indicator for that, in fact I dare say it disproves it to some degree.
You say yourself that Movei doens't have a lot of evaluation, so there is another thing that will be slowing it down, eventually.
all I say is that one cannot compare these things, the only way to compare is to have them play it out. Speeds makes no sense without some guidelines for proper implementation standards. I will bet you that I have one of the fastest SEE rutines known to man, but my makemove is slow, I made a choice.
My philosophy is that you can't build a house with sticks and stones, you need proper powertools to do the job, attack tables are such powertools, but carrying them around is a heavy burden...
Actually the I did some quick math on it too, I will leave it to the reader to figure out the answer
"Person X has a program that is spending 10% time making moves, 10% time generating moves and 50% time in the evaluation. Now Person X is given a choice, he can add some code to his structures to speed up his evalutation by a factor 2. The only downside is that it will slow down his makemove by a factor 2 also. Should he go ahead with the implementation?"

-S.

I can give some things that slows it.
1)Not using hash tables for pruning
2)Slow function to find checks in the first plies of the qsearch(Movei look at every move to check if it is check instead of doing something faster).
This is the reason that 0.0799 is slower than 0.07a in nodes per second.
3)Not having function to generate only captures(the qsearch is done by generating all the moves and choosing the interesting moves from them).
Of course person X should do the makemove slower.
The makemove of latest movei (not perft) is slower than the makemove of movei00_799 because movei update bitboards for pawn structure evaluation during make move but in the special perft version that I sent you these bitboards are commented out of the code.
Uri