Glaurung 2-epsilon: Another attempt

[Tord Romstad]

Hello all,

I've tried to solve a few compatibility problems in Glaurung 2-epsilon. There were two little problems, both of them apparently caused by differences in the behaviour of various compilers.

The first problem was that different compilers seem to have different ways of executing "for" loops where several variables are updated in parallel, this caused Glaurung to evaluate some positions differently depending on the compiler. I have rewritten these loops in a way which is guaranteed to give equivalent results everywhere (in the absence of serious compiler bugs, of course).

The second problem was that my bitscanning function didn't work on all 64-bit platforms. Curiously, this even seems to vary between different versions of GCC. 64-bit GCC-compiled executables for G5s running OS X work fine, but 64-bit Linux executables segfaults at startup. I've tried to solve this problem by introducing an alternative bitscanning function for 64-bit CPUs, enable it by uncommenting the line with #define USE_FOLDED_BITSCAN near the beginning of bitboard.h. I am not yet entirely sure that this works, but I have good hopes that it does.

Thanks to everyone who has helped me debug these problems! I hope everything will work as intended on all platforms now. Before trying to compile the program, however, it is important to read section 4 in the README file.

The new downloadable package now also contains a 32-bit Linux executable compiled by Volker Pittlik.

The URL is: http://www.glaurungchess.com

Tord

[Tord Romstad]

The second problem was that my bitscanning function didn't work on all 64-bit platforms. Curiously, this even seems to vary between different versions of GCC. 64-bit GCC-compiled executables for G5s running OS X work fine, but 64-bit Linux executables segfaults at startup. I've tried to solve this problem by introducing an alternative bitscanning function for 64-bit CPUs, enable it by uncommenting the line with #define USE_FOLDED_BITSCAN near the beginning of bitboard.h. I am not yet entirely sure that this works, but I have good hopes that it does.

According to Bernhard Bauer, it does indeed work now.

Tord

[Vempele]

The nodecounts still diverge at ply 7:

[edit: Arena set hash first to 24, then 8 MB for some reason; this is the correct one]

Code: Select all

   2	00:00	          45	0	+0,11	Nc3 Nc6
   3	00:00	         197	0	+0,54	Nc3 Nc6 Nf3
   4	00:00	         353	0	+0,11	Nc3 Nc6 Nf3 Nf6
   5	00:00	         771	0	+0,15	Nc3 Nc6 Nf3 Nf6 e3
   6	00:00	       1.583	0	+0,11	Nc3 Nc6 Nf3 Nf6 e3 e6
   7	00:00	       3.557	0	+0,21	Nc3 Nc6 Nf3 Nf6 e3 e6 Bd3
   8	00:00	       6.378	0	+0,11	Nc3 Nc6 Nf3 Nf6 e3 e6 Bd3 Bc5
   9	00:00	      17.227	1.076.687	+0,35	Nc3 Nc6 Nf3 Nf6 e3 e6 Bd3 Nb4 0-0 Nxd3 cxd3
  10	00:00	      37.686	801.829	+0,11	Nc3 Nc6 Nf3 Nf6 e3 e6 Bd3 Bc5 0-0 0-0
  11	00:00	      80.707	740.431	+0,21	Nc3 Nc6 Nf3 Nf6 e3 e6 Bd3 Bd6 0-0 Ng4 g3
  12	00:00	     180.209	826.646	+0,23	Nc3 Nc6 Nf3 Nf6 e3 e6 Bd3 Nb4 0-0 Nxd3 cxd3 Bd6 Nd4
  13	00:00	     419.727	791.937	+0,11	Nc3 Nc6 Nf3 Nf6 e3 e6 Bd3 Nb4 0-0 Nxd3 cxd3 Bd6 Nb5 0-0 Nxd6 cxd6
  14	00:01	     932.297	776.267	+0,11	Nc3 Nc6 Nf3 Nf6 e3 e6 Be2 Be7 d4 d5 0-0 0-0 Bd2 Bd7
  14	00:02	   1.997.866	744.638	+0,23	e4 Nc6 Nf3 Nf6 Nc3 e6 Bb5 Bb4 d3 0-0 0-0 d5 Bxc6 bxc6 Ne5
  15	00:04	   3.464.813	742.884	+0,25	e4 Nc6 Nf3 Nf6 Nc3 e6 Bb5 Bb4 d3 0-0 0-0 d5 Bxc6 bxc6 Ne5 Bb7

