Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Rybka 3 & tablebases & amount of memory needed
- - By Hamlet (**) Date 2008-08-06 21:27
I have almost all 6men tablebases. And I have been using rybka 2.3.2a with my tablebases. When I set hash size 256MB, Rybka can run in my computer. I have 4 giga main memory. 64-bit xp. quadcore.

Now I installed rybka 3 and tried to start it. Don't work, because she needs so much memory that my system will run out of memory. Every thread (4 )was taking over 1 giga.
Seems, that  rybka 3 uses much more memory when you have many many tablebases in your computer.
I would like to know why? What is required amount, when I have all tablebases ? 8 giga min?

I also would like to point out that f.g. Fritz starts much much faster with tablebases and donät take insane amount of main memory. Ibfeel that there is room for improvments in tablebase usege of Rybka 3.

Regards,
Hamlet
Parent - - By Vasik Rajlich (Silver) Date 2008-08-06 21:33
The Nalimov code is fairly standard so there should be no huge difference here. Are you sure that you didn't set a really big hash size?

Vas
Parent - - By Hamlet (**) Date 2008-08-06 22:08
positive.
I used to have higher hash value, but I have been collecting these tablebase files quite a long time and now I have so many that I was forced to decrease hash value from 512
-> 256 over four months ago. But I will investigate this more.

with rybka 2.x one process was over 1 giga and others were much smaller. I guessed that tablebase index was in that one big process, but now all processes are big. I was thinking that may be tablebase index is now in every process?

Hamlet
Parent - - By Bjornf (*) Date 2008-08-06 22:42
I also have a lot of TBs. When I have included them in CB10 it takes really long time to start the engine, maybe 60 seconds. And sometimes the application just hangs. Is this normal?

Another problem is that sometimes when i analyse endings Rybka doesnt seem to use TBs in a good way. It gives a long line and state +3.0, then when i step forward 5 moves or so it suddenly realize that this is draw or mate in x moves. Any idea why?
Parent - - By Hamlet (**) Date 2008-08-06 23:32
rybka don't use tablebases well. Hiarcs is much better. Long start up. Rybka is building index of tablebase files = when tablebase position comes up during the search it will know where to probe (which file and which location in this file, tablebase files are divided internally to 8 kb blocks)
Parent - - By Vasik Rajlich (Silver) Date 2008-08-07 09:01
Ok, I will revisit all of this for Rybka 4.

Please post here what you find about Rybka 3 behavior (especially at startup) so that I can include it in the documentation.

I understand that a lot of users are really huge tablebase fans, probably because this is something they can actually do something about, but really it's an area which receives a disproportionate amount of attention. The files are huge, the code is cumbersome and slightly buggy, and the improvement in analysis quality from using tablebases can be equaled by something like 2 or 3 days of normal engine work by a competent engine developer.

Vas
Parent - - By Hamlet (**) Date 2008-08-07 22:52
OK. I think that you should use some time to this tablebase isssue for R4, because we are finally getting relatively cheap solid state disks, that is going to make tablebases move useful + possible some 7men tablebases. I guess that if we get few points from 6men then we will get more from 7men.

Regards,
hamlet
Parent - By Vasik Rajlich (Silver) Date 2008-08-08 18:25
7-man TBs - ugh.

Vas
Parent - - By Arkansaw (***) Date 2008-08-10 08:51
I'm starting to see tablebases as just a means to an end, i.e. to help pple write better endgame code or understand endgame better,  but it is useless to be too optimistic about it
now we are getting 6-men, and maybe 0.01% of 7-men, and when that is done, are we going to contemplate 8 and 9 and 10 men? I think (this direction) is not sustainable within our lifetimes and the diminishing returns are too great for the resources needed
Parent - - By Permanent Brain (*****) Date 2008-08-10 14:54
I do not see why we need to determine the value of endgame databases in terms of Elo gain, only. The value for (late) endgame analysis is tremendous, both in terms of quality and speed. Also, it is not about maximum but about optimum. People often see only two extremes, ALL available tables or NO tables at all. I think both is wrong (at least for the "dynamic" use of Nalimovs during search). I think there are many good compromises, including using other, faster storage devices than normal HD. I think I have mentioned examples in this thread, and/or on other occasions.

