Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Summary of the Rybka EGTB mp bug
1 2 Previous Next  
- - By bnc (***) Date 2008-08-14 13:33
      Summary of the Rybka EGTB mp bug
      --------------------------------------------------

1. The bug consists of inaccurate evaluations, seemingly ignoring some EGTB positions
2. It exists in Rybka 3 mp and Rybka 2.3.2a mp during the search of endgame positions with access to EGTB's
3. It does not affect Rybka sp or Rybka mp with maxCPUs set to 1
4. In the examples listed below, there always seems to be an exchange of material  in the search or
    an exchange of material   in what should be a clear winning or drawn variation, leading to an EGTB position.
5. Changing the Nalimov usage parameter to "frequently" or "normally" did not help
6. Workarounds :
   a. Use maxCPUs=1
   b. Don't use EGTB's
   c. Use another engine. I ran an endgame tournament months ago that was won by Zappa Mexico. 
      http://www.talkchess.com/forum/viewtopic.php?t=20906&highlight=

Quote from Vas ....

"Ok, it seems that there is some sort of sporadic bug in the interaction between the tablebase probing, hash table and multi-processor implementation. In some cases, a normal Rybka eval + search seems to be used instead. I'll dig into it when I have a chance."
  http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=85730

My system is a quad QX6700, Vista Ultimate x64, 4g Ram, Nalimov Usage rarely, 1gb hash

            Example 1

8/8/4rk2/3R4/5P2/1K2P3/8/8 w - -


With 5 man EGTB's ...

Rybka 3 bad analysis :

  1.Re5 Ra6 2.e4 Ra1 3.Rf5+ Ke6 4.Kc4 Ra4+ 5.Kd3 Ra3+ 6.Ke2 Ra4 7.Kf3 Ra1 8.Rc5
    +-  (2.61)   Depth: 22   00:00:17  3033kN, tb=5269
  1.Re5 Rc6 2.e4 Rc1
    +-  (2.61)   Depth: 23   00:00:22  4051kN, tb=7855

Re5 throws away the win since 1. Re5 Rxe5 2. fxe5+ Kxe5 is a simple draw

Rybka 3 with maxCPUs set to 1 :

   1.Rd3 Kf5 2.Kc4 Re4+ 3.Kc3 Kg4 4.Kd2 Kf3 5.f5 Re5 6.f6 Rf5 7.Rd6 Ke4 8.Re6+ Kd5 9.Ra6 Ke4 10.Rb6 Rf2+
     +-  (1.84)   Depth: 22   00:00:42  2825kN, tb=20208
   1.Rd3 Kf5 2.Kc4 Re4+ 3.Kc3 Kg4 4.Kd2 Kf3 5.f5 Re5 6.f6 Rf5 7.Rd6 Ke4 8.Re6+ Kd5 9.Ra6 Ke4 10.Rb6 Rf2+
     +-  (1.84)   Depth: 23   00:00:53  3619kN, tb=29236

            Example 2

8/6P1/4k3/4p3/R7/4KP2/6r1/8 w - -


With 6 man EGTB's including KRp v KRp ...

Rybka 3 bad analysis :

  1.Rg4 Rxg4 2.fxg4 Kf7 3.Ke4 Kxg7 4.Kxe5 Kg6 5.Kf4 Kf6 6.g5+ Kg7 7.Kf5 Kf7 8.Kg4 Kg6
    +-  (2.93)   Depth: 30   00:00:31  3185kN, tb=3007
  1.Rg4 Rxg4 2.fxg4 Kf7 3.Ke4 Kxg7 4.Kxe5 Kg6 5.Kf4 Kf6 6.g5+ Kg7 7.Kf5 Kf7 8.Kg4 Kg6
    +-  (2.93)   Depth: 31   00:00:42  4436kN, tb=4428

Rg4 leads to a draw after 1.Rg4 Rxg4 2.fxg4 Kf7

Rybka 3 with maxCPUs set to 1 :

1.Ke4 Re2+ 2.Kd3 Rg2 3.Ra6+ Kf5 4.Ra7 Kf6
  =  (0.00)   Depth: 25   00:00:45  5564kN, tb=15794
1.Ke4 Re2+ 2.Kd3 Rg2 3.Ra6+ Kf5 4.Ra7 Kf6
  =  (0.00)   Depth: 26   00:00:55  6731kN, tb=21230

            Example 3

