Problem with UCI engines hash in Arena

[hgm]

Code: Select all

    char *Threads[] = { "CPUs", "Core Threads", "Cores", "MAX_CPU", "Max CPUs", "MaxThreads", "Max_Threads", "Number Of Threads", "NumberOfProcessors", "NumCPUs", "Processes", "Threads", "TitanicCPUsSizings", "TitanicCPUsSizings (Capitalist!)" };

It seems to me that supporting the last two actually goes against the intention of the authors. The obviously intend this as a joke, and the joke would go entirely lost if the GUI would connect the option to a prosaic common setting like "Maximum search threads" in the GUI, rather than displaying it under its own name in the Engine Settings dialog.

If engine authors prefer to make a joke of their engine, I think we should respect that.

[Lavir]

Would you want to have the individual controls of the latter dialogs as duplicates in the Tounament Options, rather than a quick way to go there? I am afraid this would overload the dialog, which is already quite full. I am also not sure what you mean by 'options'. The General Options?

Because making it as an option there would easily give the possibility of setting the thing individually engine by engine if one so want. The "common engine" has hash and cores, but hash IMO should be given also the possibility of setting it indipendently by engine (for example one 256 and another 512 if one wants) and it would be good even if it was possible to to do so for threads (think about it: in this way your GUI would be the first to have this option so easily achievable). If you can do these things easily from a simple window it's all another thing.

One way to do this easily is to set a simple check as for example the Shredder gui does. It lets you simply chose if you want all engines have these common options or have them changed engine by engine (by simply selecting them). Sadly the Shredder GUI has only this option for book and hash.

It would not "clutter" the interface that much, at all, and on the contrary I actually think the more options you give immediately to the user without sub-dialogs there the better (the most important ones naturallly, the ones that people use most of the times, and surely these are the cores, the hash, books/lines and permanent brain - another thing you have to set in Winboard in yet another window); the user that has not to search everywhere (this btw is what it happens with ChessGUI, that is, in fact, a little troublesome for beginners) and everything of most importance is there, immediately.

Other less frequently used (and more specific) options I agree should be setted elsewhere but these ones (hash, cores, PB, book/lines) IMO should be easily finded without going to search for them (along with possibility of changing engine parameters on the fly, that would be a nice touch) in the tournament/match section that is the section where they are most handy to change.

I personally think that one should specialize in the type of GUI one wants to make: jack of all trades master of none I don't think it works so well, but naturally people can have a different opinion on this. If I had to actually create a GUI myself I would make it the most specialized possible for what it should, indeed, do. I think Winboard, for the "philosophical" way it is created would make a perfect GUI specialized for engine matches. Do you imagine if it was also able to make concurrency games automatically (as CuteChess does, but actually being able to look at the games) so that you could watch/make 4 games side by side while they are being played?

It does already do that, not? If you start a match from the menu, that match will stop after 'default match games', setable from the Common Engine dialog (or, as 'games per pairing', from the Tournament Options dialog). Unless you mean something else than I think.

I meant something like in Arena when there's an option to end the tournament after the game is played or the round/cycle at the touch of a button. It is a nice touch, especially when you play LTC games.

But maybe doing this in Winboard would be more troublesome since I don't know where you could place the option. The minimalistic approach of Winboard is very good for some things but less for others.

In Chessmaster there was even the option to adjourn engine games, a thing I've not seen in any other GUI.

Another thing concerning this: I think that when you abort a game it should not be saved in the pgn if less than certain moves).

Yes, please. I always appreciate feedback. My e-mail address is h DOT g DOT muller ATSIGN hccnet DOT nl. I cannot promise that I will always agree with you, but it always very useful to hear what users want, even if in the end it would only be a minority opinion. (Sometimes irreconcilable differences in user demands can be solved by putting features under option control.)

Ok, I will send you an email ASAP with all the things that IMO would make a nice addition to Winboard for what it concerns engine vs engine matches.

[Michael Diosi]

RTFM ! This always helps !


Michael
http://www.playwitharena.com

[hgm]

because making it as an option there would easily give the possibility of setting the thing individually engine by engine if one so want.

But the Tournament Options is not a per-engine dialog. The settings you enter there are just as global as those in Common Engine. It sounds more like you would want them in the Load Engine dialogs.

The "common engine" has hash and cores, but hash IMO should be given also the possibility of setting it indipendently by engine (for example one 256 and another 512 if one wants) and it would be good even if it was possible to to do so for threads (think about it: in this way your GUI would be the first to have this option so easily achievable). If you can do these things easily from a simple window it's all another thing.

Well, I thought about the possibility to disable the centralized setting by giving an invalid value (like hash size -1 or 0 cores), and in that case take the hash setting from the option in the Engine Settings dialog. I am not sure that this would be a unique feat, though. I understood that in Shredder GUI the threads can only be set by a private engine option, so that it is really the way to set them globally is what sets WinBoard apart. (And not everyone is happy with that.)

... and permanent brain - another thing you have to set in Winboard in yet another window);