I assume that someone who is really interested in best configurations/optimizations etc. will take time to think about such compromises, and not just make a quick choice between two extremes. That's too simple.

P.S. Just because Rybka wins most games in the middlegame, doesn't mean that the chess world suddenly will ignore endgames and the difficult problems there. :-)
Parent - By BB (****) Date 2008-08-11 03:23

>I do not see why we need to determine the value of endgame databases in terms of Elo gain, only.


What? Isn't it like heresy on this Forum not to reduce all engine questions to rating points? :-P
Parent - By BB (****) Date 2008-08-11 03:21

>and maybe 0.01% of 7-men,


I think more of the 7-piece have been done already. In the June 2007 (vol 12/2) issue of British Endgame Study News, John Beasley reports that "in March Marc [Bourzutschky] told me that R+2P vs R+P had been completed under the simplifying assumption that promotions were only to Q". Of course, it's a hard drive (or more) apiece for each TB at this level.
Parent - - By Permanent Brain (*****) Date 2008-08-08 07:58 Edited 2008-08-08 08:01

> analysis quality from using tablebases can be equaled by something like 2 or 3 days of normal engine work by a competent engine developer.


Did you mean 2 or 3 years?

I don't think that search & eval can replace perfect, pre-analysed endgame data. Some endings are extremely deep and contain no visible concept. What would be your approach to solve KBB-KN for example? Within the human horizon it was believed for decades, that it is a draw. Endgame databases found it is a win, but nobody knows "how to...". Apparantly it cannot be deducted.

That is just one example. 6-piece tables must contain dozens of unclear piece sets, where either side sometimes wins, sometimes loses, and if you compare the positions each, you see no significant difference. I check 6-piece endgame positions quite often (but only online at web applets). It's pure geometry with 100+ plies of brute force calculation depth required.

I really hope that you were not serious with your statement above, which would actually mean you think the complete Nalimov tablebases are only worth 2 or 3 days of normal engine developement. I hope this is a wrong interpretation and I misunderstand something.
Parent - By Arkansaw (***) Date 2008-08-08 08:18
I think he is referring to practical endgames and not about achieving perfection for those composition-like positions
Parent - - By Hamlet (**) Date 2008-08-08 09:45
the problem is that hard disk is so slow. access to level 2 cache 10 clocks, access to main memory 100 clocks, access to hard disk 10 ms = 3,000,000,000 calculations per second * 0,01= 30,000,000 clocks.  tablebases will slow down engine so much that net effect is very small.

but solid state disks are getting cheaper and cheaper:
http://www.overclockers.co.uk/productlist.php?groupid=701&catid=14&subid=910

regards,
hamlet
Parent - By Permanent Brain (*****) Date 2008-08-09 12:22 Edited 2008-08-09 12:24
Another good alternative are USB flash memory sticks. Most useful are those with very small access times. I use a "noname" stick though because I don't go for top performance anyway. But it also feels good to avoid the intensive HD activity in tbs. related analysis. Also, I use only some important 5-piece tables, not all.
Parent - - By Vasik Rajlich (Silver) Date 2008-08-08 18:28
I really meant 2 or 3 days, to make an improvement of comparable scope.

Obviously, there is no easy way to play all 6-man positions perfectly, but there is more to chess than 6-man positions. It's a little bit like having your house a complete mess, with a 10 cm x 10 cm area scrubbed to immaculate perfection.

Vas
Parent - - By Permanent Brain (*****) Date 2008-08-08 19:40

> It's a little bit like having your house a complete mess, with a 10 cm x 10 cm area scrubbed to immaculate perfection.


Yo have described my appartement, and my mouse pad. :-D
Parent - By Vasik Rajlich (Silver) Date 2008-08-08 19:57
Ok, touche. :) I'm still right though. :)

