Hashtables size in ChessWar

[bob]

I don't follow. This tends to favor a program that does not hash in the q-search, such as Crafty. If a program does hash in the q-search, it needs a significantly larger trans/ref table to compensate for the additional positions that get stored...

So is the goal of the authors supposed to be to have the smallest possible footprint in memory, or develop the best algorithms they can? Assuming 1024mb for hash limit is hardly unrealistic today when I haven't seen a machine advertised with less than 1 gig of RAM in a year or two now...

[bob]

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

This is overlooking one important point. The programming to support 128MB of hash is absolutely identical with the programming to support 2048MB of hash. Probing is identical. Malloc() to grab the memory is identical. So I don't see why an author would set some arbitrarily small max hash size when the programming to support a larger size is no different, except to allow you to enter a number > 128MB.

So this makes absolutely no sense to me. yes there are issues where some programs (such as mine) use a power of 2 HT size, while others use a divide/modulo operator and allow any size HT. But that is a programming decision we make and I'm willing to use 96MB to my opponent's 128MB if 128MB is the max allowed on a machine...

[kranium]

i agree

what about poor old Joe? ... the unfortunate author of a new engine in group F who understands the benefits of a substantial hash size, and amazingly knows how to allocate more than 128 MB hash for his engine! Alas, the poor sole, he must suffer the indignity of reducing and limiting his engine's memory usage. why you ask? well, because there's an engine in the group whose author doesn't know how to allocate more than 8MB (or maybe chose 8 as the max hash size because it's his favorite number!?).
too bad, Joe might have done well too, he certainly was on the right track ...

freedom and equality for engines!
make the same amount of memory available to all!

Norm Schmidt
www.xyclOps.com

[Olivier Deville]

Hi Bob

Some authors of engines that will play group A explicitely told me more than 128Mb of main hash would weaken their engine.

This is why you are given the choice. I'll keep 128Mb (or the closest value for engines that don't use powers of 2) as the default main hash. But if you want Crafty to use more RAM than the crippled default settings, just tell me what to put in crafty.rc and it will be done.

I may extend this rule to all groups for next edition, we'll see.

Olivier

[bob]

Hi Bob

Some authors of engines that will play group A explicitely told me more than 128Mb of main hash would weaken their engine.

This is why you are given the choice. I'll keep 128Mb (or the closest value for engines that don't use powers of 2) as the default main hash. But if you want Crafty to use more RAM than the crippled default settings, just tell me what to put in crafty.rc and it will be done.

I may extend this rule to all groups for next edition, we'll see.

Olivier

The ideal solution for crafty is this:

adaptive xxx 64MB 1024MB 32MB 128MB

xxx should be the typical NPS crafty searches on that hardware. Assuming your GUI uses the "level" command. Then Crafty will automatically adjust the hash size between 64MB and 1024MB depending on the estimated time per move and the number of nodes that will search. Ditto for pawn hash being set between 32MB and 128MB also based on number of nodes being searched.

The calculation is roughly equal to time_per_move * NPS... A hash entry is 16 bytes, so this sets the optimal hash size to time * NPS / 16 positions, or time * NPS bytes... It is then forced to fit inside the min/max window given on the adaptive command. But for simplicity you can just estimate the time per move on average, multiply by the NPS and set the hash size to that many bytes...

I have tested on my core2 duo laptop and 1024MB does not slow crafty down whatsoever in terms of NPS, and it definitely helps in terms of time-to-depth assuming the time limit is long enough. But if it isn't, with 1024 on my hardware there is zero penalty so it is a safe number. You can try Crafty with 128mb (96mb actually), 256mb, 512mb and 1024mb to see if the NPS suffers any on your hardware, but it probably should not except on older hardware with limited TLB size...

[Olivier Deville]

Hi Bob

Some authors of engines that will play group A explicitely told me more than 128Mb of main hash would weaken their engine.

This is why you are given the choice. I'll keep 128Mb (or the closest value for engines that don't use powers of 2) as the default main hash. But if you want Crafty to use more RAM than the crippled default settings, just tell me what to put in crafty.rc and it will be done.

I may extend this rule to all groups for next edition, we'll see.

Olivier

The ideal solution for crafty is this:

adaptive xxx 64MB 1024MB 32MB 128MB

xxx should be the typical NPS crafty searches on that hardware. Assuming your GUI uses the "level" command. Then Crafty will automatically adjust the hash size between 64MB and 1024MB depending on the estimated time per move and the number of nodes that will search. Ditto for pawn hash being set between 32MB and 128MB also based on number of nodes being searched.

The calculation is roughly equal to time_per_move * NPS... A hash entry is 16 bytes, so this sets the optimal hash size to time * NPS / 16 positions, or time * NPS bytes... It is then forced to fit inside the min/max window given on the adaptive command. But for simplicity you can just estimate the time per move on average, multiply by the NPS and set the hash size to that many bytes...

I have tested on my core2 duo laptop and 1024MB does not slow crafty down whatsoever in terms of NPS, and it definitely helps in terms of time-to-depth assuming the time limit is long enough. But if it isn't, with 1024 on my hardware there is zero penalty so it is a safe number. You can try Crafty with 128mb (96mb actually), 256mb, 512mb and 1024mb to see if the NPS suffers any on your hardware, but it probably should not except on older hardware with limited TLB size...

Many thanks Bob !

Crafty 2.21_x64 bench says :

Raw nodes per second : 2222691.151623

Winboard is the GUI, thus it will send the level command.

