I won't repeat the endless discussions about how we must call the protocol option that sets the number of parallel searches will use the engine. It has never come to a common agreement. Engine programmers still use different namings that not all GUI's interpret correctly.
The last case i had encountered was almost one year ago with Gaviota for Android where Miguel Balicora used Cores that Chess for Android was prepared for but Droidfish was not. The same binary could run on quad cores when loaded into CfA but when loaded into Droidfish it was delivering one third of the kNps expected. Just because of one word in the source code.
I'd come to a double solution with kind help from both authors. Miguel compiled a version which sends Threads command instead of Cores (version 1.0d) while Peter Österlund added the option to understand Cores command into Droidfish.
Today i've noticed Deep Saros 2.3f may be suffering from the same issue because it uses none of the above namings but "cpus". I'm not sure if multi threaded search will run if Chess for Android understands it. Porting SMP functionaly to Android seems tricky sometimes but it's worth giving a try.
One solution is to set the GUI to understand "cpus" command. Another easier solution, just the same as we'd found with Gaviota, is to change the command in the source code from "cpus" to "threads" so that the GUI's can use it.
I think there's a chance to add about 150 ELO to Deep Saros 2.3f and push it above 3000 if it's only a naming issue which prevents using all the cores. I hope Jim Ablett will give a hand on the question.
P.S.: In case you don't agree with +150 ELO, you are absolutely right. The reason for me to go wrong deliberately was only to attract attention to the subject. Now the truth is that if Deep Saros coıuld go 4 threads from 1, it would gain roughly: log (3 to 4 times more knps) / log2 x 60 = 95 to 120 ELO more.
3 comments:
Hi Gurcan,
I took a look at the smp code in DeepSaros. Uses pthreads and looks ok.
It uses cpu detection on startup and the number of cpus it detects will be max that can be used regardless of setting used in UCi options menu. The code used for detection can have problems under arm cpus - sysconf( _SC_NPROCESSORS_ONLN ) - this is known to return a value that is half the actual number of cores available under arm. I replaced it with android code which works correctly - android_getCpuCount(). Don't know it this will resolve the issue, but worth a try - download test build here > http://tinyurl.com/ptj8rfj
Jim.
Thanks Jim. I've been late to come back to chess from heavy duty days at work. I first tested above alternative on RK3066 cpu without success. Cpustats shows 1 core used.
I also obtain 217 kNps regardless of threads setting, 1 or 2 threads.
Meanwhile, DeepSaros 0.9 is an opposite case and could give a clue. Although it shows up as a single thread engine, it uses all available cores all the time. Can we implement the subroutine it uses to do that into 2.3f?
Thanks for this info. May help a lot.
Post a Comment