Unless you changed other things too?

[Tord Romstad]

The nodecounts still diverge at ply 7:

Actually, I get exactly the same node counts, scores and PVs for the first 12 iterations here. From the 13th iteration it starts diverging very slightly. The PVs and the scores are still exactly the same, but the node counts are a tiny bit bigger or smaller.

This discrepancy is definitely worth studying before I release the next version, but for Glaurung 2-epsilon I think it is not worth worrying about. I feel quite sure that whatever the cause of the different node counts is, it is not likely to have a huge impact on the playing strength. I expect Glaurung 2-epsilon in Windows to be just as strong (or just as weak, depending on your point of view) as my own Mac OS X version.

At any rate, I appreciate that you have made me aware of this discrepancy. It is very likely that this is caused by a subtle bug somewhere in my code. It probably doesn't hurt the strength very much, but you never know.

Tord

[Guetti]

The second problem was that my bitscanning function didn't work on all 64-bit platforms. Curiously, this even seems to vary between different versions of GCC. 64-bit GCC-compiled executables for G5s running OS X work fine, but 64-bit Linux executables segfaults at startup.

This is not so surprising if you consider that long is 32bit on a G5 in gcc under OS X but long is 64-bit on a x86-64 linux system using the same compiler. So the differences are not necessary due to the compiler.

regards
Andy

[Tord Romstad]

The second problem was that my bitscanning function didn't work on all 64-bit platforms. Curiously, this even seems to vary between different versions of GCC. 64-bit GCC-compiled executables for G5s running OS X work fine, but 64-bit Linux executables segfaults at startup.

This is not so surprising if you consider that long is 32bit on a G5 in gcc under OS X but long is 64-bit on a x86-64 linux system using the same compiler. So the differences are not necessary due to the compiler.

Andreas,

I almost replied that this doesn't matter, because I never use the "long" type. At the last moment, just before pushing the "Submit" button, I checked my code, just to be sure. I was horrified to find the following lines in types.h:

Code: Select all

typedef unsigned long uint32;
typedef signed long int32;

The type "int32" is never used, and the type "uint32" is only used a couple of places. Unfortunately, these two places are really catastrophic. The first place is the bitscanning function, which has already caused a lot of trouble. The second place, which has been unnoticed until now, is in the class TTEntry in tt.h:

Code: Select all

class TTEntry {

public:
  TTEntry();
  TTEntry(Key k, Value v, ValueType t, Depth d, Move m, int generation);
  Key key() const;
  Depth depth() const;
  Move move() const;
  Value value() const;
  ValueType type() const;
  bool mate_threat() const;
  int generation() const;

private:  
  Key key_;
  uint32 data;
  int16 value_;
  int16 depth_;
};

Because uint32 is incorrectly defined as an "unsigned long" rather than an "unsigned int", the hash entries will become too big in 64-bit Linux (perhaps also in 64-bit Windows, I'm not sure). This not only inflates the hash table size, but also increases the price of accessing the transposition table.

This must be considered a major bug, I have therefore once again updated the source code, hopefully for the last time. 64-bit Linux and Windows users, please download the code once more. 32-bit users and Mac users, please don't bother.

Thank you very much for pointing out this bug, Andreas! I would have spent a long time before I would have found it on my own.

Tord

[Guetti]

That would explain it. If I remeber correctly, 64-bit Windows uses the LLP64 data model, like the OS X.

See also this thread, were I discussed a similar bug with Daniel in scorpio:

http://wbforum.vpittlik.org/viewtopic.p ... 313&t=5904

[anst]

If you compile with full warnings most compilers will give you a warning about this.

Stå på med et flott program !
Andreas