Stockfish and optimizing options for SMP search

[mcostalba]

Hi Marco,

Just a tip.

Most losing captures are refuted very quickly. Splitting after all good captures/killers and all of the quiet moves were already searched is IMO not worth the overhead. It might be beneficial to restrict splits only when the move picker object is in phase < LOSING_CAPTURES.

Hmm, you gave me a good related idea: do not split if there is singular move.

This is another good idea, I would say even more elegant becuase it is based on a more general property of the node and less on specific chess knowledge. I think they very well complement each other and can be used both at the same time: in an ALL node Richard's one is winning, in a CUT node Giancarlo's one is more on spot.

Although it is also true that if we have a singular move very probably it will cut off immediately and so there is no more additional moves to split (YBWC implementation) and the Giancarlo's rule happens to be already implicitly implemented in the common case.

[bob]

Hi Marco,

Just a tip.

Most losing captures are refuted very quickly. Splitting after all good captures/killers and all of the quiet moves were already searched is IMO not worth the overhead. It might be beneficial to restrict splits only when the move picker object is in phase < LOSING_CAPTURES.

Hmm, you gave me a good related idea: do not split if there is singular move.

I am not sure what you mean. But typically you would want to search the SE move first if you notice it in what Hsu called "the sticky trans table". So you wouldn't split before that move anyway. But once you have searched it with no fail-high, would you not want to split there to search the rest of the moves? I did so in Cray Blitz, and this can be an even bigger win if you allow splits at the root as well as elsewhere.

Also I am not sure the above "don't split" idea is good anyway. Suppose you are at depth 25, and you are into "losing captures" at ply=2, would you not want to split there? I'd buy that idea out near the tips, perhaps...

[mcostalba]

Hi Marco,

Just a tip.

Most losing captures are refuted very quickly. Splitting after all good captures/killers and all of the quiet moves were already searched is IMO not worth the overhead. It might be beneficial to restrict splits only when the move picker object is in phase < LOSING_CAPTURES.

Hmm, you gave me a good related idea: do not split if there is singular move.

Ok, I want to join the club

What about to split only if:

Code: Select all

moveCount < K * depth

At high depths you split whenever it is possible while at lower depths you avoid splitting on late moves. This has the statistical behavior to prefer splitting at high depth nodes than at shallow ones.

[Daniel Shawul]

You already loose big on parallelization by not searching the first move in parallel, all for the sake of reducing search overhead. YBW is optimized with different setups so it will take a lot to improve upon it. If you really want to find a good place to split, try rewinding the stack one step when you are sure you have an approximate score at the current ply after searching a couple of moves.

People have tried neural networks just for identifying places to split. I doubt we can improve upon YBW by throwing random stuff up.

[bob]

Hi Marco,

Just a tip.

Most losing captures are refuted very quickly. Splitting after all good captures/killers and all of the quiet moves were already searched is IMO not worth the overhead. It might be beneficial to restrict splits only when the move picker object is in phase < LOSING_CAPTURES.

Hmm, you gave me a good related idea: do not split if there is singular move.

Ok, I want to join the club

What about to split only if:

Code: Select all

moveCount < K * depth

At high depths you split whenever it is possible while at lower depths you avoid splitting on late moves. This has the statistical behavior to prefer splitting at high depth nodes than at shallow ones.

The formula won't work very well. Depth can easily hit 25. 1*25, 2*25, by the time you get to 2*25 it will always be true, not many positions have 50+ moves...

[mcostalba]

People have tried neural networks just for identifying places to split. I doubt we can improve upon YBW by throwing random stuff up.

Throwing random stuff up ? And how do you think engines have increased hundreds of ELO in the last 20 years ?

Hint: not thanks to neural networks

[Milos]

Ok, I want to join the club

What about to split only if:

Code: Select all

moveCount < K * depth

At high depths you split whenever it is possible while at lower depths you avoid splitting on late moves. This has the statistical behavior to prefer splitting at high depth nodes than at shallow ones.

Idea is excellent (ignore Bob he as usual has problems understanding written content), only the formula cannot be liner function of depth, it should be stronger.
I would use something like:

Code: Select all

moveCount < (depth^2)/25

[bob]

Ok, I want to join the club

What about to split only if:

Code: Select all

moveCount < K * depth

At high depths you split whenever it is possible while at lower depths you avoid splitting on late moves. This has the statistical behavior to prefer splitting at high depth nodes than at shallow ones.

Idea is excellent (ignore Bob he as usual has problems understanding written content), only the formula cannot be liner function of depth, it should be stronger.
I would use something like:

Code: Select all

moveCount < (depth^2)/25

You are certainly the well-known expert here, having written several parallel search engines...

Of course, don't let someone that has actually written parallel search chess programs, someone that actually understands the underlying issues within the alpha/beta framework, try to change your uninformed comments. Carry on.

If you had even basic understanding of parallel alpha/beta, you would see what is wrong with this idea. But, of course, you don't...

As far as that formula goes, at the root, you would only split when movecnt < 25 (assuming a 25 ply search)??? Makes perfect sense unless you know what you are doing. On a 15 ply search, you only split when movecnt < 9 (15^2/25)?

In reality, once you have searched one move, you almost _always_ want to split there. Except for the occasional case where you think another move might be best, and know that it is better to search such moves one at a time, using all available threads.

There is so much you don't know...

[Milos]

You are certainly the well-known expert here, having written several parallel search engines...

Of course, don't let someone that has actually written parallel search chess programs, someone that actually understands the underlying issues within the alpha/beta framework, try to change your uninformed comments. Carry on.

If you had even basic understanding of parallel alpha/beta, you would see what is wrong with this idea. But, of course, you don't...

You can write thousands of parallel search chess programs still your ideas are not even remotely as fresh as ideas of many on this forum (most of them having much stronger engine than your all time best).
And trying to make science out of simple engineering and parameters tweaking is just ridiculous.
Computer chess programing is not science and understanding it doesn't require neither 50 years of computer chess programing practice nor having written 100 programs (most of undergrad students know calculus much better than Newton even though he invented it, same can be applied to chess).
You can sell that "science" BS to your students but you can hardly do that to anyone that has at least a bit of understanding of scientific approach and method.

[bob]

You are certainly the well-known expert here, having written several parallel search engines...

Of course, don't let someone that has actually written parallel search chess programs, someone that actually understands the underlying issues within the alpha/beta framework, try to change your uninformed comments. Carry on.

If you had even basic understanding of parallel alpha/beta, you would see what is wrong with this idea. But, of course, you don't...

You can write thousands of parallel search chess programs still your ideas are not even remotely as fresh as ideas of many on this forum (most of them having much stronger engine than your all time best).
And trying to make science out of simple engineering and parameters tweaking is just ridiculous.
Computer chess programing is not science and understanding it doesn't require neither 50 years of computer chess programing practice nor having written 100 programs (most of undergrad students know calculus much better than Newton even though he invented it, same can be applied to chess).
You can sell that "science" BS to your students but you can hardly do that to anyone that has at least a bit of understanding of scientific approach and method.

All of that is simply 100% nonsense. But don't let that stop you. If I thought you had even a tiny bit of 'understanding of scientific approach and method' our conversations might take a different path. But you butt in with nonsense, then after getting kicked around, you leave with your tail tucked. repeatedly. This will be another one of those cases, probably sooner rather than later...