UCI flexibility

[AxolotlFever]

Hello,

I have just implemented a Pawn Hash Table, and it has raised some questions about how rigourously we must follow the UCI spec.

1. If you set the TT size in my Engine to something small like 1mb, I will still always use a 1mb pawn hash table size. Is this a problem? Should I make the pawn size configurable, or only use some small fraction of the tt size? What is considered acceptable here. This also applies to various large arrays I need for magic bitboards for example.

2. Even if you only configure one search thread, I would also like to have one thread listening for uci commands, one thread for printing the PV. Is this acceptable?

3. More generally, how generous are tournament runners to engines that use more memory than allowed, or try to use more cores than allowed?

Thank you for helping me with this, and thanks to all engine testers,
Louis

[Steve Maughan]

Hi Louis,

Most people are quite chilled about memory / thread usage unless you're being a real resource hog. So to answer your questions:

1. You can interpret the TT size as the actual TT size. Things like a pawn hash are usually relatively small and can be considered to be in addition to the TT size

2. A listening thread isn't going to take much resource. Maverick has a listening thread. Having a thread to print the PV sounds like overkill to me, but that's OK too. Allocated threads are usually interpreted as the number of *search* threads

3. Most engines have a memory overhead of some type. Maverick has a move table that is ~45 mb. It's not a problem unless you're really hogging resources.

Steve

[AxolotlFever]

Thank you very much!

[Ras]

Hash table size doesn't matter much because e.g. CCRL tests are usually done with 128 or 256 MB, see here: http://ccrl.chessdom.com/ccrl/404/about.html . If your hash table design requires powers of 2, then it wouldn't make sense to allocate only 128 MB when 256 MB are allowed just because you'd end up at 257 MB instead of 256 MB otherwise. On the other hand, you probably won't really notice a difference beyond about 10k pawn hash table entries.

The threads are about those that actually cause CPU load, which an input thread doesn't if properly used. If you used non-blocking polling input in your input thread, that would be different because it would cause constant CPU load. But with properly blocking input, it will sleep when there is no input.

Actually, the UCI spec encourages handling input in another thread because the "isready" command has to be answered also during search, and "stop" has to be recognised during search, so you need parallel input processing. The alternative with peeking into the input pipe has always been a dirty hack that shouldn't be used anymore.