Could anyone make me a Windows compile...?

[mar]

hmm, I recompiled and reuploaded the files because icc somehow (by default) embedded 100kb worth of useless optimization report. previous version didn't do that

[Evert]

Ok I managed to compile with icc.
Experimental link is here (static linking, one executable ~1M):http://www.crabaware.com/sjaak/sjaakII_intel_32bit.zip
It's likely that it won't work on XP though (I may look into it later).
What bothers me is that node counts for analyse don't match Evert's compiles (!!).

That is indeed worrying. There is a "test benchmark" command that runs a bench test. That should produce reproducible bench results. If not we should figure out what's causing the difference.

EDIT: there is also "test movegen" which does a perftest acoss different positions for different variants. That needs to pass too.

However I've noticed that this 32-bit version (no hw popcnt, no prefetch) is on par (if not faster) than 64-bit SSE4.2 compile by Evert
(however because node counts are off by some, it's an unfair comparison).
I've also noticed the 64-bit version doesn't seem any faster than the 32-bit version, which seems strange.

Yes, that is quite suspicious - particularly if it holds for large variants.

I will upload the changes along with VS2012 project/solution in case someone would want to look into it. I'm not sure though Evert will like the changes

Hey, it's GPL code, anyone can do with it what they want, whether I like it or not. I'll have a look at it anyway and try to pull essential changes in locally.

Thanks for looking into this!

[Evert]

Last note: I don't know which macros need to be defined so these versions are without SMP, I'm not sure if something else is missing.

There is no SMP. The code that refers to SMP is inherited from Jazz. I left it in for when I want to add SMP to Sjaak (at some indeterminate point in the future) but there is currently no way to use it.

[mar]

test movegen was first thing I tried and it passed.
test benchmark crashes the 32-bit compile (even yours).
The culprit is default hashtable size, which is 64M elements, but entry is 24 bytes.
I think you wanted 64M total because otherwise that's 1.5G and since 32-bit Windows apps only have 2G VA space (I think Linux has 3), it fails to allocate such a large block.
Since create_hash_table takes number of elements,
I think a simple solution would be to decrease HASH_TABLE_SIZE in game.h (but I'm really not sure, perhaps you intended to use size in bytes instead of entries).
test benchmark produces the same results for 64-bit compile (after fixing PRui64 which I messed up by prepending a % sign) and they seem absoluten even in performance, which is good (even without hw popcnt).
So the problem is in the 32-bit compile only (your 32-bit compile is fine of course).
I will look into it and once fixed, I will reupload everything.

[lucasart]

I would like to have a state-of-the-art Windows compile (preferbly a 64- and a 32-bit) if the engine Sjaak II ( http://www.eglebbk.dds.nl/program/chess-download.html ), for the purpose of distributing it in a special-purpose WinBoard package (for mini-Shogi).

The binary Windows package provided by the author isn't really acceptable to me, as it is dependent on a number of quite large general-purpose libraries (the C++ standard library) that have to be distributed with it. I was hoping it would be possible to make a 'native' Windows compile that would make use of the standard C++ infra-structure of Windows, instead of providing its own.

C++ runtime libraries are enormous, whether provided by MinGW (staitc compile), or embedded in Microsoft DLL (with all the problems of dynamic linkage and people not having the right version of the DLL, as explained by Martin).

I had a quick look at Sjaak II code, and it seems to be C, not C++, although with .cc extensions. Is it not possible to compile it as C instead of C++ ? Doing a static mingw compile as C should not be too large (obviously strip the executable to reduce cruft).

In fact, I remember that when DiscoCheck was in C (before version 4.0), I provided dynamic compiles with mingw, and they worked in Windows and were very small. It's only when I switched to C++, that I was forced to do static compile and provide enormous >1MB executables...

[mar]

Ok I found the problem and reuploaded everything, including the changes.
Even the 32-bit compile (slightly slower than 64-bit in the end) seems faster than your original 64-bit SSE4.2 compile, so I guess icc is still pretty good.

Now back to the problem, I think it's a (serious?) bug in Sjaak.
What do you think this expression evaluates to:

Code: Select all

&#40;uint64_t&#41;1 << 125

Problem is the CPU instruction on x64 does masking by 63 and obviously gcc in 32-bit mode too.
However Microsoft CRT does no masking in 32-bit emulation and hence the "problem".
(this is why I advocate compiling with different compilers at different platforms, because sometimes it can help to catch bugs)

At the end of evaluate.h I left a debug code for you (#if 0 for now) so that you can trace the problem.
But probably that's not necessary - best would be to put an assert in bitboard.h.
(the "fixes" in bitboard.h are marked with comments and FIXMEs)
I'm not sure if/how this would affect performance and/or variants that use 128-bit bitboards...

[mar]

To help you locate the problem:
it's in see, related to mask.
argument to first reset somehow fetches this very large number.

[Rein Halbersma]

Now back to the problem, I think it's a (serious?) bug in Sjaak.
What do you think this expression evaluates to:

Code: Select all

&#40;uint64_t&#41;1 << 125

Shifting an integral or enumeration type by more than its bit-length is a case of undefined behavior in C and C++. Enter the nasal demons.

[Evert]

test movegen was first thing I tried and it passed.
test benchmark crashes the 32-bit compile (even yours).
The culprit is default hashtable size, which is 64M elements, but entry is 24 bytes.
I think you wanted 64M total because otherwise that's 1.5G and since 32-bit Windows apps only have 2G VA space (I think Linux has 3), it fails to allocate such a large block.

Actually, no, but I clearly never tested this on 32 bit Windows (it works under both OS X and Linux). In practice (ie, when playing a game) the transposition table size is set by the GUI, which I think will normally avoid the problem. Either way - a smaller default table size, certainly in 32 bit, sounds like a good idea.

Since create_hash_table takes number of elements,
I think a simple solution would be to decrease HASH_TABLE_SIZE in game.h

Yes, that is the correct fix (it needs to be a power of 2 though).

[Evert]

I had a quick look at Sjaak II code, and it seems to be C, not C++, although with .cc extensions. Is it not possible to compile it as C instead of C++ ?

Nope.

It's very much "C with classes" style C++ (it's a bit messy and inconsistent beyond that), but the crucial point is that bitboard_t is a template class over uint32_t, uint64_t or uint128_t (the latter may also be a class rather than an actual integer type, depending on platform and compiler options).
This was actually the whole point in re-writing Sjaak: to prevent code duplication for 128 and 64 bit bitboards.