8/r4k1p/8/4PK2/8/3R3P/8/8 w - -


With 6 man EGTB's ...

Rybka 3 bad analysis :
 
  1.Rd7+ Rxd7 2.e6+ Ke8 3.exd7+ Kxd7 4.Kf6 Ke8 5.Kg7 h5 6.h4 Ke7 7.Kg6 Kf8 8.Kxh5 Kg7 9.Kg5 Kh7 10.h5 Kg7 11.Kg4 Kh6 12.Kh4 Kh7 13.Kg3 Kg7 14.Kf3 Kh6 15.Kg4 Kh7 16.Kh3
    +-  (2.68)   Depth: 28   00:00:19  1295kN, tb=811
  1.Rd7+ Rxd7 2.e6+ Ke8 3.exd7+ Kxd7 4.Kf6 Ke8 5.Kg7 h5 6.h4 Ke7 7.Kg6 Kf8 8.Kxh5 Kg7 9.Kg5 Kh7 10.h5 Kg7 11.Kg4 Kh6 12.Kh4 Kh7 13.Kg3 Kg7 14.Kf3 Kh6 15.Kg4 Kh7 16.Kh3
    +-  (2.68)   Depth: 29   00:00:19  1295kN, tb=811

After 1.Rd7+ Rxd7 2.e6+ Ke8 3.exd7+ Kxd7 is a dead draw

Rybka 3 with maxCPUs set to 1 :

  1.Rd8 Kg7 2.h4 h5 3.Rb8 Rc7 4.Rb6 Rc3 5.Rb7+ Kh6 6.e6 Rf3+ 7.Ke4 Rf2 8.Rb8 Re2+ 9.Kf5 Kg7 10.Rb7+ Kh6 11.Kf6
    +-  (2.07)   Depth: 19   00:00:15  1102kN, tb=6428
  1.Rd8 Kg7 2.h4 h5 3.Rb8 Rc7 4.Rb6 Rc3 5.Rb7+ Kh6 6.e6 Rf3+ 7.Ke4 Rf2 8.Rb8 Re2+ 9.Kf5 Kg7 10.Rd8 Re3 11.Rc8 Re1 12.Rc7+ Kf8 13.Kf6
    +-  (2.07)   Depth: 20   00:00:20  1409kN, tb=9371

            Example 4

8/8/8/1P6/8/P6r/1KPQ2p1/7k w - -


With 6 man EGTB's including KR v Kppp

Rybka 3 bad analysis :

  1.Qd7 Kh2 2.Qd6+ Kh1 3.Qd5 Kh2 4.Qe5+ Kh1 5.Qe4 Kh2 6.Qe2 Kh1 7.Qg4 Kh2
    +-  (4.44)   Depth: 18   00:00:20  6828kN, tb=213
  1.Qd7
    +-  (4.64)   Depth: 19   00:00:22  7171kN, tb=265

Qd7 may still lead to a win but after Qc1+ or Qd1+ or Qe1+ white can let the black pawn promote and then exchange queens with a tablebase win.

Rybka 3 with maxCPUs set to 1 :

  1.Qe1+
    +-  (#48)   Depth: 17   00:00:28  6666kN, tb=425
  1.Qe1+
    +-  (#48)   Depth: 18   00:00:38  9215kN, tb=706
Parent - - By Roland Rösler (****) Date 2008-08-14 15:00
1. The bug consists of inaccurate evaluations, seemingly ignoring some EGTB positions

You can see it in your analysis. Single core has much more tbs hits than mp version in the same time (+-  (2.61)   Depth: 23   00:00:22  4051kN, tb=7855).

6. Workarounds :
   a. Use maxCPUs=1
   b. Don't use EGTB's


My Workaround:
   a. Use maxCPUs=2048
   b. Use only 3-4 EGTB's

Remarks: If you don´t use EGTB´s, Rybka 3 plays all the bad moves like Re5, Rg4, Rd7 in example 1-3. I tested your examples and all was fine with my workaround; no bad moves :-). Okay, in example 4 she don´t find Qe1 (only Qd5 with +5).
Parent - - By bnc (***) Date 2008-08-14 15:26

> 6. Workarounds :
> a. Use maxCPUs=1
> b. Don't use EGTB's

>
> My Workaround:
>  a. Use maxCPUs=2048
>  b. Use only 3-4 EGTB's
>


Those suggestions were made "tongue in cheek" . As someone who has a quad core and 160gb of 6 man EGTB's, I will not use workaround a) or b) or those you suggested .   :) :)
Parent - By Arkansaw (***) Date 2008-08-14 15:30
Zappa II Mexico, Deep Sjeng, Hiarcs are not too bad for endgames
Parent - By gorlor (*) Date 2008-08-14 16:06
Thanks to those posting in this thread - I was keen to read a summary of this issue.

If I've understood correctly, I now intend to run R3 MP using all 4 cores but only using 3&4 man EGTBs.  This should give reliable analysis (in terms of avoiding issues), but obviously compromises the EGTBs available to R3.  I'm guessing the increased reliability outweighs the small drop in strength due to less EGTBs.
Parent - By Roland Rösler (****) Date 2008-08-14 16:10
Okay, you have the choice. :-)

