OpenChess

.
nTCEC Season 1 – Stage 3 starts Saturday March 30th at 14:00 UTC+1.

Stage 3 is a double Round Robin consisting of 8 chess engines, with a total of 56 games.
Each engine pair will play both sides of the openings, that are chosen by the nTCEC community.

The top 4 will move on to Stage 4, while those finishing 5-8 are out of nTCEC for the current Season.
Stage 4 will start 3-4 days after Stage 3 is finished.

The list of participants for Stage 3, in seed order:
Vitruvius, Komodo, Chiron and Quazar (qualified from Stage 2b)
Houdini, Stockfish, Rybka and Hiarcs (qualified from Stage 2a)

nTCEC is using 150m + 60s per move for the whole game, running on a dual Intel Xeon E5-2689 @ 3300 MHz.
Up to 16 cores can be used for engines capable of SMP.

Read the full nTCEC rules here:
http://www.tcec-chess.net/viewtopic.php?f=13&t=20

The broadcast will be running 24/7 with 1 game at a time, and can be watched here, also with chat:
http://www.tcec-chess.net/live.php
http://www.tcec-chess.net/live_wide.php (widescreen 1920px ++)

Finished games from Stage 3 will be moved here:
http://www.tcec-chess.net/stage_3.php

Read the latest nTCEC news here:
http://www.tcec-chess.net/viewforum.php?f=2

Hope to see everyone there!

Best Regards,
Martin Thoresen

Is 8GB of hash really enough for the time limits being used with 16 cores? Well, I don't know, but I will try to give an analysis anyway...

A rule of thumb, or at least my rule of thumb, is 1GB per core when I run analysis (I am typically interested in say 1 minute searches, with some hash carryover when following the game moves or PV, etc.). On a firmer basis, one can guess that most engines use 16 bytes per hash entry (yes, Rybka uses 8, but that is exceptional), so 8GB is 512M hash entries; if you hash in qsearch, I think you get (crudely) about 1.5 nodes per entry, so upon searching 750 million positions, the table would be "full" -- but that doesn't tell the whole story, as overwriting most of the leaf cruft doesn't matter too much. My sense is that true "saturation" of the hash table, when you start to replace useful info reasonably often, is perhaps 5-10 times this many nodes (again it depends on how you hash in qsearch, though the calculation differences even out a bit as most of the qsearch nodes in hash are expendable).

So with an 8GB hash, upon searching something like 5-10 billion positions I think you start to see deterioration of perfomance (per unit time, though of course not in an absolute sense), and by something like 10x that, or 50-100 billion positions, I would guess that the effect becomes quite noticeable (or at least measurable -- to test my hypothesis, I guess one could try to determine if the effective branching factor is [slightly] increasing at some sufficiently large depths, but collecting sufficient data could take a nontrivial amount of resources I fear). In fact, I would guess that if you were told that your engine was going to use up that much hash typically, you might rethink how to organise it.

For nTCEC, one can have 16 cores times 2.5 million positions per second (ballpark estimate), or 40-50 million positions per second. This means that in a 2-4 minute search, certainly not atypical with nTCEC 150m+60s, one is hitting 5-10 billion positions, and thus nearing what I speculate is the "danger zone" of hash saturation (though as I say, it is not really "dangerous", more that one is not gaining as much [or as fast] as one might expect from deeper searching).

BB+,

A couple of things:

# Very few engines can use a hash larger than 8 GB.
# Even some engines that can allocate an 8 GB hash has problems when using it (for example Quazar).

Even with only 3 (superfast) cores, some engines filled up the 4 GB hash in the previous Stages as well.

For example with the old nTCEC computer, Houdini 3 from the starting position took 2:36 to get to 99% hash usage.
With the new 16-core computer and 8 GB hash, Houdini 3 needs 1:35 to reach 99% hash usage. Sure, it's 1 minute faster, but it has also double the space to overwrite entries in.

In addition, all "minor hash" sizes can be set up to 1 GB, as explained here. http://www.tcec-chess.net/viewtopic.php?f=13&t=20.
And the EGTB cache can now be set up to 1 GB as well.

Sure, there would be enough memory to set a 12 GB hash, but most engines can't use a value that is not the power of 2, including Houdini.
And 16 GB is too much for the system. I chose this specific type of RAM because it is very good value for money and it is fast, but it is in 4 GB sticks only.

Best,
Martin

Now live!

http://www.tcec-chess.net/live.php
http://www.tcec-chess.net/live_wide.php

Standings after 3 of 14 rounds: Finished games: http://www.tcec-chess.net/stage_3.php

Standings after 7 of 14 rounds: Finished games: http://www.tcec-chess.net/stage_3.php

.
Final standings after 14 of 14 rounds:
Finished games: http://www.tcec-chess.net/stage_3.php

Congratulations to Houdini, Stockfish, Rybka and Komodo for qualifying for Stage 4 that will start in a few days.
.