UCI Hash Usage Rules

[tpoppins]

Most engines use 1 thread more than is specified by the user. This thread is merely for the UI in hopefully all of these engines and is considered by many to be inconsequential.

That is plain nonsense. Out of around 300 engines I've had to deal with only two exceed the expected thread usage: the original Drosophila 1.5.0 release uses two threads despite being non-SMP, and Cupcake 1.1a (also non-SMP) uses up to six.

[elcabesa]

That is plain nonsense. Out of around 300 engines I've had to deal with only two exceed the expected thread usage: the original Drosophila 1.5.0 release uses two threads despite being non-SMP, and Cupcake 1.1a (also non-SMP) uses up to six.

No, it's not nonsense.

Stockfish use at least one thread more than the ones you specify, and Vajolet use 2 more thread than the one that you specify.
Those are the 2 thread used by Vajolet:
1) uci interface.
2) time management.

they are 99% of time sleeping, so you don't see them when you see CPU occupancy.

That sayd the Thread option from UCI is meant for the Searching Threads, and the Hash usage are for the total of Big Tables. I won't count the tens of small 100kB table or even 1MB table used from the engine when calculating the Hash size.

It may be important in a 10 MB total memory tournament but not in 256MB or more from my point of view

[syzygy]

As far as I know, the main Hash UCI option is meant to only talk about the primary Transposition Table.

Any other large tables, sized dynamically, I would list seperate options for. Some engines have an Eval Cache.

This is wrong. The UCI specs clearly mention 'hash tables', plural.

And the same UCI spec then says "So the engine should use a very small hash first as default". So now hash is singular again.

The UCI spec was not drafted by a lawyer. I know of no UCI engine that treats the Hash setting as anything else than the (maximum) size of the transposition table (or tables if they have one for white and one for black).

Also note that the same UCI spec defines the "NalimovCache" option. I am afraid you are quite alone in taking the view that this value is also included in the Hash value. And if 99.9% of the relevant public of the UCI spec does not read it the way you would like to read it, then your reading does not count.

[noobpwnftw]

Since when the UCI protocol became rules of compliance?

It seems like most engines come to a consensus of naming various configurable parameters which are common among implementations.

The behavior of how an engine should treat those parameters are totally implementation specific and as long as the engines aren't running for their UC(N)IX or whatever branding campaign, nobody should care.

[hgm]

Also note that the same UCI spec defines the "NalimovCache" option. I am afraid you are quite alone in taking the view that this value is also included in the Hash value. And if 99.9% of the relevant public of the UCI spec does not read it the way you would like to read it, then your reading does not count.

I am pretty sure 99.9% of the public would complain when an engine worked like crap (swapping the TT to the disk) if they specified a hash size that seems reasonable compared to their total memory, which works for all engines, because that engine happens to be the only one that uses a technique requiring some extra GB (e.g.weights of a fixed-size neural net).

Things would simply not work well, if engines frivolously allocated chunks of memory similar in size to the TT for other purposes not commonly present in other engines. (I.e. anything but the TT). I don't see what you hope to gain by insisting on an interpretation that would cause trouble (and require work-arounds) for virtually every user that is not an engine-developer himself.

[syzygy]

Things would simply not work well, if engines frivolously allocated chunks of memory similar in size to the TT for other purposes not commonly present in other engines. (I.e. anything but the TT).

Which has nothing to do with how the UCI Hash option is supposed to behave according to the UCI spec.

I don't see what you hope to gain by insisting on an interpretation that would cause trouble (and require work-arounds) for virtually every user that is not an engine-developer himself.

A single post telling you once how it is, is not insisting under any normal interpretation of the word insisting.

[hgm]

Things would simply not work well, if engines frivolously allocated chunks of memory similar in size to the TT for other purposes not commonly present in other engines. (I.e. anything but the TT).

Which has nothing to do with how the UCI Hash option is supposed to behave according to the UCI spec.

I don't see what you hope to gain by insisting on an interpretation that would cause trouble (and require work-arounds) for virtually every user that is not an engine-developer himself.

A single post telling you once how it is, is not insisting under any normal interpretation of the word insisting.

I see a lawyer trying to weasle his way out of a guilty verdict by technicalities...

If there is ambiguity in the specs of how the Hash option should be interpreted, as you seem to want to claim on the basis that the specs only use the singular when it says the initial size should be small, and one of the interpretations would (in cases where it made a difference) cause things not to work to a degree from which 99% of the users would not be able to recover on their own steam, it should be obvious that this is not a viable interpretation. So it has everything to do with how the UCI specs should be read.

But if you like legal nitpicking: your claim has no merit in the first place: even if the remark for the initial size would not have spoken about 'hash', but would have explicitly mentioned "the ininital size of the main transposition table should be small", it wouldn't imply anything other than what it said. If the total has to be small, obviously any inividual table would have to be small as well. There is no exhaustive summary of tables for which this advice/warning applies, which would not be possible anyway, given that programming techniques evolve, and tables for new purposes will no doubt appear and become common in the future.

Despite the use of the singular, the remark about initial size should be taken to apply to any table of configurable size. Or do you think it would be a good idea to have an engine start with 50GB Nalimov Cache (to be prepared for handling 8-men EGT ) as a default?

[syzygy]

Things would simply not work well, if engines frivolously allocated chunks of memory similar in size to the TT for other purposes not commonly present in other engines. (I.e. anything but the TT).

Which has nothing to do with how the UCI Hash option is supposed to behave according to the UCI spec.

I don't see what you hope to gain by insisting on an interpretation that would cause trouble (and require work-arounds) for virtually every user that is not an engine-developer himself.

A single post telling you once how it is, is not insisting under any normal interpretation of the word insisting.

I see a lawyer trying to weasle his way out of a guilty verdict by technicalities...

Nope, just not interested in a total change of topic. If you think users need an option to limit max memory usage then that's fine with me, but I am limiting my contribution to this thread to the UCI Hash option. And again, as far as I know its meaning is clear to all UCI engine developers, just not to you. Since you are not developing a UCI engine, there is no need for further discussion.

[hgm]

Now it counts as ' insisting' right?

[syzygy]

Now it counts as ' insisting' right?

Insist on what? That all UCI engine developers share a common understanding of the meaning of the Hash option? Not even you are disputing this.