Cheng 4.39 Android version bugfix

[mar]

I've just found a really stupid bug in lsbit/msbit scan tables that broke the Android version of Cheng (it seems all 4.x versions were affected by this).
I wonder why nobody ever complained

The fixed version can be downloaded here:
http://www.crabaware.com/cheng4/cheng4_droid.zip
Fixed sources here:
https://github.com/kmar/cheng4

I've no idea how this version compares to Jim's compile (it didn't start on my device
I've tried to use builtin_ffsll(m)-1 but somehow it was much slower (!!) on my device. It's Intel Atom so I guess it emulates ARM?
But even that probably wouldn't explain it...
Anyway - no idea why so I kept the lookup version.

[Jim Ablett]

I've just found a really stupid bug in lsbit/msbit scan tables that broke the Android version of Cheng (it seems all 4.x versions were affected by this).
I wonder why nobody ever complained

The fixed version can be downloaded here:
http://www.crabaware.com/cheng4/cheng4_droid.zip
Fixed sources here:
https://github.com/kmar/cheng4

I've no idea how this version compares to Jim's compile (it didn't start on my device
I've tried to use builtin_ffsll(m)-1 but somehow it was much slower (!!) on my device. It's Intel Atom so I guess it emulates ARM?
But even that probably wouldn't explain it...
Anyway - no idea why so I kept the lookup version.

Hi Martin,
I had already done a bit of D.I.Y

Code: Select all

In 'tables.h' replace with this > 


------------------------------------------------------------------------------------------------


//		return __builtin_ffsl(m);	 // FIXME: doesn't work here => I wonder why?
	#else


 return ( ( unsigned ) m ) ? __builtin_ffs ( m ) - 1 : __builtin_ffs ( m >> 32 ) + 31;  // - JA



// and comment out below original routine

/*

		for (uint i=0; m && i<4*16; i+=16, m >>= 16)
		{
			u16 p = (u16)m;
			if ( p )
				return Tables::lsBit16[ p ] + i;
		}
		return 0u-1u;
*/

Jim.

[mar]

Hi Martin,
I had already done a bit of D.I.Y

Hi Jim,

that's nice I wonder if using two separate ffs is faster than a single ffsll, I will test it on real device with ARM.
My guess is it boils down to rbit + clz so perhaps rbit is expensive to emulate on x86 as there's no cheap equivalent;
still I was shocked to see that the table version was almost 1.7x faster in terms of nps (single core),
I expect it to be slower on real ARM.

[Gurcan Uckardes]

I've just found a really stupid bug in lsbit/msbit scan tables that broke the Android version of Cheng (it seems all 4.x versions were affected by this).
I wonder why nobody ever complained

That's because i never notice anything to complain about. In Rapidroid, Cheng 4.39 performed even better than under Windows, compared to the engines of the same segment like Arasan, ExChess, Gaviota, Senpai.

As seen here: http://chesstroid.blogspot.com/2015/11/ ... -2015.html

But i still wonder how good above compile will compete with Jim's latest arm7.

Finallly about x86 devices with Android, most arm compiles don't work at all. Some will work but it makes little sense because they are running with arm instructions translated to x86, at 35% to 70% of the original NPS. Kind of an emulator!

[mar]

That's because i never notice anything to complain about. In Rapidroid, Cheng 4.39 performed even better than under Windows, compared to the engines of the same segment like Arasan, ExChess, Gaviota, Senpai.

As seen here: http://chesstroid.blogspot.com/2015/11/ ... -2015.html

But i still wonder how good above compile will compete with Jim's latest arm7.

Finallly about x86 devices with Android, most arm compiles don't work at all. Some will work but it makes little sense because they are running with arm instructions translated to x86, at 35% to 70% of the original NPS. Kind of an emulator!

That's really interesting, I've no explanation for that. I suggest to use Jim's compile though.
It's just that I released something that didn't work at all on Android and now fixed it,
but I'll try builtin bit scan which should be superior to lookup tables to see how it compares on real ARM.

[Gurcan Uckardes]

I've compared JA vs Martin's compile on Exynos-4412 with 100 games. It's better than comparing nodes.

Arm7 advantage is visible. This was a 180+2 blitz match with 50 first openings of TCEC-7, 16 plies, played with both colors by each program.

Code: Select all

Program                 Elo   +   -  Gam  Score  Av.Op. Draws

1 Cheng 4.39 JA arm7 : 3028  48  47  100  58.0%  2972  52.0%
2 Cheng 4.39 MS arm5 : 2972  47  48  100  42.0%  3028  52.0%

To be sure, similar match between JA arm7 vs JA arm5 will follow in order to clarify whether above gap is only the result of the target architecture.

I've checked today with Deep Saros and both JA compiles ran at exactly the same nps! Thus, we may still suspect Jim's arm7 compiles since he's expertising it recently.

For the moment, arm7 compile leads 11-7 after 18 games out of 100. Probably everything he does on arm7 is okay.

[mar]

I've compared JA vs Martin's compile on Exynos-4412 with 100 games. It's better than comparing nodes.

Arm7 advantage is visible. This was a 180+2 blitz match with 50 first openings of TCEC-7, 16 plies, played with both colors by each program.

Code: Select all

Program                 Elo   +   -  Gam  Score  Av.Op. Draws

1 Cheng 4.39 JA arm7 : 3028  48  47  100  58.0%  2972  52.0%
2 Cheng 4.39 MS arm5 : 2972  47  48  100  42.0%  3028  52.0%

To be sure, similar match between JA arm7 vs JA arm5 will follow in order to clarify whether above gap is only the result of the target architecture.

I've checked today with Deep Saros and both JA compiles ran at exactly the same nps! Thus, we may still suspect Jim's arm7 compiles since he's expertising it recently.

For the moment, arm7 compile leads 11-7 after 18 games out of 100. Probably everything he does on arm7 is okay.

Thanks Gurcan.
I've just updated both source & Android binary to use builtin_ctz instead of tables and seems to work well on both original ARM and emulated.
(link is the same)
I chose builtin_ctz becase the compiler generated nicer (branchless) assembly than using builtin_ffs, so I kept builtin_ctz.

[Gurcan Uckardes]

Here's a second match which is directly implying a third one in order to conclude. Because 200 games show that JA arm7 takes over JA arm5 the same way it took over Martin's arm5.

I think JA arm5 vs MS arm5 must be played now.

Code: Select all

JA arm 7 - MS arm 5: 32+ 16- 52= (58.0% +56 ELO)
JA arm 7 - JA arm 5: 33+ 13- 54= (60.0% +70 ELO)
JA arm 5 - MS arm 5: in progress...

[mar]

Here's a second match which is directly implying a third one in order to conclude. Because 200 games show that JA arm7 takes over JA arm5 the same way it took over Martin's arm5.

I think JA arm5 vs MS arm5 must be played now.

Code: Select all

JA arm 7 - MS arm 5: 32+ 16- 52= (58.0% +56 ELO)
JA arm 7 - JA arm 5: 33+ 13- 54= (60.0% +70 ELO)
JA arm 5 - MS arm 5: in progress...

Thanks, I assume you're using my latest compile with builtin_ctz?
70 elo is huge difference, implying almost doubling the speed.
I find it hard to believe that ARMv7 would make such a difference.
This is good to know however and I'll probably try to build v7 binaries
in the future (no new version anytime soon though).

[Gurcan Uckardes]

Thanks, I assume you're using my latest compile with builtin_ctz?
70 elo is huge difference, implying almost doubling the speed.
I find it hard to believe that ARMv7 would make such a difference.
This is good to know however and I'll probably try to build v7 binaries
in the future (no new version anytime soon though).

Probably no. It makes two versions with exactly the same sizes but different MD5 checksums. I must be still on your first fix.
Anyway, i'll finish what is already progressing and a 4th match can follow in order to prove your last decision was better