Select 50 endgame positions and then make 100 game matches with
R3 x64 4CPU 3-4 tbs vs. Zappa x64 4CPU 3-4-5-6 tbs or
R3 x64 4CPU 3-4 tbs vs. R3 x64 4CPU 3-4-5-6 tbs
to see who is best.

My bet is on R3 with 3-4 tbs! :-)
Parent - - By Arkansaw (***) Date 2008-08-14 15:29
What's good with 6-men base when you can't use mp version with it?
What's good with mp version when you can't use 6 men base with it?
Parent - By KWRegan (*) Date 2008-08-14 16:02

>What's good with 6-men base when you can't use mp version with it?
>What's good with mp version when you can't use 6 men base with it?


Is the mechanism of this bug known yet?  Has it been properly distinguished from hash-table collisions, for instance?  I'll try to reproduce it this evening.

On top of the lack of wrong-color-RP and other previously-included endgame knowledge, plus some bugs with persistent hash which I'm not sure can be averted for analysis, this is very disappointing for my intent to gear up with Rybka 3 + persistent hash + 6-piece EGTs and finally finish my huge Kramnik-Grischuk analysis.
Parent - - By Ernst (***) Date 2008-08-14 20:46
Your "workaround" about 3-4 EGTB's is not correct.

> My Workaround:
>    a. Use maxCPUs=2048
>    b. Use only 3-4 EGTB's

Parent - - By Roland Rösler (****) Date 2008-08-14 21:50
Some explanation, please! :-)

Show me the example, where 3-4 EGTB´s on 2-4-8-16 cores failed like Rybka with no EGTB´s.
Parent - - By Ernst (***) Date 2008-08-14 22:13 Edited 2008-08-14 22:19
Did you try it with the positions shown by the topic starter? I did and it didn't "solve" the problem. The nature of the problem isn't solved by using only 3-4 piece Nalimov.
But then again I know you like to provoke. http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=79350
Parent - By Roland Rösler (****) Date 2008-08-14 23:55
Provoking is fine but not here; it´s a sincere problem!
I wrote it in a post above. I tested all 4 positions with 3-4 EGTB on my 2CPU notebook more than 10 minutes. And all was fine. Tb count in analysis was also fine (in comparison to sp version). One or two days ago I think I have to write down here the problem of the EGTB bug in Rybka. But I was to lazy. And then bnc does it in a very good way. When I looked to his analysis, I see immediately the problem. Sp version has much more tb hits than mp version. This is decisive (please have a look to the origin post of bnc and his engine analysis)! When I recognized it, I was sure. After more than an hour of own testing with 3-4 EGTB´s I had the proof (for me!). Vas mentioned it in a post. With 5 or 6 EGTB´s Rybka mp plays after some time without tbs. But I was sure, with 3-4 EGTB´s this can´t happen. And most basic for Rybka mp; she can´t play without 3-4 EGTB´s.
So, my configuration is very poor. I wish, that anyone with 8 core machines test my hypothesis. He/she can test it on the four positions (here I´m sure), then he can make own positions and very last he has to make matches to see the significance! My favourite tester would be Kullberg. Rybka 3 mp in tournament configuration (with 3-4-5-6 EGTB on 64 (128?) GB fastest SSD drives (0.1 ms access time) vs 3-4 EGTB on hard drive (~ 200 games).
If 3-4 EGTB configuration wins, I´m right. If not I´m asking for a match with no EGTB vs 3-4 EGTB. If here isn´t a gap from more than 30 Elo, I lost totally. But I can´t imagine. :-)
Parent - - By Mark Young (*) Date 2008-08-14 16:34
This bug is there in every gui but one.

