Building Crafty 22.0 on a Macintosh

[sje]

I tried building Crafty 22.0 on an Apple Macintosh running OS/X 10.5.2 with the Xcode 3.1 IDE.

Without using the IDE, "make darwin" fails; it is rather out of date.

With using Xcode, it still doesn't build, but I I have some comments that may be helpful.

1) Line 33 in chess.h is:
#define CPUS=1
I'm sure that this is supposed to be:
#define CPUS 1

2) There is no strops.h header in OS/X 10.5.2. Therefore, a change in utility.c:
#if !defined(NEXT)
becomes
#if !defined(NEXT) && !defined(__APPLE__)

3) Definition management for "lock_t" is messed up and needs fixing in several places.

4) When building in Xcode, the all-in-one including file crafty.c has to go.

5) the testepd.c file does not compile. It's only routine is never called.

6) The egtb.cpp file needs to be tweaked a bit to clear up some warnings.

7) With all of the above fixed, the program fails at initialization time on its second call to SharedMalloc. One problem is that the default value for kern.sysv.shmmax is only 4,194,304. Another problem is that it takes some work to change the system default, although it can be done if one can obtain super user privileges.

----

If there is interest from anyone on the Crafty team, they can contact me and we can work together to fix these things so that Mac users may enjoy Crafty as do others.

[Guetti]

Typing 'make darwinG5' works fine here out of the box on OSX 10.5.2 using gcc from the terminal.

Setting /etc/sysctl.conf to shmmax to 536870912 solves the problem with the insufficient shared memory.

# /etc/sysctl.conf
#
# increase maximum shared memory size
kern.sysv.shmmax=536870912
kern.sysv.shmmin=1
kern.sysv.shmmni=128
kern.sysv.shmseg=32
kern.sysv.shmall=131072

[sje]

The problem is that Apple stopped selling G5 PowerPC machines some time ago; it's been Intel only for nearly two years.

Trying "make darwinG5" on an Intel Mac results with:

Code: Select all

make target=LINUX \
		CC=gcc CXX=g++ \
		CFLAGS=' -Wall -pipe -O3 -mcpu=G5 \
			-mtune=G5 -fomit-frame-pointer -fast' \
		CXFLAGS= \
		LDFLAGS=' -lstdc++' \
		opt=' -DCPUS=4 -DPOWERPC' \
		crafty-make
gcc -Wall -pipe -O3 -mcpu=G5 		-mtune=G5 -fomit-frame-pointer -fast -DCPUS=4 -DPOWERPC -DLINUX -c crafty.c
crafty.c:1: error: bad value (G5) for -mtune= switch
make[2]: *** [crafty.o] Error 1
make[1]: *** [crafty-make] Error 2
make: *** [darwinG5] Error 2

[Guetti]

The problem is that Apple stopped selling G5 PowerPC machines some time ago; it's been Intel only for nearly two years.

Trying "make darwinG5" on an Intel Mac results with:

Code: Select all

make target=LINUX \
		CC=gcc CXX=g++ \
		CFLAGS=' -Wall -pipe -O3 -mcpu=G5 \
			-mtune=G5 -fomit-frame-pointer -fast' \
		CXFLAGS= \
		LDFLAGS=' -lstdc++' \
		opt=' -DCPUS=4 -DPOWERPC' \
		crafty-make
gcc -Wall -pipe -O3 -mcpu=G5 		-mtune=G5 -fomit-frame-pointer -fast -DCPUS=4 -DPOWERPC -DLINUX -c crafty.c
crafty.c:1: error: bad value (G5) for -mtune= switch
make[2]: *** [crafty.o] Error 1
make[1]: *** [crafty-make] Error 2
make: *** [darwinG5] Error 2

Well, the -DPOWERPC flag only unlocks the correct definitions for OSX in lock.h, although the name is maybe not perfect, it should work fine on any machine running OS X. This define was suggested by me because it required an absolute minimum of changes to the sources for Bob after the removal of pthreads from crafty.

Code: Select all

#    elif defined(POWERPC)
                        /* OS X */

#      include <libkern/OSAtomic.h>

#      define lock_t                            OSSpinLock
#      define LockInit(v)               ((v) = 0)
#      define LockFree(v)               ((v) = 0)
#      define Lock(v)                   OSSpinLockLock(&(v))
#      define Unlock(v)                 OSSpinLockUnlock(&(v))

