Designing an analysis friendly Stockfish?

[fruity]

Oh, and here's gaard's version, that includes only fruity's changes:

http://dl.dropbox.com/u/11904592/stockfish_201_PA_K.zip

My proposal was meant to put on top of what Marco Costalba posted.
That's what I've tested. So the code should include the changes for tt.cpp, but it doesn't.

Code: Select all

- c2 = (tte->generation() == generation ? -2 : 0);
+ c2 = (tte->generation() == generation || tte->type() == VALUE_TYPE_EXACT ? -2 : 0);

[gaard]

Oh, and here's gaard's version, that includes only fruity's changes:

http://dl.dropbox.com/u/11904592/stockfish_201_PA_K.zip

My proposal was meant to put on top of what Marco Costalba posted.
That's what I've tested. So the code should include the changes for tt.cpp, but it doesn't.

Code: Select all

- c2 = (tte->generation() == generation ? -2 : 0);
+ c2 = (tte->generation() == generation || tte->type() == VALUE_TYPE_EXACT ? -2 : 0);

http://dl.dropbox.com/u/11904592/stockfish_201_PA_L.zip

[fruity]

I still feel like Stockfish is doing more work than necessary when moving between positions, but maybe that's just a subjective impression.

It might be possible to improve the analysis behaviour further with respect to your impression. We could try to store and retrieve TT entries in root_search(). We could even skip iterations on appropriate PV TT hits. There are some nasty little details to consider, f.e. Multi-PV. Not sure it's worth the effort, but I think it would be a good chess programming lesson though.

@gaard
Thanks!

[ivanhoe]

How about getting rid of EGTB support to see it goes any better or faster?

[Jeremy Bernstein]

How about getting rid of EGTB support to see it goes any better or faster?

EGTB will only effect performance when there are fewer than 6 pieces on the board. Otherwise, it's ignored.

However, dealing with performance is my next planned activity. My compiles are markedly slower than gaard's. I presume that you're using MingW, gaard, or are you running a different setup? I need to take a day to play with different compiler settings and/or change to a different compiler, since we're compiling more or less the same code.

Jeremy

[ivanhoe]

64bit compiles wont load in DF12 of the following versions:

Stockfish_201_PA_K
Stockfish_201_PA_L

XP64 OS, 4GB RAM, AMD QuadCore CPU.

[gaard]

64bit compiles wont load in DF12 of the following versions:

Stockfish_201_PA_K
Stockfish_201_PA_L

XP64 OS, 4GB RAM, AMD QuadCore CPU.

http://dl.dropbox.com/u/11904592/stockf ... _PA_La.zip

Every time I start from the original source I forget to modify lock.h for XP.

[fruity]

Sorry for posting only now, but I have limited net access these days.

Thanks for sharing your results. The most interesting thing is that 2 secs of TC seem to hold and give a realistic result. I would have tested 10K at 10 secs, but more for my prejudicies than for a real reason.

Your patch should be almost the same of what I posted because the impact in qsearch should be minimal, even lower then considering mate scores

If somewhere, it would make a difference in qsearch() because node count is heavily dominated by leaf nodes.
I'm running another 60,000 games match for direct comparison between your code and mine.
Results later in the evening.

[gaard]

How about getting rid of EGTB support to see it goes any better or faster?

EGTB will only effect performance when there are fewer than 6 pieces on the board. Otherwise, it's ignored.

However, dealing with performance is my next planned activity. My compiles are markedly slower than gaard's. I presume that you're using MingW, gaard, or are you running a different setup? I need to take a day to play with different compiler settings and/or change to a different compiler, since we're compiling more or less the same code.

Jeremy

Intel's compiler (11.1) which generally outperforms MS' 2010 by 3-5%. I haven't use MinGW in a long time. IIRC, MS' optimizing compiler, free with Visual Studio Express, is a little faster.

[Jeremy Bernstein]

How about getting rid of EGTB support to see it goes any better or faster?

EGTB will only effect performance when there are fewer than 6 pieces on the board. Otherwise, it's ignored.

However, dealing with performance is my next planned activity. My compiles are markedly slower than gaard's. I presume that you're using MingW, gaard, or are you running a different setup? I need to take a day to play with different compiler settings and/or change to a different compiler, since we're compiling more or less the same code.

Jeremy

Intel's compiler (11.1) which generally outperforms MS' 2010 by 3-5%. I haven't use MinGW in a long time. IIRC, MS' optimizing compiler, free with Visual Studio Express, is a little faster.

Thanks, strange. I wonder why your compiles are so much faster. Turning off most of the optimizations for the Intel compiler, I seem to have found something slightly faster than what I was doing before, but I'm still doing comparisons, and I need to see if PGO makes a difference (it didn't with my previous settings). In any case, any speed hits are definitely not the result of the GTBs -- #ifdefing that code out doesn't have any effect on overall speed, AFAICT. Anyhow, Maybe I'll come up with a winner before the end of the day.