Building Crafty 22.0 on a Macintosh

[sje]

Cautionary warnings:

In learn.c, routine LearnBook(), the formals "tree" and "wtm" are never referenced.

Also, related to egtb.cpp:

/Users/sje/Projects/crafty/Source/tbdecode.h:853: warning: 'int comp_tell_blocks(decode_info*)' defined but not used
/Users/sje/Projects/crafty/Source/egtb.cpp:6097: warning: 'int TbtProbeTable(int, color, INDEX)' defined but not used

----

There are several global variables that share names with locals that are scattered throughout the code, While harmless to one familiar with the source, the shadowing could be confusing to a casual peruser. Here "wtm" is the main culprit with others being "title_next", "done", "total_moves", "nargs", "args", "files", "index", "buffer", "fileno", "pieces", "king", "sign", "squares", "occupied", "silent", "time_used", "search_depth", and "force".

[bob]

Diagnostics from compiling egtb.cpp:

Code: Select all

	/Users/sje/Projects/crafty/Source/egtb.cpp:83:1: warning: "lock_t" redefined
	In file included from /Users/sje/Projects/crafty/Source/egtb.cpp:54:
		/Users/sje/Projects/crafty/Source/lock.h:122:1: warning: this is the location of the previous definition
	/Users/sje/Projects/crafty/Source/egtb.cpp:4484: warning: 'TB_CRC_CHECK' initialized and declared 'extern'
	/Users/sje/Projects/crafty/Source/egtb.cpp:6303: warning: unused variable 'fWasError'
	/Users/sje/Projects/crafty/Source/egtb.cpp:6304: warning: unused variable 'block'
	/Users/sje/Projects/crafty/Source/egtb.cpp:6305: warning: unused variable 'rgbBuffer'
	/Users/sje/Projects/crafty/Source/egtb.cpp:3249: warning: control may reach end of non-void function 'unsigned int IndEnPassant21B(square, square, square, square)' being inlined

I'm not touching that code, I didn't write it and don't want to try to follow what it does...

[bob]

When trying to compile crafty with -DCPUS=4, I get the following (repeated many times):

Code: Select all

/Users/sje/Projects/crafty/Source/lock.h:102: error: can't find a register in class 'MQ_REGS' while reloading 'asm'

when it hits the inline definition in lock.h:

Code: Select all

static void __inline__ UnlockX86(volatile int *lock)
{
  int dummy;
  asm __volatile__("movl    $0, (%1)":"=&q"(dummy)
      :"q"(lock));
}

and also with the earlier LockX86() definition.

Without the -PCPUS=4, the single core version runs at about 1.1 to 1.5 Mnps on the opening position on a 2.66 GHz Mac Pro quad core.

This will take a windows/msvc expert to fix. In Crafty, I have two different inline functions for the MSB/LSB/PopCnt functions, one for 32 bit X86, one for 64 bit X86. I'm guessing that is the problem here as it is using Eugene's inline code that might be confusing the compiler. On a 64 bit machine, that most likely needs to be a movq. If you are compiling on linux, then make sure you are using the inline64 rather than inline32 include, which should be done if you have the Makefile done right...

[sje]

Are any of those custom inline lock routines really that much better than using a plain and portable pthread mutex?

[jdart]

PGO doesn't work with Arasan either, at least with the 4.x gcc compilers. It reliably crashes in the final link phase. It worked fine with older (3.4) gccs though. I've wanted to file a bug report but haven't had time to chase the problem down to a manageable size test case.

--Jon

[Zach Wegner]

Are any of those custom inline lock routines really that much better than using a plain and portable pthread mutex?

Pthread mutexes don't work with processes, or with Windows.

[sje]

Are any of those custom inline lock routines really that much better than using a plain and portable pthread mutex?

Pthread mutexes don't work with processes, or with Windows.

That's okay, because I don't work with Windows either.

More to the point, the pthreads utilities including mutexes does work (to some extent) under Windows using the Cygwin Unix-on-Windows package.

[bob]

PGO doesn't work with Arasan either, at least with the 4.x gcc compilers. It reliably crashes in the final link phase. It worked fine with older (3.4) gccs though. I've wanted to file a bug report but haven't had time to chase the problem down to a manageable size test case.

--Jon

That's always the problem with gcc bug reports, they won't look at a program the size of crafty at all.

[bob]

Are any of those custom inline lock routines really that much better than using a plain and portable pthread mutex?

Absolutely. The mutex threads can block the process, which is a huge overhead, the spinlocks just hang until the lock is released...

[sje]

At this point I've gotten Crafty running natively on a Xeon Mac Pro after adding the kernel shared memory start up configuration file. It on it's fourth 100 game blitz match with Symbolic and with the latter program running its matchbox learner after each match. No crashes or other strange behavior yet.