UCI flexibility

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
AxolotlFever
Posts: 50
Joined: Sun Nov 11, 2018 8:26 pm
Location: Germany
Full name: Louis Mackenzie-Smith
Contact:

UCI flexibility

Post by AxolotlFever » Thu Apr 25, 2019 10:52 am

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

User avatar
Steve Maughan
Posts: 1061
Joined: Wed Mar 08, 2006 7:28 pm
Location: Florida, USA
Contact:

Re: UCI flexibility

Post by Steve Maughan » Thu Apr 25, 2019 11:22 am

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
http://www.chessprogramming.net - Maverick Chess Engine

AxolotlFever
Posts: 50
Joined: Sun Nov 11, 2018 8:26 pm
Location: Germany
Full name: Louis Mackenzie-Smith
Contact:

Re: UCI flexibility

Post by AxolotlFever » Thu Apr 25, 2019 11:33 am

Thank you very much!

Ras
Posts: 1160
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI flexibility

Post by Ras » Thu Apr 25, 2019 3:27 pm

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.
Rasmus Althoff
https://www.ct800.net

Post Reply