Building Crafty 22.0 on a Macintosh

[Tord Romstad]

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.

Sure, I just don't see how it would make life easier when you are trying to do something as simple as building an universal binary of Crafty. Seems much more complicated than just calling gcc and lipo from the Makefile, if you ask me. Perhaps I am just not sufficiently familiar with XCode.

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

Sure it can, but we were talking about casual users. Nobody except the most hardcore geeks (like us) ever run anything from the command line.

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.

As far as I know, they only support UCI.

With regard to the Intel icc compiler:

I have just tried this out.

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.

These compiler switches are probably quite far from optimal. I use:

Code: Select all

CXXFLAGS = -O2 -DNDEBUG -fno-exceptions -fomit-frame-pointer -fno-rtti -fstrict-aliasing -mdynamic-no-pic -no-prec-div -ipo -static -xP

The switches -mdynamic-no-pic and -ipo are particularly important for maximum speed. Whether -O2 or -O3 is better seems to depend on the program.

For even more speed, you can try to enable profiler guided optimizations. Compile first with -prof_gen (in addition to the normal switches), run your program for a while, and then recompile with -prof_use.

Tord

[sje]

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.

An evaluation copy of the Mac OS/X version can be had for free for a thirty day trial period. I guess I could sign up for a new copy every month or so.

I'd like to know what kind of compiler command line options you're using to get a 25 percent speed improvement over g++.

[sje]

I tried:

Code: Select all

icc -O3 -DNDEBUG -fno-exceptions -fomit-frame-pointer -fno-rtti -fstrict-aliasing -mdynamic-no-pic -no-prec-div -ipo -static -xP -finline-limit=1536 -o ~/tmp/Symbolic *.cpp

And it complained:

Code: Select all

ipo: warning #11043: unresolved _fegetenv
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib
ipo: warning #11043: unresolved _fegetround
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib
ipo: warning #11043: unresolved _fesetenv
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib
ipo: warning #11043: unresolved _nan
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib
ipo: warning #11043: unresolved _nanf
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib
ipo: warning #11043: unresolved _nextafterf
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib

among a few other things, and no executable was produced.

[sje]

Okay, I dropped the "-static" option, still got some link complaints, but I did get an executable this time. Maybe there's some OS/X 10.4.x dependency on the part of the compiler.

The icc produced binary still runs slower than the g++ version, but only by 2.2 percent. The run took about six and a half minutes, so the difference is significant as it's greater than the usual random timing bobble.

[bob]

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

yes. We fixed this in 22.1 which will be out soon. Not sure how the typo happened... someone else had already pointed this out a couple of weeks back when we released 22.0...

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__)

done

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.

Not sure what you mean there. Can't you tell xcode to just compile crafty.c? That will probably produce the fastest executable since it allows inlining everywhere.

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

Not needed. It is included in test.c... not sure where that came from, probably in copying *.c files from A to B and back to A, picking up an old .c file with the rest. I had already removed this from 22.1

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.

Used to be a problem on linux to, which is why I included the message telling users how to fix this. On the Mac, I assume you do it the same way and yes, it does require super-user. Or you can edit the init scripts to add the fix to one of them so that it is done every time the system boots.

----

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.

[bob]

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.

Did you use PGO? Look at crafty's Makefile down in the "profile:" target area, and look at linux-icc and linux-icc-profile. That usually makes icc blow gcc away...

[bob]

I tried:

Code: Select all

icc -O3 -DNDEBUG -fno-exceptions -fomit-frame-pointer -fno-rtti -fstrict-aliasing -mdynamic-no-pic -no-prec-div -ipo -static -xP -finline-limit=1536 -o ~/tmp/Symbolic *.cpp

And it complained:

Code: Select all

ipo: warning #11043: unresolved _fegetenv
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib
ipo: warning #11043: unresolved _fegetround
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib
ipo: warning #11043: unresolved _fesetenv
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib
ipo: warning #11043: unresolved _nan
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib
ipo: warning #11043: unresolved _nanf
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib
ipo: warning #11043: unresolved _nextafterf
        Referenced in /usr/lib//libdl.dylib
        Referenced in /usr/lib/libSystem.B.dylib

among a few other things, and no executable was produced.

Just lose the -static. You apparently don't have all libs installed for that to work properly...

[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.

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

Interesting. Is gcc-4.2 much better for Intel than 4.0? I have it installed but it didn't really make that big a difference for crafty on PowerPC when I tried it. Maybe they included some optimizations for Intel.

[bob]

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?

For me it is no comparison... 10-15% is the usual benefit I see when comparing PGO for Intel vs PGO for gcc (when it actually works, about 75% of the gcc versions seem to crash on PGO for crafty)...

[Guetti]

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?

For me it is no comparison... 10-15% is the usual benefit I see when comparing PGO for Intel vs PGO for gcc (when it actually works, about 75% of the gcc versions seem to crash on PGO for crafty)...

This has improved. I just recently PGO crafty with gcc with different versions on Linux (4.1.1) and OSX (4.0.1, 4.2 and 4.3) and didn't encounter any problems. However, the speed gains varied a lot (5%-12%).