When I played the position (5 man position)  in Aquarium the bug was gone. Rybka 3 played the correct move.

Mark Y.
Parent - - By Zruty (*****) Date 2008-08-14 17:06
Wow :)

So, there is some another workaround present :)

Of course, this needs further investigation since Aquarium doesn't do any magic tricks to Rybka.
Parent - - By Vempele (Silver) Date 2008-08-14 17:09

>Of course, this needs further investigation since Aquarium doesn't do any magic tricks to Rybka.


With the exception of sampled search. :)
Parent - - By Zruty (*****) Date 2008-08-14 19:25
That's right. I'm not very good at chess engine writing, so I wonder whether sampled search can affect the MP EGTB access issue?..
Parent - By Vempele (Silver) Date 2008-08-14 19:29
It shouldn't (and I can't imagine how it could). But then again, it shouldn't change the tree, either. :)
Parent - By Kapaun (****) Date 2008-08-14 17:16
Aquarium maybe not - but IDeA at times does... ;-)
Parent - - By Roland Rösler (****) Date 2008-08-14 17:22
I´m sure Aquarium will solve the blind bishop problem too. :-)
Parent - - By Kapaun (****) Date 2008-08-14 17:34
Hm.... Maybe they could do something with the hash bug? :-)
Parent - - By Roland Rösler (****) Date 2008-08-14 18:07
No problem! Aquarium solves every problem you have. :-)
Make a list and send it to Zruty.
Parent - By Zruty (*****) Date 2008-08-14 19:24
Yes, but send the list by regular mail. And put something in the envelope for me to smile at.
Euros for preference, in our unstable world :)
Parent - By sylvain.renard.27 (**) Date 2008-08-14 19:26

> This bug is there in every gui but one.
>
> When I played the position (5 man position)  in Aquarium the bug was gone. Rybka 3 played the correct move.
>
> Mark Y.


Hello Mark,
I  observed the same things.
When using many 6 men TB's, infinite analysis does not start (Aquarium bug) but if you stop (after TB initialization) and run analysis again, MP analysis with Tablebases is correct
  Best regards,
     Sylvain
Parent - - By Maitra (**) Date 2008-08-14 19:08
In addition to this endgame bug, we shouldn't forget the blind bishop endgame knowledge which is completely missing from Rybka 3
Parent - - By M ANSARI (*****) Date 2008-08-15 07:36 Edited 2008-08-15 07:53
You know ... I have tried very hard to see what is behind this issue and if there is a work around.  It is obviously a problem between MP Rybka (and I mean all Rybkas ... not only R3 MP) and how EGTB information is accessed.  I am actually quite surprised that we did not identify this issue as an MP EGTB bug for Rybka since this seems to have been a problem since initial Rybka MP.  This problem does not exist in any of the Rybka's on single core.  That is why I think the problem is much more complex than we think and will not be so easy to fix ... and probably will take a long time.  It could be some obscure way that the Nalimov EGTB's work that R3 MP has a problem with ... so if you think that this is a simple bug that can be fixed in a day or so I think you are mistaken.  That is the bad news ... the good news though is that R3 will probably be quite a bit stronger once this is sorted out ... especially against the stronger engines where they don't get crushed in the opening or middle game and thus Rybka goes into the endgame with a big + that has to be nursed to get the win.  I believe in a match against the top engines ... R3 MP could probably gain around 20 ELO against the top engines ... against the weaker engines ... the gain would probably be minimal.  For now the only workaround I can think of is to have around 300 GB of EGTB's ... that in my case seems to solve the problem for 90% of the cases ... or ofcourse if you are using analysis of a position ... then it would be a good idea to do a quick check with Rybka 3 1-cpu when you feel such a position has come about (R3 SP is maybe 60 or 70 ELO weaker than R3 MP but still much stronger than all other engines).  I know it is not an elegant solution ... but until Vas figures out this bug I think that is the best way to proceed.

