Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Weak points of Rybka 2.3.2a!
1 2 3 4 Previous Next  
Poll Weakest point of Rybka 2.3.2a! (Closed)
Opening-Book choice 4 4%
Middle-game knowledge 2 2%
End-game knowledge 41 41%
Evaluation efficency 9 9%
Search efficency 5 5%
King safety 18 18%
Time management 3 3%
Parallelism Scalability 19 19%
- - By richbell (**) Date 2007-11-15 19:26 Edited 2007-11-15 19:28
So many of you had tested Rybka in different platforms with different results. I would like you to rank what you consider is the weakest point of Rybka 2.3.2a that you would see improved in 3.0.

This way we will have a overall idea what we expect from 3.0 if, you are right and Vas listens ;-)

You can vote 2 choices, most weakest and weakest. Be fair and please don't vote more than twice. 
Parent - - By Jouni (**) Date 2007-11-15 22:27
IMHO

Weakest point = tactics
Best point = endgame (with EGTBs)

Jouni
Parent - By InspectorGadget (*****) Date 2007-11-16 06:26
"Weakest point = tactics"

I used to think so too, I have changed my mind. Maybe this statement holds true in the testsuits. During play, I believe it has proved me wrong.
Parent - By Vinvin (***) Date 2007-11-16 12:17 Edited 2007-11-16 12:20
The weakest point of Rybka (before version 3) is finding a winning sacrifice. Rybka hates to analyse lines where she gives material !

The second weak point is scalabitlity over 8 CPU's, but it will fixed in Rybka 3, I suppose.

Vincent
Parent - - By Uly (Gold) Date 2007-11-16 18:47
I voted for King Safety and Time Management.

King Safety - One way of beating Rybka is to build a strong King Attack and kill Rybka before she knows what's going on. Of course Rybka is good at defending those, but not allowing the opponent to treat at all would be better.

Time Management - Rybka just plays too fast, it's like if she was saving time for harder times, but either those hard times never come (And Rybka either draws or wins with too much time on the clock, meaning the draw could have been avoided had Rybka spent more time on her moves), or they do, meaning Rybka could have avoided them by spending more time on her moves.

Third option I would have voted (but didn't): Opening-Book choice - Try to play Rybka as bookless and you will notice that she's hundreds of ELO points weaker, she just has no idea about how to play the opening. So I think that if you give her a bad book and the opponent makes Rybka go out of book early, you'll be in deep trouble (But, on the other hand, most books are decent enough to nullify this effect, so it's not a big problem).
Parent - By richbell (**) Date 2007-11-16 19:21
Ok, My votes went for End-game knowledge. I feel that's the weakest considering how other engines play. If she improves material evaluation better during end-games she would have bagged several ELOs already.

Next vote for Parallelism scalability. We all know she is already handicapped there, with potential engine strength going wasted. It would mean Elos waiting to be gained there.

Then comes opening choice and time management. As long as we have better books created opening wouldn't be a problem, but she certainly needs to utilize her time completely, and not try to finish the game as if she needs to catch the next flight to Hungary. :-)  There are so many Wins lost as draws due to this. Like +4 ands +5 evaluated and finished as draw.

Finally there needs to be some Eval bugs those needs to be fixed.

Let's see others comments more.
Parent - - By billyraybar (***) Date 2007-11-16 19:26
I agree with all that Vytron says.
Parent - By Gaмßito (****) Date 2007-11-16 21:11
What Vytron and Uri said is right. I agree too.

Regards,
Gambito.
Parent - - By Uri Blass (*****) Date 2007-11-16 19:13
I voted for endgame knowledge.

The reason is that rybka often show scores of +4 and higher  in endgames and only draw the game.

We saw examples in the match against Zappa when Rybka had totally won position in game 9 but had too high scores.
I also saw cases when rybka showed scores of more than +4 when she could only draw in CEGT 120/40 games.

I did not do statistics about it but I guess that rybka is less reliable when she gives high scores in the endgame.

Uri
Parent - - By Conwy (*) Date 2007-11-25 01:49
I would also vote for end-game knowledge.

However, the may be a hidden bias here.