Sorry, most OS X changes currently in crafty were suggested by me to Bob, and I don't have an Intel Mac. But in general, compiling crafty under Mac OSX on a core duo should be even easier than on my PowerPC G5, just use LINUX as a target, use -DPOWERPC (should probably be renamed) and remove the -mpcu -mtune flags.

[sje]

First, most Mac users, like most Windows users, are not developers and aren't generally fluent with respect to programming tools. So a very simple install is needed, and the install should be relatively up to date with current tools available on the different platforms.

Probably the best way of distributing Crafty among Mac users is to have a fat executable available for downloading for casual users, and have a working Makefile for all others.

A fat executable is a Mac application that contains binaries for each of several supported platforms. The most common arrangement is one that has ppc (PowerPC 32 bit) and i386 (Inter 32 bit) models. An even more general approach is to include ppc64 and x86-64 models as well. The Mac launcher automatically figures out the best one to use when the application is started. Of course, the x86-64 model is the best one to use for Crafty, and it's supported on every Mac currently produced along with some going back to 2006.

By itself, gcc/g++ can't make a fat executable; it has to run at least once per model. But the Xcode IDE also has full command line support, and it can be called from a Makefile with no problems. Unlike Windows or Ubuntu, ever Mac OS installer disk comes with the full tool chain, although all of it is not installed by default. An updated IDE can be downloaded for free if one has the patience and a decently sized pipe.

[Guetti]

This was to much work for me. I only wanted a fast compile for my G5 and I drop in some modified inline functions anyway before every build.
I wouldn't expect anybody with Intel processors to use gcc anyway to compile crafty but would use the free Intel compiler, cause this gives a huge performance boost.

[sje]

I wouldn't expect anybody with Intel processors to use gcc anyway to compile crafty but would use the free Intel compiler, cause this gives a huge performance boost.

Is the Intel compiler really that much better for C++ than g++ 4.2?

[Tord Romstad]

First, most Mac users, like most Windows users, are not developers and aren't generally fluent with respect to programming tools. So a very simple install is needed, and the install should be relatively up to date with current tools available on the different platforms.

Probably the best way of distributing Crafty among Mac users is to have a fat executable available for downloading for casual users, and have a working Makefile for all others.

Casual Mac users wouldn't be able to use Crafty at all, even if there were a fat executable. Operating the program from the command line is obviously not an option, and as far as I know there is no native GUI with XBoard support for Mac OS X. You won't get casual users to install X11 and XBoard.

By itself, gcc/g++ can't make a fat executable; it has to run at least once per model. But the Xcode IDE also has full command line support, and it can be called from a Makefile with no problems.

I don't see what the point of this would be -- why would you ever want to call XCode from a Makefile? Wouldn't it be far faster and easier to call gcc and lipo directly from the Makefile?

Tord

[Tord Romstad]

This was to much work for me. I only wanted a fast compile for my G5 and I drop in some modified inline functions anyway before every build.
I wouldn't expect anybody with Intel processors to use gcc anyway to compile crafty but would use the free Intel compiler, cause this gives a huge performance boost.

The Intel compiler is only free for Linux. The Mac OS X version costs $449.

Besides, Steven is right: After Apple finally released gcc 4.2 for OS X a couple of weeks ago (why did it take them so long?), the performance boost with the Intel compiler is no longer that big. For my program, it seems to be only about 25% on the Core 2 Duo.

Tord

[sje]

Well, Xcode can do more than just call gcc/g++; it can run all kinds of other code processors and utilities as needed for complicated builds.

Crafty can be run from the command line, unless something has changed this in the past version or so.

There are some Mac chess GUIs available that don't need X Windows; maybe one of these can use the xboard protocol or some adaptation thereof.

----

With regard to the Intel icc compiler:

I have just tried this out.

On the good side: Everything compiles; several cosmetic turdlets unknown to g++ were detected; the compiler takes the same optimization parameters as does g++; the x86-64 model was correctly chosen automatically; and, the Symbolic it generated ran my twelve iteration BWTC.0031 test with the exact same node counts and output PVs as the g++ version.

On the bad side: Ten percent slower.

Did I somehow miss any arcane Intel specific optimization command line directives? I'm using:

icc -O3 -finline-limit=1536 -o ~/tmp/Symbolic *.cpp

which is pretty much the same as the g++ call.