By the way ... in these type of positions ... say if you have 4 cores or more ... where Rybka sticks to its famous "+5.09" non changing evaluation ... this would be a situation where one core could be sacrificed to do a quick Monte Carlo analysis of the position.  I would put the trigger to run 1 core of analysis when the evaluation seems to be "stuck" at say depth of 20 or 30 ... this would immediately solve all these problems because 1 core already deals with these situations well ... and Monte Carlo on 1 core would immediately choose the correct path very quickly.  I think an even more sophisticated way would be to somehow incorporate 7 piece bitbases (they have a relatively small footprint) along with Monte Carlo ... this would create by far the strongest endgame playing engine on earth.  Some ideas for R4 maybe :)
Parent - By Arkansaw (***) Date 2008-08-15 07:45
I think the problem is due to preoccupation with the 'huge' elo gains, so there's a tendency to gloss over things that only contribute to 1 or 2 elo.
Parent - - By Maitra (**) Date 2008-08-15 08:17
Hi Ansari-Ok, so you are saying that this is a problem with only MP Rybka and not Rybka 3-1 cpu. In that case I give here two sample positions where issues exist with blind bishop endgame knowledge. I've not analysed these positions with Rybka 3 sp so, can you please post your analysis with R3 sp. These posiitons are a complete draw and other engines easily see it but not Rybka 3.

8/8/p1b5/5k2/8/2K5/P5P1/8 w - - 0 44


8/6k1/8/4K3/7P/1B6/7P/8 b - - 0 56


However, if you analyse these positions with Rybka 2.1 mp , it sees the draw in both these positions easily(as does any other engine for that matter) So then how can this be an issue with only MP Rybka can you please explain. Its quite surprising and I hope you will too agree that a 3200 elo engine doesn't know this basic knowledge which even a 1600 elo player has.Apart from these positions what about QK(White) Vs KP(Black) endgames where on certain positions its a draw depending upon the placement of the queening pawn like on f2,g2,h2 etc?
Parent - - By M ANSARI (*****) Date 2008-08-15 08:47 Edited 2008-08-15 08:58
First of all ... please install 5 piece EGTB's.  If you want an engine to be able to solve positions without EGTB's ... I can understand that ... but you would be talking about a totally different thing.  As I have mentioned before, the 5 piece EGTB's are available for free download and use up about 7 GB of space ... in a day where the smallest capacity HDD is 320 GB, 7 GB seems like a tiny amount to sacrifice.  If you don't have that spare capacity ... then for $23 you can buy an 8GB USB drive and install it there.  Now if you don't want to do either ... then stick to an older version that has this knowledge.  Knowledge in an engine will slow it down ... and thus make it play weaker in general.  Vas has made it clear that his priorities are to make the most gain possible in ELO strength in his engine ... and that is why is has removed some knowledge where he thinks 5 piece EGTB's cover it.  You may not agree with that philosophy ... but frankly it is up to the engine author to decide what is best.  Now back to the subject ... in first position ... although R3 SP does not give a 0.00 evaluation ... it will play moves that draw and will get the draw.  It "knows" that it can play a4 or g4 and that the loss of the pawn is an immediate EGTB draw ... something that R3 MP does not "know" or cannot see.  That is the problem.  Now in position 2 ... it is a simple 5 piece EGTB that even the MP version "sees".

