PVS & Embla

[flok]

Ah that I didn't know. Can you advise one by any chance? I'm currently use the dc-3200.bin polyglot book (from http://rebel13.nl/download/books.html).

[flok]

I'm going to fix that right away. Sorry for the inconvenience!

Takes a bit due to heavy merging.

[Rebel]

Furthermore I recommend to avoid using "goto" (you do it in your PVS code)

Not one of your usual best advices Sven

In many cases a programmer outsmarts the compiler and the hardware branch prediction. If you know in advance that in (say) 90% of the cases the branch will be taken or not then why would you leave the decision to the compiler?

I know, can of worms, I know

[Sven]

Furthermore I recommend to avoid using "goto" (you do it in your PVS code)

Not one of your usual best advices Sven

In many cases a programmer outsmarts the compiler and the hardware branch prediction. If you know in advance that in (say) 90% of the cases the branch will be taken or not then why would you leave the decision to the compiler

I know, can of worms, I know

We are talking about the goto in

Code: Select all

if (bSearchPV)
retry:
  score = -search(..., -beta, -alpha, ...);
else {
  score = -search(..., -alpha - 1, -alpha, ...);
  if &#40;score > alpha && score < beta&#41;
    goto retry;
&#125;

vs. the obvious:

Code: Select all

if (bSearchPV) {
  score = -search(..., -beta, -alpha, ...);
} else {
  score = -search(..., -alpha - 1, -alpha, ...);
  if &#40;score > alpha && score < beta&#41; &#123;
    score = -search&#40;..., -beta, -alpha, ...);
  &#125;
&#125;

where you can discuss with me for years but will never convince me that the goto way is any better, it simply confuses my eyes and is the result of pure lazyness only, nothing serious behind it. Also in the context of a ~2000-2200 engine you certainly do not want to discuss about branch prediction.

Code: Select all

end_of_discussion_about_goto:
  goto end_of_discussion_about_goto;

[flok]

https://github.com/flok99/Embla/tree/onecolor

Either there are more changes in that branch than what you planned to do, or your Git repo is not up to date again. So currently I can't see what you actually changed.

Also I can't build it even with most recent Cygwin.

Ok, they're now all up to date and I verified that they build with cygwin on windows 10.

[Sven]

https://github.com/flok99/Embla/tree/onecolor

Either there are more changes in that branch than what you planned to do, or your Git repo is not up to date again. So currently I can't see what you actually changed.

Also I can't build it even with most recent Cygwin.

Ok, they're now all up to date and I verified that they build with cygwin on windows 10.

Thanks, build works out of the box now

I now see that your PVS branch has also removed LMR, and that your most recent branch "onecolor" is under heavy development today. So good luck

[flok]

Correct: I had to figure out how to integrate LMR back in later on. First get PVS stable, then LMR back in.
In my testing (30k games) I also have a branch with both in them. Haven't pushed it to git though.

[Sven]

E.g. in qs there is that BLIND code. It checks if a piece is protected or not. I determine that during movegen.

Depth 14 takes 3.8s without blind and with only 1 color generated and 3.3s with blind and both colors generated. If I replace it by something that checks on the spot, then ttd goes up to 10s.

[...]

I did that in an hour and then it suddenly did depth 31 in a few seconds So clearly this has side effects and haven't figured out what.

I managed to compile all three branches: master, PVS, onecolor. But I could not get any of them to run under cutechess-cli. Maybe some problem at my side.

But apart from that: it is obvious that your generateMoveLists() has (had) side effects on which you rely so that removing them breaks your code. A possible approach would be to identify all those side effects (hopefully few - calculation of square protection perhaps), isolate them in code that can be called separately (obviously for both colors), and then manage to call move generation only for the current side but still getting your "side effects" from the isolated code. Now that sounds easy but in fact it may be difficult ... Nevertheless I think it will pay off, since you need it anyway for creating a captures-only move generator which would require that refactoring.

[Sven]

E.g. in qs there is that BLIND code. It checks if a piece is protected or not. I determine that during movegen.

Depth 14 takes 3.8s without blind and with only 1 color generated and 3.3s with blind and both colors generated. If I replace it by something that checks on the spot, then ttd goes up to 10s.

[...]

I did that in an hour and then it suddenly did depth 31 in a few seconds So clearly this has side effects and haven't figured out what.

I managed to compile all three branches: master, PVS, onecolor. But I could not get any of them to run under cutechess-cli. Maybe some problem at my side.

But apart from that: it is obvious that your generateMoveLists() has (had) side effects on which you rely so that removing them breaks your code. A possible approach would be to identify all those side effects (hopefully few - calculation of square protection perhaps), isolate them in code that can be called separately (obviously for both colors), and then manage to call move generation only for the current side but still getting your "side effects" from the isolated code. Now that sounds easy but in fact it may be difficult ... Nevertheless I think it will pay off, since you need it anyway for creating a captures-only move generator which would require that refactoring.

Problem of not running under cutechess-cli was solved easily (cygwin DLLs had to be copied to the right folder ...). Now I run some tests. As expected, the "onecolor" version makes illegal moves so I took it out.

Jumbo seems too strong for Embla, I even tried an old 0.4.14 version which is roughly 200 Elo points weaker than my current best version. So I'll match Embla versions against each other only.

[flok]

Problem of not running under cutechess-cli was solved easily (cygwin DLLs had to be copied to the right folder ...). Now I run some tests. As expected, the "onecolor" version makes illegal moves so I took it out.

Jumbo seems too strong for Embla, I even tried an old 0.4.14 version which is roughly 200 Elo points weaker than my current best version. So I'll match Embla versions against each other only.

I usually let it battle against dorpsgek which is around 220 elo stronger.

What do you do for tournament? Gauntlet?