Vas
Parent - - By Mark (****) Date 2008-08-09 11:52
I think everyone is now convinced that tablebases don't provide that much of a benefit in games, but they are still very important when analyzing positions near the endgame.
Parent - - By BB (****) Date 2008-08-09 12:03

>I think everyone is now convinced that tablebases don't provide that much of a benefit in games


It depends on what you mean by "much of a benefit" here - there is public evidence (CCRL results for both Deep Shredder and Toga with bitbases) that could back a reasonable expectation of at least a double-digit rating gain via suitable usage of the 5-piece data.
Parent - By Permanent Brain (*****) Date 2008-08-09 12:31
CEGT is testing Shredder 11 SE in addition to the default Shredder 11. The SE version does neither access tablebases nor does it have the Shredderbases (bitbases).

40/20:

54 Deep Shredder 11 w32 1CPU 2888 11 11 2516 56.7% 2842 34.6%
(...)
76 Shredder 11 SE 2856 41 41 180 55.8% 2815 37.2% (errormargins still big)
77 Toga II 1.4 Beta5c 1CPU 2856 15 15 1253 55.2% 2819 36.6%
78 Deep Shredder 10 x64 2CPU 2856 9 9 3550 50.2% 2854 37.2%

40/4:

88 Deep Shredder 11 w32 1CPU 2853 9 9 4084 56.2% 2810 30.6%
(...)
97 Deep Shredder 10 w32 2CPU 2850 16 16 1199 43.1% 2898 31.9%
98 Shredder 11 SE 2849 16 16 1198 53.7% 2823 31.1%
Parent - - By Vasik Rajlich (Silver) Date 2008-08-09 16:23

> back a reasonable expectation of at least a double-digit rating gain via suitable usage of the 5-piece data.


Absolutely no way! :)

Seriously, we can talk about 1 Elo or 2 Elo, but 10 is in no-way territory.

Vas
Parent - - By BB (****) Date 2008-08-10 07:20 Edited 2008-08-10 07:36

>> <there is public evidence [...] that could> back a reasonable expectation of at least a double-digit rating gain via suitable usage of the 5-piece data.
> Absolutely no way! :-)
>Seriously, we can talk about 1 Elo or 2 Elo, but 10 is in no-way territory.


I think I put enough weasel words in my statement. :) In particular, I mean bitbases, not just tablebases (or even just TBs at the root, as with the other thread).

I can demonstrate what the Public Evidence indicates:

CCRL 40/4:
  Deep Shredder 11 64-bit 4CPU             3033  +11  −11  57.5%  −52.4  34.5%  2873  
  Deep Shredder 11 64-bit 4CPU (No EGBBs)  2996  +17  −17  53.6%  −25.1  39.3%  1139
  Toga II 1.4 beta5 4CPU                   2987  +21  −21  49.6%   +1.0  42.1%  699
  Toga II 1.4 beta5 4CPU (No EGBBs)        2967  +22  −22  48.1%  +12.3  38.9%  648
  Scorpio 2.0 32-bit                       2747  +10  −10  50.7%   −3.8  42.0%  3179
  Scorpio 2.0 32-bit (No EGBBs)            2737  +17  −17  48.2%  +10.0  56.3%  997

(Scorpio 2.0 64-bit has only 32 non-EGBB games, so I excluded it).

CEGT 40/4 (pointed out by PB recently - err, actually just above this post):
  70   Deep Shredder 11 x64 1CPU   2883   10   10   2920   58.5%   2823   32.8%
  88   Deep Shredder 11 w32 1CPU   2853    9    9   4084   56.2%   2810   30.6%
  98   Shredder 11 SE              2849   16   16   1198   53.7%   2823   31.1%

CEGT 40/20:
  54   Deep Shredder 11 w32 1CPU   2888   11   11   2516   56.7%   2842   34.6%
  76   Shredder 11 SE              2856   41   41    180   55.8%   2815   37.2%


I've been unable to track down exactly what Shredder 11 Special Edition is, but PB says it has Shredderbases, and no TB usage (unclear whether the CEGT tests allowed the GUI to adjudicate via TBs). No idea if the testing was 32 or 64 bit. And "DS11 x64 1CPU" does not seem to appear in CEGT 40/20.