I'll try adaptive hash for Crafty in the next test.

Olivier

[bob]

Hi Bob

Some authors of engines that will play group A explicitely told me more than 128Mb of main hash would weaken their engine.

This is why you are given the choice. I'll keep 128Mb (or the closest value for engines that don't use powers of 2) as the default main hash. But if you want Crafty to use more RAM than the crippled default settings, just tell me what to put in crafty.rc and it will be done.

I may extend this rule to all groups for next edition, we'll see.

Olivier

The ideal solution for crafty is this:

adaptive xxx 64MB 1024MB 32MB 128MB

xxx should be the typical NPS crafty searches on that hardware. Assuming your GUI uses the "level" command. Then Crafty will automatically adjust the hash size between 64MB and 1024MB depending on the estimated time per move and the number of nodes that will search. Ditto for pawn hash being set between 32MB and 128MB also based on number of nodes being searched.

The calculation is roughly equal to time_per_move * NPS... A hash entry is 16 bytes, so this sets the optimal hash size to time * NPS / 16 positions, or time * NPS bytes... It is then forced to fit inside the min/max window given on the adaptive command. But for simplicity you can just estimate the time per move on average, multiply by the NPS and set the hash size to that many bytes...

I have tested on my core2 duo laptop and 1024MB does not slow crafty down whatsoever in terms of NPS, and it definitely helps in terms of time-to-depth assuming the time limit is long enough. But if it isn't, with 1024 on my hardware there is zero penalty so it is a safe number. You can try Crafty with 128mb (96mb actually), 256mb, 512mb and 1024mb to see if the NPS suffers any on your hardware, but it probably should not except on older hardware with limited TLB size...

Many thanks Bob !

Crafty 2.21_x64 bench says :

Raw nodes per second : 2222691.151623

Winboard is the GUI, thus it will send the level command.

I'll try adaptive hash for Crafty in the next test.

Olivier

The thing I like about the adaptive command is that you choose the min memory you want to use, and the max you want to allow, then let the program choose the optimal value and then force it to lie within those extremes. And it is platform independent. I will probably one day create a "crafty.bm" file and the first time you run it, let it run a 5 second benchmark and then add the NPS to the crafty.bm file so that the NPS can be removed from the adaptive command to make this truly platform independent. Every so often, crafty could re-run the benchmark to be sure you didn't upgrade the hardware and cause the hash size to become too small...

[Olivier Deville]

Hi Bob

Some authors of engines that will play group A explicitely told me more than 128Mb of main hash would weaken their engine.

This is why you are given the choice. I'll keep 128Mb (or the closest value for engines that don't use powers of 2) as the default main hash. But if you want Crafty to use more RAM than the crippled default settings, just tell me what to put in crafty.rc and it will be done.

I may extend this rule to all groups for next edition, we'll see.

Olivier

The ideal solution for crafty is this:

adaptive xxx 64MB 1024MB 32MB 128MB

xxx should be the typical NPS crafty searches on that hardware. Assuming your GUI uses the "level" command. Then Crafty will automatically adjust the hash size between 64MB and 1024MB depending on the estimated time per move and the number of nodes that will search. Ditto for pawn hash being set between 32MB and 128MB also based on number of nodes being searched.

The calculation is roughly equal to time_per_move * NPS... A hash entry is 16 bytes, so this sets the optimal hash size to time * NPS / 16 positions, or time * NPS bytes... It is then forced to fit inside the min/max window given on the adaptive command. But for simplicity you can just estimate the time per move on average, multiply by the NPS and set the hash size to that many bytes...

I have tested on my core2 duo laptop and 1024MB does not slow crafty down whatsoever in terms of NPS, and it definitely helps in terms of time-to-depth assuming the time limit is long enough. But if it isn't, with 1024 on my hardware there is zero penalty so it is a safe number. You can try Crafty with 128mb (96mb actually), 256mb, 512mb and 1024mb to see if the NPS suffers any on your hardware, but it probably should not except on older hardware with limited TLB size...

Many thanks Bob !

Crafty 2.21_x64 bench says :

Raw nodes per second : 2222691.151623

Winboard is the GUI, thus it will send the level command.

I'll try adaptive hash for Crafty in the next test.

Olivier

The thing I like about the adaptive command is that you choose the min memory you want to use, and the max you want to allow, then let the program choose the optimal value and then force it to lie within those extremes. And it is platform independent. I will probably one day create a "crafty.bm" file and the first time you run it, let it run a 5 second benchmark and then add the NPS to the crafty.bm file so that the NPS can be removed from the adaptive command to make this truly platform independent. Every so often, crafty could re-run the benchmark to be sure you didn't upgrade the hardware and cause the hash size to become too small...

For some reason Crafty exits. I am sending you the debug.

Olivier

[bob]

there was a bug in adaptive calculations previously, but I thought it had been fixed. Now I am not sure... It doesn't crash on my computer here, but it also does not set the right hash size either. So for the moment, set it normally and I will try to fix and release a new version that works right. Somehow the fix got lost, not sure when...

[bob]

I looked at the code and it looks to be ok. I didn't notice the "level 40 5 0" which says "40 moves in 5 minutes, then 40 moves in 5 minutes". That is about 7 seconds per move, which using your numbers is 14.4M nodes searched, which wants about 1M hash positions or 16MB. No clue why it is crashing. Can you start Crafty in a normal console window and give it those two commands (the adaptive and level commands in that order) and tell me what happens???