MSVC vs GCC

[elcabesa]

Hi, I have just tryed GCC after having compiled Vajolet for near an year with MSVC.

I wanted to modify my code because for a design choice I have the makeMove method inside the move Class and I wanted to change the code to Board.makeMove(move);
After doing the change i noticed the node count for the search changed, after some investigation I only found that it looks like to be a "problem" with compiler optimization. Debug and release compile have different node count for the same search and I could change the node count simply adding

Code: Select all

if(move.packed==0){
 std&#58;&#58;cout<<"Error";
&#125;

just before the makeMove method.

I have switched to eclipse & gcc and after some little modification to make the code compile I have generated a new engine. The node count still changed between debug & release, but changing the code from move.makemove to board.makemove(m) doesn't change the node count.

I was using MSVC 2012
I think I'm having different node count between debug & release caused by the different number of elements in the transposition table and pawnStructure table, I'll investigate

has anyone faced such a problem?

[jdart]

I recommend using the -fno-strict-aliasing option with GCC optimized builds.

This disables optimizations that break when type-casting across pointer types is used (a very common practice in C/C++ code).

--Jon

[elcabesa]

just tried but nothing changed.
it lloks like transposition Table is not the problem

[Rein Halbersma]

This disables optimizations that break when type-casting across pointer types is used (a very common practice in C/C++ code).

--Jon

Did you mean a very common practice in C code? In C++ this is strongly discouraged.

[Evert]

After doing the change i noticed the node count for the search changed, after some investigation I only found that it looks like to be a "problem" with compiler optimization.

You have a bug.

Do you use libc's rand() function? Or qsort()? No obvious reason why those would be different between debug and release builds, but you should check everything.

Also check for uninitialised variables (the compiler should be able to warn you about those if you tell it to).

I think I'm having different node count between debug & release caused by the different number of elements in the transposition table and pawnStructure table, I'll investigate

Why would those be different? Anyway, you want to keep those the same between debug and release, otherwise you're going to have a lot of difficulty reproducing problems encountered in release mode in debug mode.

has anyone faced such a problem?

Yes, a couple of times. Always uninitialised variables, array overruns or calling libc functions (qsort, in my case, for a difference between native Linux and cross-compiled Windows builds) were the cause.

[elcabesa]

I'll search the BUG

I use rand() function, but I have the same random numbers in both debug & release.

talking about trans table I have just checked I have the same number of elements in both builds. I'll try to investigate why I have differents nodeCount.

[jdart]

While not allowed in the C++ standard (or in C99), it is still a common practice, and there is a lot of existing code that does it.

--Jon

[bob]

Hi, I have just tryed GCC after having compiled Vajolet for near an year with MSVC.

I wanted to modify my code because for a design choice I have the makeMove method inside the move Class and I wanted to change the code to Board.makeMove(move);
After doing the change i noticed the node count for the search changed, after some investigation I only found that it looks like to be a "problem" with compiler optimization. Debug and release compile have different node count for the same search and I could change the node count simply adding

Code: Select all

if(move.packed==0){
 std&#58;&#58;cout<<"Error";
&#125;

just before the makeMove method.

I have switched to eclipse & gcc and after some little modification to make the code compile I have generated a new engine. The node count still changed between debug & release, but changing the code from move.makemove to board.makemove(m) doesn't change the node count.

I was using MSVC 2012
I think I'm having different node count between debug & release caused by the different number of elements in the transposition table and pawnStructure table, I'll investigate

has anyone faced such a problem?

99.9% of the time, this is an initialized variable problem. Local variables specifically. They are allocated on the stack, and when you change anything at all (including stack usage, library calls and such, the variables will end up with different values when they are allocated on a different part of the stack.

[tpetzke]

Hi Marco,

this happened to me several times and it was always a bug.

You have to trace it down by finding the node where the difference occurs. So pick a position and perform a ply 1 search, if node counts are still in sync increase to ply 2 until you reach the depth were the the difference occurs.

Now spot the exact node. Just print every n numbers of nodes a FEN in a log. Look where the FENs for node x start to differ. Now decrease n but start outputting FENs later until you have the node.

Now start to compare alpha, beta and the usual stuff in that node. Chances are the error occurred already a few nodes earlier but it manifested itself in a different FEN per node later. It takes a bit of time but at the end you'll find it.

Thomas...

[elcabesa]

today I just found 2 BUG, and now gcc debug and release has the same node count for lthe positions I tried.
MSVCC still has a different node count between debug nad release, I'll investigate it