search

official-stockfish / Stockfish

A free and strong UCI chess engine
https://stockfishchess.org/
GNU General Public License v3.0
11.56k stars 2.27k forks source link

Stockfish submissions to TCEC #2082

Closed xoto10 closed 5 years ago

xoto10 commented 5 years ago

@mcostalba @snicolet No sf version has been submitted to this season's TCEC Division Premier which is about to start. Apparently they emailed us (I'm not sure who) on Wednesday and haven't received a reply.

I have suggested they use a recent version from abrok, I suggested this one:

Author: Marco Costalba
Date: Sat Apr 6 02:03:15 2019 +0200
Timestamp: 1554508995

Fix a missing assignment in previous commit  ...

as the last one before their deadline.

Can you contact TCEC to conifrm this is the one to use please?

Can we name someone to take charge of TCEC submissions (@Alayan-stk-2 :-) ?), preferably with someone else as backup. Or officially ask them to just use the latest abrok version each time, so that we're not relying on unreliable communications?

mstembera commented 3 years ago

Yes. Another way to see it is SF runs 24% slower E runs 12% slower K runs 42% faster Since the CCCC machine has 32% more threads than TCEC the K scaling makes the most sense to first order of approximation(given different types of cores). Something seems wrong with SF and E.

vondele commented 3 years ago

sysadmin had no interest in trying custom binaries.. It is not really 'wrong with SF'. The current setup of the machine has 4x lower bandwidth than a machine with essentially the same CPUs but different memory config. Speed of SF is 2x lower. It could just be that SF is much more memory bandwidth sensitive than K. Maybe K has a different way to use TT, or some other technique that reduces memory bandwidth? Additional RAM should arrive in 1 or 2 weeks, and in principle should give SF a 2x speed boost... unless something else is not OK.

mstembera commented 3 years ago

Agree the memory bandwidth seems the most likely cause. If it is then K indeed is less bandwidth sensitive. Not refreshing the TT definitely reduces bandwidth usage so I think worth trying. https://github.com/official-stockfish/Stockfish/pull/3288 [Edit] Of course we can revert if it doesn't fix it.

vondele commented 3 years ago

I've received a message from CCCC sysadmin: new ram is installed. On the asm[fish] benchmark the server scored 301.9 Mnps

mstembera commented 3 years ago

Does this mean the extra ram fixed it? I don't know what the "asm[fish] benchmark" is nor what the expected nps for it is nor what the nps was before. Seeing SF play against K will be telling.

vondele commented 3 years ago

yes, the ram fixed it.

The benchmark refers to asmfish as used http://ipmanchess.yolasite.com/amd---intel-chess-bench.php the CCC machine is now listed there as well, as second faster system on that list.

mstembera commented 3 years ago

@vondele It looks like some engines(ex. Igel) in TCEC S21 DivP are using 256GB of hash. Can we notify them before the SuFi that we would like to use 256GB as well?

vondele commented 3 years ago

yes, should work.

vondele commented 3 years ago

@mstembera this would be the distribution of 'hashful' before bestmove for all games played in divp (128GiB, 1h TC). I think we're pretty far from the hash pressure regime. image however, doubling it for the SuFi (with 2h TC), seems like a reasonable thing to do.

Sopel97 commented 3 years ago

64 bit hash keys because we have space left?

mstembera commented 3 years ago

@vondele Yes agree doubling for 2h TC is good. As an aside perhaps I don't know how to read the y axis of the plot above but from your original plots comparing 64GiB vs 128GiB it seemed like we were in a high hash pressure regime much more. Has something changed?

vondele commented 3 years ago

y axis, is basically a density (or fraction of positions), so a histogram. Not sure what has changed, apart from nnue etc.