UCI flexibility
Posted: Thu Apr 25, 2019 12:52 pm
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
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