Thus are seen CCRL gains of +37, +20, and +10, and CEGT gains of maybe +19 and +32, though the second number has a large error. The +20/+10 numbers are from similar bitbase implementations/usages, with the +37/+25(?) from the implementation of Shredder (which is presumably a bit better). One can then use the error margins to determine a quantification of my "reasonable expectation" of at least a double-digit rating gain. :)

Some weak points of any argument based upon these data might be the short time control, and perhaps the possibility of bias coming from computational setups amongst EGBB adopters (that is: it might be the case that "power-users" are more likely to test with bitbases; and it might be that these users just happen to have systems that run DS/Toga/Scorpio a relative 5-10-20(?)% faster compared to opponents - with a sufficiently small testing group, such a bias might actually occur). My impression is that these largely are scientific quibbles, and the thrust of the original claim is not much diminished in validity by such concerns.
Parent - - By Vasik Rajlich (Silver) Date 2008-08-10 08:08
The problem is that the "error bars" are somewhat higher on a rating list than what is listed, due to different opponents and the such.

The right way to do this experiment is to isolate the variable - that is, run fixed-depth self-play matches, with tablebases being the only difference. We already did this.

Also: sometimes things are just obvious. I can't tell you whether 5-man tablebases are worth 1 Elo or 2 Elo or maybe even 3 Elo, just like I can't tell you whether the tallest man in the world is 8 feet tall or 9 feet tall or maybe even 10 feet tall. I can however tell you that they are not worth 10 Elo, just like I can tell you that you won't find any 50-foot-tall men (except in movies) :)

Vas
Parent - By Arkansaw (***) Date 2008-08-10 08:49
Maybe the value of tablebases depend on the current strength of the user, you don't need to know about endgames if you don't even reach them
Parent - - By BB (****) Date 2008-08-11 03:12

>The problem is that the "error bars" are somewhat higher on a rating list than what is listed, due to different opponents and the such.


Yes, I certainly agree with this, but then again, I phrased everything in terms of "reasonable expectation" of a double-digit gain, which (given that all the results are at least +10) shouldn't be less than 50%.

>The right way to do this experiment is to isolate the variable - that is, run fixed-depth self-play matches, with tablebases being the only difference.


Fixed-depth is the right way??!? It would seem much superior to run (say) 1m+1s with-versus-without --- and in that case, realtime bitbases should be used rather than TBs.

>We already did this.


If I cared to dredge up my old engine code (back when the 5-piece BBs worked), I could give anecdotal evidence for the experiment I described. But it would take 2-3 days of development time to figure out how to get the old code to work with the newer testing system. :) Of course, any one who has one of Scorpio/Toga/Shredder could do the same. [I could test the former two, but my impression is that the implementation is slightly inferior].

>Also: sometimes things are just obvious.


The last bastion of an argument about to collapse. :-P
Parent - - By Vasik Rajlich (Silver) Date 2008-08-11 20:25

> Fixed-depth is the right way??!?


Fixed-depth tests will give you an upperbound.

Vas
Parent - - By BB (****) Date 2008-08-12 03:42

> > Fixed-depth is the right way??!?
>Fixed-depth tests will give you an upperbound.


I see no reason to believe this. Tablebase usage deforms the tree, quite drastically in some cases. As such, a comparison is dodgy at best.

In particular, one can frequently reach a given depth faster when using tablebases. See the data from test-position that was listed here, in particular the line: With no TB support I get to depth 15 in 7.5s at 714 kN/s, with Nalimov 4-piece it takes 5.6s at 496 kN/s (both giving a 1.5 edge to White). Nalimov 5-piece takes 2.9s at 339 kN/s... (though I attach a typical codicil by saying that other programmes might differ here).
Parent - - By Roland Rösler (****) Date 2008-08-12 07:02
Tablebase usage deforms the tree

