Winboard Forum

When Crafty sends a feature string it sets smp to the number of allowable cores, and memory to the allowable memory size, like this:

Code: Select all

        Print(4095, "feature ping=1 setboard=1 san=1 time=1 draw=1\n");
        Print(4095, "feature sigint=0 sigterm=0 reuse=1 analyze=1\n");
        Print(4095, "feature myname=\"Crafty-%s\" name=1\n", version);
        Print(4095, "feature playother=1 colors=0 memory=%d\n", allow_memory);
#if (CPUS > 1)
        Print(4095, "feature smp=%d\n", allow_cores);
#endif
        Print(4095, "feature variants=\"normal,nocastle\"\n");
        Print(4095, "feature done=1\n");


But the Winboard protocol page here http://home.hccnet.nl/h.g.muller/engine-intf.html only mentions smp and memory being set to 1 if the engine supports this feature. So which is right? It does seem reasonable to me that the engine should be able to tell the UI what the allowable values are.

Printing a number other than 0 or 1 as Crafty does is non-compliant, as smp is defined as a boolean feature. The current XBoard/WinBoard implementation does understand any non-zero value of a boolean feature as 1, though, and is not pedantic about it. (But other implementations would be in their right when they replied 'rejected smp' because of this.)

It did not seem useful for the GUI to know the maximum number of cores the engine can use. The GUI settings in the Common Engine Options dialog, and the corresponding cores and memory commands were intended to inform the engine about system limits. It is upto the engine to decide whether it wants to use all the available memory or cores. If the GUI would know that Crafty can support 8 cores, and Komodo only 1, what good would that dowhen I wanttoplay them against each other? Using it as limits on the common nr-of-CPUs setting would serve no other purpose than hinder the user. The purpose of the smp feature is really only to protect the engine from receiving commands it does not implement and that might crash it.