Tablebases and the death of one of my harddisks ...

[Robert Allgeuer]

I expected it to happen some time: The harddisk used in YABRL for the tablebases has failed one and a half weeks ago.
This disk (a 40GB Maxtor 5T040H4) ran around the clock and - as most engines in YABRL do use tablebases - was heavily used. It has survived this "torture" for about 2 years (2 * 365 * 24 = about 17000 hours) before dying.
In the same computer an identical Maxtor disk of identical age is hosting the operating system and according to SMART it is still quite healthy. So in this case harddisk usage has probably made a difference and shortened life.

Robert

[Mike Scheidl]

The problem is: For a "standardised comparable" test configuration, you will probably want to let use ALL 5-piece tbs. (if not all available tbs. even). In that case, HD usage may be reducable by larger tbs. cache sizes. I use 32 MB tbs. cache.

For a "normal practise," I always recommend all 3+4-piece tbs., but only all Rook + X versus Rook (incl QR-R) 5-piece tbs. These are by far more important than all the other 5-piece tbs. So, HD accesses and the terrible slowdown effect will be reduced. I hope, that with this configuration (32 MB tbs. cache), the tbs. will indeed produce a performance gain most of the time, and also limit the HD. accesses to an reasonable amount.

[Norm Pollock]

The 5-man tbs are a real problem when certain engines start using them with as many as 14 pieces still on the board. In this situation, how could this help the evaluation? It cannot because it is so inefficient. Unfortunately I do not have a listing of those engines.

I use a second hard drive (30G) for my most of my chess stuff and especially for the tbs. I use all the 3-4-5 tbs.

One more thing. Fruit 2.1 which is arguably the best chess engine available to the general public, does not use tbs. So maybe tbs are not that important after all.

[Robert Allgeuer]

Some time ago I ran rather comprehensive tests of EGTBs, with Yace and Crafty. The result was in both cases that 5 piece tablebases give absolutely zero gain in strength. As I remember there were also similar tests by others with similar results.
This point is - as you point out - also reinforced by the fact that various of the top engines (ProDeo, Fruit, Ktulu, Little Goliath, Spike, SlowChess) do not use tablebases.

Robert

[Norm Pollock]

I have only used a single processor for chess engines but I always wondered how machines with two processors running a chess game between two engines handle tbs on a single disk drive. Do both engines access the tbs at the same time?

-Norm

[Robert Allgeuer]

I have only used a single processor for chess engines but I always wondered how machines with two processors running a chess game between two engines handle tbs on a single disk drive. Do both engines access the tbs at the same time?

-Norm

I have not come across this issue either. But if one has ponder turned on there will be contention for the tablebase accesses. If this shall be avoided one would need two sets of TBs stored on two seperate, but identical physical harddisks connected to two seperate controllers of equal speed.
Furthermore the GUI would have to allow to specify different tablebase paths for white and black. I have never checked whether any existing GUI supports this...

Robert

[Norm Pollock]

I have only used a single processor for chess engines but I always wondered how machines with two processors running a chess game between two engines handle tbs on a single disk drive. Do both engines access the tbs at the same time?

-Norm

I have not come across this issue either. But if one has ponder turned on there will be contention for the tablebase accesses. If this shall be avoided one would need two sets of TBs stored on two seperate, but identical physical harddisks connected to two seperate controllers of equal speed.
Furthermore the GUI would have to allow to specify different tablebase paths for white and black. I have never checked whether any existing GUI supports this...

Robert

Robert,

You are correct in assuming that I meant "ponder on". It will make a lot of noise when both engines are accessing separate tablebases on 2 separate hard drives.

The only alternative to 2 drives that I can imagine is for the engine on the move to have primary access to the tablebases, and the engine pondering to only have secondary access if the engine on the move is not accessing the tbs.

Or, just don't give the pondering engine tablebase access.

-Norm

[Robert Allgeuer]

I would bet that currently nobody takes care of this problem and accepts the slowdown due to concurrent access to the tablebases in such a configuration. On the other hand not too many currently test in such a configuration, I think.

Robert

[Norm Pollock]

I would bet that currently nobody takes care of this problem and accepts the slowdown due to concurrent access to the tablebases in such a configuration. On the other hand not too many currently test in such a configuration, I think.

Robert

I think many more will test in such a configuration once the dual core processors are out and become popular.

[Robert Allgeuer]

And then probably Arena and other GUIs should be extended to allow seperate tablebase directories to be used for black and white, which at least solves the problem for UCI engines.
Otherwise a tourney director would have to maintain two seperate installations for each engine: ENGINE_W using tablebase directory 1 and ENGINE_B using tablebase directory 2. And pairing would have to be accordingly, ENGINE_W plays the white games and ENGINE_B the black ones. Not overly simple ...

Robert

[Norm Pollock]

The problem is: For a "standardised comparable" test configuration, you will probably want to let use ALL 5-piece tbs. (if not all available tbs. even). In that case, HD usage may be reducable by larger tbs. cache sizes. I use 32 MB tbs. cache.

For a "normal practise," I always recommend all 3+4-piece tbs., but only all Rook + X versus Rook (incl QR-R) 5-piece tbs. These are by far more important than all the other 5-piece tbs. So, HD accesses and the terrible slowdown effect will be reduced. I hope, that with this configuration (32 MB tbs. cache), the tbs. will indeed produce a performance gain most of the time, and also limit the HD. accesses to an reasonable amount.

Mike,

What do you think about the 6-man tbs? Following your logic above I suppose you would only recommend R+X - R+Y. Not too many engines support 6 man tbs, and I wonder if they are supported by UCI guis. And, of course, how useful do you think they are after factoring in their overhead?

-Norm