Winboard Forum

Current rules of ChessWar say :

"Default main hashtables size : 128Mb"

The hardware is a Dual Opteron 252 4Gb running on WinXP Pro x64.

The time control is 40/40 for group A, 40/30 for group B and 40/20 for the other groups.

Do you think the default hashtables size shoud be increased ?

Olivier

Hi Olivier,

The hash size seems ok. What I'm going to suggest is concerning the time control.

Would it be possible to replace the time control into an incremental one (Fischer time control)?

For group A: 40m + 40s, for group B: 30m + 30s, and for the other: 20m + 20s.

I think this time control is more logical compared to X moves in Y minutes.

Edsel Apostol

Edsel Apostol wrote:Hi Olivier,

The hash size seems ok. What I'm going to suggest is concerning the time control.

Would it be possible to replace the time control into an incremental one (Fischer time control)?

For group A: 40m + 40s, for group B: 30m + 30s, and for the other: 20m + 20s.

I think this time control is more logical compared to X moves in Y minutes.

Edsel Apostol

Hi Edsel !

Thanks for the suggestion

I do like incremental time control, and I use it at OpenWar. Unfortunately it happens that some engines (old ones that won't be fixed) don't support it correctly.

First editions of ChessWar were with increment, and I got many issues. My aim is to have all engines in ChessWar, I don't want to forfeit any of them; this is why I switched to 40/x time control.

Olivier

Hi Olivier,

I always enjoy your tournaments! Keep on playing!

"Default main hashtables size : 128Mb"
This seems sufficient.

What is your maximum allowable size for pawn hash?
(If you make my engine's pawn hash too big, it slows down!)

What is your maximum allowable size for eval hash?
(My engine does not have this, but too big slows things down!)

Is there a size limit for:
main hash + pawn hash + eval hash

Who determines size of pawn hash and eval hash?

Ron

Ron Murawski wrote:Hi Olivier,

I always enjoy your tournaments! Keep on playing!

"Default main hashtables size : 128Mb"
This seems sufficient.

What is your maximum allowable size for pawn hash?
(If you make my engine's pawn hash too big, it slows down!)

What is your maximum allowable size for eval hash?
(My engine does not have this, but too big slows things down!)

Is there a size limit for:
main hash + pawn hash + eval hash

Who determines size of pawn hash and eval hash?

Ron

Hi Ron !

When engines have some more hash settings, I usually set them accordingly to the instructions given by the readme file (for instance : 4 or 8 or 16Mb for pawnhash). Horizon's pawnhash is set to 16Mb here actually.

Besides, some engines are using other main hashsizes : 96Mb for example.

Let's say it is OK for me if the engine does not take more tnan 200Mb in total (including tablebases usage).

Olivier

I think there should be a limit on total memory footprint only. It is up to the engine to decide how it will use the available space: main hash, pawn hash, EGTB cache, eval cache, move-generator tables, material tables, program code...

H.G.Muller wrote:I think there should be a limit on total memory footprint only. It is up to the engine to decide how it will use the available space: main hash, pawn hash, EGTB cache, eval cache, move-generator tables, material tables, program code...

Agreed.

Then the unwritten limit is around 200Mb at the moment.

Olivier

Well, that might have consequences for uMax!

uMax is one of the engines that has non-standard hash size, as it uses 12-byte, rather than 16-byte entries. So it is running now with 96MB hash, to respect the 128MB limit.

But main hash is the only table uMax uses, it has no Pawn hash, no table bases, etc. The main hash could be doubled to 192MB, and as the code itself is much less than 8MB, this would still fit within the 200MB limit.

So uMax could be run with argument 24 to double its hash size.

H.G.Muller wrote:Well, that might have consequences for uMax!

uMax is one of the engines that has non-standard hash size, as it uses 12-byte, rather than 16-byte entries. So it is running now with 96MB hash, to respect the 128MB limit.

But main hash is the only table uMax uses, it has no Pawn hash, no table bases, etc. The main hash could be doubled to 192MB, and as the code itself is much less than 8MB, this would still fit within the 200MB limit.

So uMax could be run with argument 24 to double its hash size.

Yes you are certainly right here !

I'll make the rules more clear, and uMax will be given more main hash.

Let's add some engines have settable main hash, but use as well other tables which size is hard coded.

I guess I'll have to check every engine for next edition of ChessWar

Olivier

hi all -

with server systems becoming so incredibly powerful...w/ fast processors, multiple CPUs, multiple cores, loads of RAM, etc., the average nodes per second that can be realized is growing. 128 MB may have been sufficient in the past, but i believe more memory is needed today. my personal belief is that more is better.

i have recently implemented a function in xyclOps that optimizes the size of hash table for the specific system it is running on. i believe crafty created this idea (called adaptive hash), and has been using it for some time now (since v. 19 i think). the concern is: on fast systems, with long time controls, the hash table could fill, with possible negative performance consequences. it seems that this could be especially true if the chess engine uses some sort of dynamic move time allocation, i.e. providing more time to search a difficult or critical position.

if hash table entry size = 16 bytes (typical)
if nps = 700,000 (many programs today run much faster than this)
and if time control = 40 moves/40 minutes (1 minute per move for simplicity)

then
60 secs x 700,000 nps = 42,000,000 nodes per move
and
42,000,000 nodes x 16 bytes = 672,000,000 bytes = 656,250 KB = 640 MB

Robert Hyatt recommends 1 GB hash for crafty at time controls of 1 minute per move or more. of course, crafty is achieving something like 6,000,000 nps (often more) … a substantially higher rate than most engines.

if interested, here’s a link to Dr. Hyatt’s post in another forum:
http://64.68.157.89/forum/viewtopic.php?t=18490

my final thought here: if the server being utilized has abundant RAM (like most do), why not allocate if for engine use? as far as I know, for chess engine tournaments, at any given time only 2 engines are playing simultaneously. thus if a server has 4 GB RAM, one could allocate 1024 MB to each engine and still have 2 GB left.

best regards-

Norm Schmidt
www.xyclOps.com

Olivier Deville wrote:

Ron Murawski wrote:Hi Olivier,

I always enjoy your tournaments! Keep on playing!

"Default main hashtables size : 128Mb"
This seems sufficient.

What is your maximum allowable size for pawn hash?
(If you make my engine's pawn hash too big, it slows down!)

What is your maximum allowable size for eval hash?
(My engine does not have this, but too big slows things down!)

Is there a size limit for:
main hash + pawn hash + eval hash

Who determines size of pawn hash and eval hash?

Ron

Hi Ron !

When engines have some more hash settings, I usually set them accordingly to the instructions given by the readme file (for instance : 4 or 8 or 16Mb for pawnhash). Horizon's pawnhash is set to 16Mb here actually.

Olivier

Thank you for your answer, Olivier.

The current version of Horizon has an upper limit of 256MB main hash. Based on other comments in this thread, I will increase the maximum allowable size in the next version. (I don't know when that might be. I have not worked on the engine in several months. I've been working on other things.)

I will also downsize the maximum size of the pawnhash setting to 4MB. I originally set the maximum size limit to 16MB for testing purposes and determined that setting the value larger than 4MB was counter-productive. (I think this information is in the readme.txt file.)

Best regards,
Ron

Hi all

Of course, having 4Gb RAM and letting the engines use 400Mb only is kind of a waste of space. If some authors think their engine will be stronger with more hash, I would not mind allowing it.

I suggest the following maximum memory usage for each engine :

1200Mb for group A (40/40)
600Mb for group B (40/30)
300Mb for the rest (40/20)

An author can always request to use less memory if he thinks too much hash will harm his engine.

Don't forget I am the end user and know nothing about programming If my proposal makes no sense, just tell me.

Olivier

In order to get more answers, I have started this thread at CCC as well : http://www.talkchess.com/forum/viewtopi ... 87&t=22037

Olivier

Thanks to all for the feedback on the Winboard Forum and CCC, on the chat and by e-mail.

Here is my new proposal :

In order to not discourage authors who are working on "not-so-strong" engines, lower divisions will keep using 128Mb of main hash, plus some more Mb for pawn hash and eval hash when settable, plus 32Mb hash for egtb/egbb cache when implemented. Some engines use other standards for main hash (eg 96Mb). I'll try to set them up in the fairest way possible.

The engines that play in upper divisions will be given more memory.

We'll start with the upcoming A group by giving the engines 1024Mb of main hash. We could do the following for ChessWar XIII :

- Group A (40/40) : 1024Mb of main hash
- Group B (40/30) : 512Mb of main hash
- Groups C and D (40/20) : 256Mb of main hash
- Groups E and F, Promotion (40/20) : 128Mb of main hash

+ some more Mb for the other tables when settable

I have one question : does it make sense to give more hash than the usual 32Mb for the egtb/egbb cache ? (64Mb, 128Mb, 256Mb...)

Olivier

Olivier Deville wrote:Thanks to all for the feedback on the Winboard Forum and CCC, on the chat and by e-mail.

Here is my new proposal :

In order to not discourage authors who are working on "not-so-strong" engines, lower divisions will keep using 128Mb of main hash, plus some more Mb for pawn hash and eval hash when settable, plus 32Mb hash for egtb/egbb cache when implemented. Some engines use other standards for main hash (eg 96Mb). I'll try to set them up in the fairest way possible.

The engines that play in upper divisions will be given more memory.

We'll start with the upcoming A group by giving the engines 1024Mb of main hash. We could do the following for ChessWar XIII :

- Group A (40/40) : 1024Mb of main hash
- Group B (40/30) : 512Mb of main hash
- Groups C and D (40/20) : 256Mb of main hash
- Groups E and F, Promotion (40/20) : 128Mb of main hash

+ some more Mb for the other tables when settable

I have one question : does it make sense to give more hash than the usual 32Mb for the egtb/egbb cache ? (64Mb, 128Mb, 256Mb...)

Olivier

Hi Olivier,

If the egtb hash is set very large then, the first time the egtbs are accessed, the engine will slow down noticeably as the large memory cache fills up from disk. An engine's search depth can lose several ply while this happens. Once the egtb cache is full there will be a noticeable speedup because most subsequent accesses will be from main memory, not from disk.

For very very small egtb settings it is the opposite: the first access is not nearly as long but subsequent accesses take longer as small portions of the disk files get transferred into memory as needed.

I would guess that smaller egtb settings [ie: 1 to 4 MB] would yield fairer tournament outcomes because no very long delays get introduced for any of the engines and search depth will remain somewhat stable. But many engines have a fixed-size egtb cache of unknown size. [My own engine was once fixed at 2 MB.] It's very difficult to determine fairness! I am interested in other people's opinions which size is 'best'.

You say: "plus some more Mb for pawn hash and eval hash when settable"
I think you need numbers. Here are your choices:

Fix maximum limits for each type of hash OR
Combine main hash plus other hashes to add up to a maximum number.

Ron

Ron Murawski wrote:

Olivier Deville wrote:Thanks to all for the feedback on the Winboard Forum and CCC, on the chat and by e-mail.

Here is my new proposal :

In order to not discourage authors who are working on "not-so-strong" engines, lower divisions will keep using 128Mb of main hash, plus some more Mb for pawn hash and eval hash when settable, plus 32Mb hash for egtb/egbb cache when implemented. Some engines use other standards for main hash (eg 96Mb). I'll try to set them up in the fairest way possible.

The engines that play in upper divisions will be given more memory.

We'll start with the upcoming A group by giving the engines 1024Mb of main hash. We could do the following for ChessWar XIII :

- Group A (40/40) : 1024Mb of main hash
- Group B (40/30) : 512Mb of main hash
- Groups C and D (40/20) : 256Mb of main hash
- Groups E and F, Promotion (40/20) : 128Mb of main hash

+ some more Mb for the other tables when settable

I have one question : does it make sense to give more hash than the usual 32Mb for the egtb/egbb cache ? (64Mb, 128Mb, 256Mb...)

Olivier

Hi Olivier,

If the egtb hash is set very large then, the first time the egtbs are accessed, the engine will slow down noticeably as the large memory cache fills up from disk. An engine's search depth can lose several ply while this happens. Once the egtb cache is full there will be a noticeable speedup because most subsequent accesses will be from main memory, not from disk.

For very very small egtb settings it is the opposite: the first access is not nearly as long but subsequent accesses take longer as small portions of the disk files get transferred into memory as needed.

I would guess that smaller egtb settings [ie: 1 to 4 MB] would yield fairer tournament outcomes because no very long delays get introduced for any of the engines and search depth will remain somewhat stable. But many engines have a fixed-size egtb cache of unknown size. [My own engine was once fixed at 2 MB.] It's very difficult to determine fairness! I am interested in other people's opinions which size is 'best'.

You say: "plus some more Mb for pawn hash and eval hash when settable"
I think you need numbers. Here are your choices:

Fix maximum limits for each type of hash OR
Combine main hash plus other hashes to add up to a maximum number.

Ron

Hi Ron

You are right, of course. I gave these numbers because many engines only support powers of 2 as a main hashsize.

Fairness is a difficult matter, and all engines will be checked one by one.

Actually most authors don't seem to care much, and a few Mb more or less don't seem to make such a difference.

Olivier

A decision has been made, please read here : http://www.open-aurec.com/wbforum/viewt ... 986#185986

Olivier