Stockfish and optimizing options for SMP search

[jwes]

Actually, in any post you write here, "fact" is one thing nobody will find...

You seams to know what everybody else assumes for a fact. I wonder when have you developed that mind reading skill???

I did _not_ say your idea was good. I said it was flawed, and explained why. If you don't get that...

To judge if idea is good or not you first need to understand it. Your "explanation" was for totally unrelated thing, therefore the only conclusion is that you didn't get it.

How hard is it to understand? Perhaps you are the one that doesn't understand the idea, which would explain why you don't get the point that the idea is not a good one. Not horrible, but certainly not good.

One simple flaw is that when you reach a position with remaining depth of N, you have _no idea_ what the tree below each of the remaining moves looks like. Might be quite simple and narrow. Might be quite deep and bushy. But one thing is for sure, the more moves that have been searched, the more likely it is that all moves need to be searched, which is exactly where we'd like to split the tree to avoid search overhead caused by an unexpected fail high.

But of course you don't understand any of that...

An interesting collorary to this is that the more sure that the more sure you are that this is a good split point, the better it would be to reduce or prune and save even more work.

I'm not sure that is true. One question is "do I need to search every node at this ply?" (Is this an ALL/CUT node?) If so, this is an excellent point to split the tree. That is independent of the "should I further reduce/prune the late moves at this ply?" question. We are trying to split at points where we don't suddenly get a cutoff (fail-high) which means that other things done in parallel here are wasted. I don't really care whether I am searching good moves or lousy moves in parallel at all, load-balancing is not an issue in my current code. If one thread runs out of work, it will quickly jump in and help the remaining threads finish their stuff...

The point is that saying "do I need to search every node at this ply?" is the same as saying "is every node going to fail low?", so the more sure you are that you need to search each node, the less risk there is in reducing or pruning.

[bob]

Actually, in any post you write here, "fact" is one thing nobody will find...

You seams to know what everybody else assumes for a fact. I wonder when have you developed that mind reading skill???

I did _not_ say your idea was good. I said it was flawed, and explained why. If you don't get that...

To judge if idea is good or not you first need to understand it. Your "explanation" was for totally unrelated thing, therefore the only conclusion is that you didn't get it.

How hard is it to understand? Perhaps you are the one that doesn't understand the idea, which would explain why you don't get the point that the idea is not a good one. Not horrible, but certainly not good.

One simple flaw is that when you reach a position with remaining depth of N, you have _no idea_ what the tree below each of the remaining moves looks like. Might be quite simple and narrow. Might be quite deep and bushy. But one thing is for sure, the more moves that have been searched, the more likely it is that all moves need to be searched, which is exactly where we'd like to split the tree to avoid search overhead caused by an unexpected fail high.

But of course you don't understand any of that...

An interesting collorary to this is that the more sure that the more sure you are that this is a good split point, the better it would be to reduce or prune and save even more work.

I'm not sure that is true. One question is "do I need to search every node at this ply?" (Is this an ALL/CUT node?) If so, this is an excellent point to split the tree. That is independent of the "should I further reduce/prune the late moves at this ply?" question. We are trying to split at points where we don't suddenly get a cutoff (fail-high) which means that other things done in parallel here are wasted. I don't really care whether I am searching good moves or lousy moves in parallel at all, load-balancing is not an issue in my current code. If one thread runs out of work, it will quickly jump in and help the remaining threads finish their stuff...

The point is that saying "do I need to search every node at this ply?" is the same as saying "is every node going to fail low?", so the more sure you are that you need to search each node, the less risk there is in reducing or pruning.

Yes, but a mistake has different consequences for each question. If you screw up the split point, you have overhead and reduced SMP performance. If you reduce things that should not be reduced, you make actual tactical/positional errors on the board... Remember that just because everything is supposed to fail low, doesn't mean that it will. And that might well influence the best move and the game outcome...

[Milos]

I am guessing that you have finally done your "tuck tail and run" routine again?

good riddance...

I figured real data would chase you away, since it is hard to argue with that. And you got real data from two different sources this go-round...

You're wrong again. I don't have time to generate the data for the moment, but I'll do it over the weekend and come back to you, don't think you'll get rid of me so easily .

[bob]

I am guessing that you have finally done your "tuck tail and run" routine again?

good riddance...

I figured real data would chase you away, since it is hard to argue with that. And you got real data from two different sources this go-round...

You're wrong again. I don't have time to generate the data for the moment, but I'll do it over the weekend and come back to you, don't think you'll get rid of me so easily .

There's already plenty of data that has been presented. By two different people. And the data agrees closely enough to call it "exactly agrees"...