Indeed, for historic reasons there is a duplicat of the 'Ponder next move' checkbox in the Adjudications dialog, where it really makes no sense at all. At the very least this should be moved to Common Engine. I figured that there would be many people that would hardly ever change those parameters, but set them for what is good for their system. I very often start new tourneys, but they almost always because I want to use different engines or engine versions, and almost never because I want another book, or hash setting. Hash and threads is also relevant for people that do not want to run tourneys at all (e.g. for analysis), and in general, I try to avoid duplicates (although I try to not be dogmatic about that)..

I think Winboard, for the "philosophical" way it is created would make a perfect GUI specialized for engine matches.

Actually its most popular usage is as ICS client, for playing human games on FICS. WinBoard is pretty much a jack-of-all-trades, and I will certainly keep it this way, because there are many variants that are not supported by anything else but WinBoard. So for the benefit of those I have to keep offering a complete set of sevices. (Engine tourneys, human-engine, human-ICS, engine-ICS, interactive analysis, book creation).

Do you imagine if it was also able to make concurrency games automatically (as CuteChess does, but actually being able to look at the games) so that you could watch/make 4 games side by side while they are being played?

This already works as long the integrated Tournament Manager exists, because it was eplicitly designed to do just that. All you have to do is double-click the touney file, to stat new WinBoard instances for increasing the number of concurrent games. (And close them again when you want to decrease the number.)

I meant something like in Arena when there's an option to end the tournament after the game is played or the round/cycle at the touch of a button. It is a nice touch, especially when you play LTC games.

Well, you can stop after the current game through the 'Machine Match' menu item. Whether that will also close WinBoard or just switch it to 'idle' mode depends on how you started it (through the menu, or from the command-line/by double-clicking a tourney file).

In Chessmaster there was even the option to adjourn engine games, a thing I've not seen in any other GUI.

I thought about writing the clock times in the 'result comment' of unfinished games as a standard measure. Then WinBoard could simply restore the clock settings when that game is reloaded, and you could start the engines to play from there. Never got to actually do it, though. It is not possible to do this in a way that would not disturb the game in some way (by losing hash info or ponder time), so it is a bit questionable how valuable this is.

Another thing concerning this: I think that when you abort a game it should not be saved in the pgn if less than certain moves).

Well, the 'certain number of moves' now is 1: empty games are not saved. I already game to the conclusion that saving unfinished games during a tournament is never useful, and almost always very undesirable. So in the 4.7.beta I already changed it such that when you abort a game, it does not save automatically to the tourney file, but prompts for a filename (which you then would likely 'Cancel').

[Lavir]

But the Tournament Options is not a per-engine dialog. The settings you enter there are just as global as those in Common Engine. It sounds more like you would want them in the Load Engine dialogs.

Indeed I would. IMO it is not good that when you run a tourney you have to change a common variable everytime, especially if that setting is not saved in the tournament file (this I don't know if Winboard does, I would have to check; I don't remember if changing the setting in the tournament change it only there or do it globally).

Maybe I want to make a tournament with 2 cores only but then leave the common settings to 4 cores, or use PB on a tournament and not on another, and so on.

Without not centralized and dedicated options you cannot run multiple tournaments with different settings too well (the only way to do it is to be sure to finish one than start another), or even run different settings between what YOU (as an human) play and what you want engine to run as when testing.

Well, I thought about the possibility to disable the centralized setting by giving an invalid value (like hash size -1 or 0 cores), and in that case take the hash setting from the option in the Engine Settings dialog. I am not sure that this would be a unique feat, though. I understood that in Shredder GUI the threads can only be set by a private engine option, so that it is really the way to set them globally is what sets WinBoard apart. (And not everyone is happy with that.)

And it's a good point that you can do that for Winboard, but it would be even better if you could choose the cores (along hash and book) to use for any engine WITHOUT changing the engine and saving it outside first (as you need to do with all the GUIs for many of these things). The only way to change the number of cores is or do it globally (if the GUI has the option) or go to the engine, change the option and save it (and if you are unlucky you even have to create a new engine just for this) and what's worse it that doing this in almost all cases (the only one not so being the Fritz GUI, because it enables you to change all engines options "on the fly", tied only to the tournament in question, the only real good point Fritz has) it means modifying the engine globally, not only in the tournament instance.

This in turn it means that if I want to have a tournament where, for example, Houdini plays with 4 cores but then I want to play it myself with only 1 core (as usual) I have to first modify it, run the tournament then modify it again, hoping I don't forget to modify it anew when I have to run the tournament again or elsewhere goodbye testing. This or create a new engine file with the cores you want to use for the occasion.

Having the best of the best IMO would be something like this:
- Hash, cores, books settable for all engines commonly or individually, without changing the engine. These three (plus Permanent Brain) doable in the tournament window.
- Possibility of setting other engine options on the fly, in the tournament only (same as Fritz does, a shame that you have to do it always, even for trivial things).
- Naturally these should be tied only to the tournament in question (and saved in it), global parameters of the engines (and hash/book etc) should remain as it is.