In an end-game, we humans may be more certain that we are correct than in earlier positions.

Therefore, we might prefer to identify positions in end-games through reasons of certainty, whereas there might be earlier faults which we cannot so easily prove.

Conwy
Parent - - By Roland Rösler (****) Date 2007-11-25 02:22
You are totally true here. But now we have to begin with the end. When this is done, we see further.
Parent - - By Vasik Rajlich (Silver) Date 2007-11-26 16:03
This is what all the endgame specialists tell themselves. Then they go play in a tournament and lose every game in the opening :)

Vas
Parent - - By Roland Rösler (****) Date 2007-11-27 00:23
I don´t say, Jeroes and Dagh should retire :-).
Okay, it´s your party and in the past your guests like the dishes. But why always starters (appetizers) and entrees (main dishes). Some guests like afters (desserts)! :-)
Parent - By Banned for Life (Gold) Date 2007-11-27 06:31
This has already been explained Roland. Americans do not play endgames. :-)

Alan
Parent - By Vasik Rajlich (Silver) Date 2007-11-28 18:34
When the main dishes are good enough, dessert is just punishment for the guests :)

Vas
Parent - By Roland Rösler (****) Date 2007-11-16 21:04
This is a good poll :-). I voted for endgame-play (first) and Parallelism Scalability (second). I´m vey lucky with the voting of the others.
Parent - By Vasik Rajlich (Silver) Date 2007-11-17 12:47
Thanks, it's interesting.

Of course, middlegame evaluation and search efficiency are always going to be #1 and #2 (in some order), but yes, we have already addressed the MP scaling and started to work on the endgames.

Vas
Parent - - By Fulcrum2000 (****) Date 2007-11-17 13:25
I miss one, TableBases lookup efficiency. When hitting TB's you see drop the processor use of Rybka (often to a very low percentage). Seems Rybka will wait for the TB value to return before going on with her normal job. I have the feeling this can be improved by parallely search other non TB moves. Don't know how difficult it is to implement, but I think it's a least worth a try.
Parent - - By turbojuice1122 (Gold) Date 2007-11-17 23:39
Does the processor use really fall, or is this due to the time for tablebase access?  Is there still an incredible drop when dealing with one of those really expensive, really fast drives?
Parent - - By Fulcrum2000 (****) Date 2007-11-18 00:21
I use a fairly fast (access time 0.7 ms) Corsair Voyager GT 8GB USB stick and see the processorload drop, this means the processor is waiting for the data from the drive to return. I think these waiting moments can be used to calculate non TB positions (technically it might be quite difficult to do, but it's worth having a look at I think).
Parent - - By Sesse (****) Date 2007-11-18 00:26
FWIW, I asked about this (asynchronous tablebase accesses) during the one of the Rybka-Ehlvest matches (I think); the response was basically "perhaps in 2020" :-)

I wonder if this would be a case where having more threads than real CPUs could actually help performance, but it seems sort of far-fetched.

/* Steinar */
Parent - - By Fulcrum2000 (****) Date 2007-11-18 01:26
This is what I had in mind, why is it far fetched?
Parent - - By Sesse (****) Date 2007-11-18 09:34
Because the extra hit by having more threads that need to communicate (and do overlapping work) is so big, I'm not sure if the occasional "I can work while accessing TBs" gain is really worth it.

/* Steinar */
Parent - - By Vasik Rajlich (Silver) Date 2007-11-22 00:59
It's certainly logical - it's a very rare case where a chess engine is I/O bound. It's just not a high priority, especially when you think about the mess in the code which it would make :)

Vas
Parent - By albitex (***) Date 2007-12-14 22:19
Vas. I believe that besides the endgameses, it would be also the management of the time to consider.
When the engine in opening, thinks minutes to play a discounted movement (and only),
this time will miss in the end, conclusive thing in the blitz games.
I
Parent - By TheMagician (*) Date 2007-11-17 16:40
I voted for end-games, because almost every engines I have seen seems to fail in some positions which are pretty easy to humans. When some engine can find same moves without EGTB than with it then I'll change my vote. :)
Parent - - By Lukas Cimiotti (Bronze) Date 2007-11-17 16:47 Edited 2007-11-17 16:51
Sorry - i voted for 3 items: 1. mp speedup (Zappa is much better here) 2. endgame knowledge (not so very important, as Rybka usually wins before the endgame) 3. King safety (not bad, but might be improoved)

