ZirconiumX wrote:ProDeo will never be hugely fast due to doing a full evaluation every node.
In fact, I followed some of its games in Division 3. And I have to say it was faster in terms of n/s than most of the other programs (64-bit ones). It was even twice as fast in some cases.
So I wonder where your conclusion that it's slow came from.
And how do you know that it does full eval every node?
Richard Allbert wrote:Have you read the link Ed provided, before posting that?
I understand it as follows: First x ply do null move as normal, as in most other programs. Avoid if alpha < score + margin. Also similar to other programs.
Remaining ply implement Selective Search according to the rules outlined.
What you do need is evaluation every node, and a lot of info from it - hanging pieces, king threats etc, and these clearly need to be accurately defined.
ZirconiumX wrote:ProDeo will never be hugely fast due to doing a full evaluation every node.
In fact, I followed some of its games in Division 3. And I have to say it was faster in terms of n/s than most of the other programs (64-bit ones). It was even twice as fast in some cases.
So I wonder where your conclusion that it's slow came from.
And how do you know that it does full eval every node?
My NPS is a bit misleading, besides counting real nodes I also count every succeeded lazy_eval and every succeeded futility pruning. Counting the number of eval's IMO would give a better picture of the real speed of the program, usually a factor of 3-5 less. Random example:
Rebel wrote:
My NPS is a bit misleading, besides counting real nodes I also count every succeeded lazy_eval and every succeeded futility pruning. Counting the number of eval's IMO would give a better picture of the real speed of the program, usually a factor of 3-5 less. Random example:
That's interesting Ed. I count every node (including qsearch) except for depth 0 nodes to not count them twice. Some count make move instead.
In that case I apologize to Matthew as I didn't know how exactly you're counting.
ZirconiumX wrote:ProDeo will never be hugely fast due to doing a full evaluation every node.
In fact, I followed some of its games in Division 3. And I have to say it was faster in terms of n/s than most of the other programs (64-bit ones). It was even twice as fast in some cases.
So I wonder where your conclusion that it's slow came from.
And how do you know that it does full eval every node?
My NPS is a bit misleading, besides counting real nodes I also count every succeeded lazy_eval and every succeeded futility pruning. Counting the number of eval's IMO would give a better picture of the real speed of the program, usually a factor of 3-5 less. Random example:
ZirconiumX wrote:it is just his move generator is slow. It is a 32 bit mailbox, not the 64 bit bitboards you are used to.
Matthew:out
.. and
ZirconiumX wrote:
ProDeo will never be hugely fast due to doing a full evaluation every node,
Matthew:out
Which is it then, slow due to MoveGen? Or Eval?
Plus, iirc, most top programs call eval each node in the search to evaluate whether to do pruning and null move.
ZirconiumX wrote:
Uri, I was on about selectivity, not speed.
Matthew:out
See above
ZirconiumX wrote:
but tactically, a selective searcher is hard to beat.
Matthew:out
How do you know this? Any evidence?
Bear in mind Uri is the author of a very strong program - one of the strongst pre Fruit, also.
1. Eval. PD's eval is huge. Even with bitboard move gen it will still have a huge eval.
2. Stockfish is hugely selective, Houdini is hugely selective, Critter is hugely selective, IvanHoe is hugely selective. They all excel at tactics.
I'm definitely interested in this technique. My programs used static selectivity long before null move pruning. Rexchess is one example and at the time people thought Rex was a super fast program.
We did not do the "dumb" thing which involves just applying some safety margin, we actually have a routine which statically determines the maximum threatened piece. In Rex I think that was applied to the last 3 ply of the search and used rules similar to what you propose.
We have never had success pushing this too far - but I think you can if you use margins in addition. When you are 4 or 5 ply back and nothing is obviously threatened and you take a cutoff because the evaluation score is greater than beta - that just isn't reasonable. Now you are missing simple positional threats.
Our current rules are based on a combination of all 3 things - static threat detection, null move pruning and margins. It's probably more complicated than it needs to be and there is probably more that could be done to improve it.
Don
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
ZirconiumX wrote:it is just his move generator is slow. It is a 32 bit mailbox, not the 64 bit bitboards you are used to.
Matthew:out
.. and
ZirconiumX wrote:
ProDeo will never be hugely fast due to doing a full evaluation every node,
Matthew:out
Which is it then, slow due to MoveGen? Or Eval?
Plus, iirc, most top programs call eval each node in the search to evaluate whether to do pruning and null move.
ZirconiumX wrote:
Uri, I was on about selectivity, not speed.
Matthew:out
See above
ZirconiumX wrote:
but tactically, a selective searcher is hard to beat.
Matthew:out
How do you know this? Any evidence?
Bear in mind Uri is the author of a very strong program - one of the strongst pre Fruit, also.
1. Eval. PD's eval is huge. Even with bitboard move gen it will still have a huge eval.
and with bitboards Rebel will slowdown of course significantly. Look clearly what he's doing in eval - you can't do that fast in bitboards. doing that incremental in 32 bits is *factors* faster.
2. Stockfish is hugely selective, Houdini is hugely selective, Critter is hugely selective, IvanHoe is hugely selective. They all excel at tactics.
Matthew:out
ZirconiumX wrote:ProDeo will never be hugely fast due to doing a full evaluation every node.
In fact, I followed some of its games in Division 3. And I have to say it was faster in terms of n/s than most of the other programs (64-bit ones). It was even twice as fast in some cases.
So I wonder where your conclusion that it's slow came from.
And how do you know that it does full eval every node?
My NPS is a bit misleading, besides counting real nodes I also count every succeeded lazy_eval and every succeeded futility pruning. Counting the number of eval's IMO would give a better picture of the real speed of the program, usually a factor of 3-5 less. Random example:
I think that basically you should count number of moves that you
make.
The number of positions that you do full evaluation is not relevant for nodes per second.
Nah this is different from program to program.
In Diep i count positions i take a very good look at. The NPS is too unstable if i'd count all moves made (which sometimes is factor 2 higher than the number of nodes per seconds Diep actually gets).
For example, i can make a move. Then the incremental attacktables that get updated in makemove, they give me the king can get captured, so you move it back. It's not a real node. It's an illegal move.
