Hashtables size in ChessWar

[hgm]

ChessWar is a league based tournament on equal hardware. Not every engine is capable of larger hash table sizes. This gives an unfair advantage to those that can use higher than 128mb.

This is pure nonsense. If a program is not capable of having a hash size larger than 128MB, it is a fault of the program. Any advantage programs derive from supporting larger hash is their own merit, and thus fair.

By your logic, the hash size could also not be set to 128MB, because there exist programs that only support hash sizes upto 64MB or 32MB. And they would have an 'unfair' disadvantage already.

In fact, the hash size should be set to zero for all, as micro-Max 1.6 does not support hash tables at all. So other engines would have an unfair advantage w.r.t. it if they were allowed to use hash tables. And null move pruning should be forbidden too, as the unfair advantage that gives over engines that do not implement it is even larger than that of a hash table...

[Christopher Conkie]

ChessWar is a league based tournament on equal hardware. Not every engine is capable of larger hash table sizes. This gives an unfair advantage to those that can use higher than 128mb.

This is pure nonsense.

Don't hold back. Say what you feel.....

If a program is not capable of having a hash size larger than 128MB, it is a fault of the program.

Being a lifeform as they are......

Any advantage programs derive from supporting larger hash is their own merit, and thus fair.

Any steroids that can improve performance are ok so long as you don't develop anger management problems as well. Olympics here I come....

By your logic, the hash size could also not be set to 128MB, because there exist programs that only support hash sizes upto 64MB or 32MB. And they would have an 'unfair' disadvantage already.

So we make it worse... Good idea.....

In fact, the hash size should be set to zero for all, as micro-Max 1.6 does not support hash tables at all. So other engines would have an unfair advantage w.r.t. it if they were allowed to use hash tables.

Yes if they dont conform to FirstChess standards its just not cricket.....

And null move pruning should be forbidden too, as the unfair advantage that gives over engines that do not implement it is even larger than that of a hash table...

I agree....we should just make a tombola and pull out the winner.... thats much more fair......

[hgm]

Any steroids that can improve performance are ok so long as you don't develop anger management problems as well. Olympics here I come....

I think this only pertains to overclocking. I already proposed that for the next Dutch Open in Leiden we should subject the winners to doping tests, making the computers submit a sample of their flow of cooling air, for temperature analysis, to check if it is not outside reasonable bounds. When the temperature exceeds factory specifications, they should be disqualified.

The managing board of the Dutch Computer-Chess Association is still debating my proposal.

[kranium]

i agree completely with H.G. Muller here.

Chris, what you're suggesting sounds rather archaic, that all engines in the same tournamnet be limited (handicapped) to the lowest common denominator.

i.e. if an particular engine doesn't support a large optimized opening book, and is at a disadvantage, should opening books be disallowed?

if an engine is programmed so that it cannot take advantage of extra memory which has been made available to it , then perhaps it should be reprogrammed. (i.e. in this case, changing the hash size from a constant to a variable should not be difficult).

as long as both engines have the same amount of total memory made available to them, shouldn't it be up to them how (or if) it's used?

for ex: one engine might choose to allocate 32 MB pawn hash table, 64 MB main hash table, and 32 MB nalimov cache, for a total of 128 MB
while another engine (which does not support nalimov and only uses 1 hash table), allocates 128 MB to the main hash table.

seems entirely fair to me...

regards,

Norm Schmidt
www.xyclOps.com

[hgm]

We could of course organize a Computer-Chess Paralympics, with separate competitions for null-move-challenged engines or hash-table-challenged engines...

[Christopher Conkie]

We could of course organize a Computer-Chess Paralympics, with separate competitions for null-move-challenged engines or hash-table-challenged engines...

You know what i meant. The lower engines the one that start out with next to nothing implemented. Are we to price them out of the market of competition? Ok a compromise. Why don't we suggest that the hash is staggered. Lower in the low divisions and higher in the higher divisions?

Christopher

[hgm]

I don't see much of a problem there. Engines without hash tables will be beaten by engines with hash tables. Because they play like an idiot in the end-game. Restricting the size of the hash table to 128MB, or even 32MB will not change that.

In fact hash-table size only marginally affects engine strength. I measured in perft that to halve the search time, you need a 4096 times larger hash table. So it seems to scale as the 12th root. Doubling the hash size would thus increase the speed by 2^(1/12) = 1.06, i.e. make it 6% faster. And that would also make it about 6 Elo stronger, as each factor 2 brings about 70 Elo points.

[Olivier Deville]

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]

A decision has been made, please read here : http://www.talkchess.com/forum/viewtopi ... 35&t=22114

Olivier

[bob]

The TLB is of fixed size, and each different physical memory page referenced needs one TLB entry. It is pretty easy to blow out the TLB badly, which slows down _all_ memory references, which can greatly outweigh the advantage of a larger hash.

In general, more hash is better, always. But if there are architectural details that make larger memory sizes more expensive in terms of latency, then this statement is no longer true...

After you increase the hash size beyond some point, the actual NPS will start to drop because of this issue...