MSVC vs GCC

[Don]

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.

Wow, does that bring back memories! I have done exactly what you described many times. I thought I was the only one.

I have found a better way - at least in unix systems it's easier to just output all the information including the node count and any relevant data that seems out of sync and then from 2 sets of logs find the diff. It may also be easy in Windows but in linux there are all sorts of easy to use tools for diff, comparing, finding what is unique, sorting and just about anything you want. For this all you need to know is the first pointer were 2 files differ.

When working on beekay (the c++ port of Komodo) there were times where I had to verify that the evaluation was the same - so I was displaying a fen string with it's evaluation. Even though the search was different I could quickly process though files and compare the positions that had the same fen and identify any glitches.

I did this same thing with the move generator, komodo has several and I would display the fen and a sorted list of moves in long algebraic - and found a couple of bugs even in komodo.

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

[Don]

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

There are many tools our there that will help you debug problems here. One that I have used is valgrind, it will find many kinds of errors. It is very easy to use. There are others too. I think valgrid will check for memory overflow problems, uninitialized variables and that kind of thing.

I assume that you also set gcc up to warn you of all errors, the option to gcc is -Wall - I always make sure my code compiles without any of the warning errors because many of them point to an actual problem. When it's not a real problem you still want to fix it so that a real error stands out.

[abulmo]

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.

I do not know if it is still a common practice, but it is clearly a wrong practice, as it prevents the compiler to do usefull optimizations.