Looking for advices

[xr_a_y]

Thank you all for the help. I've just started a tournament between different configurations to track down the potential issues. I'll post the code on github as soon as i'm not to ashamed of it

It seems there is something wrong in my pvs when applied at none root node.

Best regards

[xr_a_y]

I'm back !

after a disappointing Winter and a bottom place in March tournament, my engine "Weini" is now able to defeat fairymax quite well : 60-30-22 in a 12sec/40moves tournament (this is around +100elo).

But it takes LMR, SMP (4 threads), pondering and some bug fix of course as you have all advised me last year...

There is still two issues I don't understand well :
*why LMR at root is not good (at all: -75elo)
*why using TT at root is not good (at all: -60elo)

Another thing I don't get well (and it makes my engine slow) is the cost of "IsInCheck" function during threats detection. I know many engines pre-compute pinned pieces once and for all for a position but I found it's even slower in mine.

Still, thank you all for your advices, I now test everything with cutechess tournament.

Best regards

[Daniel Anulliero]

Huh. No question about how to compute backpropagation step in a deep convolutional network ? No Monte Carlo Simulation ? Just going on in old fashioned way.

Or was Alpha zero just some kind of Aprils fool joke. Then they fooled me.

It is far better to Hear some EXPERTS advices and write an old fashion engine for the begenning
We all saw Weini played at hgm's tournament , it is young but sure it can kill Skipper

So vI viens , good work anyway

[Henk]

Play a game against your own engine and against LCZero. Which one did you like best ?

[xr_a_y]

Here is some more details :

Code: Select all

Rank Name                          Elo     +/-   Games   Score   Draws
   1 fruit_21                      752     105     500   98.7%    2.6%
   2 weini4                        -18      24     500   47.4%   38.0%
   3 weini3                        -38      24     500   44.5%   38.2%
   4 weini2                        -62      24     500   41.2%   37.2%
   5 fairymax                     -101      27     500   35.8%   24.0%
   6 weini1                       -128      26     500   32.4%   31.6%

still with ponder ON and LMR active and weiniX X being the number of threadq.

[hgm]

Testing against Fruit makes little sense at this stage. Better use some engines around 2200 Elo as the next milestone.

Note that Fairy-Max is single core, and does not ponder. With a bug-free search and a reasonable evaluation a single-core engine should be able to convingly beat it.

[xr_a_y]

Yes there must be some other issue. But fairymax (1.2Mnps) is also nearly twice as fast as Weini (700Knps) on my hardware, so pondering just equilize in fact I think.

[hgm]

Well, part of the reason it is so fast is that it counts nodes in an unusual way, namely inside its IID loop. And even in a QS node it goes through that loop twice, first to find the 'best' MVV/LVA move, and then to actually search the captures starting with that best move. Correcting for that would bring the speed down to below 600Knps.

The other reason is that it is fast is that it has no evaluation (other than what it does incrementally, and which thus doesn't take measurable time). And it is a bit unfair to count the slowdown you get from spending time on evaluation as a speed disadvantage. It would mean the evaluation doesn't even make up in strength for the time it uses, and is thus more a waste of time than anything else.

[xr_a_y]

ok, I get your point but surprisingly, when I profile Weini, the evaluation is not that much the bottleneck. Movegenerator and threat detection is taking a lot of time (together with filling and sorting moves).

Code: Select all

  14,54%  weini                         [.] EvalOptimDriver
  13,83%  weini                         [.] GeneratorHelperCacheSquareNoStat
   7,99%  weini                         [.] GetThreadsHelperFast
   5,90%  weini                         [.] SortMovesFunctor
   5,55%  weini                         [.] Negamax
   5,19%  weini                         [.] NegaQuiesce(
   5,18%  weini                         [.] Run
   3,33%  libc-2.19.so                  [.] malloc
   2,80%  libc-2.19.so                  [.] _int_free
   2,51%  weini                         [.] Generator
   2,43%  weini                         &#91;.&#93; vector<>&#58;&#58;emplace_back<Move>
   2,40%  weini                         &#91;.&#93; ValidatePawn
   2,19%  weini                         &#91;.&#93; SetPiece
   2,09%  weini                         &#91;.&#93; ValidateIsCheck
   2,02%  weini                         &#91;.&#93; ValidateCheckStatus
   2,00%  weini                         &#91;.&#93; GetTTQ

My code for move generatiion (pseudo legal move) is quite classic. What seems to take time is to validate move is not illegal (puts own king in check) during search (GetThreadsHelperFast). For moves management, I've tried using a memorypool or a fixed size container, but I found nothing faster than vector or dequeue.

Still looking for improvement here. I suspect the code is globally to complex and not flat enough.

[hgm]

You might wonder whether it pays at all to check if moves are legal. Fairy-Max doesn't do that at all. Most moves are legal, and on those the check will be a waste of time. On the occasional illegal move, the reply node will find it can capture the King, and simply return a +INF score for that.

When you are in check, you know beforehand that most moves will leave you in check, and then it might pay to explicitly test them for resolving the check, before recursing. But better yet would be to selectively generate moves that resolve the existing check.