@approvers, what is gating this patch? I don't see any comments after the pull request was raised...

I noticed it can't be merged directly into master, but that shouldn't be a problem.
I prepared a continuous try that started well on my laptop, and I'm waiting for a resolution of this patch.

Please resolve merge conflicts and indentation issues (use spaces instead of tabs).

Other than it looks fine form me.

Apologise for the indentation issues. Have updated my Notepad++ preferences to use spaces instead of Tabs.

@rohanryan: Please fix the pull request.

Fixed indentation issues. Have I handled the merge conflict correctly?

I hope you did. I managed to merge into my repository. And I hope this will be merged into master soon because people are testing changes in lazy log formula against a master which has no sense at this point. I checked on my computer that lower depths are very important when we are low on time.

This change is a bit controversial, so we need to wait for approval from @glinscott before committing.

@zamar @glinscott : I agree this patch is somewhat TC dependent, and so a bit controversial in that sense. However, I think it can't be harmful. If you are unsure, maybe to run another test with lower increment.

Although I was a fan of this patch, I now kindly ask that we postpone an acceptance of this patch because I now see what we're doing: we are testing very complicated ideas and we didn't try some simple ones. For example, if additional depths (0,1,2) were good on 3 threads, maybe additional depths (0,1,1,2,2,2,2) are going to be good on 7 threads. In this particular patch we are not sure whether an elo gain comes from TM tweak or from factor 1.1 in front of log.

What is the controversial bit? Should I submit for re-testing? or test at
different number of threads? There is more ELO gain to be made in the
selection of helper thread depths. And I think that a near optimal solution
would be to store historical nodecounts, calculate approximate branching
factor and then estimate maximum helper thread depth. Approx branching
Factor = nodecounts(current ply)/nodecounts(current ply-1) [Rather than
relying on game phase, it relies on the current search tree. Some games may
enter different phases earlier or later.]

Another option would be to test at even larger thread counts. If the
concept is valid, the gain at higher thread counts would be even more
pronounced.

On Thu, Nov 19, 2015 at 3:09 AM, IIvec notifications@github.com wrote:

Although I was a fan of this patch, I now kindly ask that we postpone an
acceptance of this patch because I now see what we're doing: we are testing
very complicated ideas and we didn't try some simple ones. For example, if
additional depths (0,1,2) were good on 3 threads, maybe additional depths
(0,1,1,2,2,2,2) are going to be good on 7 threads. In this particular patch
we are not sure whether an elo gain comes from TM tweak or from factor 1.1
in front of log.

—
Reply to this email directly or view it on GitHub
#499 (comment)
.

@rohanryan : I tested your patch and some other variants on my computer. Your patch works pretty well, but it seems that the whole idea is somewhat dependent on the ratio time/increment. I thought it would be best first to optimize performance with simple formula (constant factors) and than to go with deeper idea. Here is one such formula
rootDepth = Threads.main()->rootDepth + Depth(int(0.5 + 1.95 * log(1 + 0.67 * this->idx)));
that looks promising.

Anyway, I'll lower priority of my test, and let maintainers to decide about this.

I think that any patch that includes depth or time is more or less dependent on time controls and that the only question is:

Do we need more tests?

@glinscott: We need your input on this one. What do you think?

It's a small ELO gain, but introduces time control dependency in SMP depth formula.

I wonder if we could scale this instead of having it be a hard switchover. The hard switchover condition is going to be hard to tune in the future.

Gary,

I agree a function that scales is a much better eventual solution than a
hard switchover. I tried a version that failed
http://tests.stockfishchess.org/tests/view/564574640ebc59227df17358
and then tried to tune the value but did not succeed.
http://tests.stockfishchess.org/tests/view/5646021f0ebc59227df17393

Not sure if the ck values etc chosen for the tuning session were
appropriate or not.

The scaling is best linked to branching factor and I've seen work from
@cuddlestmonkey
and others to calculate this.

On Mon, Nov 23, 2015 at 3:01 AM, Gary Linscott notifications@github.com
wrote:

I wonder if we could scale this instead of having it be a hard switchover.
The hard switchover condition is going to be hard to tune in the future.

—
Reply to this email directly or view it on GitHub
#499 (comment)
.

Here is a training run for the hard switchover
http://tests.stockfishchess.org/tests/view/564254130ebc59227df17260

Seems to indicate that 5.4 is better than 5. Not sure if even more tuning
is possible or that is the best value.

On Mon, Nov 23, 2015 at 8:33 AM, Rohan Ryan rohanryan@gmail.com wrote:

Gary,

I agree a function that scales is a much better eventual solution than a
hard switchover. I tried a version that failed
http://tests.stockfishchess.org/tests/view/564574640ebc59227df17358
and then tried to tune the value but did not succeed.
http://tests.stockfishchess.org/tests/view/5646021f0ebc59227df17393

Not sure if the ck values etc chosen for the tuning session were
appropriate or not.

The scaling is best linked to branching factor and I've seen work from @cuddlestmonkey
and others to calculate this.

On Mon, Nov 23, 2015 at 3:01 AM, Gary Linscott notifications@github.com
wrote:

I wonder if we could scale this instead of having it be a hard
switchover. The hard switchover condition is going to be hard to tune in
the future.

—
Reply to this email directly or view it on GitHub
#499 (comment)
.

@lucasart Is currently working on "equal thread model". Let's see what comes out of it before merging this.

@zamar: the two are orthogonal, so it won't bother me if you merge this.

@zamar: can single formulas (without time dependence) be tested as simplification against this patch?

If we waited so much with this patch, I think we can wait a little bit more,

1. to see how this formula will work:
   http://tests.stockfishchess.org/tests/view/5654c3570ebc5902cdc08490
2. to test this for no regression on 3 threads
3. to test it for no regression on 15 threads (LTC only).
   I think we can't afford more, but I think this minimum is essential if we want good SMP patches.

This patch has been obsoleted by #525. Closing.