Regards
Lukas

P.S.
i think, Rybka has the best time management of all available engines, middle game knowledge is unbeaten, evaluation is superb, and search efficiency is really super, too.
Parent - - By TheMagician (*) Date 2007-11-17 17:15

> i think, Rybka has the best time management of all available engines, middle game knowledge is unbeaten, evaluation is superb, and search efficiency is really super, too.


Sorry offtopic:
But is there a some list of Rybka's immortals or top10 games, I would like to see them because some of the rybka's games which I have analyzed has been amazing, like leaving king in the center of board where opponents heavy pieces gatheres the poor king while Rybka slowly maneuvers king attack other side of the board. That requires nerves of steel and cold blood inhuman calculations :)
Parent - By Roland Rösler (****) Date 2007-11-17 22:51
But is there a some list of Rybka's immortals or top10 games
I think no! The best game I ever see from Rybka was her immortal game against Zappa during WCCC2007. Okay, the end was a little bit annoying (draw), but the play of Rybka was fantastic.
Parent - - By Uly (Gold) Date 2007-11-17 20:54

> Rybka has the best time management of all available engines


I can only talk about my experiences with Rybka on my 1 CPU 32bit machine, but what I see, is that the games Rybka has lost (even though they're rare), are due to some blunder in where Rybka made a horrible move in a hurry, a hurry with no explanation whatsoever because sometimes Rybka has up to double the opponent's time.

So, (for example) Rybka can play a move every 1 minute, but less than 30 seconds were used on the blunder. Then next move Rybka realizes that something went wrong and that she's suddenly losing, and now starts playing slowly and carefully to defend, but when the blunder is critical, Rybka cannot recover and loses.

Had Rybka used more time (Because it had the available time) on that move, it could have found that the move was bad and played something else, probably a winning move. Rybka is just too strong in other aspects that it seems as if her time management is irrelevant.
Parent - - By Permanent Brain (*****) Date 2007-11-17 21:05
I let play experimental bullet games (most often 1+0 or 2+0) on playchess, with Rybka 2.2 and alternative settings. My experience is that if I activated "server buffer", I could change the rate of play to slow and the emergency time buffer to small. I didn't notice any time trouble. But that was in conjunction with the very optimistic outlook setting. Also, I did not test that with version 2.3.2a.

But I think these time related settings are worth to try, if you have the impression that Rybka should invest more time (and earlier) in the games.
Parent - By JhorAVi (***) Date 2007-11-18 06:33
I vote for TACTICS! But it's missing in the POLL
Parent - - By cma6 (****) Date 2007-11-22 15:07
Hi Lukas:
I tried to use Zappa Mexico in my Windows x64. Though I was able to install it in DS!! GUI, I was not able to switch to the engine. Do you know if Zappa Mexico has separate 32-bit and 64-bit versions?
                           Thanks, CMA

I didn't see the poll but if I had, I would have voted with you for MP scalability.
Parent - - By ernest (****) Date 2007-11-22 17:20

> Do you know if Zappa Mexico has separate 32-bit and 64-bit versions?
>


Strange :-( you didn't notice that Zappa Mexico is shipped in 2 versions: zappa_mexico.exe and zappa_mexico_x64.exe
Parent - By cma6 (****) Date 2007-11-22 19:26
Ernest, thanks, I will have to contact Stefan at Shredder Chess.
        
Parent - - By Lukas Cimiotti (Bronze) Date 2007-11-23 14:38
Hello,
yes, Zappa has 32 and 64 bit versions - the 64 bit version is much stronger. But both should work in any GUI that can handle UCI engines. I installed the 64 bit version in the DS 11 GUI and it works without problems.

Regards,
Lukas
Parent - - By cma6 (****) Date 2007-11-24 19:33
Lukas, thanks for the info. I finally found two files: zappa_mexico_x64 and zappa_mexico_x64.exe
Do you know which is the one to install in the GUI?
Parent - - By ernest (****) Date 2007-11-25 01:34
This is the readme.txt file which comes with Zappa Mexico.
I think you should ask Stefan Meyer-Kahlen why you did not receive it...


This Zappa distribution contains four UCI chess engines. These engines can be plugged into a chess user interfaces supporting the open UCI standard.
To do this open the chess program in which you want add Zappa to. You can for example add Zappa to the Shredder user interfaces for Windows and Linux.
In the Windows version simply select "Extras->Engines->Install Engine..." from the main menu, select UCI engine and set the path to the file you have just saved on your hard disk in the next dialog. After clicking on OK Zappa is added to Shredder. Right click in the engine window and select "Change Engine..." to load Zappa in Shredder.
The dialog to add UCI engines in the Shredder Linux versions can be found at "File->Options..." and then "Engine Options" and "Install New Engine".
In Chessbase products it works with "Engine->Create UCI Engine" from the main menu.
Please note that you need Windows x64 or a 64 bit Linux version to use the 64 bit versions of Zappa.
You can change the Zappa engine options in the user interface you have plugged Zappa into. Alternatively you can also change the included zappa.ini file. Zappa will use those values as default values when starting up. If you for example want Zappa to use just one cores of your multi core CPU just change the line
threads auto
to
threads 1
using a standard text editor like Notepad.
Parent - - By cma6 (****) Date 2007-11-25 04:04
Ernest, thanks. I read that file. But it doesn't make clear which file to use.
Parent - - By Henrik Dinesen (***) Date 2007-11-25 09:11
The one with the extension, which is "exe" here, is for windows OS. The other for Linux.
Parent - By cma6 (****) Date 2007-11-26 04:15
Henrik, thanks, that clears it up.
Parent - - By richbell (**) Date 2007-11-18 22:52
Roughly after 48 hours i am closing the poll with approximately 50 people voted. I guess weekend is over for all the timezones and everyone had an opportunity to vote. Thanks for everyone who participated. Here is a short summary.

As i predicted End-game knowledge seems to top the list with 41%.
Parallelism scalability, Evaluation efficiency and King safety seems to be next major concern.
I certainly didn't expect people to vote for search efficiency. It was a surprise it was considered weakest point of Rybka by at least 5% . (Though i agree it's always good to improve on this point, i just don't feel she is the weakest there).

I am sorry that many wanted the option of tactical play which was left out, it totally slipped through my mind. Also thanks to Vas for participating and assuring us we got MP Scaling and Endgame knowledge already getting fixed.

I am not an expert in understanding engines, it's only my passion and the knowledge gained from other experts in this forum and tournament results and studies based on that. But certainly this poll gave me a good insight and understanding on how Rybka is expected to (and hope will) evolve much stronger.

Thanks.
Parent - By NATIONAL12 (Gold) Date 2007-11-18 22:58
it was a very intresting thread you set up thanks.
Parent - - By exigentsky (***) Date 2007-11-25 05:15
It definitely has problems with king safety. I remember I had an old Rubinsteing French line that gave White a ferocious attack and Black was clearly worse. Rybka was not worried about it until seven moves later. Apart from that, she also seems to have some problems in the endgame, but far less severe.
Parent - - By maxrom (***) Date 2007-11-27 10:50
I THINK RYBKA IS bad king safety and i voteded for this. Few days ago i play vs rybka 1.0 and I go with my king in the centrum and rybka didn't attacked my king !!!
Parent - - By StrongHold (*) Date 2007-11-27 20:26
We are talking about a newer version of Rybka not Rybka 1.0. I agree Rybka 2.3.2a is not so great with king safety, but it should be improved considering 9 months to do so. Here's a game showing just that

(43) Zappa Mexico 64-bit 4CPU (3062) - Rybka 2.3.2a 64-bit 4CPU (3122) [A28]
CCRL 40/40 CCRL (1.77), 22.09.2007

1.c4 0s 1...e5 0s 2.Nc3 0s 2...Nf6 0s 3.Nf3 0s 3...Nc6 0s 4.a3 0s 4...d6 0s 5.e3 0s 5...g6 0s 6.d3 0s 6...Bg7 0s 7.Be2 0s 7...0-0 0s 8.0-0 0s 8...Ng4 Both last book move 0s 9.h3 +0.29/16 82s 9...Nf6 (Nh6) +0.14/16 43s 10.d4 (Qc2) +0.43/17 117s 10...e4 (Bd7) +0.08/18 75s 11.Nd2 +0.44/17 77s 11...Re8 +0.11/17 26s 12.Qc2 (b4) +0.39/17 84s 12...Bf5 (Qe7) +0.12/15 19s 13.g4 (Rd1) +0.19/16 124s 13...Bc8 (Bd7) +0.02/16 22s 14.Kg2 (Ndxe4) +0.45/15 53s 14...Qe7 +0.26/16 155s 15.Rh1 (g5) +0.49/15 79s 15...h5 -0.01/16 76s 16.Qd1 (gxh5) +0.49/15 48s 16...hxg4 (a5) +0.06/16 131s 17.hxg4 +0.51/5 0s 17...a5 (Nd8) +0.07/17 25s 18.g5 (b3) +0.54/17 74s 18...Nh7 +0.23/16 14s 19.Ndxe4 +0.57/16 59s 19...Nxg5 +0.26/17 22s 20.Ng3 +0.56/17 112s 20...Nh7 (Qd8) +0.27/16 68s 21.Qd3 +0.67/15 110s 21...Nf6 (Qd7) +0.34/16 76s 22.e4 +0.79/15 108s 22...Bg4 (a4) +0.49/17 153s 23.f3 (Bxg4) +0.83/16 77s 23...Bd7 (Bc8) +0.46/18 62s 24.Bg5 +0.91/16 157s 24...Qf8 (Qd8) +0.46/18 286s 25.Rh4 (Nb5) +1.16/16 124s 25...Nh7 +0.71/16 50s 26.Be3 +1.16/15 0s 26...Nf6 (Bf6) +0.83/16 70s 27.Rah1 +1.28/15 113s 27...Ne7 (a4) +1.14/16 64s 28.Bg5 (Qd2) +1.58/15 139s 28...Be6 (Red8) +1.39/16 77s 29.Qd2 (Qe3) +1.55/14 55s 29...Nh5 (Rec8) +1.71/16 62s 30.Nxh5 +1.83/16 49s 30...gxh5 +1.88/16 54s 31.Rxh5 +1.93/16 44s 31...Ng6 +2.00/18 140s 32.f4 (Nd5) +1.92/16 132s 32...f5 (f6) +1.94/16 40s 33.e5 +2.24/13 0s 33...dxe5 (Qf7) +1.99/16 97s 34.fxe5 +2.29/8 0s 34...Qf7 (Bf7) +2.39/16 81s 35.Rh7 (Kf2) +3.66/14 61s 35...Nf8 (Qf8) +3.66/16 40s 36.Bh5 +4.64/10 0s 36...Qd7 (Nxh7) +4.25/16 20s 37.Rxg7+ (Bxe8) +6.33/12 0s 37...Qxg7 +5.16/16 20s 38.Kf2 +6.33/11 0s 38...Nh7 (f4) +5.29/15 23s 39.Rg1 +7.98/16 67s 39...Nxg5 +5.86/15 15s 40.Rxg5 +8.50/16 0s 40...Re7 +6.07/15 5s 41.d5 +8.50/16 0s 41...Bd7 +7.56/17 107s 42.e6 (Rxg7+) +9.78/16 58s 42...Be8 (Rf8) +7.58/14 82s 43.Rxg7+ +10.01/15 0s 43...Rxg7 +7.53/13 32s 44.d6 (Bxe8) +11.31/16 151s 1-0

r3rqk1/1ppb1pb1/2np1np1/p7/2PPP2R/P1NQBPN1/1P2B1K1/7R b - - 0 27
Parent - - By StrongHold (*) Date 2007-11-27 22:58 Edited 2007-11-27 23:00
And heres Example # 2

(56) Rybka 2.3.2a 64-bit 4CPU (3122) - Deep Shredder 10 64-bit 4CPU (2936) [A29]
CCRL 40/40 CCRL (1.64), 05.07.2007

1.c4 0s 1...e5 0s 2.Nc3 0s 2...Nf6 0s 3.Nf3 0s 3...Nc6 0s 4.g3 0s 4...Bb4 0s 5.Bg2 0s 5...0-0 0s 6.0-0 0s 6...e4 0s 7.Ne1 0s 7...Bxc3 0s 8.dxc3 0s 8...h6 0s 9.Nc2 0s 9...Re8 0s 10.Ne3 0s 10...d6 0s 11.Qc2 +0.21/18 48s 11...a5 (Nc6-e5) +0.14/17 70s 12.a4 (b2-b3) +0.23/17 32s 12...b6 (Nc6-e5) +0.08/18 70s 13.b3 +0.17/17 56s 13...Bb7 (Nc6-b8) +0.08/18 54s 14.Nd5 (f2-f3) +0.21/20 73s 14...Nb8 +0.07/19 70s 15.Rd1 +0.19/19 38s 15...Nbd7 +0.05/18 53s 16.Bf4 (Bc1-b2) +0.18/19 90s 16...Nf8 (Nf6xd5) +0.00/17 50s 17.Be3 +0.19/18 138s 17...Ng4 (Nf8-d7) -0.09/17 42s 18.Bd4 (Qc2-d2) +0.17/18 82s 18...c5 (Bb7xd5) +0.04/19 71s 19.Be3 +0.28/16 17s 19...Nf6 (Bb7xd5) +0.03/18 58s 20.Nxf6+ +0.28/16 58s 20...Qxf6 +0.01/19 61s 21.b4 +0.17/18 86s 21...Bc6 (Nf8-g6) -0.22/18 84s 22.bxc5 (Qc2-b3) +0.02/17 92s 22...bxc5 -0.32/18 23s 23.Rab1 +0.02/18 37s 23...Qe7 (Qf6-e6) -0.56/18 65s 24.Bh3 (Rd1-d2) +0.03/18 52s 24...Ng6 -0.60/18 52s 25.Rb6 +0.00/20 59s 25...Ne5 -0.60/18 40s 26.Qb3 (Rd1-b1) +0.00/20 34s 26...Qc7 -0.67/17 30s 27.Rb1 -0.05/19 35s 27...Nd7 (Re8-f8) -0.69/19 54s 28.Bxd7 (Rb6-b5) -0.04/19 94s 28...Qxd7 -0.70/19 19s 29.Qa2 -0.04/19 91s 29...Re5 (Re8-e6) -0.71/19 74s 30.h4 (Be3-f4) -0.12/19 112s 30...Ree8 (g7-g5) -0.80/18 48s 31.Bf4 (Rb1-d1) +0.00/17 31s 31...e3 (Ra8-c8) -1.84/18 147s 32.f3 +0.12/16 18s 32...g5 (Ra8-d8) -4.57/19 111s 33.hxg5 +0.05/15 0s 33...hxg5 -4.57/20 40s 34.Bxg5 (Bf4xe3) +0.05/13 0s 34...Qh3 (Bc6xa4) -9.78/17 71s 35.Bh4 -5.55/16 80s 35...Re4 -14.14/18 68s 36.Rb8+ -5.66/15 45s 36...Rxb8 (Kg8-g7) -14.38/20 36s 0-1

r5k1/5p2/1Rbp4/p1p5/P1P1r2B/2P1pPPq/Q3P3/1R4K1 w - - 0 36


Rybka's evaluation of an opened H-file where the king lays is not so good.
Parent - - By maxrom (***) Date 2007-11-28 10:03
Very intersting, I hope that rybka 3.0 will play this king of positions better.
Parent - - By maxrom (***) Date 2007-12-13 17:27
Here you can see why I have voted for king safety  : [Event "Wertungspartie, 16m + 0s"]
[Site "Maschinenraum"]
[Date "2007.12.13"]
[Round "?"]
[White "Michael Jackson, Fritz 11"]
[Black "Trebreh33, Rybka 2.3.2a mp 32-"]
[Result "1-0"]
[ECO "A11"]
[Annotator "0.47;0.28"]
[PlyCount "45"]
[EventDate "2007.12.13"]
[TimeControl "960"]

{Rybka 2.3.2a mp 32-bit: 12.4 ply; 36kN/s GenuineIntel, (2 threads), Fritz11.
ctg, 159 MB} 1. g3 {[%eval 0,0] [%emt 0:00:00]} d5 {(e5) [%emt 0:00:00]} 2. Nf3
{[%eval 0,0] [%emt 0:00:00]} Nf6 {[%emt 0:00:00]} 3. Bg2 {
[%eval 0,0] [%emt 0:00:00]} c6 {(Lf5) [%emt 0:00:00]} 4. c4 {
[%eval 0,0] [%emt 0:00:00]} Bf5 {[%emt 0:00:00]} 5. O-O {
[%eval 47,15] [%emt 0:00:40]} e6 {[%eval 28,11] [%emt 0:01:35]} 6. cxd5 {
[%eval 40,18] [%emt 0:00:00]} cxd5 {[%eval 21,14] [%emt 0:00:16]} 7. Nc3 {
[%eval 36,17] [%emt 0:00:23]} Nc6 {[%eval 17,14] [%emt 0:00:01]} 8. Qa4 {
[%eval 32,17] [%emt 0:01:04]} Qb6 {(Sd7) [%eval 14,11] [%emt 0:00:18]} 9. d3 {
[%eval 30,16] [%emt 0:00:46]} O-O-O {(Lc5) [%eval 12,14] [%emt 0:01:03]} 10.
Bd2 {[%eval 70,16] [%emt 0:01:18]} d4 {[%eval 23,11] [%emt 0:00:30]} 11. Nb5 {
[%eval 95,16] [%emt 0:00:10]} a6 {(Td5) [%eval 48,11] [%emt 0:00:04]} 12. Na3 {
[%eval 126,16] [%emt 0:00:27]} Qxb2 {(Sd5) [%eval 111,13] [%emt 0:01:20]} 13.
Rac1 {[%eval 204,14] [%emt 0:00:11]} Bxa3 {(Dxa3) [%eval 121,12] [%emt 0:00:28]
} 14. Rc2 {[%eval 206,14] [%emt 0:00:06]} Qb5 {
(Db6) [%eval 153,10] [%emt 0:00:27]} 15. Qxa3 {[%eval 342,14] [%emt 0:00:03]}
Ne4 {(Td5) [%eval 284,13] [%emt 0:00:47]} 16. dxe4 {
[%eval 459,16] [%emt 0:00:10]} Bxe4 {[%eval 291,15] [%emt 0:00:09]} 17. Rb2 {
[%eval 556,17] [%emt 0:00:20]} Qd5 {(Dxe2) [%eval 320,11] [%emt 0:00:49]} 18.
Rc1 {[%eval 654,16] [%emt 0:00:13]} Qd6 {[%eval 403,13] [%emt 0:00:03]} 19. Rc5
{[%eval 689,15] [%emt 0:00:02]} Qb8 {(d3) [%eval 469,7] [%emt 0:00:31]} 20. Bf4
{[%eval 816,16] [%emt 0:00:05]} Rd6 {(Da7) [%eval 676,10] [%emt 0:00:09]} 21.
Nxd4 {[%eval 1154,14] [%emt 0:00:03]} Rxd4 {[%eval 728,7] [%emt 0:00:34]} 22.
Bxe4 {[%eval 1522,17] [%emt 0:00:00]} Rd1+ {
(Da8) [%eval 1053,11] [%emt 0:00:16]} 23. Kg2 {Trebreh33,Rybka 2.3.2a mp 32-b
gibt auf  (Lag: Av=0.24s, max=0.6s) [%eval 1796,13] [%emt 0:00:05]} 1-0
Parent - - By turbojuice1122 (Gold) Date 2007-12-13 17:40
I wonder if this will happen on an ordinary machine.  It appears from the nps and other info that black has used an MP Rybka with 2 threads on a hyperthreading Pentium, something that is known to give very poor results.
Up Topic Rybka Support & Discussion / Rybka Discussion / Weak points of Rybka 2.3.2a!
1 2 3 4 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill