UCI Hash Usage Rules

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
hgm
Posts: 22338
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI Hash Usage Rules

Post by hgm » Wed Jul 11, 2018 12:54 pm

"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
Posts: 60
Joined: Sat Feb 04, 2017 10:57 pm
Location: USA

Re: UCI Hash Usage Rules

Post by MOBMAT » Wed Jul 11, 2018 2:34 pm

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.
Vince S
Author of MOBMAT

"Reductions, extensions, and pruning, oh my!"

syzygy
Posts: 4258
Joined: Tue Feb 28, 2012 10:56 pm

Re: UCI Hash Usage Rules

Post by syzygy » Wed Jul 11, 2018 6:16 pm

hgm wrote:
Wed Jul 11, 2018 12:54 pm
"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
Posts: 4258
Joined: Tue Feb 28, 2012 10:56 pm

Re: UCI Hash Usage Rules

Post by syzygy » Wed Jul 11, 2018 6:22 pm

MOBMAT wrote:
Wed Jul 11, 2018 2:34 pm
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.)

User avatar
hgm
Posts: 22338
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI Hash Usage Rules

Post by hgm » Thu Jul 12, 2018 12:44 pm

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
Posts: 952
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI Hash Usage Rules

Post by Ras » Thu Jul 12, 2018 3:23 pm

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

syzygy
Posts: 4258
Joined: Tue Feb 28, 2012 10:56 pm

Re: UCI Hash Usage Rules

Post by syzygy » Thu Jul 12, 2018 7:08 pm

hgm wrote:
Thu Jul 12, 2018 12:44 pm
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.

User avatar
hgm
Posts: 22338
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI Hash Usage Rules

Post by hgm » Thu Jul 12, 2018 11:03 pm

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
Posts: 4258
Joined: Tue Feb 28, 2012 10:56 pm

Re: UCI Hash Usage Rules

Post by syzygy » Fri Jul 13, 2018 6:05 pm

hgm wrote:
Thu Jul 12, 2018 11:03 pm
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:
syzygy 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.
syzygy wrote:(...) 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
Posts: 25
Joined: Wed Feb 19, 2014 9:11 pm

Re: UCI Hash Usage Rules

Post by DustyMonkey » Sat Jul 14, 2018 8:04 am

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.

Post Reply