static eval in every node?

[zenpawn]

In the past I have tried futility pruning using a basic material eval plus margin, but from reading the chessprogramming wiki and threads here, it seems folks might be doing a full eval for things like futility pruning, reverse futility pruning, and even whether to try a null move. Does this mean the savings from these methods outweigh the cost of doing a static eval in every node?

[jdart]

Yes.

Most of the nodes are at the terminal or near-terminal edges of the search anyway, and for most of the q-search nodes you need a static eval anyway, for the cutoff test. So you are already going to do a lot of evals and adding more higher up in the tree is not that much more expensive. And doing it enables a lot of pruning and other decisions that can shrink the tree.

You can consider doing a partial (lazy) eval where possible, but can be tricky to pull off since there are multiple uses for an eval score and not all would have the same tolerance for error.

--Jon

[Kotlov]

In the past I have tried futility pruning using a basic material eval plus margin, but from reading the chessprogramming wiki and threads here, it seems folks might be doing a full eval for things like futility pruning, reverse futility pruning, and even whether to try a null move. Does this mean the savings from these methods outweigh the cost of doing a static eval in every node?

Hashing best move is better idea.

[flok]

Do you mean TT in qs?

[JVMerlino]

Yes.

Most of the nodes are at the terminal or near-terminal edges of the search anyway, and for most of the q-search nodes you need a static eval anyway, for the cutoff test. So you are already going to do a lot of evals and adding more higher up in the tree is not that much more expensive. And doing it enables a lot of pruning and other decisions that can shrink the tree.

You can consider doing a partial (lazy) eval where possible, but can be tricky to pull off since there are multiple uses for an eval score and not all would have the same tolerance for error.

--Jon

And if you have hash for eval you can save a decent amount of time.

[zenpawn]

Yes.

Most of the nodes are at the terminal or near-terminal edges of the search anyway, and for most of the q-search nodes you need a static eval anyway, for the cutoff test. So you are already going to do a lot of evals and adding more higher up in the tree is not that much more expensive. And doing it enables a lot of pruning and other decisions that can shrink the tree.

You can consider doing a partial (lazy) eval where possible, but can be tricky to pull off since there are multiple uses for an eval score and not all would have the same tolerance for error.

--Jon

Thank you. With that assurance, I'm going to retry futility pruning with a real eval. I also tried reverse futility at depths 1 and 2, but it wasn't an improvement.

[zenpawn]

And if you have hash for eval you can save a decent amount of time.

I do have this, so that's good.

[Cardoso]

And if you have hash for eval you can save a decent amount of time.

Except if you have a multi-threaded engine and plan to run it using many threads, you could have a problem with increased memory traffic and cache coherency. The more threads you add the more costly it gets.