By the way ... you mentioned that R 2.1mp does not have a problem with position 1 ... I tried it on 2.1d3 (I don't have the 2.1 only) and this is its output.  So obviously this also existed with the 2.1 version

New game, Blitz:4'+2"
8/8/p1b5/5k2/8/2K5/P5P1/8 w - - 0 1


Analysis by Rybka 2.1d3 mp:

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1
  =  (0.00)   Depth: 2   00:00:00
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1
  =  (0.00)   Depth: 3   00:00:00
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1
  =  (0.00)   Depth: 4   00:00:00
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1
  =  (0.00)   Depth: 5   00:00:00
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2
  =  (0.00)   Depth: 6   00:00:00  0kN
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2
  =  (0.00)   Depth: 10   00:00:00  7kN
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2
  =  (0.00)   Depth: 10   00:00:00  7kN
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2
  =  (0.00)   Depth: 10   00:00:00  7kN
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1
  =  (0.00)   Depth: 10   00:00:00  22kN
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4
  =  (0.00)   Depth: 11   00:00:00  43kN
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4 5.Ka2 Kf3
  =  (0.00)   Depth: 13   00:00:00  113kN
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4 5.Ka2 Kf3
  =  (0.00)   Depth: 13   00:00:00  113kN
1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4 5.Ka2 Kf3 6.Ka1
  =  (0.00)   Depth: 14   00:00:00  191kN
1.Kb2 Bxg2 2.Kb1 Ke4 3.Kc2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3
  =  (-0.13)   Depth: 15   00:00:00  447kN
1.Kb2 Bxg2 2.Kc3 Ke4 3.Kc4 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+
  =  (-0.16)   Depth: 16   00:00:00  1182kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+
  =  (-0.16)   Depth: 17   00:00:01  1656kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+
  =  (-0.16)   Depth: 18   00:00:01  2073kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+
  =  (-0.16)   Depth: 19   00:00:02  2758kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+
  =  (-0.16)   Depth: 20   00:00:02  3434kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+
  =  (-0.16)   Depth: 21   00:00:02  4256kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2
  =  (-0.16)   Depth: 22   00:00:03  5255kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2
  =  (-0.16)   Depth: 23   00:00:05  7714kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2
  =  (-0.16)   Depth: 24   00:00:06  9874kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2
  =  (-0.16)   Depth: 25   00:00:07  11930kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2
  =  (-0.16)   Depth: 26   00:00:09  15521kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2
  =  (-0.16)   Depth: 27   00:00:12  19437kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2
  =  (-0.16)   Depth: 28   00:00:16  28035kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2
  =  (-0.16)   Depth: 29   00:00:29  49683kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.a4 Kf3 4.a5 Ke3 5.Kc2 Bc6 6.Kb2 Be4 7.Ka2 Kd4
  =  (-0.16)   Depth: 30   00:00:36  62212kN
1.Kb2 Bxg2 2.Kc3 Kf4 3.a4 Kf3 4.a5 Ke3 5.Kc2 Bc6 6.Kb2 Be4 7.Ka2 Kd4
  =  (-0.16)   Depth: 31   00:00:43  76169kN
1.Kb2 Bxg2 2.Kc3 Ke4 3.a4 Kd5 4.Kb4 Kd4 5.Ka5 Bb7 6.Kb4 Bd5 7.Ka5 Bc4
  -+  (-3.59)   Depth: 32   00:00:59  104mN

(,  15.08.2008)
Parent - - By Maitra (**) Date 2008-08-15 10:08
Well Ansari- Even your Rybka 2.1 d3 mp displays a draw eval doesn't it? Its only at depth 32 that it displays a negative eval of -3.59(dont know from where that comes!).
1.Kb2 Bxg2 2.Kc3 Ke4 3.a4 Kd5 4.Kb4 Kd4 5.Ka5 Bb7 6.Kb4 Bd5 7.Ka5 Bc4
  -+  (-3.59)   Depth: 32   00:00:59  104mN

8/8/p1b5/5k2/8/2K5/P5P1/8 w - - 0 1


Well here's the analysis by Rybka 2.1c mp running in infinite analysis mode at depth=41. It still is able to see the draw here.

Analysis by Rybka 2.1c mp 32-bit:

1. =  (0.00): 1.Kb2 Bxg2 2.a4 a5 3.Ka1 Bd5 4.Kb2 Bf3 5.Ka1 Bd5 6.Kb2 Bf3 7.Ka1 Bd5
2. =  (0.00): 1.g4+ Kxg4 2.Kb2 a5 3.a4 Bxa4 4.Ka1 Bd1 5.Kb2 Bf3 6.Ka1 Bd5 7.Kb2 Bf3
3. =  (0.00): 1.g3 Bd5 2.Kb2 a5 3.a4 Bf3 4.Kb1 Bd5 5.Ka1 Bf3 6.Kb2 Bd5 7.Ka1 Bf3

( Personal 15.08.2008)
So in this case I dont think this existed in the Rybka 2.1c mp vesion at least.Please correct me if I'm wrong.
Parent - By M ANSARI (*****) Date 2008-08-15 11:20
Try it withought MPV output and clear hash first.  It could be that d3 is differnt that c ... but I don't think so.
Parent - - By Wayne Lowrance (***) Date 2008-08-16 16:31
Howdy, I would like to add my two cents worth on these positions. I have a 8 core @ 2.8 ghz, 4 gig ram, hash set to 1024, 3,4,5 tb's, Fritz8 GUI. I get the following result:

#1)   Rd3, 2.18 instant, I stopped at depth 33.

#2)   Ke4 .33 instant, I stopped at depth 31

#3)   Rd8 2.20 @ depth 23 switches Rd6 3.50 @ depth 23 I stopped @ depth 28.

#4)   Qd5 +5.36 @ depth 16 I stopped it there. I dont know if it is gonna find the mate with my tb's but I did not have the patience to find out.

It seems as though my 8 core comp with 3,4,5 tb's gave appropriate answers. What You think ?
Wayne
Parent - - By BigBen (****) Date 2008-08-16 19:38
Hi wayne, the point is that Zappa Mexico, Fritz 11 in position 4 finds the mate in 47 almost at once ...

Analysis by Zappa Mexico II:

1.Qe1+ g1Q 2.Qxg1+ Kxg1
+-  (#47)    Depth: 19/55   00:00:12  96107kN, tb=8429

New game
8/8/8/1P6/8/P6r/1KPQ2p1/7k w - - 0 1


Analysis by Fritz 11:

1.Qe1+ g1Q 2.Qxg1+ Kxg1
+-  (#47)    Depth: 18/33   00:00:05  23320kN, tb=6667

I did notice that at least Rybka 3 Human is looking at the correct move

New game
8/8/8/1P6/8/P6r/1KPQ2p1/7k w - - 0 1


Analysis by Rybka 3 Human:

1.Qe1+ g1Q
+-  (6.72)    Depth: 12   00:00:17  15048kN, tb=17

Regards
Parent - By M ANSARI (*****) Date 2008-08-16 20:00
Yes that is exactly the point.  With brute force ... given enough time Rybka 3 MP will eventually figure it out ... but why should brute force be used when EGTB's have the solution in milli seconds ... and which R3 MP sees immediately one move later.  Obviously there is a problem with communication between EGTB's and the MP generated hash ... I would tend to think that there might be more situations where we do not see where R3 MP will play a non optimal move because of this lack of communication.   Again I think that it makes a lot of difference against engines who are already very strong ... such as R2.3.2a (even though it suffers from similar bug), Zappa II, Hiarcs, D Shredder and D Fritz.  I would tend to think that this bug is not so critical against weaker opponents since they are lost in the early part of the game.
Parent - - By Wayne Lowrance (***) Date 2008-08-16 20:20
I guess the point I was trying to convey, was R3 found the correct move for the first three position in 8 processor mode instantly.  So it seems to me not as bad TB probelm that is being discussed.
The post topic as I unsterstood was that only  R3 one cpu only solved the three positions. I am just pointing out that is not my experience.
Wayne
Parent - - By Roland Rösler (****) Date 2008-08-16 23:44
He Wayne, you are the first, who claimed there is no bug at all with EGTB (5-6 man). Please show us your analyse lines (like bnc) for each position. I want to see your tbs hits. And please check your engine parameter (all standard?) and your EGTB (all 5 man; 7.1 GB?). If you can´t reproduce the EGTB fault, we have a very big problem. Then we know nothing! At last you should try it with 4 and/or 2 cores.
But first, give us the complete analysis!

PS: I can´t imagine, that you are right!
Parent - By Wayne Lowrance (***) Date 2008-08-17 00:02
Okey Dokey, hang on will take a bit to load the position
Wayne
Parent - - By Wayne Lowrance (***) Date 2008-08-17 01:14
Hi Roland you mention that I am using 5-6 man tb's. I said I was using 3,4,5 man tb's. Do you want my engine outputs still. ?
I will be most happy to provide Roland.
Wayne
Parent - By Roland Rösler (****) Date 2008-08-17 01:21
For me, there is no difference in 5 man vs 6 man EGTB in Rybka mp, considering the EGTB bug.
Your engine outputs are welcome! :-)
Parent - - By Wayne Lowrance (***) Date 2008-08-17 01:40
Depth 10, tb=1         1.Rd3,Kf5 2.Kc4, Rc6+ 3.Kb5,Re6 4.Kc5
+/- 1.41 Depth 10, 00:00:00 8kN tb=1

Depth 29, tb= 26653    1.Rd3,Kf5 2.Kc4,Re4+ 3.Kc3,Kg4 4.Kd2,Kf3 5.f5,Re5 6.f6,Rf5 7. Rd6, Ke4 8.Re6+,Kd5 9.Rb6,Ke5 10.Kd3,Rf1 11.Ra6,Rf3
+/- 1.87 Depth 29, 00:01:36 32142kN tb=26653

This is position #1 I took time to eat my dinner :) does this help ? Do you wish to see the other engine outputs.
Wayne
Parent - By Wayne Lowrance (***) Date 2008-08-17 01:55
For info, My Fritz benchmark for this comp is: 8 processor, Relative speed= 127.25.. Kilo nodes per second= 13078.
Just thought I would throw that in
Wayne
Parent - - By M ANSARI (*****) Date 2008-08-17 07:02
Well ... it could be possible that an 8 core would have less of a chance of hitting this bug ... simply because with 8 core you have 2x as many cores as a Quad ... and 4x as many cores as a Dual ... so the non determenistic nature of MP implementation would mean that you would have less chance of hitting the bug.  But the bug is there ... and I have seen it on my Octa system.  I have my Octa's now doing a LTC tourney but I might give it a shot today ... or maybe you could do the output of say 30 seconds per position and then clip analysis.  Also do you have any 6 piece EGTB's loaded?
Parent - By Wayne Lowrance (***) Date 2008-08-17 14:38
No I do not
Thank you
Wayne
Parent - By sharpnova (***) Date 2008-08-16 19:25
well why would he install 5 man EGTB? they don't work.

the blind bishop problem might not even matter or it would matter far less if 5 mans were working.
Parent - - By Ernst (***) Date 2008-08-15 09:46

> ... the good news though is that R3 will probably be quite a bit stronger once this is sorted out ...


It is a pity indeed that we didn't detect it earlier. However, when I did, I felt that I had to post it so i could be discussed and I feel that Rybka would definitely benefit when this is sorted out. I want to see a Rybka which I can trust troughout the game, especially when analyzing.
Parent - - By M ANSARI (*****) Date 2008-08-15 11:17
I definetely did detect it and informed Vas ... at the time I was not sure what the bug was ... if it was a bug ... if it was somehow related to the still very beta GUI or that somehow in the beta version the EGTB's were still not working or did not have the code activated yet.  It is very hard if not impossible to quickly figure where the problem was.  I think it was only once I messaged LK that he pointed out that this could be a problem with only the MP version ... and sure enough that turned out to be correct.  I had never thought of testing the SP version in those positions and automatically assumed that the MP version was simply an MP version that would do more calculations of the SP version.  The thing is that this does not seem to be a R3 bug ... but rather a bug in MP implementation of EGTB's that was carried over from previous MP versions.
Parent - By cma6 (****) Date 2008-08-16 14:12
Can we conclude that in Rybka mp we should use "Never" for tablebase access until the problem is fixed?
Parent - - By Vasik Rajlich (Silver) Date 2008-08-15 19:03
Thanks for the summary. I haven't had a chance to dig through the code for this yet but will do so soon.

In the meantime we'll add this to the FAQ.

Vas
Parent - - By Roland Rösler (****) Date 2008-08-16 02:43
He Vas, there is no hurry! But it would be fine, if you can say us in a month or two, what we can do to minimize the effect (a workaround).
In the meantime, we should have own results from testing about the bigness of the effect. But the endgame analyzers are really shocked and unsettled now! We all guess, something is wrong here, but nobody saw the bug.

PS: It´s fine, that we speak about endgames, when we speak about Rybka! :-)
Parent - By BigBen (****) Date 2008-08-16 09:41
Hi,
    I tend to run into this problem daily with Rybka seemingly with a big plus just to swap off into a draw. When I get the time I tend to try and fix it by what I call hard-wireing the problem in the book. I normally end up with zappa mex 2 analysing the position and working to find the position even Rybka cannot mess up lol :) (fingers crossed)

Regards
Parent - - By Patricio (***) Date 2008-08-16 16:52
"But the endgame analyzers are really shocked and unsettled now!"

If I want to analyze a game that was not resolved in the middle game, I mean all the other way around, a game which its main component is the endgame:

would be logical/useful to use Rybka 3 to analyze endgame moves?

Or in this case would be better to use R3 to analyze opening and middlegame phase and for the endgame one should use DShredder 11, DSjeng 3, or Zappa Mx2?

Best regards,

                             Patricio.
Up Topic Rybka Support & Discussion / Rybka Discussion / Summary of the Rybka EGTB mp bug
1 2 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill