node count change, please help

[PK]

In search.cpp moduke of the CPW-engine there is a following piece of code:

if ( ( depth == 1 ) &&
( !in_check ) &&
( alpha < 9000 ) &&
( alpha > -9000) &&
( fast_eval() + 200 <= alpha ) )
f_prune = 1;


if ( ( depth == 2 ) &&
( !in_check ) &&
( alpha < 9000 ) &&
( alpha > -9000 ) &&
( fast_eval() + 500 <= alpha ) )
f_prune = 1;

this looks too repetitive for my taste, so I decided to change it to something like:

int f_margin[3] = {0, 200, 500);

if ( ( depth == 1 || depth == 2) &&
( !in_check ) &&
( alpha < 9000 ) &&
( alpha > -9000) &&
( fast_eval() + f_margin[depth] <= alpha ) )
f_prune = 1;

after that I saw the node count change. Out of curiosity, I changed the compile configuration to "debug" and problem disappeared. I use Visual Studio 2008 Express Edition, and my "release" configuration is set to "maximize speed". Is there a problem with optimization routines or does the debug mode prevent program from executing some bug?

regards,

Pawel Koziol
http://chessprogramming.wikispaces.com/

[trojanfoe]

I would say it's the optmiser. However that code won't compile:

Code: Select all

int f_margin[3] = {0, 200, 500); 

(Mismatched braces)

Slightly better would be:

Code: Select all

int f_margin[2] = {200, 500}; 

if ( ( depth == 1 || depth == 2) && 
( !in_check ) && 
( alpha < 9000 ) && 
( alpha > -9000&#41; && 
( fast_eval&#40;) + f_margin&#91;depth - 1&#93; <= alpha ) ) 
f_prune = 1; 

However the code does look identical to the original, so I don't see why the optmiser is changing the node count in this way.

Cheers,
Andy

[pedrox]

Hi Pawel,

Another thing.

In badcaptures

Code: Select all

int badCapture(smove move) {

	/* captures by pawn do not lose material */
	if (move.piece_from = PIECE_PAWN ) return 0;

not "if (move.piece_from == PIECE_PAWN ) return 0;" ?

[Gerd Isenberg]

May be fast_eval has some side-effect, if called (conditionally) once or twice per node, related to pawn hash stuff and eventually some subtle bug or unintended side-effects in there ...

One idea is to compute fast_eval in advance before the conditions occur:

Code: Select all

int f_margin[4] = {0, 200, 500, 1000); 
gain = fast_eval() + f_margin[depth & 3];
...

or even try it branchless:

Code: Select all

// assuming depth <= 0 already handeld
condis   = depth < 3;
condis  += !in_check;
condis  += abs&#40;alpha&#41; < 9000;
condis  += fast_eval&#40;) + f_margin&#91;depth & 3&#93; <= alpha;
f_prune |= ( condis == 4 );

[trojanfoe]

Code: Select all

// assuming depth <= 0 already handeld
condis   = depth < 3;
condis  += !in_check;
condis  += abs&#40;alpha&#41; < 9000;
condis  += fast_eval&#40;) + f_margin&#91;depth & 3&#93; <= alpha;
f_prune |= ( condis == 4 );

That seems less efficient as all the tests are performed, where as the original AND chain at least means tests are not performed if an earlier test fails. Don't know how much difference that makes overall, but it seems efficiency is a driving factor with chess engines...

Cheers,
Andy

[Gerd Isenberg]

Code: Select all

// assuming depth <= 0 already handeld
condis   = depth < 3;
condis  += !in_check;
condis  += abs&#40;alpha&#41; < 9000;
condis  += fast_eval&#40;) + f_margin&#91;depth & 3&#93; <= alpha;
f_prune |= ( condis == 4 );

That seems less efficient as all the tests are performed, where as the original AND chain at least means tests are not performed if an earlier test fails. Don't know how much difference that makes overall, but it seems efficiency is a driving factor with chess engines...

Cheers,
Andy

You are right, most likely one of the leading conditions fails and due to the preconditions fast_eval is called only max once anyway and I confused the initial code.

Sometimes it makes sense to replace && by & for a few equally cheap relational expressions which may eventually difficult to predict. And branchless code is often easier for the compiler to produce correct code, for instance to "and" the sign-bits, while the differences might be computed in "parallel":

Code: Select all

int condis  = depth - 3;
condis  &= in_check - 1;
condis  &= abs(alpha) - 9000;
condis  &= fast_eval() + f_margin[depth & 3] - alpha - 1;
condis  = (unsigned)condis >> 31;
f_prune |= condis;

Of course this is ugly and harder to read, but it may help up and then.

[PK]

hi,

I have noticed similar node count changes in two more places, both unrelated to hash tables or evaluation. Again, changes appear only under my "release" configuration, which is optimized for speed. This time one of the modifications was simply moving a one-line conditional instruction into a separate function and I cannot possibly imagin what could have been wrong with that.

It looks like we ought to change the name of the thread to something like: problem with Visual C++ Express Edition.

Pedro, thanks for Your observation about badCaptures(), I messed something up because of misguided pretty-printing a couple of weeks ago. The function with a single "=" simply did not work. Still, I am not sure if this should be included in a simple, didactic program. Any opinions?

[Aleks Peshkov]

Your program is buggy. Is it compiler's bug or is it yours is not important.

[sje]

If you have successfully resisted coding Microsoft dependencies in your program, you should try compiling and running using gcc/g++ on Linux or Cygwin.

Program verification using two (or more!) different platforms concurrently during development can be quite beneficial.

[PK]

CPW should not be Microsoft-specific - it does not use too many libraries and Jim Ablett managed to compile previous version in a different environement.

Alex, the question whether this is a code bug somehow neutralized in a debug mode is of extreme importance - knowing how exactly it might be neutralized would help in finding it.

One idea I have is to create a very simplified version to see if it displays the same behaviour.