Designing an analysis friendly Stockfish?

[BB+]

I agree that the assert should fail when the score is between alpha and beta. My opinion is that the assert is unnecessary. It is merely saying (for the previous code) that the last move considered is the one that caused the fail-high. But now that doesn't need to be the case anymore.

[fruity]

I agree that the assert should fail when the score is between alpha and beta. My opinion is that the assert is unnecessary. It is merely saying (for the previous code) that the last move considered is the one that caused the fail-high. But now that doesn't need to be the case anymore.

If you ignore the assert you will count the successfull move also as a failure. Maybe it is better to do it this way.

Code: Select all

 void update_history(const Position& pos, Move move, Depth depth,
                      Move movesSearched[], int moveCount) {
    Move m;

    H.success(pos.piece_on(move_from(move)), move_to(move), depth);

    for (int i = 0; i < moveCount - 1; i++)
    {
        m = movesSearched[i];

        if (m != move && !pos.move_is_capture_or_promotion(m))
            H.failure(pos.piece_on(move_from(m)), move_to(m), depth);
    }
  }

But this would be a functional change and therefore should be tested with real games again.

[Jeremy Bernstein]

I agree that the assert should fail when the score is between alpha and beta. My opinion is that the assert is unnecessary. It is merely saying (for the previous code) that the last move considered is the one that caused the fail-high. But now that doesn't need to be the case anymore.

If you ignore the assert you will count the successfull move also as a failure. Maybe it is better to do it this way.

Code: Select all

 void update_history(const Position& pos, Move move, Depth depth,
                      Move movesSearched[], int moveCount) {
    Move m;

    H.success(pos.piece_on(move_from(move)), move_to(move), depth);

    for (int i = 0; i < moveCount - 1; i++)
    {
        m = movesSearched[i];

        if (m != move && !pos.move_is_capture_or_promotion(m))
            H.failure(pos.piece_on(move_from(m)), move_to(m), depth);
    }
  }

But this would be a functional change and therefore should be tested with real games again.

New builds with the above change, and re-introducing most of Peter's changes for the last GTB he submitted, but with ProbeOnlyAtRoot turned back off by default, since I find it confusing that the TBs more or less stop working when it's turned on attached. Test away!

[mcostalba]

But this would be a functional change and therefore should be tested with real games again.

The change should be totally harmless apart for a slightly slow down in the common case of !PvNode where the test is not needed.

Anyhow for the real nitpicker among you, I can even add that the assert is not correct yes, it never fires in the original code, but it is wrong to assume that the last move is the one that produced the cut-off in the general case. This is corrcet in case of single thread but in case of multi-thread we could have a ss->bestMove originated by a slave thread sub-search so that in that case all the movesSearched[] array (that is populated only by the split node master thread), contains moves different from the cut-off move.

Anyhow this is just an academic digression because real effect is harmless anyway.....

P.S: Interesting to see all you people toying around SF sources, it is a good sign and a pleasure for us, SF developers, too see. It means that SF sources are fun to hack on, as we aim to.

[zwegner]

The other thing you might want to do is change how the buffering is set in main.cpp -- see an exchange I had with Marco Costalba about it. I think the fix is to replace

Code: Select all

  cout.rdbuf()->pubsetbuf(NULL, 0);
  cin.rdbuf()->pubsetbuf(NULL, 0);

by (used by Fruit, for instance)

Code: Select all

  setvbuf(stdin,NULL,_IONBF,0);
  setvbuf(stdout,NULL,_IONBF,0);

The reason for this seems to be that "select" is used, and this is (presumably) a C function, and so the C methods to set buffers should also be used, rather than those of C++. But I really don't know the underlying specifics.

select() is a system call. The only buffers it looks at are the kernel buffers, so any userspace buffering needs to be disabled. If anything, I'd guess that the C++ version should be used, in case there are separate buffers in the C/C++ IO libraries (I don't really know much about C++ IO, and I'd prefer to keep it that way). Since Fruit uses the C fgets(), then it should be using setbuf().

[fruity]

But this would be a functional change and therefore should be tested with real games again.

The change should be totally harmless apart for a slightly slow down in the common case of !PvNode where the test is not needed.

Slightly, uneccessary slow down in the common non-PV case, but also a functional change in the PV case, where the original code makes a noop on the successfull move, first H.success(), then H.failure(). Anyhow first tests indicate it is better to throw away the assert and leave the update_history() function otherwise as it is.

[Jeremy Bernstein]

Engine              Score SFSFSFSpSFSt    S-B
SF Release 64       4,5/5  · 1 1 = 1 1    9,50
SF PGO 64           3,0/5  0 · = 1 = 1    5,25
SF Release 32       2,5/5  0 = · = = 1    4,50
Spike1.4            2,0/5  = 0 = · = =    5,00
SF PGO 32           2,0/5  0 = = = · =    4,25
Stockfish-201-64-ja 1,0/5  0 0 0 = = ·    2,00

15 of 300 games played

Some preliminary results of a little tournament. 1/1 blitz.

[Peter C]

New builds with the above change, and re-introducing most of Peter's changes for the last GTB he submitted, but with ProbeOnlyAtRoot turned back off by default, since I find it confusing that the TBs more or less stop working when it's turned on attached. Test away!

Note: It's about twice as fast with it on.

I guess this is the analysis Stockfish though, and it's behavior is much more intuitive with it on.

Peter

[Peter C]

New builds with the above change, and re-introducing most of Peter's changes for the last GTB he submitted, but with ProbeOnlyAtRoot turned back off by default, since I find it confusing that the TBs more or less stop working when it's turned on attached. Test away!

Note: It's about twice as fast with it on.

I guess this is the analysis Stockfish though, and it's behavior is much more intuitive with it on.

Peter

I guess this is the analysis Stockfish though, and it's behavior is much more intuitive with it on.

I mean off.

Whoops. Can't believe I didn't notice that till now.

Peter

[Peter C]

Jeremy, you might want to add Makefiles to the GitHub repo so that us non-VS users can build it.

I attached the files included with the GTB library and the file I use for compiling Stockfish PA GTB (which is only slightly different from the standard SF makefile).

Peter