TalkChess.com

The TCEC contest has 44 threads (about half of CCC 3).
So why not use 44 threads per engine and have pondering turned on?
The extra 2 threads will make the server more responsive and avoid competition when the machine needs to do some internal upkeep.
That way, you get double the quality with the games in the same amount of time.

As far as making engines crash, most engines on TCEC fare pretty well, so a reasonable thread count should not be a big issue.

We had major controversy in ccc1 when ht and ponder were on, so this time we are not allowing ponder

Dann Corbit wrote: ↑Sat Dec 08, 2018 3:06 am The TCEC contest has 44 threads (about half of CCC 3).
So why not use 44 threads per engine and have pondering turned on?
The extra 2 threads will make the server more responsive and avoid competition when the machine needs to do some internal upkeep.
That way, you get double the quality with the games in the same amount of time.

As far as making engines crash, most engines on TCEC fare pretty well, so a reasonable thread count should not be a big issue.

A lot of engines don't ponder.

Some even refuse to implement pondering, because UCI ponder logic is such an abortion, I don't want to soil Demolito's code base wjth this.

Dann Corbit wrote: ↑Sat Dec 08, 2018 3:06 am The TCEC contest has 44 threads (about half of CCC 3).
So why not use 44 threads per engine and have pondering turned on?
The extra 2 threads will make the server more responsive and avoid competition when the machine needs to do some internal upkeep.
That way, you get double the quality with the games in the same amount of time.
...

I think this question is an established one.

jdart wrote: ↑Sat Dec 08, 2018 1:30 am Yes, one of the points is that after a while you don't get much gain from more cores.
--Jon

I'm starting toi think that lazy SMP shall be somehow modified to work well with those high number of thread. Since the number of thread is comprarable with the number of legal moves, one can think about having some thread searching some alternative root moves. I'm thinking about mixing lazysmp, multiPV, and stockfish voting system for lazysmp.

But at the moment I don't have any working implementation and before that I have to refactor the lazysmp and multi PV code a lot

I'm starting toi think that lazy SMP shall be somehow modified to work well with those high number of thread.

Lazy SMP is basically a "share nothing" approach (except for the hash table). This may not be optimal. When I used YBWC, I had support for multiple threads sharing a move generator, so that they were both fetching moves from the same move list, but were guaranteed to get different moves. So that is one way to distribute things. (I don't know if this is actually a good idea but I have thought about it).

The other thing is, there are a lot of tuning and profiling tools available for multithreaded programs (Intel VTune for example) and these would help show hotspots .. but ideally you need a really big test machine for this to simulate TCEC & CCC conditions.

--Jon

I'm not talking about specific engine deficiencies with high core number, I'm thinking that sine we have so much threads some of them can try searching the second best move. It happens that sometimes when dpong MultiPV an engine find the strongest move faster than in single Pv, but usually it's weaker.
I think that with 90 cores, probably having 30 of them exploring other candidates can be useful

Time and time again we have proven that engines still gain vast amounts of elo with core doubling, and even with going from N cores to 2N threads, as shown by Noobpwnftw using SF 192core vs SF 384 thread.

The people who object to using these higher core counts have simply not taken the time to ensure their engines are bug free for high core counts. It should be trivial to prove that if there are no issues on 16 threads, then there are no issues on 512 threads.

Those who feel otherwise should be welcome to willingly reduce their core count and vastly decrease their engines performance. I won't feel bad about taking easy games off of those who dont understand the 100 elo to be gained between 16 cores and 90 threads.

And now the competition among big 4 is more and more intense. SF and Leela have only 0.5 score gap.

lucasart wrote: ↑Sat Dec 08, 2018 5:50 am

Dann Corbit wrote: ↑Sat Dec 08, 2018 3:06 am The TCEC contest has 44 threads (about half of CCC 3).
So why not use 44 threads per engine and have pondering turned on?
The extra 2 threads will make the server more responsive and avoid competition when the machine needs to do some internal upkeep.
That way, you get double the quality with the games in the same amount of time.

As far as making engines crash, most engines on TCEC fare pretty well, so a reasonable thread count should not be a big issue.

A lot of engines don't ponder.

Some even refuse to implement pondering, because UCI ponder logic is such an abortion, I don't want to soil Demolito's code base wjth this.

OK.
But engines work better if they use their dedicated threads alone and they not use threads together with their contender. The difference between PC with 44 threads and 88 threads is only about 10-20 Elo.