UCI Hash Usage Rules

[hgm]

"insisting on an interpretation that would cause trouble (and require work-arounds) for virtually every user that is not an engine-developer himself"

Let me make it easier. How many UCI engines are there, that do not work for most noob users, because they allocate huge amounts of memory in addition to the Hash size specified by the user?

Perhaps UCI engine authors are not as stupid as you imply them to be...

[MOBMAT]

Wow, I didn't expect the original question to turn into a major legal battle.
I thought I would request a ruling because I was testing an evaluation hash (not a pawn hash) and its size was a lot bigger than 1M. In fact, I made it 10% the size of the main hash. I was adjusting the size of the main hash to compensate for the size of the eval hash in order to stay within the UCI Hash size limit. If I didn't, then my " total hash" usage would be 110% of the size that was "allowed" by the UCI setting and I thought that might be exceeding the intent of the size restriction.
In my engines, I don't allocate (dynamically) anything except for what we call hash tables. That doesn't mean there isn't a lot of other possible memory use by an engine that might use a lot of static memory, or other areas that might use dynamic memory. What if I created my own version of 3-4 man (different implementation than any of the other endgame table bases) table-bases and stored them in memory? Would that be "fair" use of memory space? Some engines already load up existing ETBs into memory. If they are reading the disc-based files, they they are probably allocating memory for those. Should they be considering that space?
There might not be an easy answer, except to say, the UCI "Hash" only applies to the main hash table.
We have a moving target here, though. As new ideas (with their own drain on system resources) are entertained and become popular, what was considered fair use of memory then, might not be now.
I'm guessing one intent of the UCI Hash Size setting is to help the operators of events control memory use by the engines so that system resources are not exceeded. The main hash is probably the largest memory hog, so it makes sense to restrict it's size.
So, for now, I will use the UCI Hash size setting to apply only to the Main Hash table.

[syzygy]

"insisting on an interpretation that would cause trouble (and require work-arounds) for virtually every user that is not an engine-developer himself"

Let me make it easier. How many UCI engines are there, that do not work for most noob users, because they allocate huge amounts of memory in addition to the Hash size specified by the user?

I will just let you insist on changing the topic.

Perhaps UCI engine authors are not as stupid as you imply them to be...

Your character shows.

[syzygy]

Would that be "fair" use of memory space?

Fairness is not an issue here. (Sure, it may be important if you want to test engines by running them against each other on the same computer.)

[hgm]

The issue here, raised by the OP, is whether, when he would use some significantly large table that is not commonly used, he would have to deduct that from the Hash option value to get the TT size, or whether he can just use as much memory as he wants for any purpose he wants in addition to the specified value, as long as that purpose would not be a classical transposition table.

There seem to be two answers here:

I say: yes, you must deduct it. This is what the specs say. And it is also what common sense says, because if you don't, your engine will unexpectedly not work where other engines do, and you will be buried under complaints, giving your engine a bad name.

Then there is syzygy, who basically says: to hell with the UCI specs, no one takes those seriously anyway. Just go ahead, use as many additional memory as you want. Make an engine that causes as much trouble for its users as you can, because a misinterpretation of the UCI specs perfectly allows you to do so, and you can always hide behind that.

And after all, the main reason we are in this hobby is to spite other people, right?

[Ras]

Android will simply kill processes that hog "too much" memory. That's why it is smart to treat the UCI Hash parameter as total buffer size (except insignificant buffers). This way, only a few GUI programmers have to figure out how much you may allocate, and engine programmers can just use their results.

[syzygy]

Then there is syzygy, who basically says: to hell with the UCI specs, no one takes those seriously anyway. Just go ahead, use as many additional memory as you want. Make an engine that causes as much trouble for its users as you can, because a misinterpretation of the UCI specs perfectly allows you to do so, and you can always hide behind that.

And there is your character showing again. An apparent need to dishonestly misrepresent the statements of others.

[hgm]

Keep dreaming. Everyone can see that this is exactly what you are advocating. They can read, you know!

It is actually you, showing your character: when you have a technical disagreement with someone, you resort to ad-hominem attacks. Never fails.

[syzygy]

Keep dreaming. Everyone can see that this is exactly what you are advocating. They can read, you know!

I know that clowns are not supposed to be taken seriously, but you haven't yet admitted to being one, so I'll just pretend you actually mean what you write.

OK, so this is what I wrote:

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.

(...) 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.

So nowhere do I imply that UCI engine authors are "stupid". Nor do I write anything amounting to "to hell with the UCI specs, no one takes those seriously anyway. Just go ahead, use as many additional memory as you want. Make an engine that causes as much trouble for its users as you can, because a misinterpretation of the UCI specs perfectly allows you to do so, and you can always hide behind that."

Maybe one of the moderators that is not you is willing to state his opinion on whether I have been insulting all UCI engine authors.

[DustyMonkey]

If I want an engine to use a 1GB transposition table, attempting to set the parameter to 1GB isnt enough under HGM's definition, as the value I asked for is not the value that I will get. I will also need to know how much the engine is going to deduct from the value that I asked for, and that may even be based on the value of another setting.

Now I am juggling several settings just to set what was otherwise just a single setting. I guess HGM thinks this makes it twice as fun? I don't think he realizes that it actually makes it HARDER to achieve fairness when setting interact in poorly defined and absurdly specified ways.

UCI isnt a same-resources-please tournament specification. That would be somewhat... not Universal.