"It just isn't conceivable that you can design a program strong enough to beat players like me."

April 12, 2015

Possible to add 150 ELO to Deep Saros 2.3f for Android?

When it comes to naming engine parameters in programming phase, practice and theory often provoke conflicts. Xboard and UCI standards are quite old when compared to the speed the programming techniques improved since their specifications were released.

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.


Unknown said...

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


Unknown said...

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?

Unknown said...

Thanks for this info. May help a lot.