H.G.Muller wrote:I don't know of any elegant and easy ways to make my engine aware of, not to mention control the EGBB library's memory usage, unless only the cache is used. I think it's the operator/user's job to choose what EGBBs are loaded to memory, and he should of course have some idea of the memory usage. Considering the design and functionality of the Scorpio EGBB library, the memory command is not that practical for controlling EGBB size. Or are there any engines that are doing it?
I have no idea how EGBBs work. Using codes written by others, giving the engine the status of semi-clone, is dubious practice in the first place. It certainly cannot be used to derive rights from. If the Scorpio EGBB library is defective in the sence that it does not contain calls to limit its resource usage or at least inform the engine of its needs, it does not exempt the author from obeying the constraints. He can either refrain from using EGBB altogether, or write his own routines for this.
Well, we don't tell human players how many brain cells they may use, they'll use every one they can. So if we really wanted chess engines to be completely independent we'd let them use all the memory they want. But that's just the philosophy, of course it's not practical. So this is kind of a moot point.
You are overlooking an important point here, that makes your human analogy fail completely: a computer contains two (or four, or eight) Chess-playing entities, that have to
share the availabe memory. Brains in a human Chess match are not a shared commodity, each player brings along its own brain. You should compare it to the food that is allowed to be consumed in the tournament hall by the players. I still have to see the candidate match were two meals are brought in, and one of the GMs says: "I'll take both, please! All this thinking has famished me, so if you don't mind, I'll eat my opponent's meal too, and let him starve. If I eat more, I can play better Chess". And that the organizers thn would allow this.
When single engine is running on a computer, (e.g. in an OTB or on-line tourney) the memory command is not needed at all, and the operator can set it to whatever value he wants (depending on what else he wants to do on that computer!).
For an engine that already has a hash size option, it's very easy to implement a command for setting said option. And because it's so easy, we'd have a better chance of getting engine authors to do it.
I do not consider a better chance on someone doing something that is detrimental a good thing. It is better to have a small chance that they do something good, than to create a large chance that they will do something bad.
If fairness is defined by the amount of memory allocated for the engines, then no, that's not fair. But the point of using endgame tables is that they should give an advantage to the engines that use them.Punishing the engine for having endgame tables by reducing its hash size is counter-productive if we just want both engines to play as well as possible, which is exactly what I want when I'm setting up a tournament.
Well, this is not posible then, using a GUI to play them against each other on the same PC. Because each engine will always play "as well as possible" when it grabs all resources of the machine, leaving nothing (no memory, no CPU time) for its opponent. Wether you like it or not, memory is a physical resource, that is in finite supply on any machine. End-game tables require memory, and that memory cannot be used as main hash. You don't think the engine using the EGT should be punished for it by reducing its hash. So apparently you think it is OK to punish its opponent for it, by reducing this opponent's hash?
I don't share that view. Because it is in fact this view that would be very counter-productive to your defined goal of producing good Chess. Adopting this philosophy would mean that it pays for an engine to allocate a huge array next to its hash table, which it is clearing at maximum speed during ponder time, because it would be a good way to reduce its opponent's hash size and take way CPU time from it. And the opponent would quickly learn to do the same. So in the end none of the engines would get to spend too much effort on producing Chess, being hindered too much by the opponent's wasting of resources...
I know that many others think the same way; take a look at CCRL for example. Their testing conditions are clearly unfair by your definition, and they give an advantage to SMP engines and engines with endgame tables. The people who organize engine tournaments are an important part of my target market (for my upcoming GUI at least), so I want to take their needs into account.
I see that mostly as their problem. I have not made a in-depth study of what exactly they do, but I am inclined to give them the benefit of the doubt, that, if they only create unfair conditions, it is only because technical difficulties preclude them from creating fair conditions. Rather than thatthey intentionally aim to mess up their rating lists. This makes it all the more important to create the possibility for them to conduct their tests in a fair way, allowing them to make a conscious decision if they want to do fair or unfair testing. I am very confident they will do the right thing, then. And if not, I see it as their problem, not mine. I don't see it as my calling to aid and abet cheaters, no matter how large a market they might offer...
That would be just semantics. Even if the configuration option is called "Hash size", I would consider it the same as transposition table size, and would give your engine the same amount of memory that I give to the opponent. As for the pawn hash, I'd really wonder why you'd need it to be that big. But I'd probably allow it if there was enough free memory (there's plenty on my system).
If you would read the UCI protocol specs carefully, you would see that he Hash option definition speaks of "hash tables" (plural). This makes it clear that it cannot just be read as "transposition table", as there is supposed to be only one of those. I agree that "hash" in this context should not be taken litteral, providing an excuse to dodge the limit by adapting an alternative storage scheme that strictly speaking is not hashing. But the consequence of this is that the EGTB cache should be considered as part of the memory limit specified in the Hash option. The EGTB cache is just another "hash table". (It is in fact very likely to use hashing for allocating the buffers to EGTB compression blocks, so it even counts as a hash table in the strict sense).
So I don't think tere really is any difference between the UCI Hash option, and the way I defined
memory in WB protocol. Both pertain to maximum memory usage. It is just that cheating is so common in UCI engines that it has become the norm! CPW, for instance, allocates 80MB when you set its Hash option to 64MB. I inquired with the authors, and they told me this is because it allocates a Pawn hash table 1/4 the size of the TT, next to the latter.
If you have RAM to spare, it just mean you don't make the hash tables large enough.
I would want a separate configuration option (in an ini file, by a command line argument, etc.) which would let me choose which tables to load. And if I wanted to run a match with endgame tables and I had enough RAM, then sure, your engine would get its 1GB of egt memory. I don't know how building the tables during pondering is relevant.
If you have enough memory, the whole memory command is not relevant. It is only provided to hndle cases where memory use has to be limited, and should be optimized for that situation.
IMO you're pushing the pursuit of fairness so far that it actually hinders progress and handicaps the stronger engines. I guess this is one of those "We agree to disagree" things.
We indeed seem to hve a different definition of 'stronger engines'. In your definition, A would be stonger than B, despite the fact that A played weaker Chess, just because A takes away so many resources from its opponent that that opponent would be weakened even more than the A-B difference. In my definition, B would be the stronger engine, and A would be a cheater. And I can assure you the fact that my pursuit of fairness handicapping cheaters is fully intentional!
Posted: 25 Feb 2009, 18:46