Appeal to SMP-engines programmers using UCI

[hgm]

Could you please equip your SMP engine with the option 'Threads' to set the (maximum) nr of CPUs it uses? It does not matter if you are currently using another name for an option that does the same thing, just keep it if you think that name is better. But in the interest of the users of your engine, please also support a 'Threads' option. So that GUIs can recognize this option and set it from the menu for standard options tht are applied to all engines (similar to hash size and nalimov path).

It is very annoying to users if your engine does ignore his general settings, and he has to reconfigure that engine sepatately through its own options menu, every time he wants to conduct a tournament with another number of CPUs.

Please no discussion here about the question if 'Threads' would be the most logical name for this feature. We have had this discussion here for WB protocol already, and it does not converge. It is not important what the name is, but it is important that everyone uses the same name the GUI can recognize. The GUI writer decides uder which name this option appears in its menus anyway.

I have no interest in UCI protocol (my own engines are all WB), and from this neutral point of view, I can assure you that 'Threads' is the most logical choice because:
1) there are more engines that already use this than all other names together.
2) The designer of UCI protocol uses this name in his engine.

[Eelco de Groot]

Hello Harm, from principle it sounds okay but are you sure that UCI GUIs at the moment support any general settings for 'Threads'? As far as I know Shredder GUI does not do this, Chessbase I'm not sure because on a single processor I don't have to bother with that anyway, but I don't think it is set centrally? Does Arena for instance allow this maybe? Don't know.

Is it not the responsability of the engine to read the settings in the engine UCI options pane and maybe correct this if the maximum is more than the number of processors? You could make it a general setting but I think it would have to go into the UCI protocol, from Stefan Meyer-Kahlen, first that engines should be able to get this information somewhere from the GUI.

Still you could make the argument that the settings in the engine UCI options are no less important than the general settings of the GUI. Just my five cents again...

Regards, Eelco

[hgm]

Hello Harm, from principle it sounds okay but are you sure that UCI GUIs at the moment support any general settings for 'Threads'?

I am sure they don't.

But the point is, unless the engine authors agree on some standard, they never will.

- GUI authors do not implement this feature because there are too many option names around, so the can't get it to work for enough engines.
- Engine authors randomly pick whatever option name they fancy, because GUIs don't support a standard name anyway.
It is a viscious circle.

Let us break that circle!

You are correct that this should go into the UCI protocol. But a protocol is in the first place what the consensus of the users thinks it should be. If many think the word of Stefan Meyer Kahlen is essential to make this official protocol,

let us petition him here to speak that word!

As to the relative importance of GUI settings and Engine private settings, I will implement it this way in WinBoard:

If the user gives a GUI setting for the number of CPUs, all engines will use that, and the control for this in their private engine-option-settings panel will be suppressed. This is what people that play tournments would normally do. For tournaments that want to compare engines working on different numbers of CPUs (wich have a time-odds character), they would set the GUI value for nr of CPUs to zero. This would then enable all private engine controls, or would allow the engines to do as they please if the user doesn't set them on the individual engines.

As in the near future almost all engines will be SMP, and almost all users will have quads or better, I think this feature will become so important to have that eventually every self-respecting GUI will have to implement it. But let's not make it impossible for them...

[mhull]

Hello Harm, from principle it sounds okay but are you sure that UCI GUIs at the moment support any general settings for 'Threads'?

I am sure they don't.

But the point is, unless the engine authors agree on some standard, they never will.

- GUI authors do not implement this feature because there are too many option names around, so the can't get it to work for enough engines.
- Engine authors randomly pick whatever option name they fancy, because GUIs don't support a standard name anyway.
It is a viscious circle.

Let us break that circle!

You are correct that this should go into the UCI protocol. But a protocol is in the first place what the consensus of the users thinks it should be. If many think the word of Stefan Meyer Kahlen is essential to make this official protocol,

let us petition him here to speak that word!

As to the relative importance of GUI settings and Engine private settings, I will implement it this way in WinBoard:

If the user gives a GUI setting for the number of CPUs, all engines will use that, and the control for this in their private engine-option-settings panel will be suppressed. This is what people that play tournments would normally do. For tournaments that want to compare engines working on different numbers of CPUs (wich have a time-odds character), they would set the GUI value for nr of CPUs to zero. This would then enable all private engine controls, or would allow the engines to do as they please if the user doesn't set them on the individual engines.

As in the near future almost all engines will be SMP, and almost all users will have quads or better, I think this feature will become so important to have that eventually every self-respecting GUI will have to implement it. But let's not make it impossible for them...

Maybe there could be an option in WB called "set Threads alias" which would allow WB to recognize arbitrary thread nomenclature.

[hgm]

Yes, work-rounds are possible. (WinBoard does not deal directly with UCI engines, so they would have to be implemented in Polyglot.) But is still would require extra effort by each user, and it is questionable if other GUIs would take the trouble of also doing this.

The World would be a much better place if UCI engine authors simply agreed on a standard.

[trojanfoe]

I don't see what the problem is. The UCI standard allows for the engine to tell the GUI what options it supports and the GUI is responsible for displaying the dialog necessary to allow the user to change the options and saving them away in the registry or config file for later use with that engine. Why is so important that this particular option has a consistent name across all engines?

Cheers,
Andy

[Greg Strong]

I don't see what the problem is. The UCI standard allows for the engine to tell the GUI what options it supports and the GUI is responsible for displaying the dialog necessary to allow the user to change the options and saving them away in the registry or config file for later use with that engine. Why is so important that this particular option has a consistent name across all engines?

Cheers,
Andy

For tournaments - you want to run 10 engines in a tournament with the same parameters, you don't want to be bothered with finding the way to specify the # of thread for each and every one of them. It should be possible to specify that universally as you do with time controls and other fundamental parameters.

[trojanfoe]

I don't see what the problem is. The UCI standard allows for the engine to tell the GUI what options it supports and the GUI is responsible for displaying the dialog necessary to allow the user to change the options and saving them away in the registry or config file for later use with that engine. Why is so important that this particular option has a consistent name across all engines?

Cheers,
Andy

For tournaments - you want to run 10 engines in a tournament with the same parameters, you don't want to be bothered with finding the way to specify the # of thread for each and every one of them. It should be possible to specify that universally as you do with time controls and other fundamental parameters.

And what software is used to run these tournaments? Shouldn't it save the configuration for each engine and apply that configuration whenever that engine is loaded during the tournament?

[Michel]

And what software is used to run these tournaments? Shouldn't it save the configuration for each engine and apply that configuration whenever that engine is loaded during the tournament?

Imaging you want to play a tournament with all engines using 1 CPU. Fair enough. You configure each engine in the GUI to set the relevant option to 1.

Ok that worked.

Now you want to do a 2CPU version of the same tournament.

Oops.... we have to reconfigure all those engines....

Unless of course the GUI/TM had a uniform way of telling the engines to use x CPUs.

This is what this discussion is about.

[trojanfoe]

And what software is used to run these tournaments? Shouldn't it save the configuration for each engine and apply that configuration whenever that engine is loaded during the tournament?

Imaging you want to play a tournament with all engines using 1 CPU. Fair enough. You configure each engine in the GUI to set the relevant option to 1.

Ok that worked.

Now you want to do a 2CPU version of the same tournament.

Oops.... we have to reconfigure all those engines....

Unless of course the GUI/TM had a uniform way of telling the engines to use x CPUs.

This is what this discussion is about.

I see what you are saying and there is no reason why the Threads option isn't as standard as the Hash or Ponder options. I support an update to the UCI protocol to improve this situation.

Cheers,
Andy