Crafty 23.6 on ARM problems

[Max]

Thanks Jim,

for your tips! Crafty 23.6 now runs fine on my ARM based Linux system (without SMP). Your bitscan intrinsics gives a nice speed boost of nearby 8%.

After playing with some compiler options (-O2, -O3, -Ofast, -flto and -mtune=cortex-A15) it looks like -O2 produces the fastest executables and gcc 4.7.3 optimazitions through -mtune=cortex-a15 don't help much (less than 1% speedup).

Code: Select all

$ ./crafty236
unable to open book file [/usr/share/crafty/book.bin].
book is disabled
unable to open book file [/usr/share/crafty/books.bin].
pondering disabled.
Warning--  xboard 'memory' option disabled
hash table memory = 256M bytes (16M entries).
Warning--  xboard 'memory' option disabled
pawn hash table memory = 64M bytes (2M entries).


Crafty v23.6 (1 cpus)

White(1): bench
Running benchmark. . .
......

Some values from the above benchmark with different compiler options:

Raw nodes per second: 1159129, -O2 + GCC intrinsics + -mtune=cortex-a15
Raw nodes per second: 1149211, -O2 + GCC intrinsics
Raw nodes per second: 1142880, -O2 + GCC intrinsics + -flto
Raw nodes per second: 1105610, -Ofast + GCC intrinsics
Raw nodes per second: 1078021, -O2 + -mtune=cortex-a15
Raw nodes per second: 1065739, -O2
Raw nodes per second: 984421, -O3 + -mtune=cortex-a15

Max

[bob]

Forgot to mention on ARM compilers char is unsigned by default.

Jim.

At one point, IBM's AIX systems behaved exactly the same (RS6000 days)... That's how I concluded this was a problem so quickly. Seen it previously.

The C standard does not specify if char is signed char or unsigned char. It explicitly states that this is left to the compiler developer, to pick whatever is most convenient on the platform he is compiling for. (E.g. on a machine that does not support an instruction for signed compare of byte variables, or sign extension from byte to word, signed char would be much slower than unsigned char.)

If you want your code to be portable, you should only use char when you don't care if it is signed or unsigned (e.g. when you know for sure the value will always be in the range 0-127).

I understand. It was just something that was done "because it worked everywhere", and was never corrected... I'm going to take a look at all char's in Crafty for the next release to solve this...

[bob]

Suggestion: Reduce and centralize assumptions about default character and integer types.

Code: Select all

// Integer types

typedef signed   int           si;
typedef unsigned int           ui;

typedef signed   char          si8;
typedef unsigned char          ui8;

typedef signed   short int     si16;
typedef unsigned short int     ui16;

typedef signed   int           si32;
typedef unsigned int           ui32;

typedef signed   long long int si64;
typedef unsigned long long int ui64;

[/quote

I've been converting to the stdint.h stuff, which would be int8_t, which IS signed. I've already converted my bitboard (long long) stuff to the uint64_t type previously.

[lucasart]

Suggestion: Reduce and centralize assumptions about default character and integer types.

Code: Select all

// Integer types

typedef signed   int           si;
typedef unsigned int           ui;

typedef signed   char          si8;
typedef unsigned char          ui8;

typedef signed   short int     si16;
typedef unsigned short int     ui16;

typedef signed   int           si32;
typedef unsigned int           ui32;

typedef signed   long long int si64;
typedef unsigned long long int ui64;

Even better (ISO C99)

Code: Select all

#include <inttypes.h>

Goes without saying that the programmer should never assume that char is signed or not, because this is not specified by the standard. If signed char is needed, then sint8_t should be used, and if unsigned then uint8_t.

In almost all cases where I had to use char, I never cared about signedness, so I really wonder what Crafty can be doing with char that is signedness dependant...

[sje]

Even better (ISO C99)

Code: Select all

#include <inttypes.h>

In the C++ world, it's <cstdint>

http://www.cplusplus.com/reference/cstdint/

I don't use that because I dislike underscores in type names, plus I've duplicated my own code which was written long before the C99 specification appeared.

[bob]

Suggestion: Reduce and centralize assumptions about default character and integer types.

Code: Select all

// Integer types

typedef signed   int           si;
typedef unsigned int           ui;

typedef signed   char          si8;
typedef unsigned char          ui8;

typedef signed   short int     si16;
typedef unsigned short int     ui16;

typedef signed   int           si32;
typedef unsigned int           ui32;

typedef signed   long long int si64;
typedef unsigned long long int ui64;

Even better (ISO C99)

Code: Select all

#include <inttypes.h>

Goes without saying that the programmer should never assume that char is signed or not, because this is not specified by the standard. If signed char is needed, then sint8_t should be used, and if unsigned then uint8_t.

In almost all cases where I had to use char, I never cared about signedness, so I really wonder what Crafty can be doing with char that is signedness dependant...

How about representing the 64 squares of a chess board, where +1 = white pawn, -1 = black pawn, etc???