WinBoard is pretty much a jack-of-all-trades, and I will certainly keep it this way, because there are many variants that are not supported by anything else but WinBoard.

Understood. Still, some more options for tournaments I think it will not be a bad thing to have even for what your GUI wants to do.

This already works as long the integrated Tournament Manager exists, because it was eplicitly designed to do just that. All you have to do is double-click the touney file, to stat new WinBoard instances for increasing the number of concurrent games. (And close them again when you want to decrease the number.)

I didn't know this trick. Thank you for saying this to me. Certainly is a very handy thing to know.

[hgm]

Indeed I would. IMO it is not good that when you run a tourney you have to change a common variable everytime, especially if that setting is not saved in the tournament file (this I don't know if Winboard does, I would have to check; I don't remember if changing the setting in the tournament change it only there or do it globally).

Maybe I want to make a tournament with 2 cores only but then leave the common settings to 4 cores, or use PB on a tournament and not on another, and so on.

OK, I see the problem you are addressing. For exacty that reason I added the time-control settings to those written in the tourney file. But it did not occur to me that people would also want to run touneys with different hash settings, (or different books).

But it is of cose tivial to cure that.The tournney file is a nomalsettings file, and could specify any command-line option WinBoard knows. So it is just a matter of writing those settings to it too, when the file is created. Can you think of any other options as

-usePolyglotBook
-polyglotBook
-bookDepth
-bookVariation
-defaultHashSize
-defaultCacheSizeEGTB
-smpCores

that would have to be saved per tourney? (They don't have to be too outlandish: if a user wants to do something really special he always has the possibility to edit the tourney file, and add whatever he wants. In paticula he could add a line @tourneyparams1.ini, which could contain a combinattion of outlandish settings he often uses.)

... (the only one not so being the Fritz GUI, because it enables you to change all engines options "on the fly", tied only to the tournament in question, the only real good point Fritz has) it means modifying the engine globally, not only in the tournament instance.

This in turn it means that if I want to have a tournament where, for example, Houdini plays with 4 cores but then I want to play it myself with only 1 core (as usual) I have to first modify it, run the tournament then modify it again, hoping I don't forget to modify it a new when I have to run the tournament again or elsewhere goodbye testing. This or create a new engine file with the cores you want to use for the occasion.

If I understand you correctly, this sounds like something very complex to do. In WinBoard, the engines have no identity other than described in the list of installed engines, which is only acessed the moment the engines are actually loaded because they have to play a game. Even in the tourney file they only exist as 'nicknames' which are later used to identify the line with the engine command in the installed-engine list, which is stored as the (multi-line) -firstChessProgramNames option.

In principle it should be possible to write another such engine list in the touney-file, overruling the list that is stored in the winboard.ini. But creating such a list poses exactly the same challenge as doing the normal install. So I don't really see how you could ever save much effort doing it 'on the fly' for the tourney only. You still would have to go through something like the Load Engine dialog for every on-the-fly engine.

[michiguel]

[moderation]
We were observing this thread was slowly degenerating into a cat fight that has no place in CCC. When someone filed a complaint, it motivated us to clean the thread up.
We are not supposed to referee personal and/or off-topic fights and see who started what etc., but we have to make sure those quarrels do not pollute threads or just do not occur altogether. A couple here have a history of poorly interacting with each other. Maybe it would be wise to ignore the impulse to go at the other throat for a while?

/Adam, Julien, Miguel

[Modern Times]

Hi Ray, glad a serious tester has noticed this as well. I don't mean to pick on Arena, as I like the software, which came free, to boot , but some of the glitches can really get in the way of good testing.

My comments were meant as constructive criticism. Sorry if I was not aware of recent work on Arena.

Regards,
CL

The trick I think is to set the hash size in each engine's UCI parameters, because Arena's global UCI setting does not always work.

A couple of CCRL testers use Arena extensively, they don't have the issue, and I think this is what they have done to get around it.

[Graham Banks]

Hi Ray, glad a serious tester has noticed this as well. I don't mean to pick on Arena, as I like the software, which came free, to boot , but some of the glitches can really get in the way of good testing.

My comments were meant as constructive criticism. Sorry if I was not aware of recent work on Arena.

Regards,
CL

The trick I think is to set the hash size in each engine's UCI parameters, because Arena's global UCI setting does not always work.

A couple of CCRL testers use Arena extensively, they don't have the issue, and I think this is what they have done to get around it.

It's been a while since I used Arena, but from memory you need to rightclick in the engine pane after installing the engine, and set the parameters there. Same as with Shredder GUI if I recall correctly.

[Adam Hair]

Both engines (BeRoChess 1.00 - an UCI one , and Project Invincible 2.01 - a pure WB chess engine , were setted to use 64 MB hash). My match- on Arena 3.0 GUI - is a true fiasco !!! I'm extremely nervous Miky ( in the 3-rd Christmas day ) !!!


SilvianR

I understand that you may have some bad feelings for Michael. But this is not a bug with Arena 3. Arena sends the proper UCI and WB commands. However, neither BeRoChess nor Project Invincible allows for different hash allocations.