Want to know what savings to expect with pruning methods...

[asanjuan]

Here are my numbers for a 8 ply search with quiescence, using iterative deepening.
(Not the best numbers, but i'm still trying to improve ;D):

Plain alfa-beta without any intelligeng move ordering: 104.935.779 nodes
PVS, adding killers and history heuristics for move ordering: 3.452.753 nodes
adding TT for ordering and transpositions: 1.056.144 nodes
adding futility pruning: 851.423 nodes
using Null-Move pruning with R=2: 572.238 nodes
using LMR (depending on implementations): 164.887 nodes

Only a note: Take care that I only use Alfa-beta as search on the first result. The rest is based on PVS, because is expected to find the pv using the killers, so it is posible to use null window searches after that.

Hope these numbers will help you.

Just a final note: In my tests (not very exhaustive, I must say) i tried with aspirations and Mtdf, and i get the conclusion that aspiration don't help when you use PVS, and mtdf is very dependant on your TT implementation. In my case mtdf was a was a waste of time, maybe because you need both upper values and lower values stored in your TT sockets, to make mtdf prune efficiently. But really don't know. I only save one value and the node type (typealfa, typebeta or typeExact), so at the end I abandoned the idea.

[voyagerOne]

Thanks Alberto for your effort and time.

This will sort of be a benchmark for me...

By the way, are your numbers based from the beginning position?

Bill

[asanjuan]

Yes: starting position and 16Mb for TT, 2 killer moves. I think that's all.

But just a suggestion: don't try to get my numbers, i think it's better to compare the gains in %, for example: using killers ->XX% less nodes, using null move: XX% and so on.
This is because the number of nodes are very dependant on your eval function, and the less accurate your eval is, the more researches you have to do in PVS framework...
(my english isn't good enough to express this idea)
And very important: try not to search bad captures, or captures that don't raise alfa in quiescence (like a futile condition). Is a useless effort to search over them.

[Sven]

Not below 100k but far below 50M. I think you might be able to reach <2Mnodes for 8 plies (initial position) with all you have now, just with a better move ordering.

You are pretty close...the node count of my engine is 2.7M.

By the way, I average around 8-10 seconds (mid-game) at depth 8. Not 20...I thought it was 20 for some reason.

What I intended to ask was, in which order does your Qsearch look at all the captures?

MVV/LVA.

Thanks for all your input Sven.

If your node count for completing 8 plies from the initial position is 2.7M and your NPS is around 2.5Mnodes/sec then your search needs only 1 sec in that case. So my misunderstanding might be that you were talking about middlegame positions when asking whether "20 seconds for 8 plies" were normal or not, and I transferred that to the initial position which obviously was not your intent.

Nevertheless I still believe that 20..25 Mnodes (for 8-10 seconds searching at 2.5Mnps) is quite a lot of nodes for 8 plies in a middlegame position.

Sven