Stockfish v2.1 now available

[fern]

My goodnes, 28-30 ply in middle game!
You are being no nice with us, humble player with 5-6 plys deep the best day...

Fern

[tmokonen]

Thanks Jim, this compile works fine with the official book. On my machine, the difference in NPS compared to the MSVC compile is negligible.

[ernest]

Yes, but obviously the compile options are not the same...

[Mithu]

Thank you Tord , Marco and Joona for a wonderful engine that keeps improving and defying inertia...

Keep it up and rest assured that we are all indebted to your work.

P.S your website is elegant.

Hats off.

Best Regards
Mith.

[mcostalba]

I get completely different analysis:

The correct way to test any functionality change due to miscompile is to run from command line:

stockfish bench


Then verify that searched nodes must be: 6487630

[mcostalba]

Yes, I will try to investigate when I have a bit of time, probably this week-end.

Ok, I think I have found the issue with book reading under MSVC compile.

The problem happens only with the optimized 32 bit MSVC, not with the debug version I have used to test the new book code, hence I missed this bug.

The problem is here, in book.h file:

Code: Select all

template<int n> inline uint64_t Book&#58;&#58;get_int&#40;) &#123; return 256 * get_int<n-1>() + get&#40;); &#125;

This line recurively reads from the book file a number of chars specified by <int n>.

For this to work it is critical that the recursive function get_int<n-1>() is called _before_ reading the next character through calling get().

This is what _normally_ happens in all the compilers, but for some reason MSVC 32 bits when optimization flags are enabled calls get() before evaluating get_int<n-1>() and this produces a wrong book key so that position is not detected and books return a "position not found" value.

I would assume this bug is mine, not of MSVC because C++ standard does not seem to guarantee the order of evaluation of a term in a sum expression, so that we have to rewrite the code in a way to enforce the ordering, one quick hack (that works with MSVC) is to substitute the above line with:

Code: Select all

template<int n> inline uint64_t Book&#58;&#58;get_int&#40;) &#123; uint64_t v = 256 * get_int<n-1>(); return v + get&#40;); &#125;

so that 'v' is evaluated before get(), but I don't like it a lot and probably I will find something less tricky....

[Jim Ablett]

I get completely different analysis:

The correct way to test any functionality change due to miscompile is to run from command line:

stockfish bench


Then verify that searched nodes must be: 6487630

Was a miscompile, sorry. Intel optimization switch /QIfist was the culprit.
http://tinyurl.com/5saok4v

Here is re-compile which will show correct searched nodes.

http://dl.dropbox.com/u/5047625/stockfi ... tel-ja.zip

Jim.

[mcostalba]

Was a miscompile, sorry. Intel optimization switch /QIfist was the culprit.

Thanks for pointing that out !

Do you mean that the released 64 bit version was miscompiled ?

[Jim Ablett]

Was a miscompile, sorry. Intel optimization switch /QIfist was the culprit.

Thanks for pointing that out !

Do you mean that the released 64 bit version was miscompiled ?

No, only new win32 intel compile I posted in this thread. 64 bit version was compiled with Msvc.

Jim.

[tmokonen]

Thanks Jim, and Marco and the rest of the Stockfish team. You guys are very responsive to requests, and our little community benefits greatly from this.