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
Glaurung 2-epsilon: Another attempt
Moderators: hgm, Rebel, chrisw
-
- Posts: 1808
- Joined: Wed Mar 08, 2006 9:19 pm
- Location: Oslo, Norway
-
- Posts: 1808
- Joined: Wed Mar 08, 2006 9:19 pm
- Location: Oslo, Norway
Re: Glaurung 2-epsilon: Another attempt
According to Bernhard Bauer, it does indeed work now.Tord Romstad wrote: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.
Tord
Re: Glaurung 2-epsilon: Another attempt
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]
Unless you changed other things too?
[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?
-
- Posts: 1808
- Joined: Wed Mar 08, 2006 9:19 pm
- Location: Oslo, Norway
Re: Glaurung 2-epsilon: Another attempt
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.Vempele wrote:The nodecounts still diverge at ply 7:
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
Re: Glaurung 2-epsilon: Another attempt
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.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.
regards
Andy
-
- Posts: 1808
- Joined: Wed Mar 08, 2006 9:19 pm
- Location: Oslo, Norway
Re: Glaurung 2-epsilon: YET another attempt
Andreas,Guetti wrote: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.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 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;
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_;
};
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
Re: Glaurung 2-epsilon: YET another attempt
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
See also this thread, were I discussed a similar bug with Daniel in scorpio:
http://wbforum.vpittlik.org/viewtopic.p ... 313&t=5904
Re: Glaurung 2-epsilon: YET another attempt
If you compile with full warnings most compilers will give you a warning about this.
Stå på med et flott program !
Andreas
Stå på med et flott program !
Andreas