This is very true. But why you argue for tbs usage. Let us play Rybka games with NalimovUsage=Never and disabled tbs usage in GUI (very important!; also resign to never). It´s real fun!
I don´t like Vas argumentation. Trust in GUI about tbs but not in engine parameters. Maybe UCI is too comfortable for him; Winboard would be the right protocol for him!
Parent - By Vasik Rajlich (Silver) Date 2008-08-12 17:42
Ok, I mean a practical upperbound. A slightly smaller tree in a tiny handful of endgame positions isn't going to make any difference.

Vas
Parent - By Permanent Brain (*****) Date 2008-08-10 14:20 Edited 2008-08-10 14:42
S11 SE has NO Shredderbases and does not access Nalimovs during the search. The GUI is normal (no. 10). The rest is almost certainly identical, with the only remaining exception that it doesn't offer engine settings. The "SE" versions are extra versions with smaller price which are released much later than the original first editions.

As for the GUI access, I would assume that CEGT and CCRL do not turn it off, but I'm not sure. Normally, the GUI will takeover and finish the game after a tablebase position has been reached in the game.
Parent - By likesforests (**) Date 2008-08-10 14:54
Great to know. I had been considering an extra 8GB of RAM for my next build to cache all 5-man TBs in memory and raid drives to store all 6-man TBs. It sounds like more cores would yield a more meaningful improvement.
Parent - - By Banned for Life (Gold) Date 2008-08-10 07:27
Translation: I have no control over these fricken tablebases and I would like to see Nalimov get run over by a beer truck. :-)
Parent - - By Vasik Rajlich (Silver) Date 2008-08-10 08:10
No, really, 1 Elo is a nice thing. I'll often sweat for 2 or 3 days to get this. It's just that all these discussions are way out of proportion :)

Vas
Parent - - By Banned for Life (Gold) Date 2008-08-10 08:19
OK, the transition from R2.3.2a to R3 yielded about one Elo of improvement every three days for you and Larry. How long have you spent working on tablebases?

Alan
Parent - - By Vasik Rajlich (Silver) Date 2008-08-10 08:23
Can I include the time spent talking about them on the forum? :)

Vas
Parent - By Dragon Mist (****) Date 2008-08-10 08:34
LOL!
Parent - - By Arkansaw (***) Date 2008-08-07 23:02
Vegan said that using all 6 men bases will require as much as 8G of ram due to memory overhead,
although he also suggested one can try with 4G
Parent - - By ernest (****) Date 2008-08-08 02:09
> Vegan said

This guy is on the verge of being banned for lunacy by the CCRL Endgame Tablebases Forum...
Parent - By Arkansaw (***) Date 2008-08-08 02:10
really? so how much ram is really needed?
Parent - - By Hamlet (**) Date 2008-08-08 09:39
He don't know what he is talking about.
I don't know amount needed with rybka3, but it is more than  I have (4cores, 4giga) probably because of Vas' strage implementation. Hiarch uses probably something between 1-2 giga.
I don't have all tablebases yet, but will post some numbers when I have finished my downloads.

regards,
hamlet
Parent - By M ANSARI (*****) Date 2008-08-09 12:30
Wow ... 128GB SSD for less than $500 ... 4 of these on a RAID 0 array must be nice!  now that has to be a good deal.  I am also a fan of EGTB's ... but then again I have no clue what their real value of ELO strength are.  Surely it must be more than the 1 ELO gain that Vas says.  At least it feels a hell of a lot more than that when your 8 core cannot improve on a +5.09 evaluation due to that.  I think that Vas just thinks there is so much more ELO to be gained by applying the same time allocation in improving search or evaluation ... and after seeing R3 I will tend to agree with him.  Apparently engines CAN get much stronger yet and a wall has not been reached with performance gain through evaluation and search.  Once a wall has been reached I think more emphasis will be placed on EGTB's and proper usage of them through Rybka.  It would be great if Rybka could at least use the very small footprint of bitbases to steer it into a win.  Who knows ... maybe the solution to 7 piece perfect play is a combination of 7 piece bitbases merged with some sort of Monte Carlo implementation.
Up Topic Rybka Support & Discussion / Rybka Discussion / Rybka 3 & tablebases & amount of memory needed

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill